#ubuntu-release 2010-08-10
<ttx> Do we have 10.04.1 daily ISOs built to test, before we have an official "candidate" ?
<cody-somerville> Is there an archive admin around who can help me with LP #613284 ?
<ubot4> Launchpad bug 613284 in ubuntu "Sync live-build 2.0~a22-1 (universe) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,Confirmed] https://launchpad.net/bugs/613284
<slangasek> cody-somerville: done
<cody-somerville> slangasek, thanks
<highvoltage> hi! oem-install in edubuntu has been unavailable in lucid
<highvoltage> stgraber suggested a merge that will fix it
<highvoltage> the branch is debian-cd in ubuntu-cdimage
<highvoltage> if someone could approve it that would be great!
#ubuntu-release 2010-08-11
<ttx> mvo: do you plan to run upgrade tests for 10.04.1 ?
<mvo> ttx: they are running http://people.canonical.com/~mvo/automatic-upgrade-testing/2010-08-11-03:03:01-lts/
<ttx> mvo: ok thanks
<mvo> ttx: to be fair it says FAIL currently even for minor stuff like config file prompts (that is the reason why the dapper-hardy-lucid ones fail iirc
<mvo> ttx: if you need something specific to be tested (a speicifc set of packages etc) just let me know, I can arrange that easily
<ttx> mvo: ok, thanks
<ScottK> FYI with today being the last day before feature freeze: python-defaults needs to be updated to add python2.7 as a supported version (as well as a few related packages).  I am not planning on doing it and neither doko nor barry seem to be around.
<lamont> who's release god today?
<lamont> I happened to notice what day it is, and plan to get nmap uploaded tonight, unless that will get me hurt
<ogra> lamont, https://wiki.ubuntu.com/ArchiveAdministration cjwatson or kirkland (the former is on vac. i think)
<lamont> he is
<ScottK> ogra: Archive Admin != Release Manager.
<nigelb> \lastlog nigelbabu
<nigelb> grr
<newz2000> this may sound premature, but do we yet know what the URLs will be for the *beta* ISOs?
#ubuntu-release 2010-08-12
<bdrung> are we already in FF or will it come later this day?
<Laney> bdrung: not until the announcement is sent afaik
<ttx> bdrung: quick !
<bdrung> ttx: i wanted to process https://code.launchpad.net/~clint-fewbar/ubuntu/maverick/moin/merge-1.9.3-1/+merge/32400 but dholbach had already looked at it
<ttx> bdrung: I think we should push it
<ttx> bdrung: spamaps won't be around in time to fix the minor issue that is still remaining before FF
<ttx> bdrung: are you on it ?
<bdrung> ttx: no, you can take it
<ttx> bdrung: ok, I'm on it then
<ttx> hmm, as soon as LP lets me get it :)
<bdrung> ttx: can i ask you to look at another sponsor request?
<ttx> bdrung: well, i'm stuck right now by LP, but I can queue it
<bdrung> ttx: bug #378240
<ubot4> bdrung: Bug 378240 on http://launchpad.net/bugs/378240 is private
<bdrung> ubot4: you fail
<ubot4> Factoid 'you fail' not found
<bdrung> ubot4: you failed again :)
<ubot4> bdrung: Error: I am only a bot, please don't think I'm intelligent :)
<ttx> bdrung: if I have time this morning (and LP unfreezes) I'll take it, no promise though
<bdrung> ttx: thx. i don't want to touch this one because i am not a ubuntu-server member
<Daviey> Has FF kicked in?
<ara> Daviey, I don't think so, I haven't seen an email sent to ubuntu-announce
<Daviey> ara: Yeah.. *boggles* :)
 * Daviey tries to fire out 2 extra merges
<sistpoty|work> are we frozen yet? anyone to send out a reminder to u-d-a?
<ogra> sistpoty|work, shhh, dont ask, they might have forgotten about it :)
<sistpoty|work> ogra: they==release team? (damn, looks like I'm guilty then as well :P)
<sistpoty|work> cjwatson, iulian, Riddell, ScottK, slangasek: how's that for a start: http://paste.ubuntu.com/476917/ ?
<Riddell> don't we have a release manager yet?
<Riddell> skat: hello
<sistpoty|work> Riddell: oh, do we?
<Riddell> if we do, she's being very quiet :)
<sistpoty|work> heh
 * sistpoty|work must get up to date wrt. Ubuntu again :)
<ScottK> sistpoty|work: I think it's good, but I think new needs a modifier like essential or important or something.
<sistpoty|work> thanks ScottK, added: http://paste.ubuntu.com/476935/
<ScottK> sistpoty|work: Works for me.
 * sistpoty|work waits a little bit for comments from others before sending (or maybe skat would like to take over that task?)
<lamont> btw, new tarballs for maverick.  built just over 27 hours ago
 * robbiew prepares FF announcement
<robbiew> tick tock...tick tock
<sistpoty|work> thanks robbiew
 * robbiew figured people needed some additional time with LP going down for maintenance and all
 * ScottK needed extra time because he forgot to check if some packages needed sync.
<bdrung> robbiew: isn't motu-release merged into ubuntu-release?
<robbiew> bdrung: doh...cut-and-paste error
<bdrung> muhaha
 * robbiew quickly sends email correction
<bdrung> robbiew: another question: i want to get vlc 1.1.3 into maverick (1.1.2 -> 1.1.3). it's mainly a bug fix upstream release. do a need a FFe?
<robbiew> bdrung: assuming it doesn't introduce new features and/or ABI/API changes, and only bug fixes, then I don't think so
<bdrung> robbiew: no ABI changes
<ScottK> It's OK then.
<ScottK> robbiew: I don't think Kate Stewart <kate.stewart@ubuntu.com> is going to work.
<robbiew> ScottK: bah...habit
<robbiew> sometimes there are forwards setup...but you might be right
<ScottK> She shouldn't have an ubuntu.com address unless she's an Ubuntu member.
<robbiew> ScottK: ack
<lamont> Keybuk: so about 2.18....  thoughts for maverick?  or are we waiting for N?
<lamont> meh.  dinner.  afk
<cody-somerville> Has 10.04.1 been released yet?
<ScottK> cody-somerville: No.
<cody-somerville> Can someone please ping me when it is? I need to create a snapshot for OEM Services.
<charlie-tca> cody-somerville: delayed until the 17th now
<cody-somerville> ah, ok
<nigelb> some day robbiew will write a "proper" freeze email :p
<ScottK> nigelb: Some day, we'll get a proper freeze email because he's been able to delegate the writing.
<nigelb> ScottK: that too.  The last time, we got an email about Karmic being in DIF instead of maverick.
<nigelb> I wonder if the new RM has started easing in :)
<nigelb> (I know robbie is busy with loads of stuff probably)
<ScottK> She was here earlier, but didn't speak.
<robbiew> she is at LinuxCon this week...fulfilling a speaking commitment she made before joining
<robbiew> nigelb:....and yes, someday you will get a proper freeze email...and it probably won't be from me :P
<nigelb> robbiew: Heh.  :)
<robbiew> I should point out...that I've done a fairly good job with the release meeting agenda...and that is a PITA to put together ;)
<nigelb> yes, you have.  Its only with the copy & paste that you end up sending corrections :D
<robbiew> yep....being lazy gets me every time!
<nigelb> heh :)
<wgrant> cjwatson: So, bug #241129 should be fixed now.
<ubot4`> Launchpad bug 241129 in soyuz "'queue override' command scales at O(n^2) with the number of packages on the commandline (affects: 1) (dups: 1) (heat: 14)" [Medium,Fix released] https://launchpad.net/bugs/241129
<slangasek> sweet \o/
<slangasek> robbiew, cjwatson: I've reviewed the upstart SRU; bug #554172 is a pretty major bug and I think now that a fix is available, we should get it in for .1 (even at the risk of delaying .1 further) - do you agree?
<ubot4`> Launchpad bug 554172 in upstart (Ubuntu Maverick) (and 5 other projects) "system services not starting at boot (affects: 191) (dups: 15) (heat: 854)" [Medium,Fix released] https://launchpad.net/bugs/554172
<robbiew> slangasek: hmmm
<robbiew> I'm not a BIG fan of delaying .1...yet again
<slangasek> N.B.: "at the risk of", but I think this should be a pretty quick SRU verification in practice
<slangasek> the change is self-contained and only modifies the error handling path
<robbiew> right
<robbiew> I'm a strong +1 on getting it into .1
<robbiew> but we've postponed .1 twice already...and there's always "one more bug"...so if we could squeeze it in for next Tuesday, then sure
<slangasek> I can accept it now, and it'll be in the .1 ISO candidates which include -proposed in their build
<slangasek> then only if we /don't/ publish the upstart SRU do we have a risk of delay
<robbiew> ok
<slangasek> accepting, then
#ubuntu-release 2010-08-13
 * robbiew closes his eyes and holds on
<slangasek> hmm, something changed post-release to cause lilo-installer to fall out of the alternate ISO
<slangasek> er, no - cause it to be /added/ to
<slangasek> ... nope, I was right the first time
<slangasek> ah, cjwatson made that change, alrighty then :)
<slangasek> dropping langpacks from the daily-live ISO for .1; the package growth since 10.04 has all been in either the kernel or in firefox/xulrunner, both of which are infeasible to recover size from in the time remaining :(
<Laney> are we having freeze exception delegates as per previous cycles?
<ara> do you guys know when are we going to see the first 10.04.1 candidate images in the ISO tracker?
<Riddell> ara: so far our release manager hasn't appeared so I wouldn't hold your breath
<mathiaz> slangasek: hey - in which order are you planning to spin the 10.04.1 isos?
<doko> barry: as I understand it, py27 was delayed by the release team (but ScottK might know more)
 * ScottK looks at robbiew.
 * ScottK just mentioned it needed deciding since it wasn't done before FF.
 * robbiew thinks we need to postpone it
<robbiew> as it's not done
<robbiew> and FF is here
 * barry is sad
<barry> right, we talked about it before i went on vacation that the remaining handful of ftbfs could be fixed before beta
<barry> (in main)
<barry> and that i was committed to working on those and the universe failures
<doko> sorry, I didn't track this too close this week
<robbiew> barry: there was some concern from seb128 about the work it would take
<robbiew> also on the rebuilds it would cause
<barry> it would probably be ~500 packages in main+uni
<barry> iirc
<doko> robbiew: we'll have an arm rebuild of some packages anyway at some point
<robbiew> so what do we lose by doing it early in 11.04
<barry> robbiew: probably not much practically speaking.  i wonder though if it's possible/feasible to make the python2.7 package available even if not supported (i.e. no changes to python-support, python-central, python-defaults).  does that give us much?
<robbiew> doko? ScottK? ^
<barry> i do know that folks would like py27 in maverick, but i suppose waiting 6months won't kill them ;)
<doko> robbiew, barry: that I did last Sunday. it's in main (at least I pushed it there)
<ScottK> python2.7 is in Maverick.  It's just not supported for modules and extensions.
<barry> doko: cool
<ScottK> No issue with that.
<ScottK> Although it can drop to Universe if it won't be supported.
<doko> what we should do is to explicitely add support in distribute, python-profiler and python-std-lib-extension
<slangasek> mathiaz: in a very fast order, why? :)
<ScottK> Then it would need to be in Main, but that shouldn't be a problem.
<barry> doko: what do we need to add there?
<doko> support for 2.7
<doko> basically update the mav packages from my ppa
<barry> doko: is that just merging in your changes, or more work?  if the latter, how can i help given that i can't upload them?
<doko> barry: let me look at it tomorrow, before I say something wrong
<barry> doko: okay :).  i'm happy to do any and all grunt work to make this happen.  if we can get those changes in then at least people can more easily start w/2.7 and i can adjust my ppas to work out the remaining build failures.  i'll contact the appropriate mailing lists and give a status + solicit help and will work with upstreams to get fixes in, and updates in debian.  then early in 11.04 we can flip the switch.  that'll give us the rest
<barry> of this cycle and all next cycle to make this a very solid offering
<robbiew> thanks barry :)
<robbiew> I'm sure ScottK is just a little bit happier inside now, too
<robbiew> lol
<ScottK> Now barry will have lots of free time to fix other stuff.
<barry> robbiew: np!
<barry> ScottK: this is how you repay me for making you happy? :)
<ScottK> barry: Sure.  Plenty to do and you claim you're looking for more experience.
<barry> ScottK: thank you sir, can i have another? :)
<robbiew> lol
 * barry is glad someone gets the reference
<mathiaz> slangasek: I'm working on the test plan for the -server isos
<mathiaz> slangasek: Having an idea about when the -server isos would be available would help
<barry> doko, ScottK, robbiew thanks
<robbiew> barry: no...thank you ;)
<slangasek> mathiaz: ETA 20 minutes
<mathiaz> slangasek: \o/
<mathiaz> slangasek: this is awesome!
<bdrung> which archive admin rejected python-box2d and why?
<Daviey> bdrung, Looks like it's still in the new queue to me.
<bdrung> Daviey: i got two mail: "python-box2d_2.0.2+svn20100109.244-1_source.changes rejected" and "sugar-physics-activity_5+dfsg-1_source.changes rejected"
<Daviey> bdrung, Interesting.. The source package was rejected, but binary i386 and sparc are still in NEW.
<bdrung> Daviey: why can a binary be build if the source isn't accepted?
<Daviey> That is a very good point.. I an intrigued as you are!
<ScottK> bdrung: If it got uploaded more than once, it would likely get accepted once and rejected once.
<bdrung> ScottK: ok, then the question is: how does it get uploaded twice?
<ScottK> It's not rare for someone to upload a new package, realize it has a mistake, and then upload it again.
<ScottK> Or two sponsors collide and they both upload it.
<ScottK> I've seen both happen.
<bdrung> ScottK: but i uploaded them days ago
<bdrung> ok, it was only a half day ago.
<bdrung> ScottK: shouldn't it get rejected immediately?
<ScottK> Not if it's still in New.
<bdrung> instead of getting a New message.
<bdrung> so they are in New, chapter closed
<ScottK> It might not make sense, but that's how it works at the moment.
<bdrung> the reject message should be more verbose
 * bdrung has to do some network analysis. bbl
<wgrant> ScottK, bdrung: bug #62976
<ubot4`> Launchpad bug 62976 in soyuz "Soyuz should not allow duplicated packages in NEW/UNAPPROVED queue" [High,Triaged] https://launchpad.net/bugs/62976
<bdrung> wow, that's a low bug number
<bdrung> wgrant: thanks for this link
<wgrant> We only have one two-digit bug left in LP :(
<bdrung> wgrant: which one?
<wgrant> bug #25
<ubot4`> Launchpad bug 25 in rosetta "Allow discussion/commenting on translations (affects: 12) (dups: 3) (heat: 82)" [Low,Triaged] https://launchpad.net/bugs/25
<slangasek> ubuntu desktop, alternate posted for 10.04.1
#ubuntu-release 2011-08-08
<lamont> ScottK: what did you want smacked around?
<ScottK> lamont: adare.
<ScottK> It's been dead for quite awhile.
<ScottK> Running with only one powerpc buildd is not a happy thing.
<lamont> ScottK: fwiw, #canonical-sysadmins (this server) will get you whoever the victim-of-the-shift is, and they could have fixed this while I was out
<micahg> lamont: was weekend w/no one around :)
<lamont> micahg: this is sadness.
<lamont> OTOH, asiapacific came online a few hours ago
<lamont> and I'm not really here for another 9 hours
<micahg> yep, I tried to ask wgrant about it, but didn't get an answer
 * lamont goes to stab the build on ross in the face
<lamont> and back to family stuff.  was just playing catchup on scrollback
<wgrant> micahg: Sorry, am unwell and not fully here today.
<micahg> wgrant: no worries, feel better
<ScottK> lamont: Thanks.  I always forget about that one.
<lamont> micahg: wgrant wouldn't be able to do anything, #canonical-sysadmin would
<wgrant> lamont: Well, most of the time the builders recover after a while and flipping them back on in LP works.
<wgrant> Perhaps that wasn't the case here.
<lamont> wgrant: except when the buildd has a left over build-XXX tree, and that build tries to happen again... that gets you 8002
<wgrant> Hah
<micahg> lamont: also, wgrant usually comes on before the asia pacific people officially start
<lamont> he never sleeps that I've seen
<ScottK> slangasek (or any other archive admin that's around): Would you please accept prison.  I've reviewed it and it's fine, but due to Bug #822485 I can't actually accept packages right now.
<ubot4> Launchpad bug 822485 in launchpad "Repeated timeout attempting to accept a since source package (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/822485
<ScottK> since/single (fixed in the bug)
<infinity> ScottK: Done.
<ScottK> infinity: Thanks.
<micahg> would it be possible to get a sync run sometime Monday to reduce the list of merges/RCbugs/transitions needed/software upgrades? this will help to make sure that the ones that need new versions still can be worked on before Thursday
<ev> could someone please NEW libtimezonemap? A new ubiquity upload is blocking on it.
<doko> ev: done, building
<ev> doko: thanks a bunch!
<mvo> will there be a archive admin that can binary-NEW libapt-pkg4.11 today? slangasek is archive admin of hte day with a "?" according to the wiki
<mvo> if so, I will upload a new apt soonish
<infinity> mvo: I can get you covered today.
<mvo> infinity: that would be great, libapt-pkg4.11 and libapt-inst1.3 needs binary-NEW love today
<infinity> mvo: Well, upload fast and get them built before I run off for breakfast and other shenanigans.
<mvo> infinity: already done, should be waiting in the queue already actually
<infinity> mvo: Oh, indeed.  Still building on arm and ppc though, I'll wait.
<mvo> ok
<infinity> mvo: Looks like armel's still grinding on docs, and my waffle date is here.  I'll get to it when I get back, but if you're impatient, I'm sure you can find another AA between now and then. ;)
<mvo> thanks infinity, I'm impatient, but I think in thise case I will just wait :)
<cjwatson> [5~3[6~[6~  I expect I can; if I'm notmistaken the old apt is caussing d-i to fail to build, and the new apt fixes it
<cjwatson> gah, lag, hopefully you can pick out the real text from that mess
<mvo> yeah, all good
<doko> that must be some kind of waffle date ...
<ogra_> heh
<micahg> cjwatson: or infinity, would it be possible to get a sync run today or tomorrow?  there are ~100 requests waiting (20 from me:))
<mvo> looks like all the apt builds are finished now
<cjwatson> mvo: done
<cjwatson> skaet: https://wiki.ubuntu.com/ArchiveAdministration#langpack_SRUs is the main archive admin documentation I see at a quick glance; I'm quite sure there's more elsewhere about language pack handling in general though
<cjwatson> accepting the natty-proposed language packs now
<skaet> cjwatson, thanks.  will follow up with pitti and dpm, too.
<skaet> ScottK,  only bug I'm seeing in http://iso.qa.ubuntu.com/qatracker/test/6219, is bug 702283.  Its been on the list since A2,  and is in https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview/Alpha3.   Is this it?  or is there another I'm not seeing?
<ubot4> Launchpad bug 702283 in usb-creator (Ubuntu) "usb-creator doesn't create EFI-bootable USB sticks (affects: 8) (dups: 1) (heat: 51)" [Medium,Confirmed] https://launchpad.net/bugs/702283
<ScottK> skaet: When I mentioned that it was Bug #821870, which hadn't been marked a dupe yet.  I guess it's covered.
<ubot4> Launchpad bug 821870 in usb-creator (Ubuntu) "Cannot write EFI boot loader to USB Disk (dup-of: 702283)" [Undecided,Confirmed] https://launchpad.net/bugs/821870
<ubot4> Launchpad bug 702283 in usb-creator (Ubuntu) "usb-creator doesn't create EFI-bootable USB sticks (affects: 8) (dups: 1) (heat: 51)" [Medium,Confirmed] https://launchpad.net/bugs/702283
<ScottK> skaet: Did you also see the comment about adding the Kubuntu Desktop powerpc to the released images?
<ScottK> Once that's done, the cron job for Kubuntu images can be reenabled.
<skaet> ScottK,  no missed the comment on powerpc images.
<ScottK> skaet: OK.  I added a warning about the limited testing it got to the Kubuntu specific tech overview.  I'd like to see it released.
<skaet> ScottK,  ok,  will look into getting it pushed out.
<ScottK> Great.  Thanks.
<skaet> and then turn back on the kubuntu dailes.
<skaet> dailies, even. :)
<NCommander> ScottK: do we have both kubuntu alternates and live for PPC, or just live?
<ScottK> NCommander: We have both, but the alternate is completely untested.
<ScottK> (which is why I don't want to release it)
<NCommander> ScottK: k, will just release the live
<ScottK> NCommander: Thanks.
<NCommander> ScottK: publishing now, will ping once mirror sync kicks
<NCommander> argh
<NCommander> Crud, the publish script mightbe broken
<NCommander> ScottK: ping, do you have people available to test torrents? When I ran the publish script for powerpc only; it rebuilt and clobbered the old torrents for kubuntu for A3
<ScottK> I can check.
<NCommander> ScottK: I haven't published yet, as I was trying to figure out if we're screwed, but I think we're ok
<ScottK> OK.  I asked for a volunteer to check the torrents.
<NCommander> ScottK: I'm just going to kick the mirror script and pray for the best, there isn't much I can do to put the torrents back the way it was
<ScottK> NCommander: OK.  I'll let you know if I hear anything.
<NCommander> ScottK: thanks, I'll make sure this bug gets fixed :-/
<ScottK> Great.
<NCommander> ScottK: http://cdimages.ubuntu.com/kubuntu/releases/oneiric/alpha-3/
<NCommander> ScottK: if nothing else, I'll turn the crontabs back on
<ScottK> NCommander: That's it.  Please turn them back on.
<ScottK> Thanks.
<NCommander> ScottK: crontab reinstalled
<ScottK> And off we go ...
<skaet> :)
#ubuntu-release 2011-08-09
 * micahg_ thanks cjwatson profusely for the sync run
<cjwatson> micahg_: it's incomplete, but I cut the list down by 83, at least
<micahg_> that's great, thanks, it was just getting hard to tell what still needs to be done w/the open requests
<Laney> yeah, thanks a lot
<Laney> almost at the end of having to do sync runs, eh? :-)
<GrueMaster> Are we not making daily-live cds for x86/amd64?
 * GrueMaster hasn't seen one since prior to A3.
<charlie-tca> yes, but they failed today
<charlie-tca> They built yesterday - http://cdimages.ubuntu.com/daily-live/20110808/
<charlie-tca> oh, wait, you are ARM, aren't you?
<GrueMaster> I keep x86 & amd64 images on the side.
<GrueMaster> Usefull for verifying failures.
<charlie-tca> Ubuntu had them yesterday. Something went wrong today and the server refused to build them today
<GrueMaster> Ah.  Hadn't seen them in the failure emails.
<charlie-tca> Lots of 404 errors today
<GrueMaster> Now to figure out why my mirror script keeps making broken links.
<charlie-tca> They don't let me have answers very often. Usually I just get to ask questions. ;)
<charlie-tca> s/have/give
<slangasek> today's build failures are a bit odd... seems to involve failing to find the livefs downloads?
<charlie-tca> yes, something like that
<ScottK> Yesterday was, IIRC, apt turning the world upside down.
#ubuntu-release 2011-08-10
<slangasek> ScottK: well, this was for today, and I don't know why the builds would fail when they did on account of apt - the failure is well after the actual livefs build + downloading
<ScottK> Any thoughts on why the latest Kubuntu powerpc image failed due to unity, gnome-session, and ubuntuone-client-gnome not being installable?
<ScottK> I've looked through the germinate output and can't find it.
<slangasek> from what I see, ubuntuone-client-gnome has been superseded by ubuntuone-client?
<slangasek> (based on what I've just seen in a dist-upgrade here)
<ScottK> I've no idea how any of those even got on a Kubuntu CD, let alone fail an ISO build.
<slangasek> heh, good point
<charlie-tca> Desktop images failed again today; same errors as yesterday
<charlie-tca> 2011-08-10 10:59:16 ERROR 404: Not Found.
<charlie-tca> for many items at end of build
<slangasek> cjwatson: do you have any idea what's up with the live builds failing to find live filesystems on the local disk?  I don't see any pertinent changes to cdimage
<cjwatson> no, it was like that when I got back from holiday ...
<cjwatson> I'll see if I can dig into it today then
<slangasek> cool, thanks
<ara> skaet, feature freeze is today eod, or tomorrow eod?
<ara> meaning, are we safe tomorrow to upload new features?
<iulian> ara: The latter I reckon but I'm not 100% sure.
<iulian> It's definitely not today.
<slangasek> freezes officially take effect at 0000UTC on the indicated day
<slangasek> so you have about 7 hours left
<ara> thanks slangasek
<micahg> slangasek: I thought skaet said 18:00 UTC tomorrow
<micahg> http://irclogs.ubuntu.com/2011/08/05/%23ubuntu-meeting.html#t15:02
<skaet> slangasek,  freeze time was set for tomorrow at 18:00 UTC for last couple of weeks.   More lands earlier though the better ;)
<slangasek> skaet: ah, well, bonus development time for everyone then ;)
<skaet> slangasek, yup.  :)
#ubuntu-release 2011-08-11
<jamespage> good morning - please could the NEW binary package for maven-hpi-pluginÂ be accepted into oneiric - then jenkins will build! - thanks
<ogra_> so seeing that the image builds fail since days because ubuntuone-client-gnome doesnt exist anymore in the archive, could we unseed it so we get working images again ?
<ogra_> hummm....
<ogra_> and why doesnt it affect x86 and amd64 at all
<ogra_> cjwatson, i'm not sure i'm reading it wrong, but this log http://people.canonical.com/~ubuntu-archive/livefs-build-logs/oneiric/ubuntu/current/livecd-20110811.1-i386.out looks seriously strange, it seems to install a good bunch of things from universe and i see things like thunar and mythbuntu packages being installed
<ogra_> hmm, looking closer i even see multiverse packages
<jibel> ogra_, it affects alternate too, I filed bug 824418
<ubot4> Launchpad bug 824418 in ubuntuone-client (Ubuntu Oneiric) (and 3 other projects) "oneiric alternate fails to install: ubuntu-desktop Recommends ubuntuone-client-gnome which is not installable (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/824418
<ogra_> jibel, well, thats not as worrying as the x86 buildlog ... that one seems totally confused
<cjwatson> will look in a bit, I have FF work ahead of this
<ogra_> on ubuntu live filesyswtems universe and multiverse are usually disabled
<cjwatson> yes, I assume somebody has broken livecd-rootfs
<ogra_> jibel, i will unseed the pffending package temporary (since my FF work is blocked by unbuildable images atm)
<ogra_> cjwatson, well, i only added bits to the armel subarch check, that shouldnt affect x86 at all
 * ogra_ re-checks his commits
<cjwatson> or perhaps live-build I guess
<cjwatson> though that seems less likely
<cjwatson> I will concede that this is pretty odd ...
<ogra_> http://paste.ubuntu.com/663319/ is all i added
<ogra_> and thats all under the armel subarch check, i dont see how it could affect x86
<ogra_> there is one followup commit by infinity but that doesnt seem to have been uploaded yet (and it doesnt touch the components)
<cjwatson> quite so
<ogra_> and intrestingly all ports arches do look ok (modulo the build failure due to ubuntuone-client-gnome)
<ogra_> (i also think if my change was the offending one we wouldnt see multiverse in the log ... i dont enable it)
<cjwatson> yeah, it doesn't look related to your change.
<cjwatson> this broke between the 20110808.1 and 20110809 builds
<ogra_> oh, that predates all my work actually
<cjwatson> yep
<cjwatson> no live-build changes then either
<ogra_> yeah
<ogra_> was antimony upgraded  ... so  that an external app could have changed ?
<cjwatson> livefs builds don't happen on antimony
<cjwatson> they run in a chroot of the relevant release on dedicated buildds
<cjwatson> the communication channel with antimony is very narrow
<ogra_> well, they are triggered by debian-cd
<cjwatson> I am aware
<cjwatson> (actually they're not, but that's terminology)
<cjwatson> I'd rather investigate most plausible things first.
<ogra_> right, what i mean is that cdimage and debian-cd use bits and pieces from antimony to assemble the cmdlines
<ogra_> and i dont see a single commit either in debian-cd, the seeds or cdimage around the timeframe it broke
<cjwatson> debian-cd is not itself involved *at all* in livefs building
<cjwatson> it consumes the output, that's all
<ogra_> yeah, only post processing, i know ...
<cjwatson> seeds are irrelevant
<cjwatson> I agree there's nothing obvious in cdimage
<cjwatson> and if the antimony side was broken, I expect that we would see even more obvious signs in the log
<cjwatson> I really don't think this can be a problem on antimony, honestly
<cjwatson> I am not going to investigate that
<ogra_> true
<cjwatson> (unless I exhaust everything else)
<cjwatson> lamont: are you around?  I could use some debugging on the livefs buildds (if you aren't around, I'll just upload livecd-rootfs with debugging code in it, but would prefer not to)
<lamont> cjwatson: here
<lamont> please state the nature of the disfunction we are debugging
<cjwatson> lamont: universe and multiverse showing up in Ubuntu livefs build logs, and I can't see whwy
<lamont> interesting
<cjwatson> lamont: could I have 'set -x' in /usr/share/livecd-rootfs/live-build/auto/config in cardamom's oneiric chroot, temporarily?
<lamont> i386 being representative?
<cjwatson> yep
<ogra_> there is more, it also doesnt seem to proceed the seeds correctly, i.e. unity-2d doesnt show up at all
<cjwatson> ogra_: yeah, but one at a time.
<ogra_> sure :)
<cjwatson> standard debugging practice, debug the first chronological failure first
<cjwatson> otherwise you waste time
 * ogra_ keeps quiet and lets you do the work then :)
<cjwatson> jamespage: maven-hpi-plugin binaries accepted
<lamont> livecd-rootfs isn't installed in the oneiric-live chroot...
<ogra_> wow
<ev> hah
<lamont> live-build is
<jamespage> cjwatson: thankyou!
<lamont> the only auto/config in live-build: /usr/share/live/build/examples/auto/config
<cjwatson> lamont: how about in build-oneiric-live/chroot-oneiric?
<lamont> that's where I'm looking
<cjwatson> huh
<cjwatson> can you tell when livecd-rootfs was removed?
<cjwatson> I wonder if it got taken out by the apt transition
<lamont> cjwatson: paste.ubuntu.com/663341
<cjwatson> haha
<lamont> well played, apt
<cjwatson> so python-apt was temporarily broken and we lost
<cjwatson> I'm going to put a bit of extra safety into BuildLiveCD
<lamont> +1
<cjwatson> in the meantime, can we have livecd-rootfs back in all the chroots?
<lamont> well... ok
<lamont> what about germinate?
<cjwatson> livecd-rootfs will bring it all back
<cjwatson> this will certainly explain seed processing problems, and it will also explain why the livefs outputs weren't in a place where antimony could grab them
<lamont> haha.
<ogra_> heh
<lamont> so... did the arm livecd builds fail, or work?
<ogra_> arm is fine
<ogra_> i got proper error logs
<lamont> livecd-rootfs restored on i386,amd64,powerpc
<lamont> arm had it already
<cjwatson> livecd-rootfs 2.22 uploaded with the relevant fix
<ogra_> ppc looked fine too actually
<ogra_> regarding the logs at least
<lamont> cjwatson: spare me the pain and point me at a copy of BuildLiveCD to blat out?
<cjwatson> I was just going to RT it
<lamont> sure
<lamont> vanguard this week, yay me.
<lamont> attach the file in the RT?
<cjwatson> I did :)
<cjwatson> https://rt.admin.canonical.com/Ticket/Display.html?id=47318
<lamont> maybe I should sleep in more. :(
<lamont> thanks
<cjwatson> diff should be http://paste.ubuntu.com/663350/
<lamont> +27000
<lamont> It is currently 15th in the queue of tickets assigned to the Vanguard.
<lamont> and with that, afk for a few
<cjwatson> thanks for the help
 * cjwatson kicks off Ubuntu desktop livefs builds
<cjwatson> could somebody process ntfs-3g through NEW?
<cjwatson> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/oneiric/ubuntu/20110811.2/livecd-20110811.2-i386.out  more sensible failure now
<ogra_> yep, that looks like the usual error
<ogra_> i just uploaded a new meta that works around this
<cjwatson> ok
<charlie-tca> Can you kick new xubuntu builds too for the desktop? No desktop images have built for Ubuntu or Xubuntu since monday
<cjwatson> done
<ogra_> The following packages have unmet dependencies:
<ogra_>  ubuntuone-client-gnome : Depends: ubuntuone-client (= 1.7.0-0ubuntu2) but 1.7.1-0ubuntu1 is to be installed
<ogra_> RAAAH !
 * ogra_ checks rdepends 
<cjwatson> remember it installs the task, give it an hour or two to settle
<ogra_> well, meta was uploaded 3h ago
<ogra_> i missed and had to wait two publisher runs
<ogra_> err, 2h ago
<ScottK> That same package is causing Kubuntu PPC builds to fail.
 * ScottK has no idea how it even gets involved.
<ogra_> well, on ubuntu it was seeded
<cjwatson> ScottK: that's very likely due to the general insanity fixed this morning
<cjwatson> I wouldn't worry about *that* part
<ogra_> i dropped it now, but something still seems to keep it there, i might have been to careful with my seed change
<ScottK> cjwatson: Good news.  Thanks.
<cjwatson> its Task field does seem to be gone
<cjwatson> which build log were you quoting?
<ogra_> 11.1 from ac100
<ogra_> ubuntu-ac100
<ogra_> i'll wait 20min and try again
<cjwatson> ah, ubuntuone-client-gnome still has Task: ubuntu-desktop on armel
<cjwatson> perhaps because ubuntu-meta was slower to build
<ogra_> how can that be if i dropped it from desktop ?
<ogra_> ah
<cjwatson> because it has to wait for ... right
<ogra_> i thought there is a secret arch related seed i dont know about ;)
<cjwatson> ubuntu-desktop is in the desktop seed so its dependencies are pulled into the task
<ogra_> right
<ogra_> ports has the new ubuntu-desktop package already though
<ogra_> i specifically waited until it showed up in the pool, i would expect the same publisher run to clean the task, isnt that the case ?
<cjwatson> yes, but it just missed the last publisher run, and task changes take an extra publisher run to settle.
<ogra_> ah
<cjwatson> because there is hysteresis in the way that cron.publish-ftpmaster and cron.germinate are currently arranged
<cjwatson> the germinate run at the end of a publisher run feeds into the next publisher run
<ogra_> right, i wasnt aware of that bit
<cjwatson> it's a long-standing bug
<cjwatson> (and the next publisher run has to have some work to do)
<cjwatson> it'll be OK after the current publisher run completes, so for safety, say 30m
<ogra_> k
 * ogra_ crosses fingers that nobody uploads unity or nux now :)
<skaet> ogra_, cjwatson, ScottK, slangasek, pitti - heh,  on that note,  just a head's up that didrocks may miss the FF by a couple of hours due to the fact he's traveling today, and may not have enough connectivity en-route to get it uploaded.  He's expecting to finish uploads as soon as he's home.
<ScottK> skaet: I'd suggest then moving the milestone back a few hours to match his requirements so others can keep working too.
<cjwatson> given that I'm trying to test ubuntu-defaults-image with this syslinux-themes-ubuntu packaging, I'm not averse to a stable archive either just now
 * cjwatson goes for a walk while it sits and churns
<ogra_> skaet, then i pray that his train is late ... to get  the ac100 images working i need at least one output from the live builder, implementing it is a matter of 1-3h of work but to get to that point i already spend the third day fighting the archive skews
<cjwatson> can't you build a reduced livefs for testing purposes?
<cjwatson> say, just ubuntu-standard.  that would be enough to do the scripting work
<cjwatson> you could start that right away.
<ogra_> standard is recognized as a flavour ?
<ogra_> i tried -core yesterday but that isnt really designed to carry a kernel etc
 * ogra_ checks
<cjwatson> you could use ubuntu-server (= minimal + standard), and then just mangle things into place
<cjwatson> or base which is like ubuntu-server without the preinstalled pool stuff
<ogra_> that will take longer than desktop to build with the new pool we ship on server
<cjwatson> base then
<ogra_> i'll try base
<skaet> cjwatson, ogra_,   to keep the churn down (and improve the testing I suspect ;) ) do we want to ask him to do the drop tomorrow instead?    That would give us an overnight set of builds before unity/nux hits,  and give some breathing room on that dimension of churn?
<cjwatson> and it shouldn't be about build time, it should be about probability of failure
<cjwatson> skaet: I don't have an opinion on that
<ogra_> skaet, well, i expect to get a livefs today one way or the other
<ogra_> i dont want to block anyone, i'm trying with ubuntu-base now
<skaet> cjwatson, ogra_ - ok.
<skaet> hmm....
<skaet> ScottK, will get more details from didrocks and then look at adding a few more hours on.
<seb128> skaet, didrocks is travelling still
<seb128> skaet, he's on holiday starting tomorrow evening though, it might be better to still have him around for a day after the upload
<skaet> seb128,  agreed.   As soon as he's in connectivity range,  will get a revised ETA from him.
<seb128> skaet, i.e if he uploads unity today and get issues he can fix those tomorrow, if he uploads tomorrow and that breaks it's likely nobody will be around during the w.e from dx to sort it and then somebody else from desktop will have to figure what didrocks and dx did
<seb128> (yeah, I don't like uploads on fridays :p)
 * ogra_ doesnt like uploads at all :P
<Laney> why not just grant an exception for this upload?
<ogra_> Laney, because that would delay the upload until after didiers vacation i guess
<Laney> I mean I don't get why we need to delay indefinitely
<ogra_> ??
<ogra_> because didrocks is traveling and cant upload ... there is no other delay
<Laney> delay the freeze
<Laney> if it's just for one specific thing, just say that it is alright to do that
<ogra_> it os delayed ?
<ogra_> *is
<Laney> that was the discussion
<ogra_> its not 18:00UTC yet :)
<ogra_> we can tell at 18:01 if it is i guess ;)
<charlie-tca> I don't know if anyone knows it, the respins all failed on the desktop images
<charlie-tca> Ubuntu has errors like
<charlie-tca> W: Unable to read /srv/cdimage.ubuntu.com/scratch/ubuntu/daily-live/apt/oneiric-amd64/apt/preferences.d/ - FileExists (2: No such file or directory)
<charlie-tca> and xubuntu has hash sum mismatches
<cjwatson> that's a warning not an error
<cjwatson> I'm afraid I don't have time to push images up the hill right now
<charlie-tca> Sorry, I guess the error really is
<charlie-tca> mv: cannot stat `/srv/cdimage.ubuntu.com/scratch/ubuntu/daily-live/tmp/oneiric-amd64/CD1/casper/filesystem.kernel-generic': No such file or directory
<charlie-tca> make: *** [/srv/cdimage.ubuntu.com/scratch/ubuntu/daily-live/tmp/oneiric-amd64/bootable-stamp] Error 1
<charlie-tca> Okay, I will wait to request them again
<ogra_> ah, but thats alternate, 11.1 of xubuntu live built fine
<charlie-tca> no
<charlie-tca> actually, daily-live 11.1 failed to build
<charlie-tca> That was Ubuntu error
<ogra_> oh, sorry, i'm looking at the livefs build
<charlie-tca> Xubuntu shows W: Failed to fetch file:/srv/cdimage.ubuntu.com/ftp-universe/dists/oneiric/main/binary-amd64/Packages.bz2  Hash Sum mismatch
<charlie-tca> many times for different files through the log
<charlie-tca> Oh, warnings again
<cjwatson> that one probably does add up to a real error.
<cjwatson> but there's nothing I can do short of repeatedly retrying it.
<cjwatson> (which as I said I'm not going to do now, perhaps somebody else can)
<charlie-tca> Yeah, we can wait, since it will probably eventually fail for the same thing Ubuntu is failing for.
<ogra_> right, its apt-update thats failing according to the log
<ogra_> hmm, more reports about hash sum mistmatches with the archive
<skaet> ScottK,  have connected with didrocks.  Consider the Feature Freeze time adjusted to 2100 UTC.
<ScottK> skaet: I think you should write to u-d-a.
<ScottK> Thanks.
<skaet> ScottK,  makes sense,  will do.
<ScottK> Great.
<tseliot> pitti: I'm uploading fglrx-updates, nvidia-$flavour-updates and nvidia-settings-updates right now
<cjwatson> I have now changed the driver for all stable releases to ubuntu-release, and verified that this does not regress the ability of a core-dev to target tasks to a stable release
<cjwatson> skaet: my external memory in the form of bug 174375 and https://bugs.launchpad.net/launchpad/+bug/703002/comments/3 says that the next step is to add ~canonical-qa to ~ubuntu-release so that they can manage bug nominations without being in ubuntu-drivers.  Are you OK with me making that change?
<ubot4> Launchpad bug 174375 in ubuntu-community (and 1 other project) "Distribution drivers permissions may need redesign (affects: 2) (dups: 1) (heat: 7)" [Medium,Confirmed] https://launchpad.net/bugs/174375
<ubot4> cjwatson: Error: Bug #703002 is private.
 * skaet looking
<tseliot> pitti: are you still around?
<tseliot> probably not..
<tseliot> cjwatson, slangasek: can either of you approve my sources in NEW, please? nvidia-graphics-drivers-96-updates nvidia-graphics-drivers-173-updates, nvidia-graphics-drivers-updates, nvidia-settings-updates and fglrx-installer-updates
<skaet> cjwatson,  go ahead,  it seems the most pragmatic approach for now.   Lets see how it works out, and revisit if there are issues later.
<slangasek> tseliot: having a look, sure
<tseliot> slangasek: thanks
 * ScottK wonders how we are doing to document "Members of ubuntu-release who are not members of the release team"?
<cjwatson> is it an issue?  I'm having a hard time imagining canonical-qa people having the time to do bogus freeze exception approvals
<cjwatson> (I know this is a sledgehammer, BTW - it's just a smaller sledgehammer than the awful mess that is the ubuntu-drivers team)
<slangasek> tseliot: what's the logic of having these as separate source packages from the existing non-"updates" ones?
<tseliot> slangasek: so, according to what we decided at UDS, we're going to keep the -updates flavours updated during the stable release cycle, until the next Ubuntu release
<ScottK> As a general practice I think that the actual teams in LP should match the roles/authority in the project.
<tseliot> this way users can decide whether to stick with the stable drivers or to try updated drivers
<slangasek> tseliot: ah, ok - so these will receive SRUs updating them to the new upstream version within each driver series?
<ScottK> I agree it's unlikely to be problematic, but it's not ideal.
<slangasek> (tseliot: and that's been preapproved by the SRU team?)
<tseliot> slangasek: we were thinking more of a permanent ack on the -updates packages, as for the module backports, I guess
<slangasek> tseliot: right, but that's still an SRU, preapproved or otherwise
<tseliot> slangasek: so, yes that's the plan. pitti can confirm that
<tseliot> slangasek: ah, ok, I've never deal with one myself
<tseliot> a preapproved one, that is
<slangasek> tseliot: right, provided that pitti has said this is ok, it's ok with me - accepting
<tseliot> slangasek: thanks a lot
<tseliot> slangasek: so now we'll have to approve the binaries too, right?
<slangasek> tseliot: yes; that's trivial
<tseliot> when they're built, that is
<tseliot> ok
<tseliot> slangasek: have you approved fglrx-installer-updates too?
<slangasek> tseliot: now I have :)
<tseliot> slangasek: excellent. Thanks again, Steve
<lamont> ScottK: is your benevolence going to extend to bind9 getting in this evening?  (gonna be killing a couple hours in an airport later today, plus airtime, I expect I'll be wanting to upload bind9 and postfix around 2330 pacific)
<ScottK> lamont: I think it sounds reasonable.
<ScottK> I wouldn't want to be the one that had to explain to kees where there was no DNSSEC in oneiric.
<lamont> right
<lamont> and I'd prefer to not bail on current work tasks to finish it up
<lamont> because writing exception documents can be so much fun, and all that
<slangasek> well considering I have the same gripe as kees about bind9 not supporting DNSSEC, I think a FFe review can be arranged :P
<lamont> slangasek: you gonna bitch if I make it 9.8.0 instead of 9.7.3?
<lamont> it wants to be at least 9.7.3.dfsg.P1
<slangasek> not if it's done today
<lamont> cool
<lamont> it just won't make the 2100 UTC deadline
 * slangasek nods
<lamont> I still need to roll a couple security releases into the git tree, too  :(
<cjwatson> ScottK: acknowledged; I just really want to finish breaking down the ubuntu-drivers problem, since it's been dragging on for years
<ScottK> cjwatson: I'm not objecting to doing this.
<ScottK> I'd just like to see it further refined in the future.
<cjwatson> I think we're in agreement there ...
<ScottK> Last I checked (it's been awhile) ubuntu-sru had similar issues.
<cjwatson> ubuntu-sru seems to have a reasonable membership list at the moment
<ScottK> Agreed.
<ScottK> I think thought it used to have canonical-qa in it, but it does seem fine now.
<slangasek> ev: are you uploading ubiquity today to land the timezone reorg work?
<cjwatson> pitti: syslinux-themes-ubuntu is in NEW for you now
<cjwatson> pitti: I don't know how you want to handle dependencies of ubuntu-defaults-image; it will need syslinux-themes-ubuntu and gfxboot-theme-ubuntu installed
<Laney> anyone got a handy URL showing outstanding FFe requests that need tending to?
<ScottK> Laney: How about https://bugs.launchpad.net/~ubuntu-release
<Laney> if that will remain the link, sure
<ScottK> That's the one I usually use.
<skaet> ScottK, Laney - was working through some of the pages,  and came across https://wiki.ubuntu.com/StandingFeatureFreeze,  there are some things we've known are going to need an exception,  and am wondering if it makes sense to revive this page?  thoughts?
<Laney> I guess filtering it to New will be enough later
<Laney> skaet: yes, probably. Is the standing FFe policy documented elsewhere?
<ScottK> skaet: Yes.  If we need them, I think it's a good idea to document them.
<ScottK> Last cycle we just had FFe bugs that were left open.
<ScottK> I think that's OK too.
<skaet> Spotted the links from: https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze_for_new_upstream_versions
<skaet> but that's the reference I've seen so far.
<Laney> For some reason I thought they needed two acks, but I don't know why
<ScottK> Laney: That was once true for motu-release.
<Laney> ah
<Laney> So you could either track through that wiki page, or by leaving bugs open (possibly with a tag). Perhaps using LP is more sensible, as it'll be more current and searchable.
<skaet> Would prefer to have one way, and if custom is the leaving the bugs open,  that may be the right solution, and updating the process page may be appropriate.
<Laney> yep.
<skaet> cjwatson, pitti, slangasek, other release team members,  ^^ any preferences?  background info?
<Laney> having a tag may be useful as you can then get a list of all that are in effect
<micahg> Laney: that would require modifying the current tools like requestsync as well to add the tag (or have a script like bdmurray does for needs-packaging)
<Laney> micahg: no tools deal with standing FFes now anyway
<Laney> (and RT members could easily just add any tag when approving such)
<micahg> Laney: oh, this is post-approval, nevermind
<ScottK> We've done both wiki page and via bug.
<slangasek> skaet: certainly I think ~ubuntu-release bugs is the lightest-weight, most scalable approach
<skaet> slangasek, ScottK, Laney,  ok will make a note to update that process page to remove the reference to the stale exceptions page.   We'll standardize on the bugs this time around.
<ScottK> Now that we are processing exceptions for new features and not all new upstream versions, I think that they will be less necessary (e.g. I expect KDE 4.7.1 will be bugfix only).
<micahg> in general through the end of the cycle, do we still want multiarch changes from Debian?
#ubuntu-release 2011-08-12
<slangasek> micahg: they'd be subject to feature freeze
<micahg> slangasek: understood, but are they wanted :)
 * slangasek defers to the release manager ;)
<micahg> skaet: ^^
<slangasek> fwiw I would in general be willing to spend some time reviewing FFes for multiarching of any libraries that are part of ia32-libs currently
<skaet> micahg,  slangasek;  which libs are we talking about?   I can't see in my scroll back.  Had an offline glitch for an hour or so.  :P
<slangasek> I think micahg's referring to the hypothetical case at the moment
<micahg> [17:26] <micahg> in general through the end of the cycle, do we still want multiarch changes from Debian?
<slangasek> but there are about 15 packages that are interesting wrt ia32-libs right now (due to wine)
<skaet> ah,  ok.   Yeah,  it definitely will require FFEs now ;)   however if slangasek is volunteering...   should be ok to pick some up for next week or so.   After that,  we'll need to see where we are with unity/ubiquity/etc. and solid the images are.
<micahg> skaet: yeah, I'll file FFes, but I've been noticing  a couple a day in Debian and was wondering if it's wanted
<skaet> micahg,  thanks.
<slangasek> I wouldn't bother with any that aren't in ia32-libs
<skaet> slangasek,  https://api.launchpad.net/1.0/ubuntu/natty/ has no release date for natty...   any idea where it should have been set from?
<slangasek> if they haven't yet risen to the level of someone wanting them in ia32-libs, they're not worth an FFe
<micahg> slangasek: oh, it wouldn't be better to get them in now for extended testing for the LTS?
<slangasek> skaet: no clue; bdmurray raised that question earlier, I've never even heard of release dates for series being part of the LP API
<slangasek> micahg: I would expect 6 months in Debian unstable to be adequate testing on that score, if it's really a change we're just picking up from Debian
<micahg> slangasek: ok, will keep in mind
 * micahg will also keep an eye out for dh_python2 changes, but those should just be packaging changes (that I wouldn't think would be subject to FFe as it affects build time)
<ScottK> micahg: Build system changes are generally subject to FFe.
<ScottK> (I've already fixed one dh_python2 transition that resulted in an empty package in the archive)
<micahg> ScottK: oh, hmm, I've always thought packaging changes that shouldn't impact binaries don't need an FFe (yes, everyone can mess up)
<ScottK> micahg: Fixing bugs in the packaging system is one thing.  Redesign of the packaging system is different.
<ajmitch> ScottK: so switching from cdbs & pycentral to dh7 & dh_python2 probably needs an FFe?
<ScottK> Yes, but that'd be an easy one to approve in most cases.
 * ajmitch got a couple of those in just before FF
<ajmitch> at least 1 remaining to do, but I'll look at getting a FFe for a new upstream release as well
<micahg> ScottK: if that's policy for dh_python2, maybe you can send an e-mail to that regard?  I'm sure I wouldn't be the only one to have thought differently
<ScottK> I'll discuss with the release team first to make sure I'm not the outlier.
<micahg> ScottK: k, thanks, I"ll hold off until that happens, I still have to switch stragglers in the xubuntu seed to dh_python2, but won't start on that until next week
<micahg> ScottK: and if the case is that it needs an FFe, the followup question is, are the changes still desired?
<ajmitch> still plenty in universe to migrate, iirc
<micahg> at least 1091 total still, idk how many in universe
<ScottK> micahg: I would say that in general, it's desired, but let's see what I find out from my mail to ubuntu-release.
<micahg> ScottK: k
<ScottK> Personally, I'd be glad to approve any with an attached build log, the output of debc attached, and a link to a Debian bug.
<pitti> cjwatson: thanks, I source-NEWed it last night, will do binNEW now
<pitti> cjwatson: I'll just add it to the dependencies of ubuntu-defaults-builder, I think; these are small packages
<tseliot> pitti: can you approve the binaries in new for the following sources, please? nvidia-graphics-drivers-updates nvidia-graphics-drivers-96-updates nvidia-graphics-drivers-173-updates nvidia-settings-updates fglrx-installer-updates
<tseliot> pitti: also, they're in universe now instead of restricted
<pitti> tseliot: you mean multiverse?
<tseliot> pitti: launchpad says universe
<jbicha> if you're doing archive admin work today, I have a whole collection of packages that are obsolete
<jbicha> and should be removed: http://paste.ubuntu.com/664050/
<pitti> tseliot: that sounds wrong, I'll move it to multiverse
<tseliot> pitti: ok, shall we move them to main in the future?
<tseliot> pitti: restricted
<pitti> tseliot: eek, no -- these are still not free software, right?
<pitti> tseliot: restricted sounds fine to me, I'll put them there
<pitti> moved the source packages
<tseliot> pitti: yes, they're proprietary and I really meant restricted instead of main
<pitti> tseliot: will nvidia-common actually get along with these? the alternatives handling etc?
<tseliot> pitti: I'll fix nvidia-common. It's next on my TODO list
<pitti> tseliot: fglrx-amdcccle-updates looks like it would file-conflict with fglrx-amdcccle
<pitti>  Conflicts: fglrx-control, fglrx-control-qt2
<pitti>  Replaces: fglrx-amdcccle, fglrx-control
<pitti> shouldn't that have a conflicts: fglrx-amdcccle, too?
<tseliot> pitti: yes, unfortunately it's not possible to install them at the same time
<seb128> jbicha, you might want to open bugs about those or if you don't want to do that maybe drop an email on the devel list
<tseliot> pitti: let me check
<seb128> jbicha, better chance that somebody pick those from an email than from IRC
<pitti> tseliot: same with the fglrx-updates binary; it Replaces: fglrx, but doesn't Conflicts: to it, so you will install both at the same time and overwrite all of fglrx' files
<pitti> that makes it hard to switch back to fglrx
<tseliot> pitti: they both conflict and provide fglrx-control though
<tseliot> and replace
<pitti> tseliot: ah
<tseliot> pitti: same thing for fglrx which conflicts, replaces and provides fglrx-driver
<pitti> tseliot: right, looks fine; sorry for false alarm
<tseliot> better be safe than sorry ;)
<pitti> tseliot: all done
<micahg> jbicha: I'd suggest to file bugs for each group of related removals and subscribe ubuntu-sponsors
<tseliot> pitti: thanks. I guess launchpad hasn't updated the source pages yet
<pitti> oh? it should, that's fairly immediate
<jbicha> micahg: ubuntu-sponsors not ubuntu-archive?
<micahg> jbicha: removals like anything else need to be ACKd
<jbicha> ok
<pitti> tseliot: https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-updates/+publishinghistory
<pitti> looks alright
<tseliot> pitti: I still see universe except for nvidia-settings-updates which is in multiverse
<tseliot> pitti: oh, so it's the overview that's not updated
<pitti> tseliot: yes, that only updates after publishing
<pitti> +changelog and +publishinghistory are immediate
<tseliot> pitti: oh, I see. Thanks again
<doko> didrocks, there are a lot of bugs, which you claim having promoted, but which are not :-(  e.g. 795073. please be more careful
<didrocks> doko: see comment #5
<didrocks> doko: I promoted it
<didrocks> I didn't copy the output manually
<didrocks> or is there something wrong here?
<didrocks> I get the same thing with you yesterday btw
<didrocks> something you promoted that wasn't as well
<doko> didrocks, no, look at the current archive. python-greenlet is still in universe. I just promoted it
<didrocks> doko: well, I didn't copy the output manually
<doko> well, then something else is wrong
<doko> cjwatson: ^^^
<didrocks> doko: I have the same with one of your promotion yesterday
<didrocks> please check before blaming
 * didrocks looks for it
<doko> didrocks, which one?
<didrocks> doko: one sec, greeping my logs
<didrocks> grepping*
<didrocks> doko: libgrip
<didrocks> doko: https://bugs.launchpad.net/ubuntu/+source/libgrip/+bug/740206
<ubot4> Launchpad bug 740206 in libgrip (Ubuntu) "[MIR] libgrip (affects: 1) (heat: 3)" [Undecided,Fix released]
<didrocks> doko: see, I've redone the promotion yesterday evening
<doko> didrocks, see, I've redone the python-greenlet promotion now
<doko> so there seems to be something wrong
<didrocks> indeed
<didrocks> seems seed maybe was late to be edited or deps and so they were demoted?
<doko> seb128, didrocks: who can I blame^B^B^B^Bask about the new usb seeds?
<seb128> skaet I think but not sure, maybe cjwatson or pitti know better
<pitti> the initial set was done by allison; but anyway, we shold just throw out the universe stuff for now
<Daviey> ugh
<ogra_> dont say that !
<Daviey> :o
<doko> pitti: so it's ok to drop anjuta, audacity, wesnoth-1.8, fozen-bubble?
<Daviey> - python-carrot should hopefully fall off Main Inclusion, next week - being transitioned. So doesn't need touching atm.
<Daviey> - python-ipy will go away when the nova snapshot currently in unapproved queue passes (dropped as a dep)
<Daviey> - swift, glance and nova are top level depends; others need satisfying first.
<Daviey> skaet: I will not be able to attend the release meeting today, and the rest of the team are travelling.
 * Daviey will be travelling shortly.
<ogra_> hmm, where do we have the universe FF definition, do i need an FFe for a new package in universe ?
<Laney> yes
<ogra_> thx
<Laney> there's no separate process for universe/main
<ogra_> there used to be
<ogra_> and i feel that it varies every release (not sure why i feel like that) ...
<skaet> Daviey, thanks,  wendar will be hosting today.   I'll be traveling too.
<ogra_> .. so i think i better ask :)
<Laney> the motu and main release teams were merged some time ago
<Laney> no problem with asking :-)
<ogra_> skaet, ! what are you doing up already
<skaet> ogra_, heading to airport,  on way to Vancouver for LinuxCon next week.
<skaet> :)
<ogra_> skaet, to answer last night question, i dont think there is a bug about the composite vs. gksu issue yet, i'll make sure to have filed it today
<ogra_> *night's
<ogra_> mvo and dbarth know about it from conversations though, they should be prepared ;)
<ogra_> Laney, do you also know who is FFe approver for universe this time round ?
<Laney> ogra_: anyone, it's the same queue
<Laney> some of us might be more universe focused than others though
<ogra_> ah, k
<ogra_> thats a good change vs having single people assigned as we did in the past
 * ogra_ hugs Laney, thx !
<Laney> I don't know if the delegates system is still operational, but that wouldn't replace this anyway :-)
 * Laney hugs ogra_ 
<doko> cjwatson, ev: ubiquity depends on libcheese1, which depends on gst-plugins-bad. what should we do about this?
<ev> doko: it's going to be cleared up in the next upload
<doko> cool, thanks
<ev> which is waiting on me sorting the move of camerabin from gst-plugins-bad to gst-plugins-good
<mvo> ogra_: which bug is that?
<ogra_> mvo, black screen if gksu shows the dialog if metacity composite is enabled
<ogra_> running unity-2d and firing off gksu should show it
<mvo> ogra_: ok, gksu is going away anyway
<ogra_> this cycle ?
<jbicha> mvo: will pkexec gedit work? or will we have to type in a long string?
<mvo> not sure, #security was handling this, I'm not fully up-to-date
<ogra_> mvo, well, if we dont it shouldnt be hard to just comment the gamma adjusting code, no ?
<ogra_> so the window shows on a plain screen instead of black background
<doko> pitti, would you be happy with json-c in main for the desktop team? see bug #824303
<ubot4> Launchpad bug 824303 in json-c (Ubuntu) "[MIR] json-c (affects: 1) (heat: 10)" [Undecided,Confirmed] https://launchpad.net/bugs/824303
 * cjwatson uploads ubuntustudio-meta, since it's ages behind its seeds
<cjwatson> and is the sole cause of a number of NBS entries
<pitti> doko: seems harmless enough; no formal test suite, but the code is simpl enough, so no objection
<doko> pitti, can you subscribe (or the team)?
<pitti> doko: to bugs? yes
<pitti> doko: done, sub'ed desktop-team
<seb128> pitti, what team? ubuntu-desktop?
<pitti> canonical-desktop-team for now
<pitti> it's got zero bugs, and if anyone ever finds one, it's probably serious
<seb128> pitti, hum, please don't
<seb128> hum
<pitti> seb128: I can also sub myself only
<seb128> pitti, let's switch to #ubuntu-desktop to discuss it
<pitti> I sub'ed myself for now
<Laney> cheers for the backport run
 * mterry writes MIR for cython
<mterry> oh, maybe not
<mterry> doko, why does cython show up in component-mismatches?  it's part of a "cython | python-pyrex" build-depend, and python-pyrex is in main
<doko> germinate issue
<mterry> Is that just a nuance the mismatch script doesn't handle, or is that something we should change in the packagin?
<mterry> germinate is how we generate this report?
<cjwatson> not a germinate issue
<cjwatson> may be a seed issue
<cjwatson> yes, we germinate all the seeds and then compare against main
<cjwatson> well, I don't *think* it's a germinate issue anyway, it isn't normally.  I suppose I ought to check
<mterry> cjwatson, cython doesn't seem to be in platform or ubuntu seeds
<cjwatson> sure
<cjwatson> didn't say it was :)
<mterry> cjwatson, thought that was what you meant by seed issue
<cjwatson> what I mean is that normally the data should be blamed not the processing tool
<cjwatson> in much the same way that one doesn't automatically say that a bug in the output of a C program is a gcc bug
<mterry> I thought most programmers blamed gcc for their bugs  ;)
<doko> wondering why update-inetd shows up in c-m.
 * mterry does MIR for dvdauthor
<cjwatson> from what I can tell, germinate simply ends up trying to resolve build-deps from bzr before it runs across anything that would cause it to put python-pyrex in main
<cjwatson> it's important to remember that it does not care what is *currently* in main when making this judgement; it's selecting everything from scratch
<cjwatson> the simplest workaround is probably to put python-pyrex in the supported-development-common seed along with bzr (with a suitable comment)
<mterry> cjwatson, apparently, part of our delta for bzr is already dropping other build-depends that aren't in main
<mterry> cjwatson, it might make sense just to drop cython too
<cjwatson> if you do that then it will know that python-pyrex is supported before trying to resolve build-dependencies, so it won't need to make a decision about the disjunctive build-dep
<cjwatson> *shrug* either is reasonable, personally I'd probably seed it but whichever
<cjwatson> doko: it's not showing up itself, only as the cause for libfile-temp-perl
<cjwatson> though I'm not sure why it's picking libfile-temp-perl rather than perl-modules which Provides it
<cjwatson> probably because update-inetd shows up while processing a relatively fundamental seed and perl-modules hasn't been encountered yet
<cjwatson> https://bugs.launchpad.net/ubuntu/+source/germinate/+bug/723731 would be useful for this, but in the meantime I'll commit a workaround
<ubot4> Launchpad bug 723731 in germinate (Ubuntu) "control alternative dependency expansion without actually seeding package (affects: 1) (heat: 1)" [Wishlist,Triaged]
<cjwatson> doko: worked around
<doko> cjwatson, thanks!
<mterry> seb128, what's the story with cheese?  is it supposed to be in main?
<seb128> mterry, no, ev is working on getting the new ubiquity which drop that depends in
<seb128> mterry, should be done today if that works as he wants
<mterry> That will fix a lot of these component mismatches
<seb128> mterry, indeed, all the clutter, mx, gst ones
<seb128> with quite some codecs and libs due to the gst one
<doko> I hope all js mismatches are done now ...
<doko> it's now cheese which smells strongest in c-m
<slangasek> did I see that cheese was pulled in via ubiquity?  And ev said he was going to be dropping that anyway
<slangasek> so maybe this goes away with a ubiquity upload
<doko> yes, he's working on it
#ubuntu-release 2011-08-13
 * slangasek fixes an out-of-disk glitch on antimony
#ubuntu-release 2011-08-14
<iulian> tumbleweed: Re: FFe you've just approved. I was just about to hit the enter key but it suddenly came to my mind that I should refresh first and then post the comment.
<iulian> Heh.
<tumbleweed> :)
<tumbleweed> I do notice a large proportion of FFe requests are coming from ubuntu-release members. Are we much more conciencious? or is the team just staffed by people who do stuff?
<infinity> Both.
<infinity> But spoken with my release hat on, I prefer not to self-approve for fear that someone will see it as an abuse of privilege, so I suspect many of us seek out reviews to cover our asses politically. ;)
<iulian> Heh.
<Laney> yeah, I wouldn't self approve (but I would for backports, since crack there is fun \o/)
<iulian> :)
<tumbleweed> well, it's the exact opposite of self-approving. ubuntu-release team members ask for approval, other people do so less :)
<slangasek> ScottK: based on what I'm seeing so far going through the libssl0.9.8 NBS, I'm thinking we might want to do a repeat of "removal of unbuildable binaries" for oneiric. https://lists.ubuntu.com/archives/ubuntu-devel/2010-March/030509.html
<micahg> slangasek: there are about 100 packages left for the transition and people have been chopping away at it
<slangasek> micahg: so far I've looked at two of these packages, and both had compound FTBFS issues in Debian
<slangasek> which suggests to me that the remaining packages are in pretty bad shape, and we're going to wind up with most of them uninstallable by release time anyway due to libssl0.9.8 binary removal
<micahg> slangasek: makes sense, I'm assuming this wouldn't happen until the end though?
<slangasek> micahg: last time we did the removals about a month before release; one of the effects of doing it too close to release is that it doesn't give people who care about those packages to react to the removals and fix up the source
<slangasek> (which means that the archive admin who did the removals winds up getting private email from users complaining... :)
<micahg> ah, ok, well that makes sense, 1 month should be enough time to drive the rest of the transitions through
<tumbleweed> presumably only poeple upgrading to the devolpment release would notice removals
<tumbleweed> those already running it probably wouldn't
<slangasek> tumbleweed: yes - but equally, only people upgrading to the development release are likely to actually help with fixing binaries going missing
<tumbleweed> sure. I'm just saying if it was left late, many people who could help may not notice. (Although one hopes they'd read the announced removal list)
<slangasek> ah, could be
<micahg> actually, ones that are clearly bad, there are only 35 for the ssl transition (not including FTBFS transition builds)
<tumbleweed> that's small enough to be individually triaged before removal
<tumbleweed> but I'm assuming there are people who have already skimmed most of them
#ubuntu-release 2012-08-06
<stgraber> ^ these two (dnsmasq and network-manager) are part of a fix targeted for the point release, so please review as if they were uploaded pre-freeze
<stgraber> the dnsmasq change should be pretty small, the NM one is likely much bigger. I'll take a look at the diffs myself tomorrow (I've been using the test packages for a few days but didn't look at the code change myself)
<micahg> stgraber: you might want to have a look at bug 1033412
<ubot2> Launchpad bug 1033412 in lxc "package lxc 0.7.5-3ubuntu60 failed to install/upgrade: unable to install new version of `/usr/lib/lxc/liblxc.so.0.7.5': Device or resource busy" [Undecided,New] https://launchpad.net/bugs/1033412
 * micahg isn't sure if that's normal or not
 * micahg would think not
<Laney> what broke with i386 livefs builds?
<ev> could someone please let my email to ubuntu-release@ through the queue?
<iulian> skaet: ^
<infinity> Laney: The machine's down and being recovered.
<Laney> righto
<tseliot> hi, can anybody reject nvidia-graphics-drivers and nvidia-graphics-drivers from quantal-proposed, please?
<infinity> tseliot: You just said the same thing twice. :P
<tseliot> infinity: err... nvidia-graphics-drivers and nvidia-graphics-drivers-updates
<infinity> tseliot: And by reject, you mean remove?
<tseliot> infinity: if that removes my latest uploads from quantal-proposed then yes please
<infinity> Check.
<infinity> tseliot: Reason for the removal?
<tseliot> infinity: I'd like to upload the same revision to quantal and then upload a newer release to -proposed if possible
<infinity> That's not gonna happen.
<infinity> Once a package version has been accepted, it's "used".
<infinity> So, you'll need to upload a new version anyway.
<infinity> At which point, it'll supersede this one, so no need to remove it.
<tseliot> infinity: ok, never mind then. I thought the packages in any -proposed would be pending approval
<infinity> Not for the devel release.
<tseliot> infinity: ok, I've learnt something new, thanks
<infinity> It's already in the archive and built.  Or, well, failed to build, in this case. :P
<tseliot> infinity: now that's weird. It doesn't fail in my chroot. I'll investigate the issue...
<infinity> tseliot: One failed on one arch, the other on both.
<tseliot> infinity: right
<stgraber> micahg: moved to dpkg
<stgraber> micahg: I have 5-6 servers running lxc that upgraded fine with dozen of containers running on each, so it's definitely not a problem affecting all our users, and I can't see why dpkg wouldn't be able to replace a file that's currently used.
<infinity> stgraber: That's not a dpkg bug, can I bounce it back? :P
<infinity> stgraber: dpkg is trying to write to the file and failing, it's not up to dpkg to ensure the world is writable.
<infinity> stgraber: I'd assume this is either lxc userspace being wonky, or some strange kernel issue, perhaps relating to repeated suspends with active containers?
<stgraber> infinity: well, "lxc" is only installed outside of the container, so feel free to bounce to kernel ;)
<stgraber> infinity: I checked the dmesg for anything obvious but without sucess... I guess I could reproduce the failure if the file was a read-only bind-mount, but I don't see why that'd happen
<infinity> stgraber: Well, sure, and this is all outside the container.  I'm not sure how that's relevant?
<tseliot> infinity: I don't think this change should be causing a this build failure. Any ideas? https://launchpadlibrarian.net/109173874/buildlog_ubuntu-quantal-amd64.fglrx-installer-updates_2%3A8.960-0ubuntu3_FAILEDTOBUILD.txt.gz http://launchpadlibrarian.net/109008932/fglrx-installer-updates_2%3A8.960-0ubuntu2_2%3A8.960-0ubuntu3.diff.gz
<infinity> tseliot: Didn't I already fix that once before?
<infinity> tseliot: You need to merge in the changes from fglrx-installer to -updates, I'm thinking.
<tseliot> infinity: oh, wait, I did that
<tseliot> infinity: sorry about the noise
<skaet> cjwatson, infinity - http://archive.ubuntu.com/ubuntu/dists/quantal/main/dist-upgrader-all/current/ appears to be missing the .html version of the announces.   Is there a step that creates *.html automatically, or is manual from nusakan?
<infinity> skaet: It would come from the build of the package.
<infinity> skaet: Could be that the last upload didn't get pre-build.sh ran before upload or something.
<skaet> infinity,  yes,  looks like prior versions have the .html files,  so will assume just temporary glitch and cross check later.
<skaet> thanks
<cjwatson> Must be.  nusakan can't do this
 * infinity is poking it.
<infinity> "It" being the package.
<cjwatson> And any system where this is done manually (though I don't think that existed here) would be very thoroughly deprecated and will soon stop working.
 * skaet nods
<infinity> Ugh.  release-upgrader's pre-build.sh is just vile.
<cjwatson> It is possible that I should have converted this code into a cleaner language than shell some time ago ...
<cjwatson> Moderately difficult to unpick it into a reasonable object model.
<micahg> umm, anything special for seed changes in the point release?  see bug 1033575 for context (do we just use the .precise branch as before)?
<ubot2> Launchpad bug 1033575 in ubuntu-meta "icedtea-plugin shouldn't be shipped on the DVD" [High,In progress] https://launchpad.net/bugs/1033575
<stgraber> micahg: yeah, the precise branch is what's used
<micahg> ok
<infinity> cjwatson: shoop!
<cjwatson> Let's not and say we did.
<infinity> I dare you to say you did.
<infinity> April 1: Canonical invests millions in shoop development; rewrites all core tools and infrastructure.
<infinity> Seriously?  Another e-d-s ABI bump?
<infinity> Maybe we should rename +1 maint to e-d-s-and-poppler-maint.
<ScottK> I'm going to accept the cups for precise-proposed unless someone objects quickly.  It fixes an updates regression.
<stgraber> ScottK: go ahead, it's been cleared by skaet and I
<ScottK> OK.  Done.
<ScottK> skaet or stgraber : Assuming we get verification, I any objections to waiving the 7 day waiting period?
<stgraber> ScottK: let me take a quick look at the fix and I'll answer that one
<ScottK> OK.
<stgraber> ScottK: most of the change seems to be about renaming variables and looking at the actual list of affected hardware it looks small enough that even if that one regresses in some way it shouldn't be a disaster, so yeah, I'm fine with that
<Laney> if gst0.10-python isn't going to be accepted into precise-proposed due to the freeze then transmageddon should probably be removed (v-failed)
<seb128> Laney, would that block the rhythmbox SRU?
<Laney> yes
<seb128> no way then ;-)
<Laney> rhythmbox needs transmageddon needs gst0.10-python
<micahg> stgraber: can I get 12.04.1 approval for https://launchpadlibrarian.net/111961124/icedtea-web_1.2-2ubuntu1.2.debdiff ?
 * micahg guesses if he can get Kubuntu to drop it as well, it won't make a difference...
<stgraber> micahg: sounds like the first fix could wait but the second fixes some upgrade path. It's also not affecting any image we'll be releasing so even if it's slow to validate it won't affect us, so yeah, go ahead
<stgraber> (IIRC kubuntu won't release a dvd image for the point release)
<micahg> it's on the manifest still
<stgraber> oh, ok, then I guess they actually are planning on releasing a dvd image then :)
<stgraber> ScottK, Riddell: any opinion on that icedtea-web update? ^
 * micahg would prefer them to drop it from their DVD as well FWIW :)
<debfx> I agree, we should drop it
<ScottK> I doubt we're respinning the DVD, but I'm checking.
<ScottK> Actually, we are.
<Riddell> well I'm happy to be persuaded otherwise
<ScottK> We didn't before, IIRC.
<ScottK> I'd suggest respin the DVD once and once only for 12.04.2 after we have 4.8.5 and won't update KDE again.
<ScottK> That and the usual "Who's going to test it"?
<Riddell> right, let's do that then
<stgraber> Riddell: can you update the 12.04.1 manifest then?
<stgraber> micahg: so it sounds like icedtea-web will no longer affect anything we ship, so no objection to having it accepted
<Riddell> stgraber: not this one? https://wiki.kubuntu.org/PrecisePangolin/ReleaseManifest
<stgraber> Riddell: https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest/12.04.1
<micahg> stgraber: great, will upload later today then, thanks
<Riddell> skaet: change of plan, no dvds for kubuntu for 12.04.1, manifest updated
<skaet> Riddell,   ack.   We may as well start a 12.04.2 manifest off as well at the same time then,  and leave it on there though - right?
<Riddell> skaet: yep
<Riddell> stgraber: how do I remove Kubuntu DVD from Precise Daily?  I'm looking at http://iso.qa.ubuntu.com/admin/config/services/qatracker/builds and can't work it out
<stgraber> Riddell: I'll take care of that
<stgraber> Riddell: starting by disabling the cron on nusakan
<skaet> stgraber,  while you're on nusakan,  can you retrigger Ubuntu Desktop i386 and see if it will build now?    Other Ubuntu Desktop images are amd64 at 0806,  but that one is at 0804.
<stgraber> skaet: is the i386 builder back online?
<stgraber> Riddell: disabled the cron for the dvd image and removed from the tracker
<skaet> stgraber,  lack of i386 builder would explain it.
<stgraber> skaet: yeah, I saw a mention of a problem with the i386 builder earlier, explaining all the failures over the weekend. I'm not sure of the state of the fix though. Reading some more backlog now :)
 * skaet starts into the backlog as well.
<stgraber> skaet: 11:06 < infinity> Laney: The machine's down and being recovered. (7.5 hours ago)
<skaet> infinity,  is there an RT ticket, or something we can follow for the i386 builder status?
<Laney> Still getting death mails.
<infinity> skaet: Not sure, we were just pinged by elmo on the weekend that it was dead and being rebuilt.
<Laney> all I see is rt#50669
<Laney> but that implies that it's alive.
<seb128> hum
<seb128> http://people.canonical.com/~ubuntu-archive/nbs.html is empty
<seb128> did we fix everything? ;-)
<slangasek> heh, possible
<Laney> that report has been known to break
<Laney> cjwatson fixed it before
<slangasek> seb128: cross-reference with http://people.canonical.com/~ubuntu-archive/testing/quantal_outdate.html?
<slangasek> libedata-cal-1.2-15 |    3.4.3-1 |       quantal | amd64, armel, armhf, i386, powerpc
<slangasek> libedata-cal-1.2-18 | 3.5.4-0ubuntu2 |       quantal | amd64, armel, armhf, i386, powerpc
<slangasek> there's an NBS lib right there
<slangasek> so yeah, the report's broken
<Laney> how does one get access to that user to be able to fix it? ^o)
<slangasek> Laney: lp:~ubuntu-archive/ubuntu-archive-tools/trunk/, cron.NBS
<Laney> oh, it's in there
<slangasek> yep, feel free to fix it without having access to the user account ;)
<slangasek> (access to the user account should probably be limited to those who are actually archive admins... not sure that you meant to volunteer yourself for that? :)
<Laney> Actually I would be interested in that, but perhaps not right at this moment
<slangasek> seems to be archive-cruft-check that's failing
<slangasek> http://paste.ubuntu.com/1133105/
<ScottK> stgraber: Did you form an opinion about pushing the cups update out as soon as it's verified?
<stgraber> 17:19 < stgraber> ScottK: most of the change seems to be about renaming variables and looking at the actual list of affected hardware it looks small enough that even if that one
<stgraber>                   regresses in some way it shouldn't be a disaster, so yeah, I'm fine with that
<ScottK> OK.  Thanks.  I missed that.
<slangasek> Laney: are you looking into the NBS report breakage?  I don't think I'm going to attempt it, given that backtrace
<Laney> slangasek: Not exactly. I don't have a local mirror available, so there's some yaks to be shaved first.
<Laney> seb128 is an archive admin ;-)
 * seb128 hides
<stgraber> skaet: so, I'm doing some tests to figure out how we managed to use an extra 8.2MB on the squashfs since 12.04 release
<stgraber> skaet: there are two obvious ones, the kernel headers (amounting to 2MB) and printer-driver-postscript-hp (around 700KB)
<stgraber> the rest are packages that just got bigger with the most likely ones being firefox, thunderbird and libreoffice
<ScottK> stgraber: cups is released.
<stgraber> ScottK: thanks
<stgraber> skaet: so, hplip 3.12.2-1ubuntu3.1 is the one that caused the extra 700KB package from printer-driver-postscript-hp (bug 1014478)
<ubot2> Launchpad bug 1014478 in hplip "PPDs for HP's PostScript printers not installed in default installation" [Medium,Fix released] https://launchpad.net/bugs/1014478
<stgraber> so that was clearly done on purpose and approved by the SRU team, so not much hope of getting these 700KB back
<stgraber> I'll start looking at cutting some langpacks
<skaet> stgraber,  understood,  thanks.     Not sure langpacks alone will cut it.    Probably time to flag the desktop team then and see if there are good "put package on a diet" suggestions.
<seb128> there is none
<slangasek> have we considered not requiring 12.04.1 to fit on a CD?
<slangasek> we've already said quantal doesn't have to, and it's coming out in the same time frame; and we don't press CDs of the point releases
<slangasek> trying to enforce further dieting of the desktop after .0 is fraught with peril
<slangasek> though, why are the kernel headers so much bigger now?
<stgraber> slangasek: it's just the live-build bug infinity fixed, we currently ship two header packages
<slangasek> stgraber: ok; that's been fixed in -proposed since Friday or so, are we not getting test builds yet using it?
<stgraber> slangasek: nope, we need to poke IS to get it on the builders
<stgraber> slangasek: infinity ran local tests pre-upload though
<slangasek> stgraber: ok; will you poke IS please? :)
<stgraber> slangasek: yeah, infinity said he'd but that didn't happen yet so I guess I can do it ;)
<slangasek> he's off celebrating August Province Day or something
<stgraber> skaet: a quick test build here shows that removing the portugese langpack would free us 9MB on the media, making the image fit again. Any strong objection to doing that?
<slangasek> which I think you're supposed to be as well? :)
<stgraber> slangasek: nope, we don't seem to have that one on this side of the country ;)
<skaet> stgraber,  no objection.   Much better than alternative.  bye-bye portugese langpack
<slangasek> stgraber: oh yes, infinity did say Quebec was in the exclusion list, ok
<seb128> stgraber, skaet: I do object at dropping langpacks this way, how hard did we look for other solutions?
<seb128> stgraber, skaet: dropping it makes the iso less useful for 190 millions people, I don't think it's something to overlook
<skaet> seb128,   weighing this against not having a CD form factor available,  it seems the lesser of the evils.
<stgraber> seb128: well, we need to free 6MB (compressed) from the squashfs, the only package that was added since the release is printer-driver-postscript-hp that according to the bug should really be on the ISO and would only gain us 700KB if removed
<seb128> skaet, well, precise was on size, can't we just figure out where we used the space and fix that?
<slangasek> stgraber: so where did all the rest of the space go?
<stgraber> slangasek: it's non-trivial to check, my current bet is on libreoffice, thunderbird and firefox, I can try and get a rough estimate of their space before/after (just looking at /usr/lib)
<skaet> seb128,  that would have been the hope, but it looks like multiple desktop packages all got a bit bigger.
<slangasek> stgraber: have you looked at .deb sizes, as a first pass?
<seb128> pitti said that "/home/cdimage/iso-deb-size-compare on nusakan" can be used on alternate isos
<seb128> but I don't have access to nusakan to test that
<seb128> that's a different measure than the live image but that can be useful to give a clue
<infinity> My assumption is just that firefox and thunderbird grew a ton.
<infinity> Not really much mystery there.
<slangasek> I don't think it's sufficient to assume
<slangasek> packages putting weight on in SRU are a problem
<stgraber> binary sizes for firefox and thunderbird grew by around 300KB, will test iso-deb-size-compare see if that helps
<infinity> I'm already checking.
<ScottK> Where do I find the Kubuntu 12.04 dailies?
<stgraber> ScottK: /kubuntu/precise/ on cdimage
<seb128> firefox_11.0+build1-0ubuntu4_i386.deb (17.0 MiB)
<seb128> firefox_14.0.1+build1-0ubuntu0.12.04.1_i386.deb (18.0 MiB)
<ScottK> Thanks.
<infinity> http://paste.ubuntu.com/1133208/
<ScottK> What's the official size limit for 12.04 CD images?
<stgraber> ScottK: 736665600
 * ScottK notices the i386 live is missing.
<infinity> The i386 livefs buildd has "issues".
<infinity> Apparntly.
<stgraber> precise released at 732213248 and we are currently at 740601856 (looking for the amd64 desktop image). we should be getting to 737808384 with infinity's change (if my local clean + recompress is right)
<ScottK> Yeah.  I guess "mv: cannot stat `/srv/cdimage.ubuntu.com/scratch/kubuntu/daily-live/tmp/precise-i386/CD1/casper/filesystem.kernel-generic-pae': No such file or directory" is not good.
<stgraber> so assuming amd64 is the most oversized image, we should just have 1.3MB to cleanup to make it fit again, doesn't look terribly difficult until you remember that's compressed data added post-release we're talking about...
<ScottK> Kubuntu amd64 is a bit overweight too: 738504704
<stgraber> ScottK: this one should fit once the live-build change lands though as it'll save roughly 2
<stgraber> MB
<ScottK> Excellent.
<infinity> +printer-driver-postscript-hp   3.12.2-1ubuntu3.1
<infinity> How big is that?
<infinity> That's an entirely new package on the current CD.
<stgraber> 700KB compressed
<stgraber> I mentioned it earlier, it's bug 1014478
<ubot2> Launchpad bug 1014478 in hplip "PPDs for HP's PostScript printers not installed in default installation" [Medium,Fix released] https://launchpad.net/bugs/1014478
<cjwatson> has somebody fixed the NBS report?  if not, I know what the problem is
<slangasek> cjwatson: I don't believe anyone has - what's the problem?
<cjwatson> basically, bug 459418
<ubot2> Launchpad bug 459418 in lazr.restfulclient "Cache is not safe for concurrent use (by processes or threads)" [High,Fix committed] https://launchpad.net/bugs/459418
<slangasek> ok
<cjwatson> so occasionally the cache gets corrupted
<slangasek> so which bits get rm -rfed?
<cjwatson> ~/.launchpadlib/api.launchpad.net/cache - done
<slangasek> yay
<cjwatson> the second best fix is to make it run with a different cache dir, which I did for sru-report, but it's a bit more fiddly for NBS because there are multiple scripts involved so I've been putting that off
<cjwatson> the best fix is to get somebody in the LP team to release the fix-committed fix for that bug, get it into quantal, and SRU it
<stgraber> mythtv was granted an MRE and has a 12.04.1 exception, so SRU team members, please feel free to review
<cjwatson> skaet: https://bugs.launchpad.net/launchpad/+bug/174375 comment 27 - do you remember whether the problem was lack of ability to *nominate* to series, or to *target* to series (== approve nominations)?
<ubot2> Ubuntu bug 174375 in ubuntu-community "Distribution drivers permissions may need redesign" [Medium,Confirmed]
<cjwatson> (the ability to nominate is fairly widespread, and produces a "Nominated for ... [Approve/Decline]" row; the ability to target lets you actually create series-targeted tasks)
<cjwatson> It would make more sense if the problem had been lack of ability to target
<skaet> cjwatson,  task needed was targetting to a series.
<cjwatson> Right.  You'd said nominate in that comment, so I wanted to clarify since they're different permissions in LP.
<skaet> yes,  bad wording choice on my part.  sorry.
<cjwatson> np
<stgraber> rebuilt Ubuntu with the new live-build, we're now 1796kB short of fitting on the ISO
<ScottK> stgraber: I'd appreciate it if you'd redo Kubuntu as well so we can confirm if fits now.
<cjwatson> skaet: Would you care to cast your eyes over my latest comment in that bug and make sure I'm not way off base?
<stgraber> ScottK: sure. I'll trigger amd64 only as i386 is still broken
<stgraber> ScottK: running
 * cjwatson makes his bimonthly pilgrimage to APUE
<cjwatson> I wonder why cdimage/bin/kill-after bothers to set SIGALRM before forking
<cjwatson> admittedly it does have to set SIGCHLD first
<stgraber> ScottK: http://cdimage.ubuntu.com/kubuntu/precise/daily-live/20120806.1/ looks happy
<stgraber> hmm, or rather, it already was happy, might be even happier when the build publishes :)
<stgraber> (live-build finished but nusakan is still busy building the .iso)
<ScottK> stgraber: Great.  Thanks.
#ubuntu-release 2012-08-07
<slangasek> stgraber: 1796KB> that + 2MB is much less than the 7MB we were over, so that's much better than expected, no?
<stgraber> slangasek: indeed. The dailies were 7MB bigger than the 12.04 release, but we were quite a bit below the limit at that time. So now with infinity's fix we are at 6MB more than at 12.04 which is 1.8MB more than the CD limit.
<slangasek> ah
<slangasek> so, did package size analysis show where the rest of the bytes have gone?
<slangasek> I guess this is infinity's pastebin from earlier: http://paste.ubuntu.com/1133208/
<slangasek> .3MB growth in linux-image; .1MB+.3MB growth in linux-headers; .1MB growth in mdadm, which is probably just the deliberate addition of mdmon so nothing we can do about it; libreoffice-help-en-us: .5MB; firefox: 1.0MB; thunderbird: 1.4MB; libreoffice-base-core: .8MB
<slangasek> those should probably all be looked at
<slangasek> the last is particularly interesting, the .8MB delta is a 900% increase :P
<slangasek> ah, the package size in precise release was anomalous
<slangasek>     - readd move of libdbalo.so to -base-core (closes: #670350)
<slangasek> that's from libO changelog; deliberate change
 * micahg would like to know how to generate stats like the above for xubuntu images
<slangasek> micahg: let me check whether the script is shared somewhere
<micahg> thanks, xubuntu has issues with space and it would be nice to see what exactly happened between precise and quantal
<slangasek> it is not; for some reason it's not even checked into bzr :/
<slangasek> and the libO change is both deliberate and correct (AFAICS), the .so was moved from libreoffice-base which is not on the CD, to libreoffice-base-core which is
 * micahg will accept an e-mail copy or /path/to/foo on some internal server if it's not publicly shareable
<micahg> can be later, I won't have time to use it until later in the week anyways
<slangasek> micahg: mailed
<micahg> slangasek: thanks
<infinity> stgraber: I take it the live-build test was a success?
<infinity> stgraber: Ahh, yes, I see your verification on the bug; thanks.
<astraljava> Hi gang, sorry I've been a bit absent lately. I understand we're supposed to test the 12.04.1 images, correct? I'll whip up some testing on Xubuntu, and look after Studio as well.
<jibel> there is no i386 build for Precise and Quantal core, desktop and wubi for the last 3 days
<jibel> for wubi, amd64 is on cdimage.u.c but not the checksum files
<Laney> the i386 builder is broken
<Laney> rt #55115
<jibel> ok, thanks
<seb128> could somebody put bug #969359 back from private?
<seb128> users should been able to lock random bugs this way, some random user set it as a security and private bug
<seb128> when it's neither of those
<seb128> it's a g-s-d using cpu bug
 * Laney can't see it
<cjwatson> ask webops on #launchpad-ops internal
<seb128> shouldn't*
<seb128> cjwatson, thanks
<Riddell> skaet: kubuntu 12.04.1 daily images are good from the testing http://iso.qa.ubuntu.com/qatracker/milestones/204/builds
<ScottK> cjwatson: Is the package set update script somewhere where someone like me could run it and see what would be added to the (for example) kubuntu package set if you did an update?
<cjwatson> ScottK: lp:~cjwatson/+junk/packageset - fetch http://people.canonical.com/~cjwatson/packagesets, run ./packageset-push.py -n packagesets
<cjwatson> it's, er, not exactly productised
<ScottK> Sure.  Thanks.
<ogra_> is that much different from running update.sh in the metapackage ?
<cjwatson> Entirely.
<cjwatson> It's dealing with package sets, not metapackages.
<ogra_> k
<cjwatson> The latter will probably be a subset of the former.  Ish.
<ScottK> I'm going to hazard a guess it's been awhile since you ran that ...
<ScottK> It didn't actually pick up the ones I hoped it would (ktp-*), so I'm not in a great rush though.
<cjwatson> Yeah
<cjwatson> Let me go and poke it now
<skaet> Thanks Riddell.  :)
<cjwatson> ScottK: done
<ScottK> Thanks.
<skaet> thanks astraljava,  yes,  testing of the 12.04.1 daily images right now to make sure no surprises would be appreciated.
<Laney> cjwatson: I synced ghc to proposed this morning. Ideally I'd like to do the whole transition there and then copy over. Do you think it's feasible to do that given the size of the stack?
<Laney> We'll also need to teach ben about proposed too.
<cjwatson> Ahaha.  Um.
<cjwatson> Tracking it will be hell for somebody.
<Laney> yeah?
<Laney> I don't know anything about how good the tools there are.
<cjwatson> They aren't.
<Laney> hoho
<cjwatson> TBH this seems like exactly the kind of thing we can't feasibly do yet.
<cjwatson> Needs britney-style automation.
<Laney> I wondered whether ben's output would be good enough
<infinity> Laney: "ben" being the transition tracker?  It might be good enough to get by for this.  Not that the neverending ghc transition ever seems to be in perfect shape anyway. :/
<Laney> yes.
<Laney> it does get done when someone applies enough force to it
<rbasak> Do release notes exist for dot releases?
<stgraber> yes
<rbasak> Thanks
<rbasak> There will be some arriving soon :)
<stgraber> rbasak: ok :) I don't think the wiki page was created yet, but it's on skaet's todo for this week I believe
<stgraber> rbasak: will probably be at https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/12.04.1
<rbasak> This is for a couple of highbank kernel bugs that have fixes but may not make the release. Is adding ubuntu-release-notes tasks ok until the page is ready?
<stgraber> yep, IIRC we have a 12.04.1 milestone available on the ubuntu-release-notes project
<rbasak> Thanks
<skaet> rbasak,  release notes exist.   I've snapshotted off the 12.04 original ones, so feel free to edit the release note pages in the standard spot now.
<skaet> https;//wiki.ubuntu.com/PrecisePangolin  and then put the details in the product specifically.
 * skaet will get that email sent out tomorrow
<skaet> rbasak,  for server - put changes: https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuServer
<skaet> rbasak,  original release notes are now at: https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuServer/UbuntuServer-12.04
<skaet> for instance
<mahmoh> skaet: rbasak: here's the release notes bug - https://bugs.launchpad.net/eilt/+bug/1034042
<ubot2> Ubuntu bug 1034042 in ubuntu-release-notes "Calxeda ESX-1000 kernel disk detection and network reliability caveats for 12.04.1" [Undecided,New]
<rbasak> mahmoh: you should probably add the linux task to that too?
<mahmoh> it needs a milestone/release added, which I cannot do
 * skaet kicking off a rebuild of the ubuntu desktop on nusakan to see if its picking up the i386 builds properly now.   
 * skaet should have put ARCHES on... sorry. 
<nigelb> /ws/ws 17
<nigelb> grrr
<Laney> infinity: looking at http://people.canonical.com/~ubuntu-archive/transitions/ghc.html it might not be worth bothering doing it in proposed
<Laney> any opinion?
<skaet> mahmoh,  I've added a milestone to it.
<infinity> Laney: Yeah, that was what I was refering to when I said it wasn't in the best shape.
<Laney> infinity: It'll be a fair bit worse. But I doubt it matters.
<Laney> fancy copying it over?
<infinity> Laney: Sure.
<Laney> ta
<infinity> Done.
<Laney> let the games begin
<jocarter> and may the odds be ever in your favor.
 * infinity heads out for a bit.
 * Laney offloads the rebuilds to jocarter
<infinity> Laney: I'm happy to help out a bit as a "spare time" thing after-hours.  I'm pretty good at robotic rebuilds and transitions. :P
<mahmoh> skaet: thx
<Laney> infinity: Nice, thanks. I tend to prefer to sync where possible, but perhaps there isn't so much of that due to the freeze. You might find that some of the API changes for 7.4 have not have made it over yet.
<stgraber> slangasek: been looking into the size delta for firefox and thunderbird, it's mostly two files (libxul and omni.ja) that are taking an extra 2MB, so not much we can do there I guess
<stgraber> I also did a few tests at rebuilding the biggest packages in /pool with xz but that'd only save around 5kB so not really worth it
<slangasek> stgraber: rebuilding with xz also doesn't help at all for live CDs
<slangasek> oh, you mean the ones in /pool
<slangasek> yeah
<stgraber> slangasek, infinity: looks like we'd be saving 2.0MB of compressed squashfs size if we were to drop the -updates, -proposed and -security lists entry in /var
<stgraber> but keeping these for the release pocket
<slangasek> ok
<slangasek> that would be enough to get us over, yeah?
<stgraber> yep
<stgraber> we'd have an extra 300KB that might end up being used with the refreshed slideshow (potentially extra translations)
<stgraber> so if there's no big downsides you can think of, it looks like this would work
<stgraber> I'm assuming these pockets will be changing just a few days after release if not even before release, so most people will need to re-download anyway
<cjwatson> do check that the installer still works right if you do that
<stgraber> -rw-r--r-- 1 root root 735830016 Aug  7 14:29 iso.iso
<stgraber> repacked iso without the lists
<stgraber> will do a test install to confirm ubiquity doesn't explode with that
<stgraber> SRU TEAM: We have the following uploads in the precise queue that are on the 12.04.1 list: light-themes (requested by Edubuntu), network-manager, dnsmasq, mythtv (MRE and exception granted yesterday by TB)
<stgraber> when doing reviews, please start by these, then continue with these uploaded before 21:00 UTC on the 2nd of August
<slangasek> stgraber: well, RAOF is on Tuesdays and it's no longer Tuesday there ;)  I guess I can take a look at some today
<skaet> thanks slangasek
<stgraber> slangasek: yeah, and I somehow assumed RAOF would be on paternity leave, haven't checked canonicaladmin though
<slangasek> ah, good point
<skaet> ScottK,  do you have some bandwidth to help trim down the queue today for the SRUs?
<stgraber> I should also have a live-build change uploaded soonish, might try to get infinity to take a look at the change before uploading though
 * skaet nods
<stgraber> I'm almost done with an install using out-of-media langpacks + updates + extras, will then run another run without connectivty. I suppose that should be enough testing for that change.
<ScottK> skaet: Neither the time kind nor the network kind (getting my car serviced and stuck connecting via a 3G tether).
<infinity> stgraber: Did you just do the purging in the cruft-removal hook (where dbus IDs and other junk get purged)?
<infinity> cjwatson: Given that we used to purge apt lists in livecd-rootfs, unless ubiquity has since developed a dependency on not doing so, it shouldn't break.
<infinity> (But definitely worth double-checking)
<skaet> ScottK,  ack.
<stgraber> infinity: yeah, plan was to use ./scripts/build/lb_chroot_hacks though I'm not sure whether we want to check for something in the environment or just always do it
<infinity> stgraber: Always.
<infinity> stgraber: Otherwise, we could inadvertently make the installer depend on post-release pockets in the devel release and be unpleasantly surprised when we don't in a point release.
<infinity> stgraber: "rm -f /var/lib/apt/lists/*-{updates,security,proposed}*" should do it.
<infinity> stgraber: Which is totally not POSIX shell, so pre-expand that. :P
<stgraber> infinity: http://paste.ubuntu.com/1134752/
<infinity> stgraber: -security_ (etc)
<infinity> stgraber: Otherwise, you whack source with security/proposed/updates in the hostname or path.
<stgraber> good point
<infinity> (Not an issue for official media, but could be for someone doing a home-brew thing)
<infinity> stgraber: Also, where't the bug closure, and the upload to quantal?  Slacker. ;)
<stgraber> infinity: hehe, making sure it works first ;) still one test install to go
<infinity> stgraber: Anyhow, if it breaks, it's a ubiquity bug anyway, since there's no way it should be doing an apt-get install without first doing an update.
<infinity> stgraber: As the lists on the media could have been stale.
<stgraber> indeed
<stgraber> infinity: mind moving the current live-build to -updates? it's clearly been tested and it's very unlikely anyone else would be using it from -proposed
<infinity> stgraber: Sure.
<infinity> stgraber: Done.
<stgraber> infinity: live-build uploaded to precise and quantal
<infinity> stgraber: Is queuebot dead?
<infinity> stgraber: Anyhow, reviewed and accepted.
<infinity> stgraber: You'll probably want to prod webops to install that by hand on kapok for another round of testing.
<infinity> stgraber: roseapple should spit out a .deb momentarily.
<stgraber> infinity: will do
<skaet> looks like we've got i386 build capacity again,   anyone waiting on a specific image before the next round of dailies?
<stgraber> not me. I'll be interested by a round of rebuilds when we get the new live-build to confirm we're no longer oversized
<infinity> stgraber: And built: https://launchpad.net/ubuntu/+source/live-build/3.0~a24-1ubuntu32.2/+build/3708989/+files/live-build_3.0%7Ea24-1ubuntu32.2_all.deb
<stgraber> jibel: any more info on bug 1029531? it's the next one on my list of potential critical issues for 12.04.1 to investigate
<ubot2> Launchpad bug 1029531 in update-manager "cdromupgrade from Lucid to Precise failed with unmet dependencies without network connection" [Critical,Confirmed] https://launchpad.net/bugs/1029531
<stgraber> second test install without the extra lists worked fine (installing in a foreign language with extras and no connectivity)
<slangasek> stgraber: mythtv SRU processed
<stgraber> slangasek: thanks
<slangasek> stgraber: NB: I didn't say accepted ;P
<stgraber> slangasek: what was wrong with it?
<slangasek> stgraber: includes SRU-inappropriate changes to the packaging
<slangasek> including one change not mentioned in the changelog at all, and another only relevant for python3 apport
<slangasek> MRE doesn't cover random packaging changes
<stgraber> ok
<slangasek> (commented in bug #1029522)
<ubot2> Launchpad bug 1029522 in mythtv "Newer version of MythTV fixing some major bugs needs an SRU" [Undecided,Fix released] https://launchpad.net/bugs/1029522
<stgraber> skaet: FYI I queued an amd64 daily-live build of ubuntu on precise to test the new live-build (webops just deployed it on kapok for testing)
<slangasek> stgraber: what ensures that other sessions are not affected by the changes in light-themes?
<slangasek> (the comment in bug #955376)
<ubot2> Launchpad bug 955376 in salience "Text color under Ambiance in top panel of GNOME Classic is dark gray instead of white" [Undecided,In progress] https://launchpad.net/bugs/955376
<stgraber> jbicha: ^
<stgraber> slangasek: I believe that only gnome-session-fallback uses gnome-panel and the matching css class, but I'm not a user of that myself, so jbicha should be able to confirm or give more details on that
<slangasek> ok
<infinity> slangasek: Yeah, that element isn't used by the default unity-ish session.
<slangasek> so there are other changes besides adding the :backdrop
<infinity> (This does, I think, also fix a bug with trying to use ambiance with xfce, which I long ago gave up on trying to do)
<infinity> slangasek: You mean the changes for #986988?
<stgraber> Edubuntu is mostly interested by that line "-PanelMenuBar-icon-visible: true;" the rest was already stacked for SRU and so ended up going with the same upload
<infinity> Yeah, the lack of Application menu icon is a bit of wart.
<slangasek> infinity: bug #955376
<ubot2> Launchpad bug 955376 in salience "Text color under Ambiance in top panel of GNOME Classic is dark gray instead of white" [Undecided,In progress] https://launchpad.net/bugs/955376
<infinity> slangasek: Right, but you said there were other changes too.
<stgraber> infinity: yeah and I was only made aware of that issue 4 days before release (not using that alternate gnome session myself), so didn't really want to respin the world for an Edubuntu specific issue in a secondary desktop environment ;)
<slangasek> infinity: see the diff?
<infinity> slangasek: Yeah, I'm looking at it.
<infinity> slangasek: Half of it is fixing the color issues, the other half is fixing the missing panel icon.
<infinity> slangasek: (And then the dropping of the patch that wasn't being applied anyway)
<infinity> slangasek: Seems sane to me, for all that my GTK3 theming is a bit sketchy.
<slangasek> infinity: half of it is *changing* colors in a context not specific to the :backdrop class.  What's missing is the rationale for why this is guaranteed to be a fix for all users, and not a regression for some
<seb128> is there any plan from the SRU team to review packages uploaded before the .1 freeze soon?
<slangasek> the patch doesn't match the description of the patch
<seb128> we should probably get them moving to users if we want them validated on time
<stgraber> seb128: yep, some of that is being done nowish
<seb128> great
<slangasek> seb128: do you have specific packages in mind?
<stgraber> seb128: well, starting by these that are specifically targeted to the point release, then rest of the queue
<slangasek> I intentionally skipped over totem and rhythmbox because these do not appear to be high-priority or targeted to the point release
<seb128> slangasek, totem rhythmbox sqlite3  xserver-xorg-video-intel gst0.10-python transmageddon
<slangasek> those were not all uploaded before the freeze
<seb128> slangasek, I think they are trivial and would make an consequent user impact
<infinity> slangasek: Oh, all the stuff for the .button classes?
<slangasek> the only ones still in the queue that were uploaded before the freeze are rpcbind, rhythmbox, totem
<seb128> slangasek, they = totem rhythmbox
<seb128> slangasek, no, sqlite3 was uploaded before the freeze, I made sure of that
<seb128> like 1 hour before, but before ;-)
<slangasek> seb128: I looked at them and did not reach the same conclusion that they were trivial
<infinity> slangasek: I'd assumed they exposed that it was always broken/wrong when they actually put a button on the panel.  But you're right, it seems to be lacking some description.
<slangasek> seb128: heh, ok; last week when I looked, LP told me it was uploaded just after the freeze deadline, but maybe it lied.  I can review it
<seb128> slangasek, they just add a one line "Keyword" line to their .desktop for dash searchability ... was is non trivial?
<seb128> slangasek, well totem does
<slangasek> seb128: um, let me double-check
<seb128> rhythmbox does include another fix to get mp3 encoding to default to an ok quality format
<Laney> rb would require a freeze exception for gst0.10-python
<Laney> which I uploaded after the deadline
<Laney> not sure what process we have for .1 freeze exceptions
<seb128> which is linked to the gst0.10-python transmageddon fixes
<seb128> slangasek,  	diff from 3.3.4-0ubuntu1~precise1 to 3.0.1-0ubuntu21.1 (1.5 MiB)
<seb128> the queue is on crack
<infinity> slangasek: To be honest, the gnome-panel theming with ambiance in precise is so awful, I can't see how any change could be called a regression. :P
<seb128> not sure what is 3.3.4-0ubuntu1~precise1 come from
<infinity> slangasek: Even if they decide to make it pink and flashing.
<seb128> but precise has 3.0.1-0ubuntu21
<slangasek> seb128: yes, I looked at the actual diff, not just the crack one
<seb128> slangasek, let me know if I screwed up, the diff should be a one line Keywords added to the .desktop
<slangasek> seb128: right; the totem one is trivial, but the bug is also marked 'low' importance - which means it's at the end of my priority list
<seb128> I can put it High if that helps :p
<slangasek> the rhythmbox one is non-trivial
<seb128> it's low priority but trivial with a real user impact
<seb128> I don't see why it should be disgarded, I made sure it was uploaded on time
<slangasek> because it's not a priority
<infinity> stgraber: How goes the test on kapok?
<seb128> slangasek, want me to tweak the bug settings? ;-)
<slangasek> why didn't you tweak them /before/?
<slangasek> I think you're being disingenuous to suggest now that this is a priority for the point release
<seb128> because I though things specifically targetted to .1 were targetted for a reason
<slangasek> I think the fact that no one targeted it to .1, or marked it as priority higher than 'low', reflects the real priority
<seb128> i.e that the milestone itself was enough of a reason
<slangasek> this wasn't targeted
<seb128> doh, forgot to milestone it?
 * jocarter learns a nice new word
<seb128> I didn't that now
<seb128> slangasek, well, it's not a priority but as said it's a trivial fix with a real impact on the user experience
<seb128> I honestly though that any upload made before freeze would be considered
<slangasek> if it's not a priority, I'm not spending time on it, trivial or otherwise
<seb128> that's why I didn't bother more with bug settings
<seb128> well, I spent time on it making sure it was uploaded on time
<seb128> I guess we have a communication issue there
<seb128> I assumed that anything uploaded before freeze would be considered
<seb128> I wouldn't have worked on it if I didn't want it to be in .1, especially not time while I was not at work (I did took an hour at GUADEC to get those uploaded)
<infinity> stgraber: Oh, it's stuck behind a DVD build, I see. :P
<jbicha> the light-themes patch has been in quantal for more than 2 months & I haven't heard any complaints that it caused any problems
<slangasek> stgraber: I'm not disputing that you want it in; I'm saying that by my reading it's a misprioritization, and that your decision to upload it doesn't impose on the release team an obligation to include a low-prio bugfix in the point release
<seb128> slangasek, I guess that was for me?
<slangasek> jbicha: however, that's not the threshold for SRUs
<slangasek> seb128: er yes, sorry
<jbicha> slangasek: have you tried GNOME Classic w/ Compiz in Precise? it's obviously rather broken
<seb128> slangasek, ok, noted, I will not argue over that, I will know for next time that the freeze limit is "freeze for what rt considers important" and not "freeze for uploads", my mistakes
<jbicha> I was addressing the regression potential
<seb128> -s
<slangasek> jbicha: I haven't and won't.  The point is that I don't think you've established that this won't regress for those using the theme in other contexts
<seb128> slangasek, that's different from the freeze rule for normal release btw
<slangasek> "no one has complained" doesn't establish that there are no regressions
<seb128> usually we don't punish uploaders because reviewers are behind
<jbicha> light-themes is actually one of the oldest pending precise SRU's; it was kicked out of -proposed because of paperwork
<slangasek> seb128: I don't think reviewers being behind was an issue here at all.  Based on the dates, it looks to me like these two packages were skipped over by several reviewers - probably for similar reasons that I've given for my own skipping
<seb128> slangasek, the rules (for unstable cycles at least) has always be "things uploaded before the freeze date will be considered"
<slangasek> jbicha: and I think the paperwork is still not in order, because you're saying "Other sessions could not be affected" and I don't see why that's true
<slangasek> seb128: I considered it
<slangasek> "consider" != "accept"
<infinity> slangasek: Well, it can only affect sessions that run gnome-panel...
<seb128> well, usually consider is accept or reject with a reason
<seb128> not "let it sit there ignored and miss the target"
<slangasek> infinity, jbicha: oh!  Sorry, I completely missed the *filename*
<slangasek> infinity, jbicha: pardon my blindness
<infinity> (Or things that pretend to be gnome-panel, which some other desktop environment sometimes do, but I assure you that they are SO broken with Ambiance/Radiance, that they can't be made worse)
<infinity> But Unity definitely does no such pretending anywhere.
<seb128> slangasek, anyway enough arguing, it's your call at the end, I will feel free to made a comment if one of the .1 reviews says that typing DVD in the dash returns nothing ;-)
<seb128> make
<slangasek> seb128: if you'd prefer, I can reject the totem one as not meeting the SRU criteria because it doesn't fix a "high-impact bug"; I was being nice by leaving it in the queue for future consideration
<infinity> seb128: Well, it's not like it can't be accepted immediately post-.1 anyway.
<seb128> infinity, well I just find it sad that a one line fix for an obvious usability uploaded a week before the given freeze date doesn't make it
<seb128> I guess it's my fault for trusting the date we were given
<infinity> seb128: I'm staying out of point release madness mostly intentionally, the above was mostly just an attempt to calm the tone of the channel. ;)
<seb128> that failed :-p
<infinity> Evidently.
<slangasek> seb128: if you think it's a high priority bug, mark it as such and stand by the claim.  But you won't succeed in talking me into treating it as a high priority if you don't consider it so yourself
<seb128> slangasek, define high priority, I think the cost-benefit ratio is High
<seb128> or rather the opposite, the benefit-cost ratio is High
<seb128> it's a one liner making a real usability impact
<slangasek> seb128: the SRU guidelines require both a high benefit-cost ratio, and also a high absolute benefit
<slangasek> this is sensible, because the SRU process itself has an opportunity cost
<seb128> slangasek, being able to find the Ubuntu DVD player for users, is that an High bug?
<slangasek> seb128: you tell me ;)
<seb128> I've no datas to backup my claim
<seb128> but I believe that typing "DVD" in the dash and having no result is a real usability issue
<seb128> we have so many bugs so I'm not sure I would rank up at the top of the list though
<seb128> but I consider it worth fixing
<seb128> deciding on bug settings is hard ;-)
<slangasek> if marking the bug 'high' in LP feels wrong to you, then accepting it as an SRU feels wrong to me
<slangasek> if you think calling it a 'high' bug is reasonable, I have no problem processing it instantly
<seb128> it's a matter of perspective
<slangasek> (the rhythmbox one, though, was not trivial and I wasn't comfortable trying to get that in before .1)
<seb128> I guess the design guys would put it at least High
<seb128> as an engineer I tend to put non segfault or data lost bugs a bit lower
<Laney> slangasek: If that little stack of SRUs isn't going in for some time, could you please remove transmageddon from proposed?
<seb128> slangasek, ok, well, pondering the cost-benefit I put it high
<seb128> slangasek, it's somewhat back to importance,priority meaning in bugs trackers and launchpad not having that
<seb128> slangasek, it's not always easy to conciliate different factors in one setting ;-)
<seb128>  
<seb128> Laney, slangasek: the mp3 is a bit more embarassing but I agree it's late
<slangasek> Laney: transmageddon seemed to be correct per se and I accepted the first iteration; is the second one somehow dependent on the rhythmbox changes?
<seb128> it basically means anyone converting a CD to mp3 will get crappy music
<Laney> It was sadly not correct
<slangasek> Laney: but it doesn't need to block on rhythmbox?  In that case I expect it will be processed
<Laney> it blocks on gst0.10-python which is on media so I expect will wait until after the point release
<Laney> unless RB gets pushed in, which will necessarily flush it out
<slangasek> ah, ok
<slangasek> Laney: so you want the existing one removed from -proposed, and the next one stays in the queue?
<Laney> please
<slangasek> Laney: done
<Laney> thanks
<stgraber> infinity: seems like there are at least 3 builds fighting for kapok on nusakan, so I guess I'll have test results somewhere in the next 3 hours ;)
<slangasek> infinity: do you know what's happening with the X packages in quantal-proposed?
<infinity> slangasek: Staging an xorg ABI transition, still not done.
<slangasek> what's not yet done?
<slangasek> last upload was 5 days ago
<infinity> slangasek: They missed some drivers in their first pass, I already chastised them for it this morning.
<slangasek> other than the ones they said they would drop?
<infinity> slangasek: They're also waiting on a new nvidia binary blob that's in the works, I believe.
<slangasek> hmm
<infinity> slangasek: Yeah, they missed a few that they're not dropping.
<slangasek> ok
<infinity> (Like the ARM-specific ones, one in multiverse... Maybe others)
 * slangasek reads his scrollback
<slangasek> ok cool
<infinity> Scrollback would be in #-devel
<slangasek> yep, just read it :)
<infinity> tumbleweed: Who do I whine to about the fact that reverse-depends(1) doesn't take virtual packages into account?
 * infinity had to fall back on checkrdepends to look for xorg-abi-whatever rdeps.
<slangasek> hmmmm unity's v-done and in the queue for 14 days
<slangasek> are people afraid to pull the trigger on that SRU? ;)
<infinity> slangasek: No, I would have released it yesterday, but I was, y'know, not at work.
<infinity> slangasek: I poked at it on the weekend, and it looked good to go, I believe, just didn't want to do a weekend release.
<stgraber> wow, it's been a while I haven't installed 10.04, the desktop and installer really changed quite a bit since then ;)
<infinity> stgraber: Hey, ubuntu/precise is finally building on kapok. :P
<stgraber> yay!
<phillw> stgraber: as the 12.10 are stable, what chances do you think 12.10 server will get broken? I'm just about to install a VM and am willing to use it.
<jbicha> phillw: 12.10 is still Alpha so no promises things won't break
<phillw> jbicha: which is the classic "chicken & egg". I believe that they are stable enough to be used, how else can we confirm that they are?
<jbicha> sure, how critical is it that your server stays up? how difficult would it be for you to fix things if they go wrong?
<infinity> phillw: By all means, use and test away.  My number one rule for testing pre-release is "never on hardware I don't have physical access to".  So, a VM certainly qualifies as "access" to the "hardware".
<jbicha> if the answer to both is "not very" then please go ahead and test :)
<phillw> it is going to be running a test installation of a mail server.
<phillw> I have always wanted to install http://flurdy.com/docs/postfix/ onto a system, i now have a reason to do so.
<slangasek> +       install -m 644 debian/dnsmasq.conffiles debian/daemon/DEBIAN/conffiles
<slangasek> speeewwww
<ScottK> "copy-package -s precise -p kubuntu-ppa --ppa-name=staging -b --to-suite=precise --to-ppa=kubuntu-ppa --to-ppa-name=ppa kdeplasma-addons" seems a bit unwieldy.  Would it be reasonable to assume from/to suite and from/to PPA owner are the same unless specified?  That'd tighten that up to "copy-package -s precise -p kubuntu-ppa --ppa-name=staging -b --to-ppa-name=ppa kdeplasma-addons", which seems almost reasonably compact.
<ScottK> If that seems OK, I'll make the change, but I thought it merited discussion.
<slangasek> I think that would be sensible.  I've hit the same annoyance with the "partner" options
<infinity> ScottK: I think assuming they're the same unless one of either to/from is specified makes sense.
<slangasek> infinity: "one of", not "both of"?
<slangasek> because that's the current problem; you have to specify both to+from when you want them to be the same but not equal to the default
<ScottK> It does slightly change the semantics since now that would copy to quantal.
<slangasek> for partner it's worse, it defaults to the main archive and you get an error about cross-partner copies being disallowed :-P
<infinity> slangasek: Oh, right.
<ScottK> But the change seems more sensible to me.
<ScottK> I sort of assumed it worked the way I'm proposing and ended up having to delete about 50 packages out of quantal for the target PPA.
<slangasek> cyphermox, stgraber: confusion on the dnsmasq SRU.  The dbus.conf I see here says only users root and dnsmasq are allowed to own the name; the NM instance runs as user nobody; how does the dbus policy actually do what it does?
<slangasek> cyphermox, stgraber: also, doesn't the NM dnsmasq instance owning the dbus name imply the possibility that an instance of the service started from the dnsmasq (not dnsmasq-base) package will regress because the name is taken?
<slangasek> or vice-versa, actually
<stgraber> slangasek: I'll let cyphermox answer the dbus policy question. I'm running the test packages here and it's definitely working (running as nobody)
<stgraber> slangasek: for the potential conflict, yeah, that's unfortunately an issue as we can't get multiple servers to listen at the same address. I believe cyphermox is discussing with upstream to make that configurable so NM's dnsmasq can have a different dbus path or something along those lines.
<stgraber> slangasek: the default setup as shipped by dnsmasq doesn't have dbus turned on and that package isn't shipped by default on any flavour, so yeah, there's a potential for breakage there but it should be extremely limited
<stgraber> not to mention that this scenario was completely broken at 12.04's release as it's only been a few weeks since we started introducing dnsmasq hooks in all packages using it to prevent conflicts with the one shiped in the dnsmasq package
<infinity> stgraber: kapok upgraded with your live-build fix, if you want to test-spin again.
<stgraber> infinity: thanks. started
<infinity> stgraber: If it verifies for us, I think I'll just push it through, so the other buildds auto-upgrade, since that's functionally no different than manually upgrading them all anyway. :P
<stgraber> sounds good to me, the sooner we have non-oversized images, the better
<slangasek> stgraber: ok; I'm not thrilled about introducing this prospective regression in SRU.  What are the odds we could get support for different dbus path as part of this SRU round?
<slangasek> I'd rather see us defer this until we can get it exactly right, than accept it with a known regression and then have to go back and redo it, now with conffile upgrade handling
<stgraber> slangasek: cyphermox should be able to answer that, though my guess is that it's unlikely to happen for 12.04.1 as it sounded like it'd need quite a bit of work on dnsmasq upstream's side
<slangasek> stgraber, cyphermox: oh, incidentally, now that I've looked at which NM bug this is for... I think I feel rather strongly that this is a wrong fix... the real bug, AFAICS, is that NM thinks *at all* that it needs to get involved each time there's an ipv6 route advertisement
<stgraber> I must admit not being thrilled by the fix for 12.04.1, I'd have much preferred fixing the real issue (NM badly interpreting some netlink events and respawning DNS when there's no config change) but was assured by cyphermox that fixing these would lead to backporting a huge chunk of NetworkManager that wouldn't be suitable for SRU
<slangasek> hmm
<stgraber> glad we agree ;)
<slangasek> so basically we'd fix the dnsmasq flapping problem
<slangasek> but would still leave users with unnecessarily full kernel routing tables
<stgraber> correct and that's all we'd be fixing
<stgraber> we'd still be getting extra routes in the routing table as that's considered "harmless" (I still don't like it...)
<stgraber> fortunately not a whole lot of people are being hit by that bug, but for these who are (like anyone on a network I manage), it's causing dozen of DNS failures a day as firefox seems to be surpringly good at poking dnsmasq exactly during the time it's being restarted by NM
<slangasek> heh
<stgraber> not to mention my average syslog is at 8k lines per day ;)
<stgraber> (a bit over 500 dnsmasq respawns)
<infinity> -rw-rw-r-- 1 cdimage cdimage 738504704 2012-08-07 20:58 20120807.3/precise-desktop-amd64.iso
<infinity> -rw-rw-r-- 1 cdimage cdimage 736407552 2012-08-07 22:00 20120807.4/precise-desktop-amd64.iso
<infinity> stgraber: ^-- That what you were hoping for?
<stgraber> my local one is 735830016 but yeah, close enough
<infinity> Might want to spin an i386 for paranoia's sake, since we haven't had one in a while.
<infinity> And amd64+mac looks like it should be identical in size, once respun.
<infinity> Err, spin an i386 after we release this to -updates, that is. :P
<stgraber> do we have the new live-build on the i386 builder?
<stgraber> right
<infinity> Which will have to wait a publisher cycle, since I just missed one.
<infinity> Be a dear and go v-done your bug? :)
<stgraber> done
<infinity> Right, so it'll hit -updates on-disk in about an hour.
<infinity> After that, any livefs build with auto-upgrade first.
<infinity> s/with/will/
<bdrung> slangasek: i was the uploader and regression potential writer of light-themes. sorry for not mentioning that the modified files are only used by gnome-panel
<stgraber> infinity: according to my e-mail, your pocket copy failed as the binaries weren't published at the time
<slangasek> bdrung: no worries, I should've read the diff better :)
<bdrung> slangasek: but it would have saved time
<infinity> stgraber: Oh, blah.  The publisher overran.
<infinity> stgraber: Fixed.
<ScottK> copy-package updated.
<ScottK> slangasek: I didn't test the partner change, but it should be fine.
<slangasek> famous last words
<slangasek> ScottK: thanks :)
#ubuntu-release 2012-08-08
<stgraber> infinity: hmm, i386 is still oversized (just did a rebuild), that's odd... I was expecting amd64 to be bigger than i386. Checking that the cleanup properly happened on it. If it did, I'll spend some more time tomorrow trying to figure out what's taking the space on it
<infinity> stgraber: It wasn't in the archive yet.
<stgraber> infinity: it was, at least according to rmadison
<infinity> stgraber: Or, nevermind.  I can't read timestamps.
<stgraber> anyway, /var/lib/apt/lists has been properly cleaned, so it's something else
<stgraber> for some reason our i386 image is indeed taking more space than amd64...
<infinity> Curious that i386 would be bigger.
<infinity> Same package set?
<infinity> +xserver-xorg-video-geode	2.11.13-2build1
<infinity> +libstlport4.6ldbl	4.6.2-7
<infinity> Oh, and i386 includes another locale (de)
<infinity> Dropping de from i386 would probably fix you.
<infinity> Not sure how much space each langpack set takes.
<stgraber> oh, I must have been blind... I checked for extra locales and missed that one apparently
<stgraber> that clearly explains it then
<stgraber> IIRC from my last try, a locale is around 6-7MB compressed space
<infinity> I'm curious about libstlport4.6ldbl, though...
<stgraber> geode + libstlport is roughly 1MB uncompressed
<infinity> It's in ubuntu-desktop on i386 only...
<infinity> Oh, ure depends on it on i386.
<infinity> Anyhow, dropping de is probably the right answer.  Having amd64 and i386 support different languages is weird anyway.
<infinity> stgraber: Seed change committed.
<stgraber> ok, thanks. I guess Seb probably won't complain too much about us dropping German when it already wasn't shipped on amd64
<infinity> Actually, wait.
<infinity> A seed change can't fix this, can it?
 * infinity scratches his head.
<infinity> Since we install ubuntu-live as a task, via apt-get, and changing the seeds won't change the Task headers in the release pocket..
<infinity> Oh, but we have new langpacks in -updates, and they'll trump that.
<stgraber> unless we magically end up pulling the old ones from the release pocket
<infinity> Might need to release a package to -updates to force a regen of the Packages files, though. :P
<stgraber> I can probably find one, wait a sec ;)
<infinity> accountsservice looks good.
 * infinity releases that.
<stgraber> sounds good, and that one is really useful as it should fix quite a few install failures
<infinity> If we need another one later, unity-greeter looks like another one that's ready.
<infinity> And python2.7
<stgraber> ubuntu-docs should also be fine, I just need to check that it still installs and that's about it
<infinity> Why do we have one langpack sitting in proposed?
<stgraber> according to rmadison, we have more than one
<infinity> All I see is en...
<stgraber> stgraber@castiana:~/data/code/seeds/ubuntu.precise$ rmadison language-pack-fr-base | grep precise
<stgraber> language-pack-fr-base | 1:12.04+20120417 |       precise | source, all
<stgraber> language-pack-fr-base | 1:12.04+20120508 | precise-updates | source, all
<stgraber> language-pack-fr-base | 1:12.04+20120801 | precise-proposed | source, all
<stgraber> I agree that pending-sru doesn't agree with that
<infinity> So, the sru report is on crack.
<stgraber>             # for langpack updates, only keep -en as a representative
<stgraber>             if (pkg.startswith('language-pack-') and
<stgraber>                 pkg not in ('language-pack-en', 'language-pack-en-base')):
<stgraber>                 continue
<infinity> Yeah, I just got there. ;)
<stgraber> nope, it's doing what it's supposed to, it's just not telling people on the page ;)
<infinity> Tempted to add a counter to that, and list "language-pack-en (and 731 others)"
<infinity> Or even better, just "731 language packs", and not list -en at all.
<infinity> Cause that code will fail miserably if we SRU a non-en langpack.
<infinity> It'll just "disappear".
<stgraber> sounds good. Wondering how much slower the script would be if it'd also extract the bugs from these and show a unique list of bugs for all the langpacks. (Assuming we might one day see a langpack fixing a bug)
<slangasek> the changelogs themselves are autogenerated
<slangasek> so I don't think so :)
<infinity> Only a manual update would ever fix a bug.
<infinity> Which we've had once or twice.
<infinity> But it's pretty rare.
<stgraber> anyway, disappearing for a couple of hours. If you want to kick an i386 build to test the seed change, have fun, otherwise I'll wait for cron to do that for me and check tomorrow.
<infinity> I'm considering a short nap.
<infinity> Which is, I agree, not as exciting as building ISOs, but it's right up there.
<cyphermox> slangasek: yes, there is the possibility that another instance might have dbus already, though no package currently ships such a configuration; it could be done by a user. that would constitude a regression then
<cyphermox> stgraber: ^
<cyphermox> slangasek: the reason I went with using dbus for dnsmasq rather than actually changing when NM restarts dnsmasq is that such changes have already been done upstream, but are rather very intrusive, some 14 or so commits in the upstream source repo
<cyphermox> disclaimer, I'm in a coffee shop on battery right now, not my usual place either, connection may be spotty.
<cyphermox> as for the routing table issue, I'm not certain it's an issue really, just different behavior on the kernel side.
<cyphermox> afaict the dbus config for dnsmasq works properly. I seem to recall seeing something about dnsmasq being started as root then dropping privs, not sure if that would actually explain why the policy works.
<cyphermox> supporting a different dbus name didn't look *hard* but does seem to involve some mucking around that I wasn't looking forward to doing; the code is pretty complicated; but it can be done.
<cyphermox> I could also just ask upstream to look into it, though that might take a bit of time
<infinity> stgraber: Hrm.  There might be more magic involved in manipulating tasks in post-release pockets (or it might just plain not be doable).  I think I'd rather ask Colin than try to trace it. :P
<stgraber> infinity: ok, I'll try to remember to poke cjwatson about it tomorrow before our team meeting, or during the team meeting if I forget :)
<stgraber> infinity: do we still have stuff requiring two publisher run to happen? I vaguely seem to remember that being the case in the past
<stgraber> slangasek: hmm, the cd dist upgrader is really in pretty bad shape... update-notifier-common uses patch but doesn't depend on it (in lucid at least) and even if it was there, it'd fail to apply the patches (not sure they're actually needed). Then it fails to resolve the upgrade and fails...
<stgraber> the cdromupgrade script on the cd at least doesn't have the patch bug, though resolving still fails
 * micahg looks around for infinity
<micahg> infinity: nevermind, will wait until morning
<slangasek> stgraber: update-notifier-common uses patch /at runtime/?
<slangasek> trippy
<slangasek> stgraber: does cddistupgrader run from within the package, not from the copy on the CD?
<tumbleweed> infinity: me. and patches are welcome
<tumbleweed> but whining at me won't do much right now. holed up in bed, sick
<jamespage> morning all
<jamespage> would an archive admin be able to review the walinuxagent package in the precise-proposed NEW queue please
<jamespage> this package is already in quantal; its required to enable use of azure IaaS on precise
<cjwatson> ScottK: your copy-package change makes sense to me.  (This is an example of UI that I thought was completely broken in the Launchpad scripts, but I was starting off the client-side versions with the same UI and figuring people would fix it once they got annoyed ...)
<cjwatson> stgraber,infinity: nothing runs germinate over stable series at all right now.  I'm not sure how we'd go about changing tasks post-release ...
<infinity> cjwatson: Well, I have a theory that if Task headers change in updates/proposed (ie: because of the combination of a seed change and a newer package version), then apt might honor that.  I haven't tested this theory.
<infinity> cjwatson: But yes, one would need to germinate for post-release pockets to make that work.
<infinity> (And it may still not work)
<cjwatson> If Task headers change, you might be right.  But right now I don't think they will.
<cjwatson> I guess we could fall back to installing metapackages if we have no choice ...
<infinity> No, they definitely don't change right now, because there's no germinating for non-devel releases.
<infinity> Installing metapackages seems like a potentially uglier hack than just removing langpack-de in a precise-only live* hack.
<cjwatson> Yeah.
<cjwatson> Hm, why does /srv/launchpad.net/ubuntu-archive/ubuntu-misc/more-extra.override.precise.main have a recent timestamp?
<cjwatson> Oh, cronscripts/publishing/cron.germinate fiddles with it for Supported overrides.
<cjwatson> You could edit /srv/launchpad.net/ubuntu-archive/ubuntu-misc/more-extra.override.precise.main in place when the publisher isn't running.  And then cry a little and file an LP bug that you had to.
<cjwatson> Probably best to do virtually anything else though ...
<infinity> Hahha, yeah, I'll pass on that.
<infinity> Removing the langpack by hand is less ugly.
<infinity> Or, at least, more auditable.
<cjwatson> Indeed.
<cjwatson> Somebody trying to figure out how it all worked later might have a chance of arriving at the answer.
<infinity> Speaking of overrides, have you noticed the frequency of apt-ftparchive whining about malformed overrides has gone through the roof?
<cjwatson> No - where?
<infinity> publisher logs.
<cjwatson> Hm, what's that about then
<cjwatson> Maybe a stupid line length limit?
<infinity> Dunno.  We always used to get a few of them here and there in older post-release pockets, but now we get a ton of 'em.
<infinity> I didn't spend much time looking at it, except to look at some of the whined-about line numbers to determine that nothing looked broken.
<cjwatson>    char Line[500];
<cjwatson> libmng1/powerpc Task    ubuntu-desktop, ubuntu-usb, kubuntu-desktop, kubuntu-active-desktop, kubuntu-active, edubuntu-desktop, edubuntu-desktop-kde, edubuntu-usb, xubuntu-desktop, mythbuntu-frontend, mythbuntu-frontend, mythbuntu-desktop, mythbuntu-backend-slave, mythbuntu-backend-slave, mythbuntu-backend-master, mythbuntu-backend-master, ubuntustudio-generation, ubuntustudio-video, ubuntustudio-audio-plugins, ...
<cjwatson> ... ubuntustudio-publishing, ubuntustudio-photography, ubuntustudio-graphics, ubuntustudio-recording
<cjwatson> -> 507 chars
<infinity> Oh, special.
<cjwatson> Note that the line numbers are off by one
<cjwatson> (Well, zero-based)
<cjwatson> Ahaha
<cjwatson> apt-cache show libmng1
<cjwatson> Task: ubuntu-desktop, ubuntu-usb, kubuntu-desktop, kubuntu-active-desktop, kubuntu-active, edubuntu-desktop, edubuntu-desktop-kde, edubuntu-usb, xubuntu-desktop, mythbuntu-frontend, mythbuntu-frontend, mythbuntu-desktop, mythbuntu-backend-slave, mythbuntu-backend-slave, mythbuntu-backend-master, mythbuntu-backend-master, ubuntustudio-generation, ubuntustudio-video, ubuntustudio-audio-plugins, ubuntustudio-publishing, ...
<cjwatson> ... ubuntustudio-photography, ubuntustudio-graphics, ubuntustudio-reco
<cjwatson> Truncation is *not* IRC's fault
<infinity> Oh, even more special!
<infinity> So it is actually causing a real-world bug then.
<infinity> Awesome.
<infinity> Bumping that buffer up to 1024 seems like it wouldn't be rocket surgery.
<infinity> Or some other arbitrary number.
<cjwatson> Yeah.
<infinity> SRU to precise (for if cocoplum ever gets upgraded), and backport to hardy-cat?  Profit.
<cjwatson> lucid-cat, I hope.
<infinity> Err, yes.  That one.
<stgraber> slangasek: from what I could see, inserting the cdrom prompts the user asking whether they want to start the package manager, upgrade or cancel. If they select upgrade, then the cdromupgrade script that's in /usr/lib is called, not the one from the media.
<stgraber> slangasek: and that one does runtime patching of files in the upgrader tarball and fails to do so either because of the missing patch package or because of the no longer valid patch
<stgraber> slangasek: in either case, the UI starts without any of the changes being applied, so no real harm done, luckily
<stgraber> then we have the problem that we are apparently missing around 400 packages on our media to make a succesful lucid to precise upgrade without internet usage
<stgraber> I attached the full package list to the bug. Quite a bunch are transitional packages (as expected) and a few are binaries and libraries for stuff that we dropped
<jamespage> please could walinuxagent be rejected from the precise-proposed NEW queue - I need to put a target architecture restriction on it...
<bjf> skaet: the precise kernel has passed all testing
<skaet> thanks bjf!  :)
<slangasek> stgraber: well, removing some of those old packages is also an acceptable outcome for an upgrade... it doesn't have to actually upgrade each of them
<xnox> slangasek: stgraber: from Ubiquity design doc. If there is no network the upgrade option is presented as "Upgrade Ubuntu to 11.04 [maps to reuse]
<xnox> Documents, music, and other personal files will be kept. System-wide settings will be cleared. Warning: Some installed software may be removed unless you connect to the Internet before continuing."
<slangasek> xnox: this is the alternate CD, not the desktop CD
<xnox> sure. I hope it still does give a ~ similar warning though?
<stgraber> xnox: yeah, it shows a warning
<cjwatson> It's more like the update-manager UI
<stgraber> can someone from the SRU team review mythtv in the queue please? it's targeted for 12.04.1 and has an MRE
<slangasek> looking
 * stgraber pokes queuebot
<stgraber> oh, stuck in LP authentication for some reason...
<micahg> infinity: was your overwrite of platform.quantal intentional (seems to have all the changes)?
<micahg> infinity: oh, sorry, not you
<micahg> zul: ^^
<zul> micahg: ?
<micahg> zul: your update removed 3 revisions and pushed one that seems to include all the changes
<cjwatson> Please use bound branches for the seeds
<zul> micahg: no it wasnt
<cjwatson> That way you won't find yourself having to merge
 * micahg just does a bzr pull before modifying anything
<cjwatson> You can convert your existing branch to a bound branch (aka checkout) using 'bzr bind :parent'
<cjwatson> Then a commit will (a) automatically push (b) refuse to commit if you're out of date
<game2> xnox / micahg, can you look at bug 1016438 ?  I was asking if it would make 12.04.1.
<ubot2> Launchpad bug 1016438 in precise-backports "Please backport btrfs-tools 0.19+20120328-3 (main) from quantal" [Undecided,Confirmed] https://launchpad.net/bugs/1016438
<zul> cjwatson: done
<micahg> game2: backports aren't tied to the point release schedule
<cjwatson> ta
<micahg> game2: let's move to -devel
<stgraber> yay, queuebot works again (not sure why the auth token suddenly became invalid...)
<slangasek> superm1: see #ubuntu-devel for mythtv review comments... looks like a FTBFS to me
<slangasek> oh, superm1 is here, that's not the highlight I meant to trigger ;)
<slangasek> stgraber: ^^
<stgraber> slangasek: http://paste.ubuntu.com/1136656
<stgraber> slangasek: the added Breaks in launchpad-lib indeed fixed that part of the issue, though there seems to be a pretty big mess around network-manager, gnome-bluetooth, gnome-settings-daemon and some icon themes (just looking at the last few lines)
<slangasek> stgraber: libnspr4 is at the root of it
<stgraber> slangasek: they don't seem to have direct conflicting contents, though they certainly provide the same library (libnspr4 has been multi-arched), should I try to downgrade that Conflicts to a Breaks?
<slangasek> stgraber: libnspr4-0d is a transitional package demoted to universe; libnspr4 in precise conflicts with the old one; evolution-data-server still wants libnspr4 apparently
<slangasek> Breaks would still mean "cannot configure", which would result in a similar failure to calculate the upgrade
<slangasek> ah, it's the old version of e-d-s... so it goes back even farther
<slangasek> libcamel-1.2-29
<slangasek> er, no, I'm getting tangled
<slangasek> ah, it's evolution-plugins
<slangasek> stgraber: please try the same trick here: have libnspr4 Breaks: old evolution-plugins to hint it out of the way
<stgraber> slangasek: ok, will try. I have the next batch of breaks if you want to have a look (tried by simply adding libnspr4-0d to my local archive to bypass that problem)
<slangasek> stgraber: Breaks: evolution-plugins (<< 3.2.0-0ubuntu2) should work
<slangasek> sure, hit me :)
<stgraber> http://paste.ubuntu.com/1136706
<slangasek> stgraber: that one looks like it might be easier... seed libgnome2-0 into the pool?
<stgraber> slangasek: "Fixing libnspr4:amd64 via remove of evolution-plugins:amd64" <- looks like that did the trick
<slangasek> tada
<slangasek> will you prepare uploads to these packages adding the Breaks?  I can review them today
<stgraber> yep, once I can get that upgrade running, I'll push the SRUs
<slangasek> excellent, thanks :)
<stgraber> slangasek: next batch: http://paste.ubuntu.com/1136717
 * stgraber will really need to commit that dist-uprader change to allow external repositories. Having to patch the code every time is getting annoying ;)
<slangasek> man, hardly seems like we're making any progress :P
<stgraber> hehe, yeah... I'll have to check with jibel that this kind of stuff is tested by QA a bit earlier next time so we have some time to fix the mess ;)
<slangasek> looks like none of the OOo transitional packages are on here
<slangasek> (for the libO rename)
<slangasek> so a bunch of those probably need added
<slangasek> how are we on size for the alternate?
<stgraber> we have around 3MB of free space, at least on the amd64 one
<slangasek> openoffice.org-emailmerge, openoffice.org-core look to be the key transitional packages; both should be small of course
<slangasek> you may need more of them to get an upgrade to libO instead of just a removal of OOo :P
<stgraber> except that openoffice.org-core doesn't exist in precise
<slangasek> really?
<slangasek> huh
<stgraber> yep, we have a whole bunch of transitional package but that's not one of them
<slangasek> so that's possibly unhelpful
<slangasek> ok; the openoffice.org package should be quick enough to SRU if we think we need it, since that's just the transitional packages
<stgraber> yay for having a source just for the transitional packages
<stgraber> I was kind of worried we'd need to upload libreoffice for that
<stgraber> building openoffice.org-core here, will add all the binary packages from openoffice.org to my local archive, see if that does the trick
<stgraber> slangasek: http://paste.ubuntu.com/1136755
<stgraber> I hope we won't need a lot of the openoffice transitional package because at 120K a package that's 21MB if we need the whole lot...
<slangasek> 120k?  eep
<slangasek> how is it 120k?  OOo-writer is only 4k
<infinity> slangasek: build-essential uploaded for bug #1034568 ... I'll let you and stgraber decide if it should be targetted to .1 or not (though I see no harm in letting it through)
<ubot2> Launchpad bug 1034568 in build-essential "build-essential shouldn't be Multi-Arch: foreign" [Undecided,Fix released] https://launchpad.net/bugs/1034568
<slangasek> infinity: cheers
<infinity> slangasek: Other than the bug closure in the changelog (and the version number), it's identical to the quantal version.
<infinity> stgraber: 120k?  I'm assuming that's a local build without a truncated changelog, or any other binarymangling magic?
<slangasek> ah right, that would do it
<slangasek> stgraber: yeah, the real packages are only one-inode-big after changelog truncation :)
<stgraber> oh, indeed I don't appear to have pkgbinarymangler installed, that'd explain it
 * infinity is strangely proud that his "mangler" namespace has survived all these years without someone insisting on renaming it to something more "professional". :P
<slangasek> stgraber: ok, this one's tricky.  vinagre was a dep of ubuntu-desktop in lucid; in precise it's been replaced by remmina.  But vinagre is still in the archive (in universe) so we can't just make it a transitional package
<slangasek> the ideal upgrade path here is to remove libvte9 and vinagre on upgrade
<seb128> slangasek, hey, what do you think it's the limit to take a decision on whoopsie on,off for LTS .1?
<seb128> slangasek, and do you have an opinion on who,how we will decide?
<slangasek> seb128: I think that's a decision that could be made up to the final freeze for .1.  However, I would much rather see the pain points addressed (which ev is working on) so that we can keep it enabled
<slangasek> seb128: from your perspective, what's the threshold we should be meeting to keep it enabled?
<stgraber> slangasek: do you know how to force the removal of libvte9 and vinagre in the dist-upgrader? I added both to the ForcedObsoletes list but that one seems to be used at a later point, so the initial resolving still fails
<slangasek> stgraber: I indeed do not have a good (clean) way to force their removal
<slangasek> I said that was the ideal... but I don't think the ideal is reachable here :)
<slangasek> an alternative is to bring libvte9 (the gtk2 version) into the pool
<slangasek> well, wait
<slangasek> the end of that log shows vinagre being removde
<slangasek> which is correct
<seb128> slangasek, sorry I got distracted by other thing ... threshold, it's difficult to say, we don't have enough number
<seb128> the discussions are mostly based on direct feedback, online comments, online article and personal experiences
<seb128> those brings info but we have no way to know if they are an accurate reflect of the majority's opinion
<seb128> slangasek, my gut feeling is that we still have way too many prompts for valid or buggy reasons and that this move is detrimental to Ubuntu's image rather than beneficial for the LTS
<seb128> this move = keeping whoopsie running
<seb128> users just hate being prompted about random issues
<slangasek> seb128: I don't think this is something that can reasonably be decided by gut feeling.  There will always be some number of users who are annoyed at seeing the prompts, and those are going to be the most vocal *about* the prompts
<seb128> slangasek, who would be in the project best placed to fix a target for an acceptable error prompt rate? the TB?
<slangasek> ultimately they would decide, if we can't agree ourselves :)
<seb128> what do you suggest is the best way forward to get to an agreement?
<seb128> it's a shame nobody cared to try to step up to do those whoopsie improvements earlier
<seb128> one week before .1 is very late to get any result
<slangasek> you didn't raise the issue until now
<seb128> (and I did discuss those issues with ev in private and raised them at .1 weekly meeting over a month ago)
<slangasek> ah
<seb128> slangasek, that's not true
<seb128> nobody picked them up
<seb128> I think I mentioned it in some of the release team summary email sent on friday for desktop as well
<seb128> it's just that until somebody does a fuss about it everybody is so busy that they get ignored
<seb128> well anyway it's late to argue on that, but I can show meeting logs where I raised it, and at several instance
<seb128> it just happens that nobody in the .1 meeting had an opinion
<slangasek> so let's pick a number that we think is acceptable for an "average" user interaction with whoopsie
<slangasek> and then we can figure out what it takes to achieve that
<seb128> works for me
<slangasek> is an average of 1 crash a week acceptable?
<infinity> I must be using my computer wrong, cause I haven't seen a whoopsie prompt in months. :/
<slangasek> I see them regularly
<seb128> infinity, ls /var/crash ... empty?
<infinity> seb128: Aye.
<slangasek> but I also am running quantal, and *want* to see them when things go wrong
<seb128> slangasek, 1 a week would be great, I would settle for around 3 to 5 a week
<infinity> seb128: 3 to 5 per week is likely where we're already at.
<slangasek> (and for several releases I haven't seen any problems with software crashing on session shutdown)
<seb128> infinity, we said average is 1.45/day
<seb128> no?
<infinity> (That previous assumption of 10 per week was based on reaaaaaly bad math)
<seb128> which is 10 a week
<slangasek> seb128: no, the average is 1.45/day /among users who report them/
<slangasek> on that given day
<seb128> slangasek, take in mind that apport cut out reports after 3 reports
<slangasek> the graph is misleading, as I said on the list; ev is working on getting is better data
<infinity> Yes, but it's per day, per-reporting-user.
<seb128> so that bias the stats a lot
<infinity> So, any user who has a day where the same thing crashes twice, boom.
<infinity> That's not 10 per week.
<slangasek> seb128: we don't know that it biases the stats a lot, we only know that it /could/ bias the stats a lot :)
<infinity> That's what we call someone who needs to take a statistics course. ;)
<seb128> slangasek, that's part of the issue, we have too much unknown s
<seb128> like how many report are dismissed
<seb128> how many are invalid and not sent
<seb128> how many are cut by outdated depends
<slangasek> we could also explicitly look at how many of the crashes are a user reporting the same crash three times
<slangasek> outdated depends should only affect launchpad bug reporting, not crashdb
<slangasek> the crashdb is meant to collect everything it can
<slangasek> precisely so that we have as much data as possible for the analysis
<seb128> ok
<seb128> so do we have an idea how many report the average user receive atm in the end?
<slangasek> so the only ones that won't show up are 1) crashes that have shown more than 3 times, 2) crashes the user has explicitly chosen not to submit
<slangasek> seb128: sorry, not sure what you're asking
<seb128> slangasek, you said "<slangasek> is an average of 1 crash a week acceptable?"
<seb128> slangasek, what's this number atm?
<seb128> i.e from where do we start?
<slangasek> we don't know, ev is generating another index across the database so we can answer this
<seb128> ok
<seb128> so I think we need to wait on that number to decide on an acceptable target
<slangasek> (s/index/mapping/, technically)
<slangasek> why do we wait?
<seb128> but yeah, 1 a week would be fine for me
<seb128> because we don't know where we stand
<seb128> maybe we are under 1 a week?
<slangasek> I think the target should be judged on its own right according to what we think is a reasonable experience
<seb128> I would say 3 a week is fine
<seb128> 1 is better
<slangasek> the only reason to wait is if we're starting from the assumption that the current rate is too high even though we don't know what it actually is ;)
<seb128> if we are over 3 we need to do something
<seb128> my guess is that we are >> 3
<seb128> (I'm not a normal user, bug I can't start a guest session here without having one for example)
<slangasek> my guess is very different :-)  but for my part, I'm happy to agree that 3/week/user is a reasonable limit for the average
<seb128> ok, let's agree on 3 then
<seb128> what's next? ;-)
<slangasek> next is to get the results of ev's query
<slangasek> and see where we are vs. that limit
<seb128> ok
<slangasek> and discuss ways to reach it
<seb128> any ETA for that?
<slangasek> ev: ^^ do you know when we can expect the new mapping to be done?
<slangasek> seb128: my shot-in-the-dark ETA is "this week"
<seb128> which still work for the "take a decision on time for .1"
<seb128> the hard freeze is end of next week
 * slangasek nods
<slangasek> btw, how does apport even know the same crash has been seen 3 times?
<slangasek> since /var/crash itself is periodically emptied
<seb128> what is the period?
<slangasek> weekly
<seb128> it has a counter in the .crash
<seb128> it's to avoid having the same issue nagging you every 10 minutes until end of time
<seb128> so it's 3 times by week :p
<slangasek> right
<slangasek> so in fact, if we're taking an average over 90 days, the apport limit is probably not a factor
<seb128> well, ev is talking about removing it because he considers it a bug
<seb128> it could make some issues pop a lot more
<seb128> like you could go from 3 prompt a week to 25 because of 1 bug
<slangasek> right... I think there would be push-back against making that change in an SRU
<seb128> yeah
<seb128> hum, need to get online, be back in a few minutes
<seb128> re
<stgraber> slangasek: hmm, can't figure out what's going on with vinagre, so looking at the hpijs/libhpmud0 one for now...
<slangasek> yes, I think the vinagre part may be a red herring entirely
<slangasek> actually, I'm not sure either of those should be fatal for the upgrade calculation
<stgraber> oh, actually the log is telling me why
<stgraber> "The package 'screen-resolution-extra' is marked for removal but it is in the removal blacklist."
<stgraber> though that error is just plain weird... the package isn't part of a default install on precise, so I'm not sure why it's part of the blacklist
<stgraber> "blacklist expr 'screen' matches 'screen-resolution-extra'" <- that'd be why...
<stgraber> changed to ^screen$, retrying with that
<stgraber> slangasek: success!
<slangasek> sweet :)
<stgraber> well, it's failing because my local archive isn't signed, but I'm taking that as a sign that the resolution part worked
<stgraber> ok, so we "just" need an SRU of launchpadlib-integration, nspr, seeding libgnome2, adding openoffice.org-core to openoffice.org + seed some of these and update update-manager
<stgraber> sounds trivial ;)
<slangasek> yep! :)
 * stgraber adds bug tasks
<slangasek> all in a day's work
<slangasek> for the launchpadlib-integration and nspr SRUs in particular, I think the regression-test should include a full run of jenkins upgrade testing
<slangasek> both o->p and l->p
<stgraber> sounds good
<stgraber> I'll also add a depends on patch to the upgrader as it's clearly using it (the fact that it fails just happens to be another bug)
 * slangasek nods
<scott-work> skaet:  for 12.04.1, do we need to report test results on iso.qa website?
<skaet> scott-work, yes please.
<skaet> please report under precise-daily
<scott-work> if so, are the daily images (and therefore the test cases) changing daily as well?
<skaet> scott-work,  images are changing daily,  but we can look at it historically and see over date range.
<scott-work> skaet: copy that, thank you
<bkerensa> =/
<bkerensa> The requested URL /ubuntu/dists/quantal/main/dist-upgrader-all/current/DevelReleaseAnnouncement.html was not found on this server.
<bkerensa> ?
<slangasek> bdmurray: ^^ anything to do with your meta-release changes today?
<slangasek> bkerensa: what were you doing when you saw this message?
<infinity> slangasek: No, it has to do with the last upload of the dist-upgrade being broken.
<slangasek> ah
<bkerensa> slangasek: why I was upgrading a system to 12.10 of course
<bkerensa> :D
<infinity> Someone didn't run pre-build.sh (or it failed to do what it's meant to).
<bkerensa> ahh I better not upgrade then
<bkerensa> =/
<stgraber> infinity: I'm about to do a dist-upgrader upload to quantal
<stgraber> (for another bug)
<infinity> stgraber: Great, make sure pre-build.sh DTRT, then. :P
<infinity> And the above bug will be solved at the same time, and everyone can rejoice.
<bdmurray> slangasek: no and I'm fixing it now
<bkerensa> can someone ping me when dist-upgrade is working :) it would be much appreciated
<slangasek> ok :)
 * bkerensa should just subscribe to quantal-changes
<slangasek> bkerensa: that error only pertains to the release notes, which should certainly not impact the upgrade unless there are other bugs
<infinity> bdmurray: You and stgraber both seem to be fixing it. :P
<bkerensa> <infinity> slangasek: No, it has to do with the last upload of the dist-upgrade being broken.
<bkerensa> <slangasek> ah
<bkerensa> ^
<bkerensa> so its just release notes?
<infinity> bkerensa: Yeah.  As in, the source package didn't contain the html files.
<bkerensa> ah
<bkerensa> kk
<bdmurray> infinity: I'll stop then
<cjwatson> ScottK: Hm.  A thought about your copy-package change.  How is one now supposed to copy from a PPA into the primary archive?
<cjwatson> ScottK: See e.g. https://wiki.ubuntu.com/ArchiveAdministration#Publishing_packages_from_the_ubuntu-mozilla-security_public_PPA (which I was about to update to drop the .py until I noticed this problem).
<ScottK> Give me just a minute and I'll look.
<cjwatson> I wonder if we need a --to-primary switch or something.
<cjwatson> Also, --to-partner should probably suppress the default propagation of --ppa to --to-ppa, and vice versa.
 * stgraber wonders if he'll ever get one of mvo's pre-build.sh to run fine the first time around
<ScottK> cjwatson: I was considering that if --to-ppa-name was missing, one could assume it was to the primary archive, but I like --to-primary better as I think it's good to be explicit about that.
<ScottK> I can implement that and the partner changes, probably tonight.
<cjwatson> Excellent, vociferous agreement.  Thanks.
<cjwatson> I just removed copy-package.py from LP, so I was checking for leftovers ...
<cjwatson> http://people.canonical.com/~cjwatson/tmp/loc-cum.png attempting to leave a decent-sized mark in the LP codebase size
<cjwatson> Hmm.  scripts/ftpmaster-tools/obsolete-distroseries.py seems like the sort of thing perhaps best not exposed over the API.
<cjwatson> Then again, derived distros, maybe.  But I don't think I've ever run that on Ubuntu ...
<ScottK> Right, so if there isn't a commit from me tomorrow morning, please re-ping me.  I'm about to go out for dinner and should be able to have a look after.
<cjwatson> OK.  Thanks again.
<stgraber> infinity, bdmurray: debdiff between what I'm uploading to quantal now and the previous version is quite big, but comparing to the one before that, it looks reasonable, so I "think" I did the right thing and we're back to a working source package :)
<stgraber> now to try to achieve the same thing with the precise one...
<stgraber> gah... wth did someone thing it was a good idea to check that the update-manager test suite is a child of a process called "init"?
<stgraber> running in arkose, pid 1 isn't called init!
<infinity> stgraber: That's a bizarre check...
<stgraber> yeah... anyway, bind mounting a file on /proc/1/cmdline should do the trick for now
<stgraber> oh nice ... the release upgrader in quantal FTBFSed ...
<stgraber> (obviously it's building fine on my machine, wouldn't be fun otherwise)
<stgraber> ah, caused by the LANG=C on the builder
<stgraber> oh, I know what the bug is ;) apparently you're not allowed to have unicode in your name...
 * stgraber changes name quickly to test an easy workaround
<bkerensa> anyone by chance know which package dist-upgrade is?
<cjwatson> ubuntu-release-upgrader, in quantal
<cjwatson> it used to be in update-manager
<bkerensa> kk
<stgraber> cjwatson: any idea on how to quickly fix ubuntu-release-upgrader's setup.py to not explode when parsing my name?
<stgraber> (or I'll just drop the accent and upload, I don't really care that much)
<cjwatson> Can you show me how to reproduce the explosion?
<bkerensa> cjwatson: any idea how to file bugs against it? When I ubuntu-bug ubuntu-release-upgrade it says package does not exist
<cjwatson> Spell it correctly.
<cjwatson> (missing "r")
<bkerensa> same problem
<bkerensa> Package ubuntu-release-upgrader does not exist
<cjwatson> Maybe it needs a binary package.  Try ubuntu-release-upgrader-core.
<bkerensa> k
<bkerensa> bingo
<stgraber> cjwatson: have some utf-8 (like my Ã©) in debian/changelog, run python3 setup.py with LANG=C
<stgraber> cjwatson: setup.py calls "dpkg-parsechangelog --format rfc822" which returns my name in the Maintainer field and crashes the python script
<infinity> stgraber: Get a less French name.
<bkerensa> :D
<knome> stgraber, Ã© <3
<cjwatson> Odd; I wonder why universal_newlines=True isn't sufficient there.
<bkerensa> stgraber: we could just call you Stephan Graber ;)
<Laney> Grubby Steven
<cjwatson> Oh, universal_newlines decodes using locale.getpreferredencoding() and there's no way to override that in subprocess.  Sigh.
<cjwatson> stgraber: Er, for now, try using LANG=C.UTF-8 instead?
<cjwatson> That's guaranteed to exist and should avoid this.
<stgraber> cjwatson: tell that to the buildd ;)
<cjwatson> You can do that in debian/rules ...
<stgraber> I guess I can override in debian/rules
<cjwatson> That's a grotty awkwardness with python3 subprocess, though.
<stgraber> bdmurray: hmm, looks like you forgot to commit your precise-proposed upload to the bzr branch...
<stgraber> (for update-manager)
<bdmurray> stgraber: oh, let me look
<stgraber> bdmurray: well, I'll fix the branch for you as I already commited a bunch of changes
<bdmurray> stgraber: thanks, sorry about that!
<stgraber> gah ... apparently not only are the builders setting LANG=C but also LC_ALL=C ... will need one more upload to fix that mess then (I only exported and tested LANG)
<stgraber> can someone please reject that upload ^ I'm going to send a new one with the right -v as there's already an upload in the queue
<infinity> stgraber: Sure.
<stgraber> and re-uploaded
<stgraber> slangasek: that's all the packages for bug 1029531 uploaded to precise and quantal (when applicable). If you're still planning to review today, everything's ready.
<ubot2> Launchpad bug 1029531 in update-manager "cdromupgrade from Lucid to Precise failed with unmet dependencies without network connection" [Critical,In progress] https://launchpad.net/bugs/1029531
<stgraber> I'm going out for a while but should be back around in a couple of hours.
<stgraber> yay, ubuntu-release-upgrader actually built this time around!
 * stgraber -> out
#ubuntu-release 2012-08-09
<babyface> jamespage, hi James,   precise-server-ec2-daily  test are unstable, and some test case failed.    http://10.98.0.1:8080/view/Precise/view/ISO%20Testing/job/precise-server-ec2-daily/ARCH=i386,REGION=us-west-2,STORAGE=instance-store,TEST=proposed,label=ubuntu-server-ec2-testing/170/
<ScottK> Anyone using copy-package for PPA to PPA copies that had yesterday's update should update again.
<ScottK> cjwatson: copy-package update done.  Found a bug in my work from yesterday that would have resulted in accidental copies to the main archive which I've fixed.  Also added the target archive to the confirmation dialogue so that kind of thing is visible in the future.
<ScottK> (plus did the changes we discussed)
<cjwatson> ScottK: brilliant, thanks
<jamespage> babyface, transient issue - don't worry about it :-)
<babyface> jamespage, ack. actually, I'm not watching and triaging the result of the ec2 jobs,  but I think it's good to let you know the status of it, due to maybe you don't watch the job everyday.  ;)
<jamespage> babyface, utlemming keeps a closer eye on them
<jamespage> babyface, we are going to shift that testing to be part of the image publication process - so Image's won't be made public unless they pass
<babyface> jamespage, cool
<ev> seb128, slangasek: my intention is not to remove the 3 crash limit as an SRU. It would be a quantal or later thing. I raised removing it only because we were talking about the existence of the limit.
<seb128> ev, hey, just replied to your email with my issues
<ev> seb128: heh, just replied on #ubuntu-devel
<seb128> ev, sorry I though we were on -devel :p
<smartboyhw> Hi!
<skaet> slangasek,   stgraber -  can manual builds be done today to test out the update fixes rather than waiting for the daily build tonight?
<skaet> is it just a matter of waiting a day?  (thought the fix sounded close, based on the meeting)
<slangasek> stgraber: before the -7 days> my biggest concern there is whether there will be further SRUs accepted that need to be on the CDs to be fully validated
<slangasek> skaet: we can certainly fire them off manually
<stgraber> slangasek: I'm not aware of any installer fixes that would still need to land, though we might have some more upgrade related fixes
<stgraber> slangasek: can you look at openoffice.org in New?
<slangasek> stgraber: accepted
<stgraber> jibel: confirmed that it's still blocking on launchpad-intergation, probably because it's missing one package on the alternate media to get the upgrade path
<stgraber> I'm going to try and figure out which one as having them all definitely solved the upgrade yesterday
<slangasek> jibel: I said to stgraber that these added Breaks: on library packages in SRU needed a regression test of a full jenkins upgrade auto-test for o->p and l->p; does that happen automatically right now using the packages in -proposed, or if not, could you get us one manually?
<jibel> slangasek, auto-upgrade tests are currently setup to upgrade with -proposed enabled.
<slangasek> jibel: ok cool, thanks
<stgraber> slangasek: easiest way out of the remaining launchpad-intergation mess seems to be to seed liblaunchpad-integration1.0-cil and liblaunchpad-integration1. Both are in main, total disk usage would be 26K
<slangasek> stgraber: ah, you had added liblaunchpad-integration1.0-cil to your local repo for testing?  Sure, that seems reasonable
<stgraber> slangasek, jibel: I have the list of all missing packages on alternate now, most of them are pretty small. I'll now update the seed and respin to confirm that actually works
<stgraber> slangasek: yeah, I had all the binary packages for the sources I was messing with, that was obviously a mistake as that's now causing some more failues that I should have seen yesterday...
<stgraber> slangasek: hmm, that's interesting. Apparently with my current list of extra packages (libgnome2-0, liblaunchpad-integration1.0-cil and libnspr4-0d) I don't need the new openoffice.org-core
<stgraber> will spin a media with just these added, then run the upgrade and see what happens to openoffice/libreoffice, we might still need it to get something kind of reasonable post-upgrade
<stgraber> slangasek: hmm, looks like we'll need something more clever... adding the -cil package made germinate bring half of mono with it
<stgraber> making the media oversized
 * stgraber checks that it at least works
<slangasek> ah yuck
<slangasek> how did that work for you locally then?
<stgraber> apparently the upgrader didn't mind having the new -cli but the old mono
<dpm> hi all. So the language packs for 12.04.1 have been signed off and the ones that have been can be moved from -proposed to -updates. I generally give the list onhttps://wiki.ubuntu.com/Translations/LanguagePackUpdatesQA#Test_results_Ubuntu_12.04_.22Precise_Pangolin.22 to pitti and he does the uploads. Who can help me with that in his absence?
<skaet> slangasek, ^ can you help?
<stgraber> dpm: what happens to these that haven't been tested? do they stay in proposed, get removed from proposed or get copied without explicit sign-off?
<stgraber> I'm wondering as the signed off list is much shorter than the list we currently have in proposed
<dpm> stgraber, good question. Generally we only get a bunch of people testing langpacks, and we upload only those signed off to -updates. The rest (I believe) remain in -proposed for a while for late-comers, as it's my understanding that it's relatively trivial to copy them to -updated. Otherwise, it should be safe to remove them
<stgraber> cjwatson: welcome back to civilisation!
<cjwatson> 14 days
<cjwatson> sorry, 16 days
<slangasek> heh
<slangasek> cjwatson: welcome back ;)
<ScottK> me wonders where cjwatson  went?
<cjwatson> I've been on mobile internet, coffee shops, etc. for the last two weeks due to a DSL outage.
<ScottK> Oh.  Right.  I knew that.
<ScottK> Welcome back indeed (said with full irony from a coffee shop.
<cjwatson> Judging by my ISP's fault ticket, if it goes down again it's probably because they didn't realise it's up.
<ScottK> Nice.
<stgraber> slangasek: hmm, just realized I can't seed libnspr4-0d that easily... the binary package is in universe
<micahg> what is that package actually needed for?
<slangasek> stgraber: er, libnspr4-0d wasn't supposed to be part of it anyway, the Breaks was added to libnspr4 right?
<infinity> stgraber: The source is in main, we can certainly promote the binary in post-release pockets.
<infinity> stgraber: (Assuming it's needed, which perhaps it's not, from slangasek's comment)
<stgraber> micahg: contains compatibility symlinks for libnspr4
<stgraber> slangasek: yeah, it's another case that we didn't see as I had all the nspr binaries in my local archive. Let me give you the upgrade log when that one is missing
<micahg> oh, hrm, sorry, I thought we inherited that from Debian...I guess it was the main package before
<stgraber> slangasek: http://paste.ubuntu.com/1138051
<cjwatson> dpm: AFAIK only you, pitti, and maybe one or two other people have access to the system that builds the source packages and does the uploads
<cjwatson> dpm: That system should I think have sufficient privilege to do them though?
<infinity> cjwatson: They're already in proposed, he's talking about migration to updates... I think.
<stgraber> cjwatson: the packages are already in -proposed, the current step is to pocket copy them to updates
<stgraber> gah, infinity was faster
<skaet> :)
<cjwatson> Ah
<infinity> stgraber: That time you took to add "-" to proposed cost you precious miliseconds.
<dpm> cjwatson, yeah. I can do the uploads for someone to sponsor them to -proposed. Now it's about moving them to -updates
<cjwatson> In that case surely it's just a giant sru-release call
<cjwatson> http://bazaar.launchpad.net/~ubuntu-langpack/langpack-o-matic/main/view/head:/doc/operator-guide.txt
<cjwatson> linked from ArchiveAdministration
<cjwatson> Did pitti really not just copy all the langpacks?  That actually kind of surprises me
<cjwatson> I guess not based on https://launchpad.net/ubuntu/+source/language-pack-ja
<cjwatson> dpm: Is there a -base refresh in here?
<dpm> cjwatson, yeah, it's a full langpack upload
<cjwatson> In that case I'm very wary of copying -gnome without -kde or vice versa
<cjwatson> In case I end up breaking dependencies
<cjwatson> I'd rather copy a whole language at once
<dpm> cjwatson, I think pitti copies only the gnome or kde one that has been signed off, but I'm not 100% certain. In any case, I think it should be safe to copy the whole language too
<cjwatson> Are you prepared to sign off on me copying language-pack-{gnome-,kde-,}{en,ug,fr,hr,uk,de,sl,nl,zh-hans,zh-hant}{,-base} ?
<cjwatson> Think I got all the language codes right
<cjwatson> Oops, I read the wrong section
<cjwatson> I wish this were listed by code
<cjwatson> language-pack-{gnome-,kde-,}{en,ca,fi,uk,sl,es,fr,hu,it,hr,ga,ug,nl}{,-base} ?
<dpm> yep, double-checked and the list looks good
<cjwatson> Running
<dpm> thanks cjwatson
<stgraber> slangasek: confirmed that current alternate + libnspr4-0d => resolver happy
<slangasek> stgraber: ah, ok
<slangasek> infinity: ^^ will you promote this then? :)
<stgraber> though I'll still have to revert the launchpad-integration -cli addition and find some other way around that problem as I don't want the alternate to be oversized :)
<cjwatson> dpm: Done, pending the next publisher run
<dpm> excellent, thanks again cjwatson
<infinity> slangasek: Consider it done.
<infinity> stgraber: libnspr4-0d will be in main (in proposed) after the next publisher.
<seb128> ^ could that d-conf upload be consider for .1?
<stgraber> infinity: thanks
<seb128> also the compiz is the queue should be reviewed
<stgraber> seb128: what's it fixing?
<seb128> dconf?
<seb128> or compiz?
<stgraber> dconf
<seb128> compiz is an update of the current proposed one with a fix for the arm* ftfbfs
<stgraber> I know that compiz is just the armel/armhf fix
<stgraber> and should indeed replace the one currently in proposed
<seb128> stgraber, a bug which makes unity-2d just segfault when used on a machine with a dconf profile with multiple databases
<stgraber> slangasek: in theory after the next publisher run + respin, alternate should be back to CD-size and work for upgrades
<stgraber> slangasek: a quick test showed that I can drop liblaunchpad-integration1-cli and just seed liblaunchpad-integration1, making the resolver happy and avoiding the inclusion of all of the mono packages
<slangasek> huzzah
<stgraber> I still have no idea what the system will look like post-upgrade though ;)
<SpamapS> Sorry for seeming a bit out of touch, but are we only accepting super high-priority stuff into precise-proposed now?
<stgraber> SpamapS: yes, only things that got an exception or were uploaded before the 2nd of August 21:00 UTC
<SpamapS> ok. d-conf is one of those things then. :)
<stgraber> yep
<slangasek> bug #1034806 puzzles me
<ubot2> Launchpad bug 1034806 in aptdaemon "aptd crashed with UnicodeDecodeError in _emit_acquire_item(): 'ascii' codec can't decode byte 0xd0 in position 0: ordinal not in range(128)" [Medium,New] https://launchpad.net/bugs/1034806
<stgraber> SpamapS: mythtv is also one of these and I see was re-uploaded recently
<slangasek> it's a top crasher for the day and for the month.  It's also apparently *not* the one cjwatson just fixed in aptdaemon SRU
<slangasek> SpamapS: the only diff in the new mythtv upload vs. the old one should be a dropped line from the .install file that fixes a FTBFS
<slangasek> SpamapS: provided that's the case, I've already reviewed it and it should be good to go in (but I don't have time to check that myself at the moment)
<cyphermox> slangasek: so, if I address the dbus name issue RFN, you think bug 1004775 would be fine for 12.04.1
<ubot2> Launchpad bug 1004775 in network-manager "NetworkManager restarts dnsmasq and adds host route on every IPv6 route lookup" [High,Fix released] https://launchpad.net/bugs/1004775
<cyphermox> ?
<slangasek> cyphermox: yes... I still think the clutter in the kernel table is bad, but that would at least satisfy my concerns of regression
<cyphermox> ok
<cyphermox> clutter in the routing table: it's not pretty, I agree, but it's not know how to fix this.
<cyphermox> there was a patch for the default route that addresses this but it's already in precise. or at least supposed to be
<slangasek> ah, ok
<cyphermox> yup, it's in 0.9.4.0-0ubuntu4.1
<slangasek> stgraber: unassigning bug #1034794; live-initramfs is a universe package not used by any of our builds, the set of affected people is likely to be very small
<ubot2> Launchpad bug 1034794 in update-manager "10.04 -> 12.04 upgrade should remove live-initramfs" [Low,New] https://launchpad.net/bugs/1034794
<stgraber> slangasek: works for me. jibel raised that one during the 12.04.1 meeting
<SpamapS> slangasek: ok, new mythtv reviewed, it is indeed just one removed line
<SpamapS> -debian/30-mythtv-sysctl.conf etc/sysctl.d
<SpamapS> slangasek: so, thats good to accept, yes?
<slangasek> SpamapS: yep
<stgraber> slangasek: success! latest alternate build fits on a CD and contains everything needed for the upgrade
<stgraber> now checking that the upgrader tarball works too (instead of using my heavily patched copy)
<skaet_> :)
<stgraber> jibel: confirmed, precise.tar.gz is indeed the one from the release pocket, not from -proposed (or -updates)
<stgraber> so we need to fix that too
<stgraber> looks like upgrade.sh needs some updating to look at the other pockets
<stgraber> infinity, cjwatson: does that look sane to you? http://paste.ubuntu.com/1138274/
<slangasek> cjwatson: bug #1034806 on aptdaemon is definitely looking suspicious to me as a possible SRU regression.  errors.u.c says it was "first seen" in 0.43+bzr805-0ubuntu1, but all but one of the crash reports are from today
<ubot2> Launchpad bug 1034806 in aptdaemon "aptd crashed with UnicodeDecodeError in _emit_acquire_item(): 'ascii' codec can't decode byte 0xd0 in position 0: ordinal not in range(128)" [Medium,New] https://launchpad.net/bugs/1034806
<infinity> stgraber: Why the for loop?  Don't you just want one or the other?
<dobey> micahg: i don't see that discussion?
<micahg> dobey: not your case specifically, but regressions in general, see above
<dobey> oh, more general regressions
<dobey> actually, what i'm hitting isn't a regression exactly
<stgraber> infinity: I'm breaking after the first it finds. The loop is there because I can't assume we'll always have one in the updates or proposed pocket
<stgraber> as a one time trick for precise I could certainly just hardcode -proposed and switch to -updates whenever we change the rest of the images, but there's no good reason not to make that change generic enough that it can be applied to quantal as well
<infinity> stgraber: Would make more sense to just set $POCKET based on if it has anything in it, than the convoluted for/break... Though the end result is the same, I suppose.
<stgraber> infinity: indeed, I can do that
<infinity> Or, rather, set SOURCEDIR based on if there's anything in the descending set of pockets.
<infinity> Also, I'm loving the gratuitous use of ls there...
<infinity> Not that that's your code. :P
<infinity> But if you change the SOURCEDIR setting to be based on walking the possible options, and setting it iff there's something found, then you can drop the ls and use if [ -n "$SOURCEDIR" ]
<infinity> That feels a little bit more readable/maintainable to me, but YMMV.
<infinity> Unless SOURCEDIR is used later in the script.
<stgraber> infinity: http://paste.ubuntu.com/1138303/
<stgraber> infinity: full script: http://paste.ubuntu.com/1138304/
<infinity> stgraber: How and where does PROPOSED get set?
<stgraber> infinity: PROPOSED is an environment variable that's pased when calling for-project, I'm kind of hoping nothing resets it later on (haven't tested that it makes its way to upgrade.sh)
<infinity> Kay, you could drop the whole UPGRADER_POCKETS block
<infinity> And just do "for POCKET in ${PROPOSED:-$CODENAME-proposed} $CODENAME-updates $CODENAME"
<infinity> Err, but inverting the test. :P
<infinity> ${PROPOSED:+$CODENAME-proposed}
<stgraber> wouldn't that fail if PROPOSED is set to 0?
<infinity> Does that happen?
<infinity> (But yes, it would)
<stgraber> well, all the other places where we test PROPOSED seem to consider 0 as a possible value, so I guess it can happen
<infinity> Curious.  I've only ever seen us set it or not, not set it to naught.
<infinity> But fair enough.
<stgraber> doing a test run on precise, if that works, I'll apply the change to quantal too
<infinity> That feels backwards. ;)
<infinity> (But makes sense in this case, since quantal has no post-release junk)
<stgraber> hehe, yeah, but we're missing an upgrader in -updates for quantal ;)
<stgraber> right
<jibel> I just confirmed bug 1034668, that's probably something we want fixed for 12.04.1. I'll upload the logs
<ubot2> Launchpad bug 1034668 in update-manager "Upgrade from Lucid to Precise does not install packages for Global Menu: indicator-appmenu" [Undecided,Incomplete] https://launchpad.net/bugs/1034668
<stgraber> bdmurray: ping
<seb128> is there any chance http://launchpadlibrarian.net/112345416/ubuntuone-installer_3.0.2-0ubuntu1.1_source.changes gets consider for 12.04.1?
<seb128> it fixes the most frequently reported issue on today's errors.ubuntu.com
<bdmurray> stgraber: hi
<stgraber> bdmurray: your apt-clone change seems to be broken, just found about that now that we have an updated update-manager on the media
<stgraber> bdmurray: let me paste you the stack trace
<stgraber> bdmurray: http://paste.ubuntu.com/1138397
<stgraber> bdmurray: I'm also having a look at it, so if you're too busy I can probably figure it out and fix it
<bdmurray> stgraber: i can sort it out
<stgraber> bdmurray: my current guess is a python2.6 vs python2.7 syntax change
<bdmurray> stgraber: i agree
<stgraber> bdmurray: I have a system where I can extremely easily test a fix, so feel free to send the new .py my way for testing
<stgraber> I guess using two separate "with" statements should be the easiest
<bdmurray> stgraber: I used f = open(sources, 'r') and f.close() after the for loop and it seemed to work
<stgraber> yep, that works too
<seb128> did anyone from the SRU or .1 team read my comment about ubuntuone-installer's precise SRU?
<stgraber> bdmurray: can you upload that to -proposed now (using -v0.2.2 to include the previous changelog entry)?
 * stgraber prepares to rebuild update-manager once again
<stgraber> seb128: looking at the diff
<bdmurray> stgraber: is there a bug report for apt-clone?
<stgraber> bdmurray: I don't think so, I'm probably the only person who tried the precise SRU on lucid at this point
<stgraber> seb128: gah... I was sort of hoping for a bugfix only release...
<seb128> stgraber, talk to dobey if you think only one of the fixes should be backported?
<dobey> hrmm?
<stgraber> dobey: as you know we're a week past the 12.04.1 upload deadline and your upload includes quite a bit more than just the fix we want for 12.04.1
<dobey> stgraber: actually, i didn't know the dates exactly for that; have been a bit out of touch with 12.04.1 info as i've been swamped with stuff for our new version of ubuntu one and shipping it in quantal
<bdmurray> stgraber: uploaded apt-clone
<Laney> please could somebody move glib2.0 to release?
<stgraber> bdmurray: thanks
<stgraber> slangasek: can you review apt-clone?
<infinity> Laney: Sure.
<Laney> cheers boss
<dobey> stgraber: also not sure who you mean by 'we' there. 'we' as in 'ubuntu one' want all those fixes in.
<slangasek> stgraber: apt-clone> yes
<stgraber> dobey: the "we" in there is the 12.04.1 team, only bug 853060 is milestoned, the rest can wait till after 12.04.1
<ubot2> Launchpad bug 853060 in ubuntuone-installer/trunk "ubuntuone-installer crashed with GError in function(): Failed to execute child process "ubuntuone-control-panel-gtk" (No such file or directory)" [Critical,Fix released] https://launchpad.net/bugs/853060
<slangasek> dobey: we're at the point where we have very little margin for error on SRU verification to get things into 12.04.1
<slangasek> so every change not related to the bug seb128 is flagging, and which increases the chance of a regression and a failed SRU verification, likewise increases the chance of that fix missing .1
<dobey> slangasek: understandable. and pretty much 100% of the other fixes are all non functional fixes anyway
<slangasek> (I haven't looked at the actual upload yet - just providing context here)
<slangasek> dobey: interesting that debian/patches/00_system-cache-only.patch updates the test suite, it doesn't appear to actually introduce any unit tests for the corresponding code change
<slangasek> (i.e., there's no test here for a broken ppa source)
<dobey> right
<slangasek> stgraber, bdmurray: apt-clone accepted
<stgraber> alright, rebuilding update-manager then
<phillw> stgraber: are you mad busy, or do you have 5 minutes for a quick PM?
<bdmurray> so what is reviewable in the precise-proposed queue? only items before a certain date or?
<stgraber> phillw: pretty busy
<phillw> stgraber: okies, when you get chance, let me know if the new drupal QA site should be installed on 12.04 server or if you're happy for it to be on 12.10 so I can set up the VM for it to be tested on.
<stgraber> phillw: I'm not aware of any "new" Drupal site. The current Drupal site is iso.qa.ubuntu.com or iso.qa.dev.stgraber.org for the staging version and runs on 10.04 LTS
<phillw> stgraber: okies, when you have some free time, I have a small drupal aware team willing to work with you and balloons on it.
<stgraber> slangasek: ^ can you review?
<slangasek> stgraber: yes
<stgraber> slangasek: the diff won't show any change as the embeded apt_clone.py is copied at build time
 * slangasek nods
<stgraber> slangasek: I checked that the new apt-clone has been published, so we should be good
<slangasek> stgraber: accepted
<bdmurray> slangasek: are there special constraints on reviewing the precise-proposed queue?
<ScottK> bdmurray: Yes.  It should be stuff uploaded before the freeze deadline or stuff that's RC for 12.04.1 only.
<stgraber> slangasek, infinity: got to disappear for a few hours, but I have a basic debdiff for the live-build trick. Would like to have someone confirm that it's done at the "right" place though: http://paste.ubuntu.com/1138613/
<stgraber> will look when I'm back and if there's agreement upload that hack
<infinity> stgraber: Removing just "language-pack-de-base firefox-locale-de" should do the trick, since the other depend on -base.
<infinity> stgraber: And avoids the fact that your fancy expansion might not do what you think it does when you're 4 shells deep. :P
<slangasek> bdmurray: hmm, you mean the new queue or the unapproved queue?
<bdmurray> slangasek: the unapproved
<slangasek> bdmurray: right - what ScottK said then, plus unseeded packages can go in anytime
<bdmurray> slangasek, ScottK: how do you feel about displaying the last bug comment for "golden" bugs in the sru report on hover of the bugnumber?
<ScottK> Purple too.
<ScottK> Seems like a nice idea.
<slangasek> bdmurray: as long as it doesn't make the report too long to load
<bdmurray> slangasek: long to load or long to generate?
<slangasek> load
<infinity> slangasek / stgraber: So, eglibc uploaded to quantal (want to make sure it builds everywhere and has no test regressions on all 5 arches, since I only tested amd64 heavily here)
<infinity> slangasek / stgraber: But, if all goes well, this is pretty much exactly the same delta I'd want to apply to precise: http://launchpadlibrarian.net/112361562/eglibc_2.15-0ubuntu15_2.15-0ubuntu16.diff.gz
<slangasek> infinity: quantal or quantal-proposed?
<infinity> slangasek / stgraber: The first two patches are trivial and, IMO, "obviously correct".  Sadly, it's the latter mess that's what's actually wanted by the world. :/
<slangasek> (did you break my multiarchzâ½)
<infinity> slangasek: quantal... Thanks for the remindeer than I'm naughty on that score.  I keep forgetting about M-A skew.
 * slangasek has a look at the patches
<infinity> slangasek: Maybe we should have some sort of testing migration, and send all $suite uploads to $suite-proposed.  I think I'll bring that up at the next UDS. :P
<infinity> slangasek: I *probably* could have backported avx-fma4 without avx-fma4-fixups, but those two patchsets are the ones I worked on with Carlos and Adreas upstream, and they're what, ultimately, got well-testing in 2.16 and 2.15.x, so I'm not particularly comfy with mangling them just to try to reduce the size of the backport.
<slangasek> I think I'm unlikely to be able to do a good review of this at the moment.  Nothing stands out as "not appropriate for SRU" though
<infinity> s/well-testing/well-tested/
<infinity> Anyhow.  We'll see how the 4 testsuite runs pan out in quantal, and if that's good, I'll upload the precise one immediately after, since you said it all looks "SRU appropriate".
<infinity> Should there be argument later, I can try to mangle, or postpone to .2
<slangasek> it's .2 material at this point anyway
#ubuntu-release 2012-08-10
<infinity> walinuxagent binaries in precise/NEW heading to main, I assume?
<slangasek> infinity: yawp
 * infinity pokes the debs for sanity first.
<infinity> The linux-image-extra-virtual dependency is kinda icky...
<infinity> Given that we don't normally depend on kernels at all.
<infinity> Means installing that will pull in a different kernel if you had, say, generic installed.
<infinity> Are we okay with that?
<infinity> slangasek: ^-- Thoughts?
<infinity> I suppose that, given that it's meant to be installed in Azure VMs, which should be built with linux-image-virtual anyway, it might be mostly a non-issue, but it still feels "wrong".
<infinity> And I think my eyes just crossed at the 50ish or so emails from soyuz about all the kernel SRUs I just mangled...
 * skaet has kicked off a chinese image build for precise 
<infinity> Aww, crap, I missed one eglibc bug.
 * infinity fixes.
<micahg> infinity: just one, that's amazing :)
<slangasek> infinity: well, this has already passed NEW once in quantal, so I don't see much point in pushing back on the dep
<infinity> slangasek: Mmkay.
<infinity> micahg: Okay, lots, but one that I meant to fix in this batch. :P
<stgraber> infinity: thanks for the update on eglibc.
<stgraber> infinity: I uploaded live-build with the recommended change (and filed a bug for tracking).
<stgraber> Would be great if someone could review and let it through when it lands. I haven't tested it, but the easiest way to test it is to have it deployed on the buildds...
<infinity> Do you have any someones in mind? :P
<stgraber> the usual workaholics, so you, ScottK, slangasek or cjwatson now that he's back on some kind of internet :)
<stgraber> though you're the only one with a livefs setup to test my fix before it lands on the buildd :)
 * infinity gives it some time to get diffy wit' it.
<infinity> And yeah, I can test locally.
<stgraber> my quick look through live-build suggests that the autoremove run will be done before that cleanup call. So in theory if any of the packages brought extra no-longer-needed dependencies, they won't be cleared. But I doubt that's the case.
<infinity> Oh, actually.
<infinity> You're doing it in chroot-hacks?
<infinity> Which means the langpack will still be in the manifest.
<infinity> Or...
<infinity> Wait.
<infinity> langpacks are in the live seed, or desktop?
 * infinity looks.
<infinity> Oh, live.
<infinity> In that case, nevermind my babble, cause hacks runs before the live manifest is generated.
<infinity> (One could, perhaps, argue that the hack belongs in a local-hook provided by livecd-rootfs, though.
<infinity> )
<stgraber> yeah, I wasn't aware of when the manifest is built, but it's apparently built at the beginning of lb_binary and the hacks are applied in lb_chroot, so before that
<infinity> The manifest is done in lb_chroot too.
<infinity> It's just that hacks happens between the two manifests. :P
<infinity> As do hooks.
<stgraber> really? grep doesn't seem to agree so it must be called something else than "manifest" ;)
<infinity> Chroot chroot "dpkg-query -W" > binary.packages.live
<stgraber> ah, ok, explains why grep didn't find it
<infinity> grep is a cruel mistress.
<infinity> Well, I'm going to reject that anyway.
<infinity> For two reasons.
<infinity> Possibly three.
<infinity> I should have reviewed it better last time. :P
<infinity> For starters "apt-get --purge -y <package>" isn't a valid apt-get command.
<stgraber> doh, indeed
<infinity> On top of that, while you do attempt to guard it with i386/precise, on the off chance those packages aren't installed, do we want it hard failing, or do we want a || true?
<infinity> And then, on top of it, it might be less icky as a local hook.  But I'm less picky about that, a hack is a hack, and we're not maintaining it for Q+
<stgraber> hmm, not too sure about that one, I think it'd like to know if the project/arch match matches something else than what I want
<stgraber> as it'd mean it might also remove the langpack from an image where we want it (like some flavours)
<infinity> Actually, I didn't look at the guard closely.
<infinity> What does it match?
<infinity> (I rejected it already, can't see the diff anymore...)
<stgraber> PROJECT = precise and ARCH = i386
<stgraber> which is put in the environment by BuildLiveCD
<infinity> precise isn't a PROJECT.
<stgraber> good point
<infinity> And if you're matching release, then you've broken every non-ubuntu-desktop build.
<stgraber> yeah, I want PROJECT = ubuntu
<infinity> Especially the ones that don't have that langpack in the first place (see the bit about the guard).
<stgraber> which should get my just the ubuntu desktop livefs
<stgraber> added a || warning, that should be enough to not break the world while still letting me verify that the check is correct
<infinity> Kay.
<infinity> And yeah, PROJECT=ubuntu should do.
<infinity> It'll actually match wubi too, but I doubt anyone cares.
<infinity> In fact, we tend to want wubi to have an identical package set.
<infinity> So...
<stgraber> infinity: http://paste.ubuntu.com/1138924/
<infinity> ARCH might be randomly overloaded.
<infinity> You might want $LB_ARCHITECTURES
 * infinity tests the above diff, but with LB_ARCHICTECTURES, and with es instead of de and amd64 instead of i386, since his builder is amd64...
<infinity> The following packages will be REMOVED:
<infinity>   firefox-locale-es* language-pack-es* language-pack-es-base*
<infinity>   language-pack-gnome-es* language-pack-gnome-es-base*
<infinity> 0 upgraded, 0 newly installed, 5 to remove and 0 not upgraded.
<infinity> I call that success.
<stgraber> es?
<stgraber> oh, I guess you tried against an amd64 build so had to pick -pt or -es
<infinity> Right.
<infinity> I'd rather keep de anyway.
<infinity> stgraber: Deploying to both kapok and cardamom, so you can verify it DTRT on i386, and does nothing on amd64.
<stgraber> infinity: perfect, thanks
<infinity> stgraber: All done.
<stgraber> infinity: ok, started a respin of desktop (for live-build) + alternate (for update-manager)
<stgraber> infinity: resulting images look good, no more oversize
<infinity> stgraber: Shiny.  And logs look reasonable?
<stgraber> waiting for them to show up on lillypilly, checked the manifests of all images and it's as expected
<infinity> lftp http://cardamom.buildd/~buildd/LiveCD/precise/ubuntu/latest
<infinity> less *out
<infinity> Profit.
<infinity> Well, except that globbing doesn't work. :P
<stgraber> yeah, just checked these as I got tired of waiting, looks good, no mention of my warning on there
<stgraber> grabbed ~buildd/BuildLive.out. AFAICS nothing started building after my builds, so I think I checked the right ones ;)
<infinity> Yeah, I just checked both, looks good.
<stgraber> marked the bug verification-done
<infinity> Released.
<infinity> Argh.
<infinity> NBS report just went empty again.
<infinity> Stupid cache.
 * infinity decides to not care and have a nap instead.
<tjaalton> hey, the sru's in bug 1031784 are critical for .1. Would someone ack the uploads to -proposed?
<ubot2> Launchpad bug 1031784 in xserver-xorg-video-intel "Artifacts on screen with ivy bridge" [Critical,In progress] https://launchpad.net/bugs/1031784
<cjwatson> sorry for lack of automatic security->updates copying for expat; fixed now
<cjwatson> so, we now have pocket queue admin permissions in Launchpad, although per-series versions of those will have to wait for another landing/deployment (I got my first version a bit wrong)
<cjwatson> I have done this to start with:
<cjwatson> $ ./edit-acl -p ubuntu-security --pocket security -t admin add
<cjwatson> Added:
<cjwatson> Queue Administration Rights for ubuntu-security: archive 'primary', pocket 'Security'
<cjwatson> jdstrand: ^- I think the above should allow you to use 'unembargo --copy' directly, with no need for ubuntu-archive to approve; I suggest that you apply http://paste.ubuntu.com/1139300/ so that your copies go straight through without you needing to approve them manually either
<Laney> do we want that for backports?
<Laney> also, yay for that
<cjwatson> jdstrand: I'd appreciate you folks doing this for your next security update, and if it works, I think we can totally decommission the old system
<cjwatson> Laney: Probably, but perhaps that should be stable releases only?
<cjwatson> Which will require me to get per-series permissions working
<cjwatson> Mind you, -backports doesn't work in the development series anyway ...
<Laney> I think we can be trusted not to mess with it in the brief interim ...
<cjwatson> And if -backports started working in the development series, we'd want to let you use it anyway
<Laney> I don't know how it's broken atm, straight reject?
<cjwatson> Straight reject
<cjwatson> $ edit-acl -p ubuntu-backporters --pocket backports -t admin add
<cjwatson> Added:
<cjwatson> Queue Administration Rights for ubuntu-backporters: archive 'primary', pocket 'Backports'
<Laney> nice
<cjwatson> Give that a try then next time you have a chance?
<Laney> I think I have one to try now-ish
<cjwatson> You should be able to use either the web UI or the queue client in u-a-t
<Laney> cjwatson: I see checkboxes for all queue entries, is that expected?
<cjwatson> Ish, if you actually try to do anything with those it'll refuse
<cjwatson> (or should ...)
<Laney> ok
<cjwatson> It's sort of a bug that you get checkboxes, but annoyingly tedious to fix
<cjwatson> Maybe we should verify this though
<cjwatson> Laney: wanna try rejecting build-essential/precise-proposed?
<cjwatson> (I choose reject because the permissions are equivalent, but it's fairly harmless if it goes wrong)
<Laney> FAILED: build-essential (You have no rights to reject component(s) 'main')
<cjwatson> Good
<Laney> strange that it refers to a component
<Laney> also: ^ that was me
<cjwatson> It doesn't know which of the several possible rights you don't have but should ;-)
<cjwatson> possibly worth adding the pocket to that message, but meh
<Laney> I see, I didn't know that per-component permissions existed
<Laney> let's try doing lucid with the tool
<cjwatson> Per-component queue admin permissions were all we had before
<Laney> queue -s lucid -Q unapproved info â is that right?
<cjwatson> -s lucid-backports
<Laney> that works
<tjaalton> anyone on sru rotation today?
<Laney> nice
 * cjwatson wonders if there was a WI for that somewhere
<cjwatson> Don't see one
<tjaalton> it would be important to get the fixes in bug 1031784 in 12.04.1 installer, is it too late already?
<ubot2> Launchpad bug 1031784 in xserver-xorg-video-intel "Artifacts on screen with ivy bridge" [Critical,In progress] https://launchpad.net/bugs/1031784
<tjaalton> not installer, but the image
<Laney> tjaalton: Friday is slangasek's day, so you should wait until a bit later
<tjaalton> Laney: ok, thanks
<Laney> SRU team is a bit thin on europeans, actually
<jdstrand> cjwatson: awesome, thanks. I had tyhicks (a non-core-dev) try to use --copy yesterday and it worked great for him (still needed AA approval at the time)
<jdstrand> cjwatson: (expat)
<jdstrand> cjwatson: I'll make the change to our script, but we probably won't push anything until next week (we typically only push high priority updates on fridays)
<jdstrand> (change committed)
<cjwatson> Right, the per-pocket upload permissions would have handled his case
<stgraber> tjaalton: that package is already in the queue right?
<tjaalton> stgraber: which one? there are two uploads
<stgraber> tjaalton: ivy bridge fix in xserver-xorg-video-intel
<tjaalton> stgraber: don't see any email about it being accepted
<stgraber> xserver-xorg-video-intel (2:2.17.0-1ubuntu4.1) in the queue seems reasonable, diff is small, looks pretty obvious, so I'm happy with an exception for that one
<tjaalton> thanks
<stgraber> slangasek: can you take a look at xserver-xorg-video-intel when you're around?
<tjaalton> mesa is kinda problematic since it's on top of an existing sru in proposed, which is also anew upstream stable release
<stgraber> skaet: all the Ubuntu images now fit on their media, I'm now doing yet another test run of the alternate upgrade to make sure that the new update-manager fixed the remaining issues
<tjaalton> but the new patch is small just like -intel
<stgraber> ok, let me check if there's something I can do to get the current mesa into -updates so we can then get your new one in -proposed
<stgraber> though that may have to wait till Monday as releasing updates to users on a Friday is usually considered a bad idea
<stgraber> tjaalton: one of the bugs related to the mesa currently in -proposed is bug 1031821. Can you have a look to see what's going on?
<ubot2> Launchpad bug 1031821 in mesa "package libgl1-mesa-dri 8.0.3-0ubuntu0.1 failed to install/upgrade: libgl1-mesa-dri:amd64 8.0.3-0ubuntu0.1 cannot be configured because libgl1-mesa-dri" [Undecided,New] https://launchpad.net/bugs/1031821
<tjaalton> looking. has worked for me though
<stgraber> it's currently the only potential regression from the SRU in -proposed, so if it can be confirmed that this isn't something introduced by the SRU and someone can confirm the tests (piglit) pass as expected, then it should be ready to be copied (per MRE criteria)
<tjaalton> looks like he had mismatched versions of i386/amd64 binaries for some reason
<tjaalton> the i386 version lagging behind
<tjaalton> so, not caused by upstream code :)
<stgraber> jibel: can you test the offline upgrade again with the latest alternate? it seems to work here (10.04.4 up to date using the latest amd64 media as upgrade source)
<jibel> stgraber, sure, I can do that.
<skaet> stgraber,  WOOT!     glad to hear they all fit.  :)
<stgraber> skaet: looking at the flavours, kubuntu dvd is the only oversized I noticed and they're not releasing it, so looks like we're fine there too
<skaet> stgraber,  goodness.   Switch over to building from -updates now?
<stgraber> skaet: I think I'd prefer to still have -proposed enabled for the weekend, try to get people to do as much verification as possible until Monday, then on Monday copy as much as we can to -updates and THEN switch to -updates
<ScottK> Laney: You should be using queue from ubuntu-archive-tools anyway so you don't need to care about check boxes...
<Laney> ScottK: I did; it was just to test both interfaces.
<ScottK> OK.
<stgraber> skaet: some bits need to move to -updates before we can start building without -proposed anyway (like debian-installer, nspr, openoffice.org, update-manager, update-notifier, launchpad-integration and apt-clone)
<skaet> stgraber,  ok.   But want to do a full respin on monday as soon as we switch over,  rather than wait for the dailies that night.
<stgraber> skaet: yep
<seb128> hum
<seb128> NBS is empty again
<seb128> cjwatson, I think you said it was some corrupted datas to rm? can you do it again?
<jibel> stgraber, the result of the resolver is odd. it removes and holds back a lot of stuff. especially the removal list is surprisingly long with 233 packages
<stgraber> jibel: well, it was kind of expected that this upgrade mode would remove quite a few more stuff from the system than an online upgrade
<jibel> stgraber, I'll upgrade anyway, and we'll see the result.
<stgraber> I saw one package having a preinst issue trying to do some apporty stuff, ignored it for now to see if the rest works
<stgraber> looks like the preinst tried to call one of the apport scripts and failed because apport was in the middle of an upgrade
<slangasek> seb128, cjwatson: removed the cache, rerunning the report
<seb128> slangasek, thanks
<seb128> slangasek, is that something I've access to? where is it?
<jibel> hm, evolution is removed, all of the mono stack :/
<infinity> seb128: lillypilly:~ubuntu-archive/.launchpadlib/
<seb128> infinity, thanks
<infinity> seb128: (.../cache/)
<stgraber> jibel: sure, we don't have evolution on the media, so the upgrader is removing it and replacing by thunderbird
<stgraber> jibel: same thing for mono, we don't ship it anymore, so it can't get upgraded, causing anything that depends on it to be removed
<stgraber> jibel: if you were hoping to get the same result as an internet-enabled upgrade, prepare to be very disappointed ;) I'm currently hoping the system still boots and lets me login
<infinity> stgraber: You're setting an awfully high bar there.
<jibel> stgraber, no, I'm just hoping that the result is usable
<stgraber> jibel: in theory the upgrader is enforcing that unity is present and some other parts of ubuntu-desktop, so we should be getting some kind of desktop
<jibel> :)
<infinity> "In theory we should have a desktop", this bar is just getting higher and higher.
<stgraber> the good news is that in theory it's going to be the last release where we "support" this
<stgraber> infinity: depends on definition of "desktop", we might be able to stretch that to "X + xterm = desktop" :)
<stgraber> slangasek: I'm trying a restore + upgrade using the tarball attached a week ago by bdmurray, maybe I'll get lucky this time around...
<jibel> stgraber, the result of the upgrade looks like a desktop. I had a crash in libxml-sax-expat-perl during upgrade, I ignored it and upgrade finished.
<stgraber> jibel: ok, I believe it's the same that crashed for me, giving me a python stacktrace in the terminal window
<stgraber> jibel: will take a look see if that's easily fixable
<stgraber> but yeah, besides that I'm getting a bootable system with lightdm and unity, so doesn't look too bad
<stgraber> jibel: confirmed, there's no way of removing libxml-sax-expat-perl... that's what's causing the failure
<stgraber> jibel: the postinst depends on update-perl-sax-parsers which doesn't exist on the system
<stgraber> s/postinst/prerm/
<jibel> stgraber, bug 990256
<ubot2> Launchpad bug 990256 in libxml-sax-expat-perl "package libxml-sax-expat-perl 0.40-2 failed to install/upgrade: ErrorMessage: subprocess installed pre-removal script returned error exit status 2" [Undecided,Confirmed] https://launchpad.net/bugs/990256
<stgraber> right, that's the one... so looks like we need a 10.04 SRU to get out of that one
<stgraber> I'll check in a few minutes, multi-tasking quite a bit at the moment
<skaet> release team:   please leave newly uploaded  unity stack in -proposed over the weekend.     seb128 will give explicit ok before it should be moved over.
<slangasek> stgraber, skaet: I've reviewed xserver-xorg-video-intel in the queue and confirmed that it looks like a safe, targeted hardware-enablement change.  Should I accept this?
<stgraber> slangasek: yes
<stgraber> slangasek: ideally, we'd also need mesa for the same issue, though we'd first need to clear the one currently in -proposed
<slangasek> skaet: quantal-proposed?  Why is seb128 wanting it held off?
<slangasek> that's contrary to the stated policy for $devel-proposed
<skaet> slangasek,  that was the request at the end of the meeting.   Am assuming he wants more testing done on it.
<slangasek> quantal-proposed is not for testing
<slangasek> seb128: ^^
<slangasek> seb128: if it hasn't already been tested, it shouldn't be uploaded to quantal-proposed.  quantal-proposed is only for assuring archive consistency.
<seb128> slangasek, usual w.e paranoia
<seb128> it has been tested and went through automatic and manual testing
<seb128> so no concrete or valid reason ;-)
<seb128> slangasek, same reason you don't copy SRU to -updates on friday :p
<skaet> slangasek,  http://launchpadlibrarian.net/111795520/xserver-xorg-video-intel_2%3A2.17.0-1ubuntu4_2%3A2.17.0-1ubuntu4.1.diff.gz ?  if so,  yes,  agree.
<slangasek> seb128: ok.  so it doesn't really need an explicit sign-off, does it, it just needs us to not copy it until monday?
<slangasek> skaet: yep
<ScottK> That's still not why we're supposed to be using -proposed in the development release.
<cjwatson> Remember that, once we have automation, the automation is very unlikely to care whether it's the weekend or not.
<seb128> slangasek, yeah, I didn't ask for sign off, I just said 'better to copy it on monday so we have a relaxed w.e'
<seb128> ScottK, we use it because otherwise amd64 users get unity removed while it's not built there yet
<ScottK> Yes.  This is what it's for.
<slangasek> seb128: would you have uploaded today if you didn't have -proposed?
<ScottK> It's the don't copy it until Monday part that's out of scope.
<skaet> slangasek, seb128,  yeah my bad for asking for the explicit check.
<seb128> slangasek, yes, I just don't want the copy to land to the archive on sunday when I'm not around
<stgraber> jibel: did you test oneiric to precise upgrades without network? I'm wondering if you'd be hitting the same libxml-sax-expat-perl issue.
<slangasek> seb128: how about if it lands in 2 hours when you're not around? ;)
<seb128> slangasek, I will still be around tonight and looking at stuff tomorrow morning
<seb128> so the upload timing works
<seb128> having a copy on saturday evening or sunday doesn't work
<slangasek> ok
<seb128> so it's "copy tonight or monday please"
<seb128> not sunday :p
<slangasek> yep, understood
<seb128> though it's mostly paranoia
<jibel> stgraber, I think I did, but now I have a doubt. Let me try that quickly.
<seb128> there are all chances the update is fine
<slangasek> as cjwatson says, once we're automated you shouldn't rely on this kind of schedule accomodation from the server
<cjwatson> Though we'll probably have to have some kind of equivalent of filing RC bugs to inhibit propagation
<ScottK> I have another paranoia and that's that all this "let's used -proposed" stuff ends up reproducing Debian Testing/Unstable.
<ScottK> Which cjwatson isn't helping.
<slangasek> ScottK: not reproducing testing/unstable is precisely *why* I'm adamant that people not put stuff into -proposed for testing :)
<ScottK> Agreed.
<seb128> to be clear those are not in proposed for testing
<seb128> they have been testing in a week in a ppa
<seb128> and went through automated and manual testing process
<seb128> it's just me being paranoid
<slangasek> seb128: understood - thanks :)
<seb128> just forget about the whole thing and copy on sunday if you feel like doing it ;-)
<cjwatson> Speaking of, is all this X stuff copyable?
<cjwatson> It's been there for >1week
<jibel> stgraber, no crash on upgrade from Oneiric, the package is not installed by default.
<infinity> tjaalton: Que pasa with the xorg transition?
<stgraber> jibel: ah, that'd explain it then
<seb128> cjwatson, I'm not sure, ted just got bitten badly by the nvidia drivers not working with the quantal-proposed stack
<stgraber> so I might get away with just fixing it in lucid then, though I suppose we should SRU to the rest just to be safe
<seb128> like they would segfault X after using a GL app
<cjwatson> Again, though - not what -proposed is for ...
<seb128> I don't think that's what it was used for
<seb128> I think it was used to get the abi transition complete before copy
<seb128> I'm just pointing that I know about an issue with the new stack though
<seb128> tjaalton should comment though
<slangasek> cjwatson: as of infinity's last check, there were some !x86 drivers still missing
<slangasek> and we were waiting for an nvidia drop that was supposed to have landed already
<slangasek> s/was supposed/is supposed/
<seb128> it landed and seems to run fine until you use GL
<seb128> or at least for ted
<SpamapS> Question about .changes files and moves to -updates ..
<infinity> SpamapS: ?
<SpamapS> openvswitch had a minor change uploaded but did not re-gen the changes back to pre-updates
<SpamapS> thusly, bug 1021530 fell off our sru report
<ubot2> Launchpad bug 1021530 in openvswitch "[SRU] update to include stable fixes for OVS 1.4" [Medium,Fix committed] https://launchpad.net/bugs/1021530
<infinity> SpamapS: Would be nice if it had been reuploaded with a proper -v ..
<seb128> can we get http://launchpadlibrarian.net/112417114/ubuntu-sso-client_3.0.2-0ubuntu2_source.changes reviewed for 12.04.1
<seb128> it's one of the top errors.ubuntu.com issues
<SpamapS> Other than us having to manually mark the bug fix released, will the lack of the -v cause any issues if it is released to -updates ?
<seb128> bug #937132
<ubot2> Launchpad bug 937132 in ubuntu-sso-client "ubuntu-sso-login crashed with RuntimeError in /usr/lib/python2.7/dist-packages/gi/overrides/Gdk.py: Gdk couldn't be initialized" [High,Confirmed] https://launchpad.net/bugs/937132
<slangasek> SpamapS: fwiw, the tooling doesn't currently support us very well in this; in cases where there's an existing -proposed upload, I manually download and check the .changes
<infinity> SpamapS: No, it causes no actual issues, just that it requires manual paperwork and tracking, which is a hassle (and error-prone, if the missed bugs don't end up verified correctly)
<SpamapS> slangasek: seems like queuediff could give us a heads up
<slangasek> queuediff only looks at the diff
<slangasek> this is "tooling doesn't support us well in this" :)
<SpamapS> queuediff also looks at whether or not there's already an upload in -proposed
<SpamapS> and warns us
<SpamapS> so it seems like it could go one step further, and look at the changes file, and flag it
<slangasek> I want the whole thing to go a lot more than one step further
<SpamapS> "changes file missing versions already uploaded to -proposed but not in -updates
<slangasek> I want an interactive tool that I can say y/n in that will run sru-accept and q accept for me ;)
<slangasek> I agree that better .changes sanity checking should be part of this
<stgraber> seb128: looks reasonable, diff only contains the bugfix we want, bug is missing a testcase/rational/regression potential though, but with that fixed, I think it's doable
<SpamapS> slangasek: agreed, however we both know incrementally better today is better than perfection never
<slangasek> SpamapS: absolutely
<slangasek> I'm just sayin', if someone feels like doing the work, I have a wishlist too ;)
<SpamapS> ok so to the more accute problem of openvswitch..
<SpamapS> its not on the list of "all green +7 days" bugs .. but I think it should go to -updates
<SpamapS> its not on any CDs either
<tjaalton> cjwatson, infinity: yeah nvidia is badly busted, and i wanted to wait for vbox upstream to try fixing their driver. also, the arm video drivers still need to be updated
<SpamapS> (universe)
<tjaalton> we talked about the stack on #ubuntu-x, and thought that it shouldn't hurt to keep it in proposed until most issues are shaken out, but still copy it before the FF
<slangasek> SpamapS: provided that whoever copies it over is happy to be on the hook in case of regressions this weekend...
<slangasek> tjaalton: so in case you missed the discussion above, quantal-proposed is *not* supposed to be used for testing, it's only supposed to be used for getting packages into a consistent installable state so that quantal remains installable; this is effectively a misuse of quantal-proposed
<tjaalton> there's also a showstopper mesa bug affecting unity, which makes it difficult to update it to 8.1 series at the same time
<tjaalton> slangasek: oh
<slangasek> tjaalton: it happens that in this case having it stay in -proposed isn't going to mess us up because it's a self-contained set of related server packages... but please don't make a habit of this
<slangasek> testing should happen before upload to -proposed, in a ppa if appropriate
<SpamapS> slangasek: No I was thinking Monday
<slangasek> SpamapS: right, perfectly ok then
<SpamapS> slangasek: I just want to let the bug subscribers know whats up
<tjaalton> well the problem is the changed video abi that means updates to drivers the x-tem (or debian xsf) doesn't control
<tjaalton> *team
<tjaalton> i guess x-x-video-all isn't installable on arm, x86 is fine
<tjaalton> that's the real showstopper, rest is details then
<tjaalton> archive-wise
<infinity> tjaalton: Using it to transition the ABI is fine, using it to test that the software doesn't suck isn't.
<infinity> tjaalton: That was sort of the point. ;)
<tjaalton> understood, and it doesn't suck :)
<tjaalton> just that it would break nvidia that's in quantal..
<infinity> tjaalton: So, in this case, as soon as the ARM drivers (and whatever else is missing) are uploaded and built, it should be ready to transition.
<tjaalton> yep
<tjaalton> next week! :)
<stgraber> infinity, slangasek: I see that you either uploaded or are listed in the cedarview packages. They are currently both in depwait waiting for libwsbm that'd need promotion to satisfy the dependency.
<infinity> stgraber: It's in universe in quantal too, some sort of MIR for that would be nice.  And we can't promote it in precise-release, so it would also need a version bump in precise-proposed, just so we could promote the new one.
<infinity> (None of this has to do with me, I just re-signed one of the uploads after I jacked it in the queue) :P
<stgraber> ok :)
<stgraber> slangasek: hmm, I must be missing something very obvious here... so we have that crash on 10.04 => 12.04 upgrade when removing libxml-sax-expat-perl because its prerm is calling update-perl-sax-parsers which is provided by libxml-sax-perl. BUT libxml-sax-perl is a dependency of libxml-sax-expat-perl. So how is it possible for it to have been uninstalled (rc state) BEFORE libxml-sax-expat-perl was removed?
<infinity> stgraber: Is there a dependency loop being broken somewhere?
<infinity> stgraber: Depends is meant to guarantee that the depended-on package is there for prerm invocation, but only if there are no loops (same rules as depends and postinst configure)
<stgraber> infinity: hmm, that's probably the problem. Will have to go read apt.log to try and figure it out then
<stgraber> infinity: misisng libxml-namespacesupport-perl seems to be the cause of it
<stgraber> infinity: will try the easy fix by just seeding it...
<stgraber> it doesn't depend on anything but perl and it's in main, so that's a 15K fix in theory
<stgraber> and respinning...
 * cjwatson has a second go at landing the Archive.getAllPermissions work for stgraber
<cjwatson> You might get that early next week if I'm lucky
 * infinity ponders some sort of brunch.
<stgraber> cjwatson: that'd be great, thanks!
<cjwatson> 17436 tests run in 4:02:52.873891, 1 failures, 0 errors
<cjwatson> ^- frustrating
<infinity> cjwatson: Close enough.
<stgraber> jibel: I'll ask you to run the test with the new alternates when they're done building. Looks like your test setup is faster than mine (I don't have a 10.04.4 snapshot, so I need to reinstall and re-upgrade...)
<stgraber> that's if you're still around. If not, I'll do it here
<stgraber> jibel: images are done building
<slangasek> stgraber: "that crash"> link, please?
<stgraber> slangasek: bug 990256
<ubot2> Launchpad bug 990256 in libxml-sax-expat-perl "package libxml-sax-expat-perl 0.40-2 failed to install/upgrade: ErrorMessage: subprocess installed pre-removal script returned error exit status 2" [Undecided,Confirmed] https://launchpad.net/bugs/990256
<slangasek> ev, seb128: btw, bug #1024806 is a great example of an SRU regression detected by virtue of errors.u.c ;)
<slangasek> sorry, bug #1034806
<ubot2> Launchpad bug 1034806 in aptdaemon "aptd crashed with UnicodeDecodeError in _emit_acquire_item(): 'ascii' codec can't decode byte 0xd0 in position 0: ordinal not in range(128)" [Undecided,New] https://launchpad.net/bugs/1034806
<slangasek> stgraber: this is the perl / perl-modules skew issue.  The problem isn't that the dependency has been /removed/, it's that a transitive dependency has been /upgraded/
<slangasek> i.e., /usr/bin/update-perl-sax-parsers isn't missing - it fails to compile
<slangasek> stgraber: see the perl changelog entry for 5.14.2-9 for guidance
<stgraber> slangasek: hmm, ok. Weird that libxml-sax-perl is marked as rc according to dpkg then
<micahg> hrm, that sqlite tracker is wrong, I'll fix it
<slangasek> stgraber: it wouldn't have been rc at the time libxml-sax-expat-perl failed; it was probably removed in a second clean-up run of apt, not shown in this log
<jibel> stgraber, sorry dinner time, syncing now
<micahg> do negative lookaheads work in the transition tracker?
<infinity> cjwatson: Any idea why this explodes?
<infinity> cjwatson: change-override -x optional libxml2 sgml-base xml-core
<infinity> cjwatson: Other than the part where I'm setting section instead of priority.  Ignore me.
<cjwatson> sucky error message from LP mind
<infinity> Quite.
<micahg> can someone from the release team please merge https://code.launchpad.net/~micahg/%2Bjunk/transition-tracker/ into the transition tracker if it looks sane?
<stgraber> slangasek: right, so that's indeed the problem. As it's also a case of using File::Basename, I guess applying the same trick as for mono-gac should work?
<bdmurray> slangasek: as today is your day I thought you'd like to know the sru report has text on mouseover now
<slangasek> stgraber: without digging further into it, I couldn't say for sure.  mono-gac was especially complicated, this one might only require a Breaks: on the old libxml-sax-perl?
<stgraber> slangasek: http://paste.ubuntu.com/1139826/ is what I get during an upgrade
<cjwatson> try doc-base
<cjwatson> which I think had a relatively simple workaround
<stgraber> ok, perl-base as a versioned conflict against doc-base (<< 0.10.3)
<cjwatson> hm, maybe it wasn't that
<slangasek> bdmurray: mouseover> nice, thanks :)
<slangasek> versioned conflicts are relatively simple
<cjwatson> stgraber: caution; I vaguely recall that in past iterations of this problem, no package metadata was good enough
<slangasek> just not relatively friendly :)
<stgraber> cjwatson: actually, I wasn't looking at the right version of perl. The versioned conflict is in perl-base, perl-modules, libperl5.14 and perl itself
<cjwatson> iirc, a conflict only works if the conflicted package has been fixed to handle the case where perl is unconfigured
<cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=278495#100
<ubot2> Debian bug 278495 in doc-base "perl can be in a unusable state during upgrade" [Serious,Fixed]
<cjwatson> see also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649174 for a similar example
<ubot2> Debian bug 649174 in update-inetd "update-inetd: make robust against being run when perl-base and perl-modules are out of sync" [Important,Fixed]
<cjwatson> which has a "try module and fall back to local implementation" pattern
<cjwatson> the conflict is then just there to make sure that the tools are upgraded before starting the paired perl/perl-modules upgrade
 * slangasek nods
<slangasek> right, that's what was done for mono-gac
<cjwatson> bdmurray: hm, it picked an odd last comment to show for https://bugs.launchpad.net/ubuntu/+source/mawk/+bug/955791
<ubot2> Ubuntu bug 955791 in mawk "Source and destination overlap in memcpy" [Undecided,Fix committed]
<stgraber> so we need to patch libxml-sax-perl to stop using Basename, then SRU that, then seed it (it's currently not in the pool), then add a versioned conflict to perl, then SRU that?
<cjwatson> I'd have expected comment #21 there, I think
<stgraber> slangasek: I guess adding a Conflict libxml-sax-perl (<< 0.99+dfsg-1) would do the trick as we don't actually ship or need it, so apt will get it removed, then upgrade perl. Though that's not clean and we could probably still hit the bug for these upgrading with internet connectivity (though apparently it's currently going through a different path and avoiding this issue)
<slangasek> stgraber: has the original bug been reproduced with 12.04.1?
<slangasek> this may be much ado about a tempest in a teacup
<stgraber> slangasek: well, the bug report is just what jibel found after we both had our 10.04 => 12.04.1 upgrades to fail
<slangasek> ah
<stgraber> so I'm definitely reproducing this issue every time I upgrade to 12.04.1 without connectivity
<slangasek> so a complete fix would be to SRU libxml-sax-perl to not require perl-modules, *then* add the versioned Conflicts
<bdmurray> cjwatson: ah, I'll dig into it
<slangasek> there's no guarantee that just adding the Conflicts won't make this *worse* for users doing Internet-enabled upgrades
<slangasek> and it's very difficult to regression test that
<stgraber> indeed
<slangasek> stgraber: seems like the doc-base fix is the appropriate example for this - a dirname() reimplementation is called for
<stgraber> slangasek: I haven't touched any perl code in years, but isn't SAX.pm just "importing" Basename without using it? from what I see the only use of dirname() is in the Makefile, which shouldn't impact installed systems?
 * stgraber should probably look at the binary package instead of the source ;)
<slangasek> stgraber: it imports the dirname() function from the Basename module, and uses it
 * slangasek is looking at /usr/share/perl5/XML/SAX.pm on his local quantal
<stgraber> oh, indeed it does
<slangasek> mm, File::Spec would also be an issue
<slangasek> I think
<slangasek> ah, no, that's in perl not perl-modules
<stgraber> ok, so I'll do some copy/pasting from doc-base then
<stgraber> slangasek or anyone who has a clue about perl: http://paste.ubuntu.com/1139887/ <- does that look something that should be working?
<slangasek> stgraber: yeah
<stgraber> slangasek: ok. Pushing to quantal and precise then
<slangasek> stgraber: please also forward to Debian
<jibel> slangasek, I can reproduce bug 937196 easily, which is a dupe of bug 1017001
<ubot2> Launchpad bug 937196 in apt "10.04 LTS -> 12.04 upgrade failed: ifupdown depends on upstart and initscripts but they are not configured (dup-of: 1017001)" [High,Confirmed] https://launchpad.net/bugs/937196
<ubot2> Launchpad bug 1017001 in apt "package resolvconf 1.63ubuntu14 failed to install/upgrade: ErrorMessage: pre-dependency problem - not installing resolvconf" [Critical,Confirmed] https://launchpad.net/bugs/1017001
<jibel> slangasek, install mythbuntu 10.04, don't apply updates, and run do-release-upgrade -d
<jibel> not sure it is a valid test scenario though
<slangasek> jibel: !! a test case!  Thank you!
<slangasek> jibel: can you update the bug with that info?
<slangasek> (it is a valid test scenario; it's recommended that you apply updates first, but it shouldn't break if you didn't)
<stgraber> slangasek: that's both perl and libxml-sax-perl in the queue, hopefully these two should do the trick
<slangasek> stgraber: yep, thanks
<jibel> description updated with a test case
<stgraber> slangasek: and sent to Debian (they had Debian bug 658702 for that already)
<ubot2> Debian bug 658702 in libxml-sax-perl "libxml-sax-perl: update-perl-sax-parsers sometimes fails when called from old-prerm during squeeze->wheezy update" [Normal,Open] http://bugs.debian.org/658702
<slangasek> stgraber: cheers
<slangasek> interesting that it's only sev: normal, apparently Debian fixed their libxml-sax-expat-perl to not fail in this case
<slangasek> oh... but that only works if you're actually upgrading the package, not removing it
<slangasek> jibel, stgraber: bug #1034668 features libbrasero-media0 prominently, which came up already in the CD upgrader case
<ubot2> Launchpad bug 1034668 in update-manager "Upgrade from Lucid to Precise does not install packages for Global Menu: indicator-appmenu" [High,Confirmed] https://launchpad.net/bugs/1034668
<stgraber> slangasek: I'm wondering if the added Breaks on launchpad-integration will fix/change that bug as a side effect
<slangasek> jibel: when you reproduced bug #1034668, did you have -proposed enabled?
<ubot2> Launchpad bug 1034668 in update-manager "Upgrade from Lucid to Precise does not install packages for Global Menu: indicator-appmenu" [High,Confirmed] https://launchpad.net/bugs/1034668
<stgraber> slangasek: according to apt.log, he didn't. It's unpacking launchpad-integration 0.1.56 instead of 0.1.56.1
<slangasek> jibel: are you generally testing with -proposed enabled right now?  That's fairly important given the set of upgrade-related fixes currently waiting there
<infinity> I hope those accepts aren't also with overrides.
<infinity> Cause if they are, I look forward to someone messing it up with arch skew when the other arches land. :P
<jibel> slangasek, automated tests are done with proposed enabled. I didn't try #1034668 with proposed but I can.
<slangasek> infinity: appindicator was a pocket-copy, at least
<slangasek> jibel: would be good to confirm if it's reproducible with the updated launchpad-integration
<infinity> slangasek: ?
<slangasek> the apt.log shows there's a *chance* it won't be
<infinity> slangasek: A pocket-copy that was building?
<slangasek> infinity: oh, no, I'm confusing myself
<slangasek> the pocket copy was something else entirely :)
<infinity> Couldn't wait 20 seconds for the PPC build... :P
<infinity> Impatient.
<micahg> infinity: are there not policies about these sorts of things?
<jibel> slangasek, with proposed enabled I still get in apt.log
<infinity> micahg: Technical, or verbal?
<micahg> infinity: verbal I guess
<infinity> micahg: I tend to rap people on the knucles when they impatiently do partial binary accepts.  But if they know what they're doing, they won't hurt anything.
<jibel> Holding back indicator-appmenu:amd64 rather than change libdbusmenu-glib1:amd64
<stgraber> jibel: can I get the new apt.log?
<jibel> stgraber, sure
<infinity> micahg: (If they do skew things, we have reports to point it out, it's just annoying)
<stgraber> slangasek: thanks for the copy to quantal, for some reason I forgot that one yesterday (the fix obviously isn't needed in quantal, but having precise have an higher version than quantal isn't too good ;))
<slangasek> jibel: ok - please add that to the bug, and we can do an SRU for indicator-appmenu to
<slangasek> +o
<slangasek> stgraber: sure thing.  it was just chance that I noticed it :)
<stgraber> not to put any extra pressure, but if you want me to run another 10.04 => 12.04 upgrade today with the new fixes, I'd need perl and libxml-sax-perl accepted now-ish
<jibel> I attached the resolver logs to the report
<jibel> I'm a bit slow, FF consistently crashes when I switch from 1 workspace to the other :/
<slangasek> stgraber: ack, sorry, got lost while waiting for the queuediff to generate
<slangasek> stgraber: looks like the wrong version in the perl conflicts
<slangasek> << $quantal, not << $precise_proposed
<stgraber> oops
<stgraber> please reject then
<slangasek> done
<slangasek> stgraber: perl accepted
<stgraber> i386 and amd64 perl has been published, respinning alternate
<slangasek> have the other CD-upgrader fixes checked out in jenkins?
<slangasek> I'm inclined to get them copied over to -updates today; I'd rather give them further time to steep in -updates due to the nature of the likely regressions
<slangasek> (i.e., $random_upgrade_bug_due_to_packages_we_didn't_test)
<slangasek> hmm, hmm; https://jenkins.qa.ubuntu.com/view/Precise/view/Upgrade%20Testing%20Dashboard/job/precise-upgrade-lucid-main/ could be better
<stgraber> slangasek: I just had a quick look at the versions on jenkins, the tests don't seem to be running with proposd
<stgraber> *proposed
<slangasek> oh
<slangasek> jibel said they were
<slangasek> well, I guess we need to get that sorted first
<slangasek> confirmed
<slangasek> so, definitely no copying today
<ScottK> It could go either way.  That could be a reason to definitely copy today.
<slangasek> ScottK: no, because we haven't even gotten a regression test on jenkins yet
#ubuntu-release 2012-08-11
<stgraber> slangasek: looks like that worked. The upgrade is still running but it's past the point where the crash would usually happen.
<cjwatson> slangasek: ah, I was about to assign 1034806 to myself :)
<cjwatson> slangasek: I think it probably wants to look like http://paste.ubuntu.com/1140237/ ?
<slangasek> cjwatson: <cough> yes, I just realized I should probably assign it to myself because I've been working on it for the past half hour :P
<cjwatson> which would apply to quantal, even though using python3 there dodges the issue
<slangasek> yeah, that matches mine
<slangasek> just working on the test case now
<cjwatson> good, we followed the same chain of logic
<cjwatson> a test case was what I hadn't got to yet
<stgraber> I'd have thought that with all that LP work, you'd know be completely converted to TDD ;)
<slangasek> also needs the iso-codes build-dep, which is in quantal already but not yet in precise
<slangasek> stgraber: well when 80% of the work is tracking down the bug and the other 10% is split evenly between figuring out the fix for the bug and figuring out the test case... :)
<cjwatson> stgraber: :-P  I make sure the test fails without the fix, but that doesn't always mean I write the test first ...
<stgraber> ;)
<cjwatson> (but it's true that the balance in LP is necessarily shifted more towards using the test suite, since it's so much less work to engineer a reproduction environment that way than by bothering to actually run a full instance)
<slangasek> cjwatson: do you have time to review the mp I just sent for that buG?
<cjwatson> urr, pretty confused by it being committed to lp:ubuntu/precise-proposed/aptdaemon and thus containing a bunch of other stuff
<slangasek> hmm
<slangasek> gar, not at all what I told it to do
<slangasek> and I suppose uncommitting will simply anger the branch god
<cjwatson> but looking at the diff
<slangasek> oh, I see, I tried to create a branch under a 'precise-proposed' directory and UDD laughed at me
<slangasek> sigh
<slangasek> http://paste.ubuntu.com/1140316/
<slangasek> that's consistent
<cjwatson> .../precise/...
<cjwatson> compare https://code.launchpad.net/~ubuntu-branches/ubuntu/precise/aptdaemon/precise-proposed/+merge/119222
<cjwatson> i.e. the third bit is a series not a suite
<cjwatson> anyway, approve review sent with a couple of minor notes
<slangasek> right, so the fact that 'lp:ubuntu/precise-proposed/aptdaemon' works is entirely because someone wants to watch me suffer ;)
<slangasek> thanks for the review
<slangasek> -p ab> heh, that was my next commit
<stgraber> slangasek: upgrade completed, no error and a working unity desktop post-reboot
<slangasek> stgraber: huzzah
<stgraber> hopefully we'll know if we broke anyhing else in the process when we get some jenkins run with -proposed on Monday ;)
<slangasek> indeed
<cjwatson> and accepted
<slangasek> cjwatson: the regressions/ subdir doesn't seem to be processed at build time by the testsuite in quantal; is it expected to be?
<slangasek> hmm, language-selector was marked for python3 but the dbus backend isn't actually compatible at all :/
<slangasek> cjwatson: heh, and in fact test_lp768691 doesn't run under python3 at all (either the old or new test) because there's no such thing as 'unicode'
<cjwatson> slangasek: I don't know
<cjwatson> That would be a glatzor question
<slangasek> fair'nuff
<slangasek> ok, that's all the aptdaemon UnicodeDecode crashes that errors knows about, phew
<slangasek> ev: so, that strange dip in all the crash graphs on 5/17... when did the retracer backlog get cleared?
<ev> slangasek: I don't think it has to do with the retracers, as they're not involved for python crashes, which are also showing the dip
<slangasek> ok
<slangasek> interesting
<ev> the retracers are a whole 'nother ball of pain for me, actually:
<ev> ugh, damn open id
<ev> the link I was going to paste isn't working
<slangasek> it's also possible that many of these crashes hit users more than 3 times per week, so a week after upgrade they've stopped reporting
<slangasek> but I wouldn't expect it to be quite so sharp, or quite so universal, in that case
<ev> yeah
<slangasek> anyway, just throwing out the thought... back to cleaning house now :)
<ev> at least the lines aren't exactly the same
<ev> it's not like it's just somehow sourcing the same data for all of them
<ev> but there's something special about the 17th
<ev> and I have no idea what it is yet :-/
<ev> I looked for apport uploads around that time
<ev> but there really isn't anything that lines up
<ev> and I suspect we'd see more of a gradual drop off if that broke it
#ubuntu-release 2012-08-12
<Laney> micahg: you here?
<micahg> yes
<Laney> micahg: you should be able to accept backports yourself now
<micahg> Laney: ooh, looking
<Laney> edit-acl -t admin -S lucid -p micahg query
<micahg> wow
<micahg> Laney: do we have any issues with overrides for existing backports?
<Laney> i'm not aware of any
<cjwatson> micahg: how do you mean?
<micahg> cjwatson: I've never done this before and saw the drop downs and was wondering if any manipulation was necessary for non-NEW stuff on approval
<cjwatson> Generally just leave those alone.
<micahg> yeah, that's what I did
<Laney> I think it's recommended to use the 'queue' tool
<ogra_> cjwatson, are you now also spending your sundays in internet cafes ?
<cjwatson> Mobile hotspot on my phone.
<cjwatson> Just about works.
<stgraber> cjwatson: your home internet broke again?
<cjwatson> stgraber: lasted twelve hours and then fell over
<cjwatson> and I'm over the "fair use period" on my mobile broadband so I think it'll be back to coffee shops and libraries next week, as I'm now seriously restricted between 1600 and midnight :-/
<babyface> utlemming ,   job  quantal-server-ec2-daily are failing in jenkins,  http://10.98.0.1:8080/view/Quantal/view/ISO%20Testing/job/quantal-server-ec2-daily/69/
<micahg> anyone mind if I add a PTS link on the transition tracker?
<micahg> http://paste.ubuntu.com/1143787/ is the diff I'd like to apply
<Laney> i'm not sure it will be rebuilt
<Laney> you should apply it to the new transition tracker
<micahg> hrm?
<micahg> to the configs branch?
<Laney> no, the code one
<Laney> however, mehdi has implemented a proper template system upstream so this will be doable through that when we merge that
<micahg> should I wait?
<Laney> if you want it deployed soon then you should get it into the new branch and into the ben package in quantal, then backported to precie
<Laney> that's what we'll be running soon
<micahg> where's the branch?
<Laney> lp:ubuntu-transition-tracker
<Laney> iirc
#ubuntu-release 2013-08-05
<apw> systemd seems to have some 'stuck' autopkgtest test, jenkins seems to be reporting them complete, but they show RUNNING in britney
<cjwatson> jibel: ^-
<jibel> apw, cjwatson unstucking
<apw> jibel, thanks
<psivaa_> cjwatson: xnox: reported bug #1208401 for lvm server smoke test failures from 20130803. Reported against lvm2. Not sure who else to ping :)
<ubot2`> Launchpad bug 1208401 in lvm2 (Ubuntu) "saucy server lvm installations fail to boot " [Undecided,New] https://launchpad.net/bugs/1208401
<xnox> psivaa_: well recent TIL is good to ping as well. https://launchpad.net/ubuntu/+source/lvm2/+changelog were the images with 2.02.98-1ubuntu3 ok?
<xnox> psivaa_: maybe apw and/or roaksoax need a ping about ^
<psivaa_> xnox: thanks
<didrocks> cjwatson: infinity: I wonder if the chroot isn't stuck: https://launchpad.net/ubuntu/+source/mesa/9.1.4-0ubuntu6/+build/4845897
<cjwatson> didrocks: asked ops, thanks
<didrocks> hhyw
<xnox> infinity: can you de-new tk8.6 from above ^ that should be the last bits of multiarching tk/tcl s
<infinity> xnox: Danke.  Is this tcl/tk multiarch stuff going to end up in Debian so we don't have to carry deltas forever for detecting things in configure, etc?
<xnox> infinity: bugs and patches are in bts. It's uploaded in experimental, pending de-newing there. So eventually it will land, hopefully in jessie time frame.
<infinity> xnox: jessie's a long way off, one would hope. :P
<stokachu> how would i get a python 2.7 application into main if it is not being accepted in a seed update?
<stokachu> its a private python module so making it a build dependency on another package in main doesn't make sense
<stokachu> bug 1206106 is the one im working on
<ubot2`> Launchpad bug 1206106 in sosreport (Ubuntu) "[MIR] sosreport" [High,Fix committed] https://launchpad.net/bugs/1206106
<infinity> stokachu: "Not being accepted in a seed update" how?
<infinity> stokachu: It either needs to be seeded, or isn't in main.  There's no in between here.
<stokachu> infinity: i was told that python 2.7 wasn't being accepted
<stokachu> infinity: i created an MP to see sosreport on cloud-image, desktop, server, and server-ship
<stokachu> seed*
<infinity> stokachu: python2.7 is in all those tasks already.
<infinity> stokachu: Though, we'd prefer not, sure.  I take it porting sosreport to python 3 would be very painful?
<stokachu> infinity: not to painful i've started on the port already
<stokachu> but im getting some push from cloud guys to have it seeded on cloud-image
<infinity> stokachu: So see it for cloud-image.  It's their seed.
<infinity> stokachu: Who told you that you can't?
<stokachu> infinity: smoser didnt want any new python 2.7 private modules in there
<stokachu> and i believe seb128 didn't want any new python 2.7 on the server one
<stokachu> or maybe that was desktop, im not sure
<seb128> it was desktop
<stokachu> seb128: thanks i forgot :D
<seb128> I've no say about server
<seb128> and don't really care what they do
<seb128> but we have been under pressure to drop python2 from the desktop install for some cycle and we are not adding new users
<infinity> stokachu: So, which "cloud guys" are asking for it to be added?  Clearly not smoser.  Or is he arguing with himself? ":P
<infinity> stokachu: Anyhow, it could be seeded in supported.  It doesn't need to be in any default install to be in main.
<stokachu> infinity: so could i get it seeded in supported and then talk to the cloud team about the importance of having it on their seed?
<infinity> stokachu: Yeahp.
<infinity> stokachu: I'll do it now.
<stokachu> infinity: awesome man i appreciate it! was just updating the MP
<stokachu> infinity: should i just close this https://code.launchpad.net/~adam-stokes/ubuntu-seeds/ubuntu.saucy/+merge/177469
<infinity> stokachu: Yeah, just ditch the MP, I already committed.
<stokachu> infinity: thanks man this helps a lot
<infinity> stokachu: And commented on the bug to reflect the current state of... Whatever.
<stokachu> infinity: haha love the comment
<xnox> stokachu: given that all of openstack is python2.7 it is inevitable to have python2 on server images.
<stokachu> xnox: good point
<stokachu> med_: ^
<xnox> stokachu: ditto cloud-init on cloud images.
<med_> nod.
<med_> stokachu, thanks.
<stokachu> med_: :)
<infinity> xnox: Right, but the point is that some product managers would prefer not to accept any *new* python2.7 packages.  The goal is to reduce the number to 0, not use the current >> 0 value to excuse increasing it.
<infinity> stokachu: ^
<stokachu> infinity: ok sounds good
<skellat> infinity: Are you available and willing to take a look at this today perhaps? https://bugs.launchpad.net/ubuntu/+source/xubuntu-docs/+bug/1207493
<ubot2`> Ubuntu bug 1207493 in xubuntu-docs (Ubuntu) "[SRU] Documentation does not match shipped system version (11.10 shipped with 12.04)" [High,Confirmed]
#ubuntu-release 2013-08-06
<infinity> slangasek: You around?
<slangasek> infinity: ohai
<infinity> slangasek: https://launchpad.net/ubuntu/+source/debian-installer/20101020ubuntu136.11
<infinity> slangasek: Can you sru-release that as soon as its all built and published (in an hour or two)?
<slangasek> infinity: ack
<infinity> slangasek: The current precise-updates d-i is built against a kernel that never made it to -updates, so iz broke.
<infinity> slangasek: Belay the d-i/precise request.  I'm still awake, I'll nab it on the next publisher run.
<slangasek> infinity: mmk
<apw> openvswitch seems to have built and tested just fine (second time) and yet britney is listing it as autopkgtest fail ... could someone who knows how poke it
<ogra_> is there any way for a packge to know it is installed on a package builder ?
<ogra_> infinity, ^^  do you knwo ?
<stgraber> ogra_: that's sounds like an hack ;) but I suppose checking for /build may do the trick
<ogra_> stgraber, better than nothing :)
<ogra_> we need a way for libhybris to know it lives in a build env ...
<ogra_> else it sets an alternative for GLES that points too a non existing android dir
<ogra_> (instead fo just using mesa ... which it shoudl for builds)
<stgraber> ogra_: you may also be able to use some env variables set by dpkg-buildpackage which should be better than looking at /build (as /build won't exist on your local machine when running debuild)
<stgraber> ah though if you need that to be checkable from the postinst of a build-dep, then I guess /build may be the only way (that I can think of anyway)
<ogra_> well, doesnt postinst see the env vars ?
<ogra_> that sounds more proper than checking for /build
<ogra_> rsalveti, ^^^
<stgraber> ogra_: yeah, it'd except that it's not dpkg-buildpackage installing the build-deps but sbuild, so you'll be missing most/all build env variables that early in the build process
<ogra_> i need an opinion ... builds fail if Mir is involved because hybris sets the GLES alternative to /system/lib ...  during build we'd like it to use mesa instead
<ogra_> stgraber, bah, k ... so that wouldnt help
 * rsalveti looks
<rsalveti> ogra_: why is hybris even used there?
<ogra_> rsalveti, yeah, i was pushig to just drop the dep from Mir as well
<ogra_> but tvoss says that doesnt work because he uses its herades for gralloc etc
<ogra_> so the -dev is a build dep of Mir (which breaks all normal armhf desktop installs :( )
<ogra_> *headers
<rsalveti> hm, in theory it should just use mesa
<rsalveti> where is tvoss
<ogra_> they were about to move the alternative creation into lxc-android-config but i vetoed
<ogra_> (thats like udev shipping an xorg.conf)
<rsalveti> ogra_: where did this discussion happened?
<cjwatson> Isn't there a way to select a GLES provider other than via the system alternative?
<seb128> rsalveti, in half a dozen channels and lists today :p
<ogra_> cjwatson, not implemented i think
<cjwatson> Some solution like that sounds much more likely to be robust to me
<cjwatson> ogra_: You have to implement *something* :)
<ogra_> cjwatson, and it would involve changing lots of packages i guess
<rsalveti> seb128: haha
<cjwatson> Surely not
<seb128> rsalveti, he pinged you earlier on #phablet, maybe pong there
<cjwatson> Strawman: LD_LIBRARY_PATH or LD_PRELOAD
<ogra_> i.e. nvidia/ati drivers on x86
<cjwatson> ogra_: I don't care about drivers, this is at build time
<ogra_> cjwatson, yeah i suggested that ... seb128 decliend ... i forrgot why
<ogra_> rsalveti, sadly it is spread all over the channles (and the ML now)
<ogra_> there he is :)
<seb128> cjwatson, ogra_: we are not going to patch every package in the archive calling xvfb-run make check...
<ogra_> tvoss|lunch, stop eating :)
<tvoss|hungry> ogra_, done ;)
<ogra_> seb128, ah, right, i remember it was valid ... just forgot what it was :)
<ogra_> cjwatson, no it isnt
<ogra_> cjwatson, it is for packages that depend on libmir
<cjwatson> How about a shim library that tries GLES from the Android directory and falls back to Mesa if it doesn't exist?
<rsalveti> tvoss_: so, why do you need to build-depend on libhybris?
<cjwatson> Should be eminently doable with dlopen et al
<ogra_> cjwatson, that would break image builds ... we dot have android available there
<cjwatson> ogra_: What are you replying to?
<ogra_> <cjwatson> How about a shim library that tries GLES from the Android directory and falls back to Mesa if it doesn't exist?
<ogra_> <r
<tvoss_> rsalveti, because the mir client library needs hardware/fb.h, hardware/gralloc.h at buildtime
<cjwatson> ogra_: Can you elaborate on why that would break image builds?  Why do they need to load GLES?
<ogra_> cjwatson, oh, i see, you would drop the alterbnative completely
<cjwatson> And why would they care if they got Mesa as a run-time choice?
<ogra_> yeah, i didnt get that bit
<ogra_> sorry
<cjwatson> ogra_: Not necessarily, since that's probably wired in elsewhere, but have an alternative provider that can dynamically select for itself
<ogra_> i thought yu wanted a separate entiti for setting the alternative
<cjwatson> I would prefer to leave the alternative in place and have it point to something smart
<tvoss_> cjwatson, that's what we need and want for supporting multiple vendor-specific egl/gl implementations being installed and usable in parallel
<ogra_> yeah
<ogra_> well, i think having the postinst be intelligent would suffice
<cjwatson> No, it's better not in the postinst
<cjwatson> Because the postinst is run in a non-Android environment (image build) and then the contents of the system transferred to a device where Android is present
<cjwatson> You could have the library's constructor do a few checks with dlopen and then set a load of function pointers based on what it finds
<cjwatson> It's certainly no harder than all the crazy stuff libhybris already does :)
<ogra_> so you would do it in libmirclient ? or in hybris ?
<rsalveti> tvoss_: so would it need such files for all archs?
<cjwatson> And this way, you can check for what you actually care about (is Android there?) rather than a strange proxy (are we in a package build environment?)
<cjwatson> ogra_: Don't know enough about them to pick one
<ogra_> k
<tvoss_> rsalveti, no, only if we build the android driver model, and we take armhf as a trigger for that
<seb128> rsalveti, it doesn't, the deps is only there on armhf, but armhf != android
<ogra_> (arent you on vacation ? i pinged adam on purpose because i thought so :) )
<cjwatson> ogra_: Me?  No
<ogra_> ah , k
<ogra_> i thought you said something about skiing yesterday
<rsalveti> seb128: tvoss_: right, assuming armhf == android is already wrong indeed
<ogra_> yeah
<infinity> If hybris is linked against this library, it seems sensible for it to be the one doing the resolution at runtime.
<infinity> Since it's the only thing that cares about which one it uses.
<tvoss_> rsalveti, fully agreed, and we would love to have a different trigger
<ogra_> infinity, it isnt linked thats the issue ... it uses the alternative ... but forcefully sets it
<ogra_> (to something nonexisting)
<infinity> ogra_: It "uses" the alternatives, how?  It's still linked to and/or dlopening a library, or there wouldn't be a problem. :P
<ogra_> it is linked to the alternative ... which the postinst sets to something that doesnt exist if android isnt available
<rsalveti> tvoss_: seb128: do you have the build log for the original issue?
<infinity> ogra_: If it's a dlopen, this becomes trivial.  If it's linked, then you'd need an intelligent stub.
<tvoss_> infinity, hybris provides an alternative libEGL, that gets selected as the default when hybris is installed
<rsalveti> too many parallel talks and my brain is still waking up
<seb128> rsalveti, https://jenkins.qa.ubuntu.com/job/unity-saucy-armhf-autolanding/157/console
<seb128> rsalveti, that's one
<cjwatson> ogra_: Not I.  In two weeks I'm going to be in the middle of the Alps, but whether that will involve any skiing is debatable since I've never skied before
<infinity> tvoss_: Oh, I see.  So it's everything else being linked to it that's the issue.  Not running it through hybris.
<ogra_> cjwatson, heh, Alps = skiing for me like armhf = android for tvoss_ ;)
<cjwatson> In that case I would suggest a new stub library
<tvoss_> rsalveti, don't have it handy, but in summary: hybris installed -> egl from hybris forced as default -> applications accessing default egl impl -> kaboom
<rsalveti> seb128: that's because it's trying to use that library when running the test, right?
<infinity> tvoss_: So, the libhrybris-provided libEGL should be a stub that loads the right bits if they're there, and not if they're not.
<tvoss_> cjwatson, +1, and we could reuse that work to support vendor-specific (nvidia, amd) egl/gl implementations being installed in parallel
<tvoss_> but: we need a short-term fix to unblock CI
<seb128> rsalveti, it's trying to use a graphical toolkit, which leads to that
<rsalveti> right, it's not just a linking issue, it's indeed trying to use the library
<seb128> rsalveti, same issue on ubuntu-system-settings trying to run a qt5 ui through xvfb-run
<rsalveti> and failing because hybris can't load /system/lib/libGLESv2.so
<tvoss_> infinity, true, but see my comment to cjwatson :) ideally, the mesa egl would be clever, and hybris would be just another implementation
<tvoss_> rsalveti, right, linking is not the problem
<cjwatson> Perhaps, but there's no reason you should block on that.
<cjwatson> Or even try to do it in the first pass.
<ogra_> why cant xfb unset the alternative btw ?
<ogra_> as a quick hack
<ogra_> *xvfb
<cjwatson> Sounds scary
<cjwatson> Messing with alternatives is on my "avoid if possible" list
<tvoss_> cjwatson, the moment tests are executing, they crash
<ogra_> well, hack ... and quick were in the sentence :)
<cjwatson> Especially outside maintainer scripts
<stgraber> ogra_: because people have xvfb installed on their desktop machines too?
<cjwatson> Quick hacks can be hard to undo
<ogra_> stgraber, crazy people :P
<stgraber> ogra_: well, I'd expect any ubiquity developer to have it and anyone who worked on projects that mvo once started ;)
<ogra_> why would i need it for ubiquity ? i just test  in a real X :)
<stgraber> (unless they like windows randomly popping up on their screen while the pre-commit stuff runs ;))
<cjwatson> ogra_: We have this thing called a test suite :)
<ogra_> :)
<ogra_> i dont mind popping up windows
<rsalveti> tvoss_: would we also have test cases to test gralloc or such?
<rsalveti> if so, then we're back to the same issue, even with a stub
<tvoss_> rsalveti, sure, exercising the mir parts that make use of it
<rsalveti> we basically can run such tests that depend on hybris if we're not in a valid android environment
<rsalveti> unless we have fake stubs for everything, but which will cause side effects for the tests as well
<tvoss_> rsalveti, true, that's why a lot of mir tests on armhf are currently disabled
<ogra_> cjwatson, stgraber, in any case i would just make xvfb-run export something like "HYBRIS_USE_MESA" and make the hybris postinst alternative setup be conditional for this as the quick hack i was proposing ... shouldnt do any harm to xvfb-run
<rsalveti> heheh
<stgraber> ogra_: I doubt that'd work as you'd need to have the dependencies be installed under xvfb-run which I doubt they are
<ogra_> oh, right, so HYBRIS_USE_MESA would have to override the alternative inside hybris ...
<ogra_> thats not a quick hack anymore indeed
<rsalveti> if anyone around, mind taking a look at ^
<rsalveti> just moving stuff from libhybris into more packages, android-platform-headers, libhardware2 and libhybris-common1
<rsalveti> this will solve that mir/hybris issue in the archive for armhf that we had today
<rsalveti> will split the rest after proper discussion with upstream, as I'd like some libs to get renamed as well
<seb128> rsalveti, seems weird that you don't have Replaces/Breaks (<< new), on the old binaries, to avoid file conflict on update?
<rsalveti> seb128: the new packages would need to replace/breaks << libhybris, right?
<seb128> rsalveti, yes
<rsalveti> doing so many things in parallel that I forgot that
<seb128> rsalveti, otherwise you might have apt hitting file conflicts if the e.g libhardware is unpacked before libhybris is upgraded
<rsalveti> seb128: let me cook another upload
<seb128> rsalveti, thanks
<seb128> rsalveti, also you are sure it's not going to break touch? e.g nothing is depending on libhybris and expecting to get libhardware with it?
<rsalveti> seb128: mir is the first one
<seb128> rsalveti, you might want to keep libhybris depending on libhardware (if it's not doing it through shlibs)
<seb128> rsalveti, to avoid those issues
<rsalveti> seb128: yup
<skellat> Greetings.  Is anybody willing and able to dispose of this SRU request plus Sponsored Upload request?  https://bugs.launchpad.net/ubuntu/+source/xubuntu-docs/+bug/1207493
<ubot2`> Ubuntu bug 1207493 in xubuntu-docs (Ubuntu) "[SRU] Documentation does not match shipped system version (11.10 shipped with 12.04)" [High,Confirmed]
#ubuntu-release 2013-08-07
<micahg> skellat: -release isn't a good venue to ask for sponsorship, the patch pilot in -devel would be a good place
<tumbleweed> grumble. I can't reproduce this failure https://jenkins.qa.ubuntu.com/job/saucy-adt-beets/. Ideas?
<xnox> tumbleweed: i have seen in the past jenkins mirror be behind, such that it'd test new .dsc againt out-of-date .deb. And the logs don't spell out clearly which version of package under test got installed =(
<tumbleweed> I wish there was an easy way to make ADT run tests without building from source
<xnox> tumbleweed: you are using lp:auto-package-testing scripts right? (they download ubuntu cloud image & run tests in there against a package from archive/ppa/bzr/local)
<tumbleweed> xnox: no, adt
<tumbleweed> ok, let me try that. but maybe not here at debconf...
<xnox> tumbleweed: so two scripts in auto-package-testing under bin/ is exactly the same way the tests are running in the lab. one is setup test-bed to create one and the other one is run-adt-test to run a test on a snapshot of the test bed under qemu.
<xnox> tumbleweed: right. Well i'll arrive on sunday and we can poke it then and there =) i can easily run adt tests on my remote server for you.
 * cjwatson starts deploying the phased-updater
<cjwatson> Seems to take a long time to start up without doing very much, although it has got past the point of logging into Launchpad
<cjwatson> Ah, just as I say that it starts sending mail
<cjwatson> 2013-08-07 11:51:47,417 - INFO - [u'ps-jenkins@lists.canonical.com'] mailed about [raring/nux] Possible Regression
<cjwatson> 2013-08-07 11:51:48,174 - INFO - [u'ps-jenkins@lists.canonical.com'] mailed about [raring/compiz] Possible Regression
<cjwatson> that might not get much attention ...
<cjwatson> All SRU team members: please update your ubuntu-archive-tools checkouts to at least r764
 * yofel just got a bunch of mail with that topic, so it seems to work ^^
<cjwatson> I hope it's useful.  If it's wrong, though, complain to bdmurray, I'm just playing sysadmin here :-)
<mdeslaur> cjwatson: how do I check the phased update status of a package?
<mdeslaur> cjwatson: I just got a bunch of emails for security updates that say the phased update has been stopped
<cjwatson> mdeslaur: Like I say, I'm just operating this, but I think it only actually decreases the phased update percentage if there was already one (other than "everyone") set
<mdeslaur> cjwatson: ok, I'll wait for bdmurray then, thanks
<cjwatson> So the e-mails are probably wrong in that detail, but right about there being a regression to look at
<cjwatson> mdeslaur: You can see the phased update percentage on https://launchpad.net/ubuntu/<series>/<arch>/<binarypackage>
<cjwatson> (Which is bloody hard to find by navigation so I suggest memorising the pattern)
<cjwatson> It should normally be the same for all binaries in a source
<mdeslaur> there's...nothing in the column
<mdeslaur> https://launchpad.net/ubuntu/raring/amd64/libdns95
<cjwatson> Yes, that means "everyone"
<cjwatson> My understanding is that this is a transitional period, because the things that have been published to -updates haven't had a PUP set
<cjwatson> But that was why I was asking SRU team members to update to ubuntu-archive-tools r764
<cjwatson> I recall we talked about what to do with security updates at the client sprint but I don't remember what we agreed
<mdeslaur> I don't recall the exact outcome either...I believe we discussed a maximum time for security updates and having the urgency field work to bypass it or something
<cjwatson> At any rate I'm reasonably sure that at the moment security updates just won't have phasing applied
<cjwatson> But hopefully Brian can clarify
<bdmurray> mdeslaur: I'm still investigating but the email notifications were in errors, as cjwatson indicated the phasing has not been stopped.
<mdeslaur> bdmurray: ok, so I can disregard for now?
<bdmurray> mdeslaur: Yes, for now
<mdeslaur> bdmurray: thanks
<seb128> bdmurray, it would be nice to send an email to ubuntu-devel@ about what's going on maybe?
<bdmurray> seb128: yes, I'll be doing that today.  Nothing was supposed to happen yet as no packages in -updates have a phased update percentage set.
<cjwatson> ubuntu-archive-tools> make that r765
<bdmurray> cjwatson: one more phased-updater change https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/pu-no-email/+merge/179013
<cjwatson> bdmurray: done
<bdmurray> thanks
<Ampelbein> Can someone accept the libpar2 binary packages in saucy NEW? Or do they need to get reviewed first?
<ScottK> They need to get reviewed.
<Ampelbein> Ah, ok. Thought that was only for new source packages. Learn something new every day ;-)
<ScottK> No, new binary packages too.
#ubuntu-release 2013-08-08
<xnox> can libimobiledevice be denewed ^ it's api/abi transition which i'd like to complete whilst patch piloting
<seb128> xnox, looking
<xnox> seb128: thanks a lot!
<bdmurray> cjwatson: How would you find the publishing history here? https://launchpad.net/ubuntu/raring/i386/apport  I'm specifically interested in the Superseded record with p-u-p set to 10%.
<bdmurray> using the Launchpad API
<slangasek> infinity: precise ISOs are all listed as oversized... do we have too many kernels again?
<ogra_> cant have anough kernels
<cjwatson> bdmurray: You mean something like this?  http://paste.ubuntu.com/5962969/
<bdmurray> cjwatson: yep, but is there anyway to get there from getPublishedSources?
<tseliot> any admins around who can reject some packages for me?
<stgraber> tseliot: sure
<tseliot> stgraber: nvidia-prime fglrx-pxpress and jockey in precise-proposed, thanks
<stgraber> tseliot: done
<tseliot> stgraber: thanks again
<wgrant> bdmurray: spph.getPublishedBinaries()
<cjwatson> bdmurray: You could go through each published source and call getPublishedBinaries on it, I suppose, but it would be slow if you had to go back very far
<slangasek> tseliot: reject> hmm, so are you prepping a reupload?
<tseliot> slangasek: yep, I wanted to add a fix for bug which has already landed in saucy. I'll reupload in a minute
<tseliot> *for a bug
<tseliot> slangasek: I can give you the relevant diffs if you want
<slangasek> tseliot: ok
<tseliot> slangasek: you can find the patches in the three directories here: http://people.canonical.com/~amilone/1198942/
<cjwatson> ^- one-line fix for a v-failed SRU; should be a quick review for somebody
<stgraber> cjwatson: I'll take a look
<stgraber> bdmurray: any idea why ./sru-review -s lucid debootstrap doesn't work?
<cjwatson> works for me
<stgraber> http://paste.ubuntu.com/5963264/
<bdmurray> Did you get the warning about it already being published?
<stgraber> nope, just what I pasted above
 * stgraber tries on another machine
<stgraber> bdmurray: ok, on another machine it seems to work (and indeed I'm getting the already published warning there)
<stgraber> so maybe some caching problem on my laptop, will investigate later
<stgraber> cjwatson: there you go
<bdmurray> stgraber: okay, weird
<cjwatson> thanks
<bdmurray> Does anybody have an idea why ogmrip is in the SRU queue for raring?
<bdmurray> the changelog just says "New upstream release"
<Ampelbein> Ups. I accidently uploaded to precise-proposed, can that upload of tboot be removed please. Sorry sorry sorry.
<infinity> slangasek: We shouldn't be overly kerneled, the fix last time around should still be valid.  Stuff might have just gotten bigger again.  Time to drop English? :P
<infinity> slangasek: Or, more realistically (if it's not something obvious we can fix), time to say "if you want CD-sized ISOs, install from 12.04.1" and stop guaranteeing it for point releases?
<slangasek> infinity: wasn't 12.04 already oversized for CDs?  I don't remember now
<infinity> slangasek: Nope.
<infinity> slangasek: http://releases.ubuntu.com/precise/
<slangasek> anyway, if everything has just gotten bigger, then yeah we should raise the limit and call it good; but I think we want to check first that we don't have spare packages on the images
<infinity> slangasek: Those are all CD sized.  But easy enough to diff some manifests and see if something went obviously awry or if it's just that firefox/tbird/etc grew again.
<slangasek> infinity: would you mind having a look at that?
<infinity> slangasek: I think we're down to a point where we can no longer remove any langpacks, so we're running shy on options to shrink precise.
<infinity> slangasek: Yeahp, I can haz look.
<slangasek> ok
<infinity> slangasek: Nope, doesn't look like we've added anything (though, we've removed a few packages), so it's just that stuff got bigger.
<slangasek> infinity: ok, thanks for checking
<infinity> slangasek: I'll poke at it and see if there's any sane path to shrinkage before we decide to give up and tell people precise point releases ain't gonna fit on CDs anymore.
<slangasek> cjwatson: ^^ any objections to just letting 12.04.3 spill over beyond CD size?
<slangasek> hmm, this may be my favorite typo ever: DEB_BUILD_POTIONS
<xnox> slangasek: https://plus.google.com/+FlorianRohrweck/posts/KAgNuNKQHgJ
<slangasek> wgrant, infinity: hey, so do you guys know if launchpad is ok with :any build-dependencies, or if there's more work needed to support that?
<slangasek> xnox: hah
<wgrant> slangasek: Our sbuild will break on that.
<wgrant> I believe.
<slangasek> wgrant: fiddlesticks
<cjwatson> slangasek: spill over> I have minimal ability to care just now, I think
<cjwatson> people can always use .2.  of course it would be nice to avoid it
<slangasek> wgrant: so, ah, how about that plan to upgrade away from a fork of a nine-year-old version of sbuild? ;)
<slangasek> wgrant: the reason I'm asking is that we're at the point where this blocks having stock packages in the archive be cross-buildable, for things like unity: https://code.launchpad.net/~saviq/unity8/prepare-cross-build/+merge/179250
<slangasek> cjwatson: ack
<wgrant> slangasek: The main blocker is getting Soyuz ddeb support switched on, which is waiting on librarian space, which is waiting on a physical SAN move.
<wgrant> We went through it all in London, and it looks like the upgrade should be pretty painless.
<slangasek> wgrant: ok.  Do you have an ETA from IS on this?  (Is there as RT I can play along with at home?)
<wgrant> slangasek: I'm not sure of an ETA.
<slangasek> ok
<slangasek> I guess I'll pester IS then :-)
<slangasek> wgrant: btw, how does soyuz ddeb support relate to the sbuild upgrade?
<wgrant> slangasek: ddebs are currently implemented by a hack in sbuild which copies them to public_html.
<slangasek> aha
<wgrant> ITYM eww
<slangasek> so... supposing we needed :any support sooner than IS was going to get us the newshiny librarian... how much work would it be to forward-port that patch?
<wgrant> It's possible that we can do it from outside sbuild.
<wgrant> Or hack it back in
<wgrant> But we also either need to backport precise's sbuild to hardy, or get the remaining buildds off hardy.
<wgrant> And we can't do the latter yet.
<slangasek> we... can't?
<wgrant> It's complicated :)
<cjwatson> needs builderstack
<slangasek> muttrgrmbl
<cjwatson> we should draw a diagram, the dependency graph is non-trivial
<infinity> slangasek: Doing any support in our sbuild is trivial.  And may already work.
<infinity> slangasek: Because the right answer when you're always building natively (as we are) is just to stip off :foo and pretend you wanted native.
<slangasek> infinity: right, that's a much better shortcut
<infinity> And we already do.
<infinity>         # For the moment, we treat multiarch-annotated build-dependencies as
<infinity>         # the same as any others because we're not implementing a
<infinity>         # cross-buildd.
<slangasek> ah, spiff
<infinity>         $deps =~ s/:any//g;
<infinity> So, sbuild supports it, as long as LP doesn't choke elsewhere.
<infinity>         $deps =~ s/:native//g;
<slangasek> so unity isn't going to explode suddenly :)
<infinity> Wait, didn't we already have a bunch of :any build-deps before?  (gettext?)
<infinity> So, this is provably tested and known working.
<slangasek> ah, yes; I think those wound up being backed out and handled differently because *Debian* wasn't ready to cope with them yet at the time
<slangasek> but they did go through once already in Ubuntu
<wgrant> Oh, I just remembered that we got rid of some in the not too distant past, but it could quite possibly be that it was a Debian issue... oops.
<infinity> So, yes, the "use a sane sbuild" thing is on the roadmap, but not urgent.
<slangasek> infinity: right, thanks for setting me straight before I started burning the curtains
 * infinity wonders why lib32asound2 and libc6-i386 are on the precise CDs.
<infinity> Not that this is new, they appear always to have been.
<slangasek> interesting question
<infinity> sl-modem-daemon, apparently.
<slangasek> horrifying answer
#ubuntu-release 2013-08-09
<slangasek> pretty sure we should shoot sl-modem-daemon in the head; I remember it being unmaintained/unmaintainable and RC-buggy already back in lucid
<infinity> Well, dropping that might get your CDs down to size.  Maybe.
<infinity> Then again, if we just give up the CD size thing, we could go 750 or 800 and include some actual translations again.  Which could be nice.
<slangasek> certainly, the intersection of (people who need a newer image for enablement) and (people who need sl-modem-daemon) should be null
<infinity> Linux for Human Beings* (who speak English) is a bit irritating.
<slangasek> if it makes you feel better about it, we could squeeze the tlh langpack on
<infinity> *snicker*
<infinity> linux/armhf build down from 17.5h to 5.25h.  I think I'm happy with that.
<Sarvatt> infinity: just curious, is that on a 24 node calxeda or a 12 node?
<slangasek> 24
<Sarvatt> kind of expected faster for 24 vs a panda if it was that.. unless the old ones weren't pandas
<slangasek> Sarvatt: 24 *nodes* != 24 *cpus*
<slangasek> think blade server
<slangasek> each of which is quad-core
<slangasek> (IIRC)
<Sarvatt> ah, so it builds on one and the rest can be off building other stuff?
<slangasek> Sarvatt: yes; each node is a separate host, https://launchpad.net/builders kishi[1-23]
<Sarvatt> oh thats awesome :)
<Sarvatt> if only LO webkit kernel firefox and chromium could be blocked it would be enough for public arm ppas :)
<infinity> Sarvatt: Yeah, each node is a quad core A9 w/ 4G of RAM and its own disk.  They just happen to share a box and a network/power backplane.
<infinity> Sane ARM PPAs will happen when we have ARM kit that can do paravirt.  So, A15s or A57s.
<didrocks> Mirv: NEWed FYI ^
<Mirv> ah, great
<tjaalton> didrocks: hey, have you had time to look at MIRing nvidia-prime & fglrx-pxpress (lp1204820)?
<didrocks> tjaalton: not today, can append that on Monday
<tjaalton> didrocks: ok, thats fine, thanks
<cjwatson> slangasek: Debian's still not ready to cope with :any, AFAIK; current sbuild and buildd can cope, but I don't think wheezy's can, and I think wanna-build explodes.  This was on my list to chase down at DebConf
<jibel> cjwatson, infinity FYI I swtiched autopkgtest to ftpmaster and per package configuration files when there is one. So linux and libreoffice can use bigger disks, more RAM and CPUs.
<jibel> and linux is green now
<rbasak> SRU verification failed on bug 1121874. 32 affected on bug 1210380, which appears to include people who aren't aware that they have -proposed enabled.
<ubot2`> Launchpad bug 1121874 in mysql-5.5 (Ubuntu) "MySQL launch fails silently if < 4MB of disk space is available" [Medium,Triaged] https://launchpad.net/bugs/1121874
<ubot2`> Launchpad bug 1210380 in mysql-5.5 (Ubuntu) "package mysql-server-5.5 5.5.32-0ubuntu0.12.04.2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Confirmed] https://launchpad.net/bugs/1210380
<rbasak> 32 affected in just a few hours, so please can we pull mysql-server-5.5 from -proposed asap?
<xnox> !regression-alert
<ubot2`> cjwatson, jdong, pitti, skaet, ScottK, kees, Daviey, pgraner: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
<xnox> see rbasak ^
<rbasak> xnox: it's only -proposed, not -updates
 * xnox ponders where above list of people is maintained.....
<rbasak> In ubottu, AFAIK.
<xnox> cause it should include update list of archive admins... who can remove packges.
<rbasak> Evidently nobody tested this upload. doko ^^
<seb128> infinity, slangasek: ^
<seb128> xnox, rbasak: I can run the delete command if you want
<seb128> but I'm neither nor in SRU team nor knowing the details about this specific issue
<rbasak> It's only i -proposed, so I don't think it's critical to do it right this minute. An hour is fine IMHO, so I guess we can wait for an SRU team member.
<seb128> e.g I decline responsibility if deleting it is wrong :p
<seb128> let me delete it
<seb128> rbasak, xnox: it's "mysql-5.5 5.5.32-0ubuntu0.12.04.2 in precise-proposed"?
<rbasak> seb128: yes. 5.5.32-0ubuntu0.13.04.2, 5.5.32-0ubuntu0.12.10.2, 5.5.32-0ubuntu0.12.04.2
<seb128> rbasak, xnox: dropped from proposed for the 3 series, please see with the SRU team what to do next then
<rbasak> seb128: thank you!
<seb128> yw
<seb128> stokachu, ^
<seb128> doko_, ^ you sponsored it it seems
<jdstrand> cjwatson: hey, you probably saw but I thought I'd explicitly say, I approved the click MIR yesterday
<xnox> Do we want python-virtualenv in main or not?
<stgraber> jibel: aware of any autopkgtest problem? I see ceph as RUNNING according to britney but it's been done for a couple of days now and lxc is also marked as RUNNING though it's not listed on either public or private jenkins
<stgraber> jibel: nevermind, they both just started doing stuff :)
<stgraber> jibel: so looks like they're shown as RUNNING before they actually get scheduled (or before the UI knows about them?)
<jibel> stgraber, yes, there is a delay between the time britney submits a test request and jenkins catches it
 * stgraber gets some popcorns and watches the lxc adt run, hoping this one will succeed
<jibel> stgraber, jenkins polls every 15mn for new tests, it is on my todo to replace this with an inotify watch on the incoming directory
<ScottK> It would be nice if those would be called "PENDING" or something until they start.
<stgraber> jibel: that'd be nice indeed. I think we forgot (or didn't know) about this 15min delay when we discussed the total build+migration time for packages back at the release engineering sprint (I think we assumed it'd just start instantly)
<stgraber> jibel: http://10.98.0.1:8080/view/Saucy/view/AutoPkgTest/job/saucy-adt-lxc/ARCH=amd64,label=adt/30/ <- any idea? (I'll see if I can reproduce it here)
<jibel> stgraber, no idea why mkstemp call fails
<stgraber> jibel: hmm, reproducable locally, odd. Let's see if I get that too outside of adt
<stgraber> jibel: same lxc-create outside of adt is fine...
<stgraber> jibel: hey, so what weird magic is adt-run doing?
<stgraber> jibel: I'm sshed into the VM, running "lxc-create -t ubuntu -n saucy-dep8 -- -r saucy" works, running it through adt-run doesn't
<stgraber> jibel: found it!
<stgraber> jibel: unset TMPDIR
<jibel> stgraber, hm, it could be because adt-run redefined TMPDIR
<jibel> :)
<stgraber> and now everything works
<stgraber> jibel: did that behaviour change recently? I'm wondering because we did have succesful runs for lxc...
<jibel> stgraber, no it didn't, adt-run setting TMPDIR has always been a problem
<stgraber> ok, not sure how our tests ever worked then ;) anyway, I'll just push the unset TMPDIR to the archive and be done with it
<stokachu> seb128: what was wrong with it?
<seb128> stokachu, bug 1210380
<ubot2`> Launchpad bug 1210380 in mysql-5.5 (Ubuntu) "package mysql-server-5.5 5.5.32-0ubuntu0.12.04.2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Confirmed] https://launchpad.net/bugs/1210380
<stokachu> seb128: hmm ok i tested it and it worked lemme go back and see what happened
<stokachu> seb128: ok i see the issue lemme go back and talk with support and get it straightened out
<seb128> stokachu, thanks
<jdstrand> cjwatson: ok, handled click promotion to unblock people. see https://bugs.launchpad.net/ubuntu/+source/click/+bug/1208800/comments/4 and change as desired
<ubot2`> Ubuntu bug 1208800 in click (Ubuntu) "[MIR] click" [Undecided,Fix released]
<slangasek> cjwatson: +1 for having it fixed at DebConf :)
<rtg> Why is Saucy armhf kernel still in the NEW state ? Its been done for over 7 hours.
<slangasek> rbasak: why are people not aware they have -proposed enabled?
<slangasek> rtg: because NEW requires manual processing
<rbasak> slangasek: I think there may be a class of users who just check everything, including maybe the -proposed box in update-manager.
<rbasak> slangasek: a comment like "Ubuntu: fix it soon, it broked all my mysql servers when upgraded." for something only in -proposed suggests this to me.
<slangasek> heh
<ScottK> I have suggested before that the wording around proposed is just a bit too inviting to casual users.  The response was basically, "but we want a lot of people to test running proposed".
<ScottK> I thought that was wrong before and I think it's wrong now.
<ScottK> I think it would be better to make proposed NotAutomatic like backports so you only get packages you explicitly want from proposed.
<rbasak> I'm not completely convinced by that. We have enough users that some proportion will always misinterpret, no matter what you do. The question is what that proportion is, and all we have here is evidence that at least one user misinterpreted.
<rbasak> There exist casual users who actually like to be on the bleeding edge and accept that, and 44 of the 45 affected may belong to that group (we have no indication otherwise).
<ScottK> I've also seen people enable proposed when asked to test something, take one look at it and say "It wants to upgrade 80 packages, OMG, no!"
<rbasak> I have no objection to pinning back -proposed by default, for when it is enabled.
<rbasak> Though perhaps that might be better off managed with careful update-manager UX.
<rtg> Can I get someone to NEW the Saucy armhf kernel binaries ? I'd like them to bubble up into release soon.
<ScottK> I think you'd want the combination of NotAutomatic and a proper UI.
<infinity> rtg: Done.
<rtg> infinity, thanks
<infinity> rtg: Are we ready to see 3.11 go to the release pocket today?  Have we triple-checked that tseliot's got nvidia/fglrx happy with it?
<rtg> infinity, tseliot has assured me that there are uploaded and functional
<rtg> that they*
<infinity> rtg: Alright.  We can bump d-i and watch the world burn over the weekend, or do it on Monday.  The latter may still be saner, unless we're all very confident. :)
<rtg> infinity, I'm gonna dogfood 3.11 on tangerine today, but I've also been running it on at least one other SNB 2 way. Since I'm gonna be gone this weekend, maybe we should wait until late Sunday ?
<infinity> rtg-afk: Waiting until Sunday/Monday to let it out of -proposed is fine by me.  Maybe I'll finish up the d-i/seed mangling by then and you/Andy can do the d-i ABI bump yourselves.
<rtg> infinity, wfm
<slangasek> ScottK: yes, I thought there was broad agreement that -proposed should be NotAutomatic, the problem is we don't yet have the UI to allow this to do something sensible
<ScottK> Ah.  Ok.
<ScottK> slangasek: BTW, did you see my comment on the blanket FFe for phone stuff?  Any thoughts?
<slangasek> ScottK: yes, saw the comment, sorry for not having a chance to reply yet
<ScottK> OK.
<slangasek> ScottK: my personal feeling is that the release team's freeze enforcement shouldn't be used as a proxy battle for other disagreements over the contents of packages
<slangasek> and that if qt5 maintenance is still problematic, we should face this head-on
<ScottK> I agree we should also face it head on, but think it shouldn't get the free pass.
<slangasek> for instance, supposing a change to qt5 was needed, and the patch got upstreamed and then backported; should someone have to request a separate FFe for that?
<ScottK> No, but based on past performance, I don't think it's reasonable to delegate assuming that'll be done.
<slangasek> is that wrt recent past (qt5)?
<ScottK> I have not had a chance to review the packages recently.
<ScottK> For raring I did give an FFe on the condition the change would be dropped for saucy since it wasn't upstreamable and then guess what didn't happen.
<slangasek> ScottK: can you give me a pointer to the source package that happened on? (since there are a few of them in the case of qt5...)
<ScottK> Sure.
<slangasek> but raring is certainly recent enough that I agree we should be paying attention to this
<ScottK> slangasek: The package is qtbase-opensource-src, the FFe was bug 1126205, and the relevant patch, enable_appmenu_support.diff (still there).
<ubot2`> Launchpad bug 1126205 in indicator-appmenu (Ubuntu) "[FFe] Bring Unity appmenu / HUD integration to Qt5" [Undecided,In progress] https://launchpad.net/bugs/1126205
<slangasek> ScottK: thanks
<ScottK> Also, there's another patch in there, fix_maliit_activation.patch, that says it should be upstreamed or dropped, but neither has happened.
<seb128> ScottK, it didn't happen *yet*, that's still on their list (I saw somebody mentioning it/the bug on their list of target before updating to 5.1, so they are aware of it)
<seb128> ScottK, where you see misbehaviour there are mostly people with just too much to do...
<ScottK> seb128: The agreement in the FFe was that it would be dropped when saucy opened.
<seb128> ScottK, that patch is already a special case since it's to avoid a regression compared to what we had with qt4, and it has not been creating any issue so far that we know about
<seb128> ScottK, right, people who agreed on that shouldn't have said that
<seb128> ScottK, it was clear that the requirement was not a reasonable one, I would have argued back against you if I had seen it when the discussion happened
<ScottK> That was the time to have the discussion.
<seb128> ScottK, the rational was "let's regress rather than take a patch which has been carried for ages in old qt, for the sake of making a point about getting things upstream first or not"
<slangasek> seb128: well, that didn't stop someone from agreeing to those conditions...
<seb128> ScottK, right, I can't remake history, I just can say I'm going to participate to the discussion next time so we don't sign to do things we are not going to do
<seb128> slangasek, right, and I agree there was a screwup there
<seb128> slangasek, but I can't really change it after fact...
<seb128> slangasek, all we can do is work to ensure we do better next time
<slangasek> so, I think that brings me back around to my original point that release team freezes shouldn't be used to dictate policy wrt the contents of packages
<slangasek> there's clearly a disagreement here about what the contents of the qt5 packages should be; the arbiter of that disagreement should be the TB, not the release team
<ScottK> That's true, but I think it's reasonable for the release team to keep an eye on things late in the cycle to make sure there's no late churn.
<seb128> right
<seb128> the issue was not the end of the cycle though
<seb128> it was having the patch kept for the next cycle
<seb128> which as slangasek is more a TB issue than a release team one
<ScottK> It started though around a late add of a feature to the package.
<seb128> the feature part of the discussion was reasonable, you pushed back
<seb128> they got stuff tested properly, including all rdepends
<seb128> the rational was "avoid a regression" which was a fair one
<seb128> I'm not sure "what happens next cycle" should be used by the release team as an hammer for ffe discussions
<seb128> the ffe are about "is that ok to land now", not about "is it ok to have those changes in Ubuntu in principle"
<ScottK> Right, but would all that testing have gotten done if they didn't have to ask for an FFe?
<ScottK> You know it wouldn't have.
<seb128> no, and I agree it makes sense to discuss a blanking ffe
<seb128> what I'm arguing against is how "next cycle work" was used there
<ScottK> Fair enough.  What I'm arguing is that there's not a demonstrated pattern of following through on agreements.  I don't think there's a lot of point in arguing.  I'm not going to suddenly trust them to DTRT.
<ScottK> Getting stuff upstream properly has been a fight with PS and its antecedents since Karmic and I don't expect it to change.
<seb128> ScottK, right, but it's not right to use your position in the release team to try to force changes of behaviour of people in exchange of having their ffe approved (when the behaviour is upstreaming of changes and not related to the said ffe)
<ScottK> Separate from the patch issue, I think having had an FFe to enforce the additional testing was the right thing for that change.
<rsalveti> hey, if someone around, mind checking ofono? there's a new ofono-scripts package, useful to debug ofono-rild related issues in touch
<rsalveti> and one less package via ppa
<infinity> rsalveti: Poking.
<rsalveti> infinity: thanks
<infinity> rsalveti: Looks sane.  Those all come from the upstream source?
<infinity> rsalveti: Can you get that pushed to Debian too?  Seems like a reasonable addition to the packaging.
<rsalveti> infinity: yup, only big change there is the rild patch, to add support for the rild based modems
<rsalveti> yup, we discussed with cyphermox and he will be doing the package upstreaming for it next week
<rsalveti> debian is a bit behind as well
 * infinity nods.
<rsalveti> infinity: awesome, thanks so much
 * rsalveti vacation \o/
<infinity> rsalveti: Are you stealing Ursula from me too, or vacationing alone?
<rsalveti> infinity: oh yeah :-)
<rsalveti> we'll be in montevideo, uruguay next week
<infinity> rsalveti: Awesome.  Have fun.
<rsalveti> thanks, have a nice weekend!
<infinity> rsalveti: House-hunting a bit?  She was telling me that you're looking to relocate.
<rsalveti> yeah, that's a possibility indeed
<rsalveti> we'll see :-)
<infinity> Very cool.  Enjoy yourselves.
<rsalveti> hate this city
<rsalveti> heheh
<rsalveti> thanks, cya!
#ubuntu-release 2013-08-10
<slangasek> relocating to Uruguay?  who does *that* :)
<infinity> slangasek: People who live in Brasil, apparently.
<slangasek> infinity: people who live in Brazil and have a grudge against Argentina, maybe?
<slangasek> I mean, c'mon, Uruguay only exists because the two of them needed a buffer state ;)
<infinity> All I know about Argentina is that they have a booming beef industry.  I know nothing of their politics. :P
<infinity> "Uruguay won its independence between 1811 and 1828, following a four-way struggle amongst Spain, Portugal, Argentina and Brazil."
<infinity> That's enough to sell me on them.
<slangasek> "won" its independence
<infinity> Takes some serious fortitude to flip the bird to four nations at the same time.
<slangasek> ;)
<slangasek> that's historical revisionism
<slangasek> Uruguay was created by fiat by a treaty between the powers that were struggling over the territory ;)
<infinity> Ahh, yes, the article goes into more depth later. :P
<infinity> Either way, they appear to have some very impressive moustaches in their history.
<infinity> So, that's something.
<slangasek> gaucho + moustache -> gaustache
#ubuntu-release 2014-08-04
<jamespage> please could someone reject my upload of ceph for trusty - just spotted a typo in the changelog (Monday morning and all)
<slangasek> jamespage: done
<jamespage> slangasek, thanks!
 * jamespage goes to try again...
<slangasek> ^^ would appreciate a binary new review on autopilot-qt
<seb128> slangasek, I can do
<slangasek> seb128: cheers :)
<seb128> slangasek, well, I was going to do it but looks like somebody beat me to it ... ;-)
<slangasek> oh, ok then!
<slangasek> thanks anyway :-)
<seb128> yw ;-)
<cjwatson> shadeslayer: Did you notice you got a working build?  http://cdimage.ubuntu.com/kubuntu-plasma5/daily-live/current/
<cjwatson> shadeslayer: Please confirm it's vaguely sensible and I can cron it
<shadeslayer> cjwatson: I'll have a look
<shadeslayer> cjwatson: can we get http://paste.ubuntu.com/7951962/ in casper?
<cjwatson> shadeslayer: sure
<shadeslayer> thanks! :)
<cjwatson> Though I'll fix it up
<cjwatson> Pretty sure you mean /root/usr/bin/sddm there
<cjwatson> And we have this cool thing called indentation ;-)
<shadeslayer> ah yes :)
<cjwatson> Also should use the standard variables there ... anyway, will fix
<cjwatson> shadeslayer: Does http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/utopic/casper/utopic/revision/1137 look OK?
<shadeslayer> cjwatson: yes, thanks!
<cjwatson> shadeslayer: thanks, uploaded.  Does the image otherwise look reasonably sensible?
<shadeslayer> cjwatson: yep
<cjwatson> shadeslayer: ok, let me cron it for you then
<shadeslayer> \o/
<cjwatson> shadeslayer: http://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/revision/1449
<shadeslayer> \o/
<shadeslayer> cjwatson: btw I think I'm going to move to kill kubuntu-active
<shadeslayer> it's pretty useless
<cjwatson> up to you guys
<shadeslayer> cjwatson: ping
<shadeslayer> cjwatson: do you reckon https://launchpad.net/ubuntu/+source/parted/3.2-1 could have caused http://i.imgur.com/nBDZWgo.png
<shadeslayer> cjwatson: most certainly seems like the culprint as the string comes from parted
<clarkb> Hello, I was pointed this direction to see if I could get https://cloud-images.ubuntu.com/releases/streams/v1/com.ubuntu.cloud:released:hpcloud.json updated. Not sure who to ping for that
<clarkb> there are new images on the hpcloud side, but the signed json file has not been updated with them
<pleia2> I pointed him here, hoping someone knows who inside canonical to nudge about this
<clarkb> I am specifically interested in 'Ubuntu Server 14.04.1 LTS (amd64 20140724) - Partner Image'
<elmo> clarkb: I think you want utlemming, but I could be wrong
<sil2100> infinity: hi! Are you around by any chance? I would need someone with access to snakefruit
<rcj> clarkb, the streams for hpcloud are up to date now, sorry for the issue
<clarkb> rcj: great thank you
<pleia2> thanks \o/
<ScottK> what's the forecast for getting more arm/ppc builders back?
<elmo> ScottK: it's being worked on again now, sorry for the delay
<ScottK> Thanks for the update.
<ScottK> Buildds looking much happier now.
<rbasak> Wow, the Trusty SRU queue looks like fun right now.
<ScottK> It's mostly KDE, so I'll clear that shortly.
<cjwatson> shadeslayer: yes, will see if I can track that down tomorrow
#ubuntu-release 2014-08-05
<seb128> could somebody review unity-gtk-module in the trusty SRU queue? it was uploaded with gtk, which got approved, but they would need to go together for the fix to be fully functionnal
<seb128> until then nothing is buggy, but the bugfix can't be verified
<seb128> (need to go to the office, bbiab)
<Riddell> anyone care enough about ppc64el to investigate okteta build failure? https://launchpad.net/ubuntu/+source/okteta upstream disclaims liability https://bugs.kde.org/show_bug.cgi?id=338032
<ubot93> KDE bug 338032 in general "compile failure on ppc64el" [Normal,Unconfirmed]
<xnox> Riddell: a bit cryptic =) why would ld exit 1, if it only issued a warning and not an error. I think infinity and/or doko might find ^ interesting
<doko> Riddell, where is the error? apparently it did build
<Riddell> doko: launchpad says it didn't https://launchpad.net/ubuntu/+source/okteta/4:4.13.97-0ubuntu1/+build/6233320
<doko> ahh, latest upload was trusty
<doko> Riddell, please can you address upstream, that explicit linking with -lc on linux is not necessary?
<popey> infinity: when should 12.04 users expect to get a prompt to go to 14.04? (.1)
<mlankhorst> I thought the EOL notification was already there
<mlankhorst> or do you mean 12.04.1 or below?
<elfy> mlankhorst: I think popey refers to the upgrade to 14.04.1 notification from 12.04
<popey> i am talking about people running 12.04 on their machines, update manager not offering an upgrade to 14.04*
<popey> i have seen multiple reports over the last few days people saying they're not getting offered the upgrade
<Riddell> doko: is that the cause of the problem?
<doko> Riddell, I don't think so, but explicit libc linking is almost always wrong on linux
<infinity> popey: Soon.
<doko> Riddell, workaround uploaded
<Riddell> oh?
<Riddell> I see it, thanks doko
<bluesabre> Since 14.04.1 is now out and we're not doing any more respins, can we release this one to trusty now?  https://bugs.launchpad.net/ubuntu/trusty/+source/lightdm-gtk-greeter/+bug/1331871
<ubot93> Launchpad bug 1331871 in lightdm-gtk-greeter "[SRU] Please backport lightdm-gtk-greeter 1.8.5 to trusty" [High,Fix committed]
<shadeslayer> cjwatson: any luck with parted?
<shadeslayer> cjwatson: live-build needs this patch http://paste.ubuntu.com/7961448/
<shadeslayer> oh, apparently happens in 2 placess
<shadeslayer> http://paste.ubuntu.com/7961528/ seems more appropriate
<Riddell> unless anyone objects I plan to force override the ubuntu-release-upgrader test in pykde4 since I've no idea where it comes from http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#pykde4
<shadeslayer> Riddell: comes from http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/utopic/ubuntu-release-upgrader/utopic/files/head:/debian/tests/
<Riddell> yeah, what the heck is nose-test ?
<shadeslayer> checks if ubuntu-release-upgrade has a nose
<shadeslayer> presumably that's why it fails
<Riddell> but how does it smell?
<cjwatson> shadeslayer: out of meetings now and resuming debugging.  it's proving annoyingly annoying to extract debug info
<shadeslayer> :(
<cjwatson> and I had to start by fixing parted builds from git
 * shadeslayer fixed live build meanwhile
<shadeslayer> silly variables I tell you
<cjwatson> I think I have to fix something else for you to have it use live-build from your PPA
<cjwatson> oh, but you're using your own imager
<cjwatson> meh, whatever
<shadeslayer> yep
<shadeslayer> worked around for now
<Riddell> I've removed kubuntu-active from the crontab file in ubuntu-cdimage, can someone update the crontab accordingly on the cdimage builder?
<cjwatson> Riddell: done
<cjwatson> \o/
<Riddell> thanks cjwatson
<stgraber> any SRU team member around for a very quick review that's critical for 12.04.5?
<stgraber> (the ltsp kernel enablement patch had to be updated again, I really need to add that to whatever procedure we have for HWE kernels...)
<jibel> mlankhorst, could you have a look at bug 1351262 ? it's blocking 12.04.5 alternate
<ubot93> bug 1351262 in xorg-lts-transitional "precise alternate installations fail with unmet deps due to the conflict ' xserver-xorg-lts-trusty : Conflicts: libgl1-mesa-dri (>= 0~)'" [Critical,Confirmed] https://launchpad.net/bugs/1351262
<jibel> stgraber, ^ RC bug
<stgraber> jibel: ah great, another one...
<stgraber> infinity, bdmurray, arges, SpamapS, ScottK: any of you around for a quick review of ltsp in the precise unapproved queue?
<arges> stgraber: i'll take a look
<stgraber> arges: thanks!
<stgraber> arges: the diff should basically be s/saucy/trusty/g
<SpamapS> stgraber: It's probably time for me to lay down my AA/SRU hat. Haven't touched a package in Ubuntu in a year. :-/
<arges> stgraber: no bug associated with this?
<stgraber> arges: nope, just copy/paste from last time and apparently we didn't back then :)
<stgraber> arges: the test case is relatively simple "are the ubuntu alternate images busted? yes/no" :)
<arges> stgraber: ok accepted...
<stgraber> arges: and I'll release the update to -updates as soon as it's published in -proposed so I can kick new images (though as jibel said above, those images are also busted for another reason at the moment...)
<stgraber> arges: thanks!
<arges> np
<stgraber> jibel: I've got a couple other fires to work on first so hopefully mlankhorst will show up soon enough to take care of this, otherwise I'll look into it when I'm done with the rest :(
<stgraber> I suspect what we want to figure out is how is this enablement stack different from what we did in saucy and then change whatever's different so things work again
<infinity> SpamapS: I can drop you from the teams, if you're not using them anymore.
<stgraber> or maybe I can get infinity to look into bug 1351262 for me? :)
<ubot93> bug 1351262 in xorg-lts-transitional "precise alternate installations fail with unmet deps due to the conflict ' xserver-xorg-lts-trusty : Conflicts: libgl1-mesa-dri (>= 0~)'" [Critical,Confirmed] https://launchpad.net/bugs/1351262
<infinity> SpamapS: Dropped from SRU and AA.  If you ever find the time and motivation to come back, let me know.
<infinity> stgraber: I can look, I make no promises about the result of said looking.
<stgraber> infinity: that's already way more than I can do at the moment, so I'll take anything :)
<SpamapS> infinity: thanks.
<infinity> Hrm.  So, that should be reproducible on a chroot, one would think.
<infinity> Shouldn't need a full install run to play with that.
<ScottK> Wow.
<ScottK> A wild SpamapS appears.
 * ScottK waves
<SpamapS> Aye, unfortunately it's just to clear up that I'm not here. ;)
<ScottK> Yes, unfortunately.
<stgraber> ubuntu server is ready for testing
<mlankhorst> stgraber: ??
<mlankhorst> jibel: not again?
<mlankhorst> jibel: last time it was due to glamor-egl pulling in the wrong depends can you see what package it is this time?
<mlankhorst> jibel: https://launchpadlibrarian.net/162352830/glamor-egl-lts-saucy_0.5.1-0ubuntu4.2~precise1_0.5.1-0ubuntu4.2~precise2.diff.gz was the fix for saucy
<infinity> mlankhorst: Oh good, maybe you have some idea what's going wrong. :P
<jibel> mlankhorst, I looked at that bug from 6 months ago but it's different
<mlankhorst> infinity: probably if you can get me a verbose apt-get log
<mlankhorst> jibel: maybe looks like a similar theme
<jibel> infinity, for reference it was bug 1278737
<ubot93> bug 1278737 in xorg-lts-transitional "Upgrade to trusty fails from precise backported enablement stacks" [High,Fix released] https://launchpad.net/bugs/1278737
<jibel> mlankhorst, this time it is not an upgrade to trusty but the installation of precise
<mlankhorst> jibel: yeah but it's not that bug, I've seen it in a saucy seed
 * jibel digs deeper into launchpad
<mlankhorst> unfortunately I don't know if a bug was opened about it, but the fix at the time (really workaround) was for apt-get to see the libgl1-mesa-glx-lts-trusty first, so it would try to use that instead of libgl1-mesa-glx unrenamed
<infinity> mlankhorst: Do you recall how this magic was done?
<infinity> cjwatson: Do you have any recollection of... Any of this?
<mlankhorst> infinity: no we got lucky that glamor-egl-lts-saucy was the first package to request libgl1-mesa-glx, so we could add the workaround to it
<mlankhorst> infinity: but if you can get me a verbose apt-get debug log I should be able to see if we could fix it this time
<infinity> mlankhorst: Without downloading a CD and trying myself, the verbosity in the d-i log there is the same for you as it is for me.
<infinity> mlankhorst: And you might have more luck debugging on the fly than I would, if you grab an ISO and play.
<mlankhorst> infinity: oh last time it happened when preparing one of the iso's
<mlankhorst> infinity: I sit ok if I look at it tomorrow morning?
<mlankhorst> near bed time for me
<mlankhorst> I sit -> is it
<stgraber> respinning ubuntu alternate for ltsp now
<stgraber> everything else is either already built and ready to test or still building and will show up in the next few minutes
<jibel> what does this version means in a conflict: Conflicts: libgl1-mesa-glx (>= 0~) ?
<mlankhorst> jibel: non-virtual package
<jibel> ok
<stgraber> infinity: bug 1353086
<ubot93> bug 1353086 in ubiquity "no kernel modules found" [Undecided,New] https://launchpad.net/bugs/1353086
<stgraber> infinity: looking around, shouldn't that d-i be moved to -updates?
<infinity> stgraber: Oh, was it not yet?
<infinity> stgraber: Yes.  Yes it should.
<infinity> stgraber: I can do that now, if you haven't already,.
<stgraber> infinity: go ahead
<infinity> stgraber: DOne.
<stgraber> I'll then monitor and respin alternates and server once it's published
<infinity> stgraber: So, alternates and server will need a retry after that publishes.
<infinity> stgraber: Jinx.
<infinity> stgraber: Probably also worth double-checking the current state of proposed and making sure you don't care about anything else. :P
<infinity> Err, like livecd-rootfs.
<infinity> So... Everything needs to rebuild.
<jibel> meh it failed on 20140805.2 :(
<infinity> And base-files...
<infinity> And grub...
<infinity> Whee.
 * infinity releases a bunch of stuff.
<stgraber> oh, fun
<stgraber> that's probably why I opened that pending-sru tab for this morning, then got distracted...
<infinity> stgraber: parted might be interesting too, but I'll let you dig into that and decide.
<stgraber> infinity: yeah, parted sounds like a win and it's basically the last useful moment to accept it for precise (well, except people using netboot images)
<infinity> stgraber: No verification, on it, sadly.
<stgraber> yeah, I'll verify it real quick
<infinity> stgraber: Thaty 96-day-old ubiquity might want love as well.
<infinity> Though, it seems the fix wasn't really a fix, so meh.
<stgraber> infinity: yeah, I looked at the bug report and then decided to skip it
<infinity> (not broken either, mind you)
<elfy> infinity: hi - quick question, we're (Xubuntu) down apparently for 12.04.5 but we don't want to be - does removing from the testing tracker stop .5 building or do we need to do something else?
<elfy> or is it too late in fact
<infinity> elfy: Talk to stgraber.
<elfy> stgraber: ^^
<infinity> elfy: If you weren't using HWE stacks (were you?), there's no real reason for you to do the point release.
<infinity> elfy: If you were, though, you don't really want to leave your users with the "current" precise ISO being unsupported.
<elfy> apparently we weren't
<stgraber> elfy: hi
<elfy> infinity: yea understood
<infinity> Yeah, you weren't.  Just double-checked.
<stgraber> elfy: ok, so I'll remove any build you have and that'll be it. Thanks for letting me know.
<infinity> So, no particular reason you would *have* to do the release.  If you don't want to, easier for everyone involved.
<elfy> awesome - thanks chaps :)
<shadeslayer> cjwatson: is the cronjob working for Kubuntu Plasma 5? I don't see ISO's for today
<stgraber> Just marked the world as disabled as we're expecting a mass respin in about 30min
<infinity> Looks like it was just ubuntu, edubuntu, and mythbuntu doing HWE stacks in precise.  We really need to fix that in trusty.
<cjwatson> shadeslayer: I don't think it's time yet
<skellat> stgraber: queuebot just mentioned that it is spinning up a .5 for Xubuntu.  elfy still wanted that nuked.
 * elfy really should take that off ignore now and again :(
<elfy> thanks skellat
<stgraber> skellat: if you look at the tracker you'll noticed they're not there
<elfy> thanks stgraber :)
<skellat> stgraber: That works.
<bdmurray> infinity: is it time to change meta-release-lts yet?
<infinity> bdmurray: If nothing's come up since that update-manager upload went in, we're probably good.
<stgraber> starting the mass respin now (parted just appeared on ftpmaster so we should now have everything)
<bdmurray> infinity: I'll have a look around launchpad and see if I find anything
<infinity> bdmurray: Alright.  I'm not personally aware of anything, so if you don't find any more waving red flags, go ahead and make the switch.
 * infinity is going to have a siesta to make up for the lack of sleep last night.
<tgm4883> infinity: not sure who to tell, but Mythbuntu isn't doing any more 12.04 releases
<stgraber> tgm4883: ok, so no 12.04.5 for you then?
<tgm4883> stgraber: correct
<stgraber> ok, there's already a respin in progress, I'll let it finish and just remove you from the tracker afterwards
<tgm4883> sounds good, thanks
<xnox> stgraber: infinity: cjwatson: do i need to compile new wubi for 12.04.5?
<stgraber> xnox: if you had to do that for 12.04.4, then I guess so, yes
<xnox> stgraber: is it just me, or some kind of ubuntu/precise images ftbfs? I'm getting ftbfs emails.
<xnox> stgraber: we also need to build the precise wubi livefs image, and i don't see it on the iso tracker nor a recent build for it.
<stgraber> xnox: I did trigger a wubi build earlier
<stgraber> and I have another one currently building
<stgraber> http://cdimage.ubuntu.com/precise/wubi/
<xnox> oh, right. i was looking at the wrong wubi ( http://cdimage.ubuntu.com/wubi/ )
<xnox> silly me, that one stopped in raring or whenever. should be cleaned up i think.
#ubuntu-release 2014-08-06
<mlankhorst> morning
<mlankhorst> oh yeah getting the complaint about the no kernel modules with the alternate cd :(
<xnox> Wubi sent for signing in RT #73935
<jibel> mlankhorst, if it's to debug the lts-trusty installation failure, use http://cdimage.ubuntu.com/precise/daily/20140805.1/
<jibel> it should work
<mlankhorst> ok thanks
<jibel> mlankhorst, you can also probably reproduce in the chroot or minimal vm by installing the task ubuntu-desktop^
<mlankhorst> jibel: yeah that's going to be problematic
<mlankhorst> jibel: it mentions 12.04.4 though, or was that description not updated?
<jibel> mlankhorst, no idea if it failed with lts-saucy in 12.04.4.
<jibel> mlankhorst, with http://cdimage.ubuntu.com/precise/daily/20140805/precise-alternate-amd64.iso I confirm that you can reproduce the lts-trusty failure
<jibel> mlankhorst, download this image then you start it with something like: qemu-img create /tmp/disk.img 8G && /usr/bin/qemu-system-x86_64 -m 1024 -display sdl -vga std -enable-kvm -drive file=/tmp/disk.img -cdrom ~/iso/ubuntu/precise-alternate-amd64.iso
<jibel> proceed with the installation and it'll fail
<mlankhorst> ok
<mlankhorst> it's installing base system now
<mlankhorst> oh indeed
<mlankhorst> jibel: I'm getting a different failure though, about python-couchdb and some other python packages
<mlankhorst> http://paste.debian.net/113906/
<mlankhorst> oh, that's probably from the preseed I was using
<jibel> mlankhorst, don't use any preseed, just what's on the image. These packages are installed by automated tests
<mlankhorst> ah
<mlankhorst> jibel: libgl1-mesa-dri is part of task ubuntu-desktop
<mlankhorst> jibel: so what's happening simply seems to be that it's trying to install libgl1-mesa-dri and libgl1-mesa-dri-lts-trusty simultaneously, no deeper causes afaict
<jibel> mlankhorst, ah good to know.
<mlankhorst> is there anything else you oneed, or do you think you can fix it from here?
<shadeslayer> can I ask for a Kubuntu Plasma 5 ISO spin in ~30 minutes?
<shadeslayer> infinity: stgraber ^^ ?
<shadeslayer> oh, parted would still be broken though
<cjwatson> it is, though I think I have a handle on it
<shadeslayer> \o/
<doko> infinity, cjwatson: did you promote ruby-hiera without promoting the source? and without a MIR?
<rbasak> doko: it got renamed from "hiera". Or something like that.
<doko> rbasak, is there a bug report for this?
<rbasak> doko: no, but I did post https://lists.ubuntu.com/archives/ubuntu-release/2014-July/002966.html
<rbasak> doko: what else is needed? I thought it'd be a no-brainer.
<doko> rbasak, I'm not subscribed to -release
<doko> ok, promoted
<rbasak> Thanks!
<rbasak> doko: while you're looking, there was also https://lists.ubuntu.com/archives/ubuntu-release/2014-July/002967.html
<rbasak> New dependencies on haproxy-doc, pulling in nodejs of all things.
<rbasak> I suggest demoting just the haproxy-doc binary to universe, if that's acceptable?
<doko> rbasak, sure, https://bugs.launchpad.net/ubuntu/+source/haproxy/+bug/1353421 is your's then =)
<ubot93> Launchpad bug 1353421 in haproxy "haproxy: component mismatch (depends on twitter-bootstrap and friends)" [Critical,Confirmed]
<rbasak> doko: commented
<doko> rbasak, no, fix it!
<rbasak> doko: please can you elaborate?
<doko> ahh, let me try an exclude in the seeds
<jibel> mlankhorst, actually I've no idea where this must be fixed. if it's a seed issue I don't know how it works.
<mlankhorst> jibel: neither do I to be honest, I think the default cd's explicitly had a step to remove libgl1-mesa-dri etc from the seeds
 * mlankhorst checks again
<doko> rbasak, here are more server related component mismatches: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg =)
<mlankhorst> cjwatson: hey do you know how we fixed the libgl1-mesa-dri/libgl1-mesa-dri-lts conflicts in the normal cd?
<cjwatson> mlankhorst: all I know was the thing you remembered about glamor
<cjwatson> have no other brain cycles just now due to parted
<mlankhorst> jibel: why does the alternate cd contain libgl1-mesa-dri/glx and libglapi-mesa ?
<jibel> mlankhorst, I really don't know how this part works
<mlankhorst> presumably the same reason why it's trying to install
<mlankhorst> can I see the build logs for the cd somewhere?
<cjwatson> mlankhorst: http://people.canonical.com/~ubuntu-archive/cd-build-logs/
<cjwatson> link at the top of each log to the livefs build log on Launchpad
<cjwatson> (in cases where the image contains a livefs)
<mlankhorst> ok
<mlankhorst> * Chose libgl1-mesa-glx to satisfy xserver-xorg-core-lts-trusty
<mlankhorst> hm..
<cjwatson> might just need a preferred alternative there then
<mlankhorst> yeah but first one that shows up from the log seems to be mesa-common-dev
<Riddell> anyone able to debug why kde4libs and all its friends in kde sc 4.13.97 doesn't want to transition to -release ?
<Riddell> the nepomuk packages have gone away
<Riddell> I wonder if I've still got some to delete
<mlankhorst> cjwatson: looks like you ma be right
<mlankhorst> cjwatson: where is  /srv/cdimage.ubuntu.com/scratch/ubuntu/precise/daily/tmp/precise-amd64/list ?
<cjwatson> on nusakan
<cjwatson> but it's autogenerated every build
<rbasak> doko: probably best leave jamespage to sort out the tomcat8 mismatches. I think zul is looking after the Openstack-related ones.
<zul> rbasak:  i am
<rbasak> doko: FYI, I've also got an upcoming mysql-5.5 to mysql-5.6 switch
<mlankhorst> cjwatson: ah, is there any documentation on how to build the official image myself?
<cjwatson> not really
<cjwatson> sorry I can't help right now
<cjwatson> maybe this evening ...
<mlankhorst> ok
<doko> rbasak, please don't build using gcc-4.4 ;-P
<rbasak> doko: :)
<shadeslayer> cjwatson: any ETA on parted?
<cjwatson> shadeslayer: found the problem, but the obvious revert breaks a test, so trying to figure out a way to deal with it without breaking ABI
<shadeslayer> okay :)
<doko> xnox, pitti: is it safe to accept systemd & upstart?
<jibel> stgraber, for info, ubiquity crashes on ubuntu desktop 12.04.5 and oem mode
<jibel> stgraber, I'll file a bug
<pitti> doko: yes, from my POV
<pitti> doko: it's just a new python3-systemd package, and I dropped the Python 2 one
<pitti> (no rdepends)
<xnox> jibel: =((((( please shoot me a number, i'll look into it asap.
<doko> pitti, and systemd-sysv?
<pitti> doko: ah right; requested by slangasek and jhunt; that shoudl go to universe for now
<pitti> doko: it's not installable yet, but will soon be with my pending sysvinit merge
<xnox> pitti: doko: does systemd-sysv correctly replace only pot-split upstart?
<xnox> s/pot/post/
<xnox> or does it even matter?
<pitti> xnox: it doesn't replace it at all?
<pitti> xnox: it conflicts: to upstart (but not to -bin)
<xnox> pitti: ack, yeah conflicts should be enough.
<jibel> xnox, syslog http://paste.ubuntu.com/7970723/ to reproduce press F4/OEM in syslinux, then 'Install Ubuntu'. wait until it crashes
<mlankhorst> can I get xserver-xorg-video-s3 and xserver-xorg-video-sis removed? they're no longer in debian sid
<mlankhorst> https://launchpad.net/debian/+source/xserver-xorg-video-s3 https://launchpad.net/debian/+source/xserver-xorg-video-sis
<jibel> xnox, stgraber bug 1353531
<ubot93> bug 1353531 in ubiquity "[12.04.5] ubiquity crashes in OEM mode in info_loop in in ubi-usersetup.py, line 394 with : TypeError: sequence item 0: expected string, NoneType found" [Undecided,New] https://launchpad.net/bugs/1353531
<cjwatson> shadeslayer: building a Debian upload now - can I just let it autosync in some hours, or do you need it faster?
<shadeslayer> autosync is fine
<cjwatson> great, sorry about the delay
<cjwatson> http://anonscm.debian.org/cgit/parted/debian/parted.git/commit/?id=11ccc7136ada703a3dcf932609023392c5bbf95f was the fix FWIW
<cjwatson> it's a bit hacky, so I'll need to sort it out better with upstream, but it seems to do the job for now
<Riddell> stgraber: you're on 12.04.5 duty?
<Riddell> it says no kernal modules were found
<Riddell> I don't miss the alternate installer
<stgraber> Riddell: yep
<Riddell> stgraber: do I need to update a seed somewhere?
<stgraber> hmm, I see a whole lot of lts-saucy stuff on that media, so yeah, something looks a bit off
<Riddell> oh it needs "Move precise from lts-saucy to lts-trusty"
<stgraber> what does?
<Riddell> dunno I just read that in the ubuntu.precise seed bzr changelog
<stgraber> ok, so first question is does kubuntu actually do the enablement kernel and X stuff?
<Riddell> gosh I don't remember, maybe we don't for precise
 * stgraber goes to look at kubuntu 12.04.4 alternate
<stgraber> so that's confusing, the only kernel you've got on the 12.04.4 image is the original 3.2 but then you also had a bunch of 3.11 kernel modules for whatever reason. So it looks like the installer was using 3.11 but the installed system was on 3.2
<Riddell> I think we may have tried to use lts enablement but didn't quite manage it properly
<xnox> jibel: looks very corrupt, from code "errors" list may only ever have strings.... And I cannot reproduce in my VM instance. Is there something fishy going on with network  / vm hostname? is there internet connectivity to the VM?
<jibel> xnox, this is how I start the iso. qemu-img create /tmp/disk.img 10G && /usr/bin/qemu-system-x86_64 -m 1024 -display sdl -vga std -enable-kvm -drive file=/tmp/disk.img -cdrom ~/iso/ubuntu/precise-desktop-amd64.iso
<jibel> xnox, I'll check network connectivity
<jibel> xnox, but I guess it's okay, the release notes link is displayed on other tests
<jibel> xnox, I'm on utopic if that matters
<stgraber> Riddell: ok, I think I know what needs to happen, doing that now
 * Riddell looks appreciative
<xnox> jibel: host utopic here as well. Your image checksum please?
<jibel> xnox, 968441ac29b8cb088f24aa5851451881e0efbe5afff31e3c137850b7e9804209  /home/j-lallement/iso/ubuntu/precise-desktop-amd64.iso
<jibel> same as http://cdimage.ubuntu.com/precise/daily-live/20140805.3/SHA256SUMS
<stgraber> Riddell: updated your seeds, rebuilding alternate now
<Riddell> great thanks stgraber
<jibel> xnox, there is network connectivity. the hostname is ubuntu, does ubiquity build another hostname from a serial/model/brand anything specific to the machine?
<xnox> jibel: it tries to, yes. e.g. for me i end up with "dima-virtual-machine" name based on dhcp and the fact that it's a virtual machine.
<jibel> xnox, ah it might be it. For me in the last step it pre-fills computer name with: ubuntu-SMBIOS-implementations-newer-than-version-2-7-are-not-fully-supported-by-this-version-of-dmidecode-Standard-PC-i440FX-PIIX-1996
<xnox> lolz =)
<xnox> jibel: clearly dmidecode is failing =)))))))))))
<xnox> jibel: do you have some custom qemu / kvm  / smbios installed?
 * xnox upgrades my machine
<xnox> jibel: submitted succes OEM test, for ubuntu amd64 precise
<xnox> on the iso tracker
<jibel> xnox, okay, I've only standard components
<xnox> (that string looks like a complete error message from dmidecode)
<shadeslayer> cjwatson: thx for the patch btw :)
<cjwatson> phew
<shadeslayer> why the phew? :D
<xnox> jibel: i'm running older qemu, upgrading now, hopefully that's the bug.
<doko> xnox, the uninstallability is because libscalapack-openmpi1 depends on libblacs-mpi1, and not libblacs-openmpi1 as it should. no trying to figure out why
<cjwatson> shadeslayer: because it took a day and a half :)
<xnox> doko: i did switch from one implementation to another on various arches in the past. they should all match within a given stack, and ideally match the default mpi for the arch.
<jibel> xnox, likely. It works on vbox where the name is ubuntu-Virtualbox. I'll mark the test as passed and update the report. ubiquity shouldn't crash if dmidecode returns unexpected strings. But not critical for the release
<xnox> true.
<xnox> jibel: well, if we respin, i'll prepare a fix for it....
<Riddell> what's the status of meta-release-lts being updated for trusty?
<stgraber> Riddell: let me know if that still doesn't boot for you ^
<stgraber> Riddell: I still see a bunch of packages that really shouldn't be on your media but those that should be are there, so it doesn't look any worse than 12.04.4 so far :)
<shadeslayer> cjwatson: hah :D
<shadeslayer> cjwatson: {{hugs}}
<stgraber> Riddell: just gave that new image a quick try and I get all the way to partitioning so hopefully that means it now works
<Riddell> stgraber: lovely, thanks
<stgraber> xnox, jibel: so did you make any progress on that OEM bug? is that an actual regression from 14.04 or just something which changed in the test setup and made it show up?
<xnox> stgraber: oem mode fails on qemu 2.1 (utopic) as reported by jibel.
<xnox> stgraber: no idea if trusty/utopic also fails.
<jibel> stgraber, it's dmidecode that returns loooong strings with qemu 2.1
 * jibel tries with utopic
<stgraber> do you have a plan on how to fix that?
<jibel> xnox, there is no OEM mode in utopic desktop ?
<stgraber> (a last minute ubiquity change means respinning a whole bunch of things, all desktops and alternates...)
 * jibel tries with trusty :)
<xnox> jibel: there is... but one must manually type out kernel cmd arg.
<xnox> stgraber: well, we can release note that 12.04.5 does not work on qemu 2.1 (or newer smb-bios) or let me come up with a minimal fix to work-around it.
<cjwatson> stgraber: but respins are really fast now ;-)
<cjwatson> (yes, I know, QA not so much so, but ...)
<xnox> and we don't have new signed wubi yet.
<stgraber> yeah, at least we don't have to sit and wait for 5 hours anymore :)
<stgraber> hmm, looks like we need more seed changes, there are reports of kernel mismatch on server too... let's look into that
<jibel> xnox, stgraber works with trusty, trying with 12.04.4
<stgraber> jibel: is that because dmidecode returns something more reasonable on trusty or because ubiquity deals with it somehow?
<xnox> stgraber: it returns two line comment "SMBIOS implementations newer than version ...." and then what ubiquity expects/wants "QEMU"
<xnox> =(
<jibel> stgraber, because dmidecode doesn't return a warning on trusty while on Precise ubiquity tries to convert this warning to an hostname
<jibel> BTW 12.04.4 is also affected, so not a regression
<xnox> imho dmidecode is broken and should be spewing the comment into stderr, and not into stdout....
<xnox> but that's dmidecode sru into precise + respin. =/
<stgraber> well, in any case, if we want this fixed, it's sru + respin
<stgraber> so there's a patch against our current dmidecode which bumps SUPPORTED_SMBIOS_VER to 0x0208
<stgraber> I wonder if just cherry-picking that into precise's will do the trick
<stgraber> jibel: do you still have an affected VM around you could run a test dmidecode for me on?
<xnox> yes, that would help.
<jibel> stgraber, sure
<stgraber> jibel: what's the bug number again?
<xnox> hm, actually ubiquity cod emakes no sense..... errors has "hostname_error_length" and it fails to handle that error condition. Thus we have been so far lucky, and it's just the first time hitting any error =/
<stgraber> jibel: nevermind, found it in backlog
<xnox> jibel: stgraber: http://paste.ubuntu.com/7971511/
<xnox> hostname returns a list of errors for which it is suppose to fetch strings, but for some reason hostname_error_length string is not returned and instead None is returns, which bombs out ubiquity.
<stgraber> jibel: packaged are available at: https://launchpad.net/~stgraber/+archive/ubuntu/experimental/+packages
<xnox> what should be happnening, is correct warning string fetched / added....
<stgraber> jibel: *packages
<stgraber> xnox: ok, please push that to ubiquity trunk. I think I'd rather not touch ubiquity for precise if we can avoid it. It's the last point release so if fixing dmidecode works, let's just do that.
<xnox> ack.
 * stgraber gets back to being confused as to where the kernel mismatch is for server
<stgraber> mlankhorst: oh, and any progress on the alternate X HWE stack mess?
 * xnox reviews your dmidecode fix.
<stgraber> xnox: it's a simple copy of the patch we carry in current dmidecode so hopefully that does the trick
<Saviq> guys, any idea about http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#systemd
<Saviq> is sysvinit being synced from debian or something?
<cjwatson> Of course it isn't :)
<stgraber> hmm, how old is that d-i on the server image... running kernel is -30 instead of -32, I wonder how that happened
<cjwatson> This is easy to check: https://launchpad.net/ubuntu/+source/sysvinit
<Saviq> cjwatson, yeah, that I know
<Saviq> cjwatson, but will it be?
<Saviq> cjwatson, systemd in proposed requires it to be...
<xnox> Saviq: just pitti needs pocking. There is a pending sysv merge to get it up to high enough version.
<cjwatson> pitti: ^- do you have a plan to resolve that?
<cjwatson> Saviq: sync != merge
<cjwatson> Saviq: when we say sync around here we mean a verbatim copy
<Saviq> cjwatson, yeah sure, that I know, didn't know this was a merge
<xnox> stgraber: dmidecode from your ppa fixes everything as well.
<stgraber> yay
<xnox> stgraber: +1 from me....
<infinity> stgraber: Did you not rebuild after we promoted d-i?
 * xnox the non-release team person.
 * xnox should fix that.
<stgraber> infinity: 21:38 UTC, that's almost certainly after we promoted d-i
<stgraber> infinity: but yeah, the build log shows it picked up the old d-i, so I'll rebuild now
<stgraber> xnox: ok, thanks for confirming, I'll upload to the queue now
<xnox> stgraber: and it would all work, if errors were printed to stderr.... ubiquity would get proper QEMU string and live would be wonderful and we wouldn't need to upload dmidecode.
 * xnox files a bug against dmidecode.
<stgraber> xnox: yeah, agreed, errors on stdout is stupid...
<stgraber> infinity: can I get you to review that one? ^
<xnox> and ubiquity specifically diverts stderr when calling dmidecode.
<ara> stgraber, quick question if I may
<stgraber> ara: sure
<ara> stgraber, when are point releases moved to old-releases? as soon as the new point release is released?
<ara> stgraber, i.e. when 12.04.5 gets released, 12.04.4 will move to old-releases?
<ara> stgraber, or is it other criteria?
<stgraber> ara: yes, unless we forget to do it (it's a manual action)
<stgraber> ara: but usually we only keep the original release (12.04) and the last point release (12.04.5) on releases.u.c
<stgraber> infinity: LP seems to be unhappy with dmidecode, not producing a diff... here's my local one: http://paste.ubuntu.com/7971624/
 * stgraber -> out for a few minutes
<jibel> stgraber, dmidecode 2.11-4ubuntu0.1 doesn't make ubiquity crash
<infinity> jibel: That was quick testing for a package still in the queue...
<jibel> and it identify an SMBIOS 2.8 instead of returning a warning
<stgraber> infinity: I uploaded it to a PPA first :)
<infinity> Ahh.
<ara> stgraber, thanks for the quick reply!
<jibel> infinity, I got the build from https://launchpad.net/~stgraber/+archive/ubuntu/experimental/+build/6246998
<stgraber> ok, so once that one is accepted, built and copied to -updates we can rebuild all images with ubiquity on them. The new server images will hopefully work too. So we'll then be left with that alternate X HWE stack weirdness to figure out, then hopefully we'll be good for the point release...
<jibel> infinity, it is just to make cjwatson lie when he said QA was no fast :)
 * stgraber disappears again for a bit longer this time.
<infinity> stgraber: server has dmidecode on it too.
<infinity> stgraber: I think dmidecode is a rebuild world event.
<ara> stgraber, what about 14.04 and 14.04.1 images? both are in releases.ubuntu.com
<ara> stgraber, (we are trying to fix the links in the certification site)
<cjwatson> jibel: my bad :)
<xnox> infinity: point release images become out of date with respect to updates pocket. so one doesn't have to rebuild server image with updated dmidecode. And that ubiquity/oem codepath is not used on server.
<infinity> xnox: But the source ISOs won't match.
<stgraber> arges: the rule is "original release + last point release" so it makes sense to have 14.04 and 14.04.1
<stgraber> arges: sorry, was meant for ara but she left :)
<xnox> infinity: =/ doh.
<arges> stgraber: i was wondering what i did : )
<stgraber> infinity: rebuild the world it is then
<stgraber> xnox: any idea what bug 1353568 is about?
<ubot93> bug 1353568 in ubiquity "ubiquity never gets to partitioning page in 12.04.5 live or ubiquity sessions" [Undecided,New] https://launchpad.net/bugs/1353568
<infinity> stgraber: Actually, releases.u.c should only carry the latest point release.  14.04 still being there is because I didn't archive it while the website links were still broken.
<infinity> stgraber: If you check 12.04, it only has .4
<stgraber> infinity: hmm, ok.
<xnox> stgraber: no idea, and incomplete information. commented.
<stgraber> davmor2: ^
<davmor2> stgraber: yeap when I have five minutes I will improve the bug it was just something quick to act as a marker
<davmor2> xnox: It might actually be the 3rd party drivers for the wifi, but I really need to pull out the logs to know for sure I'll be doing that after tea when I have a few minute free though
<ScottK> infinity: Given the non-LTS nature of some of the HWE components shipped on the point release media, might not leaving the original make sense?
<infinity> ScottK: The website links to old-releases for people who want .1 without HWE.  I'm not sure if it'd be more or less confusing to have double the images on releases.u.c
<xnox> davmor2: oh, was the crash after clicking next on the page "you have internets, you have disk space, etc." ?
<infinity> ScottK: (I've asked the same question myself, just not sure the best way to represent the whole mess)
<xnox> davmor2: could be well about the drivers.
<davmor2> xnox: yeap sorry I forgot you have the select timezone next
<davmor2> not partitioning
<davmor2> d'oh
<davmor2> long day
<pitti> cjwatson, xnox: argh, sorry about that; I locally have my sysvinit merge installed, so I didn't notice
<pitti> slangasek: would it be ok to upload my sysvinit merge to -proposed as well and set a block-proposed bug until you review? or revert the systemd upload?
<ScottK> infinity: I'm not either.  I think ideally you'd have the choice of HWE or non-HWE on the point release install media, but that's suboptimal for other reasons.
<stgraber> jibel, xnox: when one of you has a minute, can you try https://launchpad.net/ubuntu/+source/dmidecode/2.11-4ubuntu0.1 and make sure that works too?
<infinity> ScottK: Aye.  It's an easy option to offer for d-i/netboot types (and we do), which I expect covers most of the people who deeply care, but it's harder for ISOs.
<davmor2> xnox: added syslog and installer debug.  I don't see a partman log
<davmor2> xnox: anything useful there?
<davmor2> xnox: apport-collected on the bug too
<davmor2> stgraber: ^
<doko> xnox, same for mumps ... uploaded
<stgraber> dmidecode copied to precise-updates, will begin the mass rebuild once that's published
<jibel> stgraber, verification done!
<jibel> :)
<pitti> cjwatson, xnox, Saviq: I lowered the initscripts dep of systemd; will push back up (it's technically correct) when we finally land the sysvinit merge
<jibel> davmor2, bah, looks like a kernel oops
<davmor2> jibel: sadtrombone.com
<Saviq> pitti, thanks
<stgraber> took a while for dmidecode to get to precise-updates, finally starting the mass respin now
<cjwatson> ScottK: I recently heard that the kernel team would like to go back to having both ("back" because it's what we did in lucid, well actually we just had all the available stacks as options there)
<cjwatson> So would consider doing that in trusty
<cjwatson> Both on the .N install media, I mean
<stgraber> zequence: are you guys participating in 12.04.5?
<slangasek> pitti: why does the systemd upload need reverting wrt sysvinit?
<slangasek> pitti: again, I really do not think anything should be uploaded to -proposed that is not expected to go into the release pocket almost immediately; for sysvinit, I am planning to review but can't commit to getting it done before next week
<ScottK> cjwatson: That would definitely help.
#ubuntu-release 2014-08-07
<xnox> pitti: slangasek: don't we in fact have enough of things ported to satisfy the requirements implied by the versioned dependency? e.g. such that all that's needed is lowering the versioned dependency to the appropriate ubuntuX?!
<stgraber> infinity, cjwatson, slangasek: so if either one of you has a few minutes, I've got a very simple reproducer for the 12.04.5 alternate issue. "apt-get install xserver-xorg-lts-trusty ubuntu-desktop^"
<stgraber> hmm, actually, failing too but not entirely identical, I suspect doing those two in two steps will give us the same output (trying that now in a container).
<rcj> stgraber, just an fyi, I'll be doing the release for cloud images since utlemming is at a sprint.
<stgraber> rcj: ok, I'll ping you when I start working on the announcement. I'm not expecting a release before at least mid-afternoon US/Canada eastern time tomorrow.
<rcj> stgraber, sounds good.  and if you forget and ping ben instead don't worry, his nick triggers on my client
<stgraber> haha, nice :)
<pitti> slangase`: the reverted dependency bump was harmless in the end; Debian bumped it to ensure to get an NFS fix with systemd, but that's not a big concern right now in utopic
<pitti> xnox: I don't remember us backporting the NFS fix in sysvinit; but it's not urgent, we'll just land the merge
<pitti> xnox: NFS under systemd under utopic isn't an urgent matter right now
<cjwatson> pitti,slangase`: What wasn't harmless, as it turned out, was introducing the systemd-sysv binary package :)
<pitti> cjwatson: indeed, thanks for the upload
<cjwatson> That meant that libpam-systemd's systemd-sysv | systemd-shim dep tried to resolve systemd-sysv first, failed, and gave up in a confused heap
<pitti> right; that worked before because we didn't build systemd-sysv
<cjwatson> I'm pretty sure my upload wasn't the right answer, but it seems to have unblocked build-deps at least for now
<cjwatson> As Adam said, having systemd-shim preferred somewhere else might be a better plan
<pitti> cjwatson: I think the only "better" answer is to make systemd-sysv installable, but I don't think we want this to be the preferred dep until we actually want to switch over
<pitti> and that might still be a year or so out
<pitti> so keeping this dep swap seems correct to me
<cjwatson> hm, ok
<pitti> cjwatson: Steve/James want systemd-sysv for some images of their's, so they asked for building it now
<pitti> (tracked at bug 1351306)
<ubot93> bug 1351306 in sysvinit "Cannot uninstall upstart and install systemd-sysv" [Undecided,In progress] https://launchpad.net/bugs/1351306
<cjwatson> Yeah, familiar with that image
<cjwatson> Today is Debian import freeze; I'll shut down auto-sync later today
<Mirv> could someone remove qtconnectivity-opensource-src 5.3.1-1 from utopic-proposed so that I could upload a 5.3.0 update instead?
<Mirv> doko asked me about the various Qt 5.3.1 packages in utopic-proposed and I responded they could be all removed so to make the eventual 5.3.x upgrade via landing PPA instead
<Mirv> qtscript actually slipped its 5.3.1 to release pocket too, but that didn't hurt. there is a newer Debian version though in -proposed.
<infinity> Mirv: And why don't we want the newer versions?
<infinity> Mirv: It's in sync with Debian, that's generally considered a good thing.
<Mirv> infinity: the Debian's 5.3.1 build-deps on qtbase 5.3.1, and at this point of RTM it seemed risky to update even to newer minor version. some of the modules also can't be upgraded if qtbase stays at 5.3.0, since there are run-time version checks in Qt.
<infinity> Mirv: Weren't we planning to fork the archive for these very sorts of reasons?
<infinity> Mirv: That said, new minor versions are probably not a terrible idea at all, just need some testing.
<Mirv> infinity: yes, it should happen still this week, but I'm not sure about how quickly whan can start to put stuff normally to ubuntu after that.
<Mirv> infinity: minor versions of Qt have broken some things subtly before, so for RTM that's a no-go
<infinity> Mirv: changes in any package break things subtly, we can't stop development on everything that's in the image/sdk.
<Mirv> but regarding -proposed, the testing will need testing via landing PPA anyhow, so it wouldn't hurt not to have those 5.3.1 packages removed from -proposed and land everything (synced or not) from the landing PPA
<infinity> Mirv: So, yes, I agree that it might want evaluation, and that the forking probably needs to happen soon, but if you're going to single out Qt, I can give you dozens of other packages changed in the last week in Ubuntu to worry about.
<Mirv> with 5.3.0 I however removed the certain packages from landing PPA before publishing, so that the packages in -proposed would be reused, so that's also possible
<infinity> Mirv: (Not to freak you out, just saying, this is the process and the model)
<Mirv> infinity: Qt is slightly problematic because everything is based on it, and if I would be to start upgrading to 5.3.1, it could critically slow developing other things down, since everything depending on eg. qtbase-abi-5-3-1 needs to be locked for the Qt transition. and that's not including the subtle but possibly serious bugs that could be introduced.
<Mirv> so timeline wise, it doesn't fit, but it should be ok as soon as we have the archive forked
<infinity> Mirv: So, when the archive is forked, do your 5.3.0 uploads in the forked archive? :)
<infinity> Mirv: Given that it's all FTBFS in proposed, it's not hurting anyone.
<infinity> But given that it's all FTBFS, I guess I can remove it too.  *shrug*
<Mirv> infinity: actually this upload is not for Ubuntu, but more like for Kubuntu. Ubuntu doesn't even use it, but the package if basically Bluetooth package without working Bluetooth support at the moment.
<infinity> It'll autosync the next time it's updated in Debian, though.
<infinity> Because we're in sync.
<cjwatson> RTM's only supposed to get stuff that's been already tested in Ubuntu, generally
<infinity> Which is good.
<infinity> Not bad.
<Mirv> infinity: oh, there's autosync after sync period for packages that are already in sync?
 * cjwatson fails to parse that question
<Mirv> anyway, I just figured out KDE people might want a working Qt Bluetooth module, even though we don't use it
<infinity> DebianImportFreeze is, actually, today. :P
<cjwatson> Right
<infinity> So, I suppose if we remove this and Colin turns off the cron job, only a manual sync will bring it back.
<cjwatson> I'll flip cron this evening
<infinity> But you can argue with the Kubuntu folks, since I bet they want it.
<Mirv> wow, when it has been moved to be so late :) I thought it was in June. ok, that explains it.
<infinity> And rightly so.
<cjwatson> We've been pushing it later as the economics work out much better this way.
<Mirv> yes, I agree it's much nicer this way, thanks for that
<mlankhorst> cjwatson: did you find out more about bug 1351262 ?
<ubot93> bug 1351262 in xorg-lts-transitional "precise alternate installations fail with unmet deps due to the conflict ' xserver-xorg-lts-trusty : Conflicts: libgl1-mesa-dri (>= 0~)'" [Critical,Confirmed] https://launchpad.net/bugs/1351262
<cjwatson> mlankhorst: No, sorry, have had no time
<mlankhorst> ok np
<cjwatson> I wasn't expecting to be involved in 12.04.5 ...
<mlankhorst> well I don't know how to create iso's
<cjwatson> You don't need to
<cjwatson> 01:50 <stgraber> infinity, cjwatson, slangasek: so if either one of you has a few minutes, I've got a very simple reproducer for the 12.04.5 alternate issue. "apt-get install xserver-xorg-lts-trusty ubuntu-desktop^"
<cjwatson> 01:53 <stgraber> hmm, actually, failing too but not entirely identical, I suspect doing those two in two steps will give us the same output (trying that now in a container).
<zequence> stgraber: Yes, we will participate in 12.04.05
<mlankhorst> cjwatson: ah ok :-)
<cjwatson> I'm pretty certain trying to create ISO images would be a dddistraction for this
<mlankhorst> yeah
<mlankhorst> but how do I get libgl1-mesa-dri/glx removed from the ubuntu-desktop task?
<cjwatson> You can't
<cjwatson> We can't change tasks after release
<cjwatson> This is why we use metapackages for point releases
<cjwatson> (So yeah, actually stgraber's test isn't hugely meaningful, then)
<cjwatson> mlankhorst: ok, what image is this affecting, and how can I reproduce the problem?
<mlankhorst> but isn't that what the alternate cd does? select the ubuntu-desktop task and add the lts-trusty stuff
<mlankhorst> cjwatson: it affects the alternate cd, I've tested with 20140805.1 because later had the no modules found bug
<cjwatson> oh, well, we do an independent germinate run for the alternate CD, we're not reliant on archive tasks
<cjwatson> mlankhorst: How can I reproduce this problem?
<mlankhorst> cjwatson: simply install the image in a vm, it will fail with that error
<cjwatson> if the kernel modules are out of sync then I think I need to fix that first
<mlankhorst> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1353086
<ubot93> Launchpad bug 1353086 in ubiquity "no kernel modules found" [Undecided,Confirmed]
<cjwatson> gar why is that on ubiquity
 * cjwatson moves
<jibel> mlankhorst, really, I think kernel module is fixed in 20140806
<mlankhorst>  ok
<mlankhorst> I' ll try
<jibel> cjwatson, before you start anything on "no kernel module found" let me confirm if it is fixed or not
<cjwatson> Certainly looks like it should be fine
<cjwatson> uname -a matches udebs
<mlankhorst> ok
<jibel> cjwatson, mlankhorst I confirm that on alternate 20140806 kernel and modules match, and the remaining issue is the installation of the task ubuntu-desktop
<mlankhorst> jibel: yeah I can reproduce the error message by simply doing apt-get install --install-recommends xserver-xorg-lts-trusty libgl1-mesa-{dri,glx}{,-lts-trusty} libglapi-mesa{,-lts-trusty}
<mlankhorst> in a pbuilder chroot
<mlankhorst> so the real problem is having libgl1-mesa-dri, libgl1-mesa-glx and libglapi-mesa on that iso
<Riddelll> stgraber: what's new in the images today?
<jibel> Riddelll, last respin was a fix to dmidecode to support smbios > 2.7 and not crash ubiquity
<Riddelll> thanks
<jibel> psivaa, precise lamp is still unstable, you didn't push your fix?
<psivaa> jibel: ohh, sorry you must have missed my message about it:
<psivaa> Aug 01 11:06:50 <psivaa>	jibel: https://code.launchpad.net/~ubuntu-server-iso-testing-dev/+junk/server-tests-precise is being a junk branch, i've created another junk with these changes
<psivaa> Aug 01 11:06:51 <psivaa>        http://bazaar.launchpad.net/~psivaa/+junk/precise-lamp-test-fixes/revision/271
<jibel> psivaa, I know you have a fix in your junk but it'd be more useful in production :)
<psivaa> jibel: the production tests are themselves are using a junk branch ( which i agree is questionable) and i can not push to that branch
<psivaa> jibel: i can create another project for this but that'd require all the precise jobs to be regenerated
<jibel> psivaa, now you can
<psivaa> jibel: great. thanks. will push it
<cjwatson> mlankhorst: right, I suspect I'll need to tweak cdimage or possibly the seeds for this, but just trying to carve out enough sprint time to test it
<mlankhorst> ok
<mlankhorst> thanks
<jibel> psivaa, are server tests not using utah?
<psivaa> jibel: precise ones dont use uta
<psivaa> *utah
<jibel> psivaa, ah, I didn't realize it was still using the old ubuntu-server-iso-testing. And who was maintaining it for the last 2 years?
<pitti> cjwatson: ah, systemd-sysv is known to be uninstallable, hence britney doesn't let it propagate; is it possible to override that, or do we need to wait on the sysvinit merge?
<jibel> (I guess the answer is no one :))
<psivaa> plars: i dint think it needed much maintenance for precise tests, except couchdb failing a couple of times or so.. i with the help of retoaded do fix them
<xnox> pitti: it's best to fix it, since increasing total uninstallable count can lead to britney later trading one uninstallable for another and causing havoc...
<jibel> psivaa, anyway, thanks for the fix. let me know when I can retrigger LAMP tests
<cjwatson> pitti: Not sure
<cjwatson> It's possible, but as xnox says possibly problematic
<cjwatson> Hm, I wonder what forces xserver-xorg-lts-trusty to be pulled in in the first place
<pitti> cjwatson, xnox: ok; I suppose we could do another sysvinit upload with just that change, and I'll re-re-re-re-redo the sysvinit merge
<psivaa> jibel: np. in the landing meeting. will do it in ~20 mins
<cjwatson> mlankhorst: I think you could fix this by changing the preferred libgl1 alternative in xserver-xorg-core-lts-trusty
<cjwatson> It's currently libgl1-mesa-glx
<xnox> pitti: shouldn't it just be s/sysvinit-core// ? cause sysvinit-core provides halt/init/poweroff/reboot/runlevel/shutdown/telinit all of which systemd-sysv is suppose to provide and in fact declares replaces on it....
<xnox> wait. read it wrong.
<pitti> xnox: it's because our current initscripts still hard-depends on upstart and mountall
<mlankhorst> cjwatson: ok I'll look, last I checked the packaging had the correct one at least, maybe it needs a similar hack?
<mlankhorst> oh DERP
<xnox> pitti: ah, i see.
<pitti> xnox: which is fixed in my pending merge; I'll prepare an upload with just that
<pitti> to get that out of the way
<mlankhorst> probably happens at shlibdeps time
<mlankhorst> libglx adds it, lets see if it happened in saucy too
<mlankhorst> odd, it should have been
<pitti> xnox: ok, done in https://launchpad.net/ubuntu/+source/sysvinit/2.88dsf-41ubuntu17
<xnox> cjwatson: stgraber: wubi for 12.04.5 for what it's worth http://people.canonical.com/~xnox/wubi/precise/wubi-r281-precise-signed.exe
<cjwatson> xnox: hm, I guess I need to install that and any images that have it need to be rebuilt ...
<cjwatson> I lose track
<xnox> it was signed and done yesterday, but i didn't get any emails from RT =/ =(
<xnox> so it could have been on yesterday's respin, oh well.
<cjwatson> copied, http://people.canonical.com/~ubuntu-archive/wubi/precise/stable symlink repointed
<psivaa> jibel: i've triggered the lamp jobs. and sorry i have no idea why i pinged Paul in the earlier message :/. must be muscle memory
<psivaa> jibel: and the dashboard is happy now :)
<mlankhorst> can someone drop xorg-server-lts-trusty_1.15.1-0ubuntu2.1~precise1 ? it will conflict with the fixed xorg-server
<mlankhorst> it's in precise's NEW queue
<mlankhorst> cjwatson: ^ enjoy
<xnox> cjwatson: ubiquity in precise doesn't look like it was rebuild since the last https enablements: apt-setup 1:0.55ubuntu4.1 base-installer 1.122ubuntu7.4 choose-mirror 2.39ubuntu4.1 debian-installer-utils 1.88ubuntu2.2
<xnox> do we need those in ubiquity?
<cjwatson> I'm not sure, check the changelogs?  is it just https?
<cjwatson> I'm not hugely bothered about https there if it otherwise works
<jibel> psivaa, thank you
<psivaa> jibel: yw
<wgrant> cjwatson: Do we care about the special case in edit-acl's query command which uses all_distro_archives if no archive is given? The other commands all just default to the primary archive.
<cjwatson> wgrant: It's sort of useful to be able to see them all, but maybe it should be a separate option instead
<cjwatson> (Because otherwise I forget about the existence of partner or something)
<doko> Riddell, cjwatson: does one of you look at the kde migration?
<Riddell> doko: I've looked at it and my eyes started bleeding, I don't know where else to look
<Riddell> doko: I removed some nepomuk packages because that's gone in this version of KDE SC
<Riddell> but it didn't help
<mlankhorst> jibel: can you accept xorg-server-lts-trusty? it should fix your iso, if lucky
<jibel> I cannot do that, I am just QA not archive admin :)
<mlankhorst> ok
<cjwatson> mlankhorst: that's a biggish diff against current precise - do you think it can be verified in time?
<mlankhorst> er?
<mlankhorst> it's 4 lines
<cjwatson> I was expecting a diff for just this change
<cjwatson> http://paste.ubuntu.com/7979052/
<mlankhorst> 2:1.15.1-0ubuntu2~precise2
<cjwatson> Er, hm, where's that I wonder
<cjwatson> Oh, unapproved not new
<mlankhorst> weird, how did that end in unapproved :P
<cjwatson> I think that LP bug was fixed
<mlankhorst> ah
<cjwatson> mlankhorst: William confirms that's fixed now
<mlankhorst> just delete the one in NEW, I'll see if I can get in the 2.1 later
<cjwatson> I did
<cjwatson> Bah, sru comment didn't happen because wrong source, will fix
<cjwatson> ah comment but not bug source
<cjwatson> status.  whatever
<jibel> jamespag`, if you want to smoketest iscsi on 12.04.5 server, it's the only test missing with maas
 * stgraber reads backlog
<mlankhorst> so with xorg-server-lts-trusty in -proposed, time to respin alternate?
<mlankhorst> # apt-cache show xserver-xorg-core-lts-trusty |grep glx
<mlankhorst> Depends: xserver-common-lts-trusty (>= 2:1.15.1-0ubuntu2~precise2), keyboard-configuration, udev (>= 149), libc6 (>= 2.15), libdrm2 (>= 2.3.1), libgcrypt11 (>= 1.4.5), libgl1-mesa-glx-lts-trusty | libgl1, libpciaccess0 (>= 0.12.902), libpixman-1-0 (>= 0.30.0), libudev0 (>= 161), libxau6, libxdmcp6, libxfont1 (>= 1:1.4.2)
<mlankhorst> that seems to work at least
<stgraber> mlankhorst: no, we need to move it to -updates first
<mlankhorst> ah
<mlankhorst> ok let me see if it runs locally
<stgraber> mlankhorst: can you just install that one from -proposed in a chroot or something to confirm it installs fine?
<stgraber> mlankhorst: if it does, I'll consider that verification-done and will copy it to -updates
<mlankhorst> it installs, but I'm still on precise so I can check if it runs too
<stgraber> xnox: so wrt wubi I'm a bit lost, did we still let people install using wubi in 12.04? if so, I suspect we indeed need a respin of everything that includes it...
 * stgraber doesn't like the idea of a mass respin this late, it'll be very hard to still release today if we do
<xnox> stgraber: i believe in 12.04 it is still supported. I do know that without update the old wubi will break, as it will keep on looking for 12.04.4
<mlankhorst> stgraber: go ahead, verification-done
<xnox> stgraber: i thought cjwatson was pondering on respins, not sure if he did that or not.
<mlankhorst> still boots -core on my system
<stgraber> xnox: damn, ok...
<stgraber> xnox: I'm not seeing any respins, so I guess I'll release mlankhorst's upload to -updates and then do a mass respin
<stgraber> zequence, Riddell, jibel: bad news, we're heading to another respin in about an hour. Affected will be ubuntu alternate and anything which contains wubi (fix for 12.04.5) or xserver-xorg-core-lts-trusty (to be in sync with the source image)
<Riddell> good thing I haven't started testing today yet :)
<stgraber> so at this point, I'm expecting a very very late 12.04.5 release, still kinda hoping to make it today but I guess tomorrow isn't entirely out of the question at this point :(
<jibel> stgraber, for desktop its just the cd not the livefs that is affected or are you rebuilding the livefs too?
<stgraber> jibel: I suspect we have xserver-xorg-core-lts-trusty in the desktop livefs
<jibel> :(
<jibel> right
<jibel> the day will be long
<stgraber> realistically, if you already tested the current one, just re-test wubi and test a single install, if that works, you're good. It's a LTS release and I know we haven't released any other thing in between, so if the image isn't corrupted, past results should stand.
<jibel> stgraber, realistically I won't be able to do much more than this.
<jibel> server, netboot and core looks good at least :)
<stgraber> yay, some good news!
<stgraber> can you mark those as ready on the tracker?
 * stgraber figures out the list of needed respins
<stgraber> ok, so we have some good news there, though not for jibel
<stgraber> Edubuntu DVD => full respin
<stgraber> Kubuntu desktop => iso respin (same livefs)
<stgraber> Ubuntu alternate => full respin
<stgraber> Ubuntu desktop => full respin
<stgraber> Ubuntu DVD => full respin
<stgraber> Ubuntu Studio DVD => iso respin (same livefs)
<stgraber> Now I just need to figure out how we do an iso respin only in the new world order
<stgraber> oh, I guess just not passing --live should do the trick
<stgraber> cjwatson: are you around to confirm?
<Riddell> stgraber: kubuntu alternate no respin?
<stgraber> nope, not needed as it doesn't contain wubi and doesn't have the HWE X stack
 * Riddell gets on with testing
<stgraber> and the ones I listed above as iso respin only, means that you should just give a very limited spot check to make sure the livefs didn't get corrupted, but any existing testing you've done should still apply
<cjwatson> stgraber: confirmed
<cjwatson> stgraber: for alternates, suggest running:  germinate -s ubuntu.precise -d precise,precise-updates,precise-proposed -a amd64 --no-rdepends
<cjwatson> and check that libgl1-mesa-{dri,glx} aren't in desktop-common or desktop, only the -lts-trusty variants
<stgraber> cjwatson: only seeing the lts-trusty ones, so looks like we're good
<cjwatson> Yay
<stgraber> ok, so rebuilding the wubi-only images now since those are trivial, still waiting for xserver-xorg-lts-trusty to publish
 * stgraber grabs the new kubuntu image to confirm wubi matches xnox's build
 * stgraber spins up a new ubuntu alternate
<stgraber> confirmed that wubi on the image and wubi on people.u.c have the same md5, so things look good
<stgraber> Riddell: you should be all set for 12.04.5 at last
<Riddell> stgraber: lovely
<stgraber> jibel: there you go, hopefully those will actually work ^
<stgraber> zequence: those studio images should be your 12.04.5 images unless you notice a major issue with them. As I said above, only the iso was respun, not the livefs, so a simple spot check is enough if you already tested the previous one.
<jibel> hopefully
<stgraber> current status is that I'm doing an alternate test install to confirm the X issue has been resolved, once that's confirmed, I'll respin the rest of the affected images
<jibel> stgraber, don't waste your time on this I'm on it
<stgraber> jibel: how far are you with your install?
<stgraber> here it just went past the point where it'd usually fail in the past!
<jibel> stgraber, here too
<stgraber> starting the respins of edubuntu dvd, ubuntu desktop and ubuntu dvd
<stgraber> all building now
<stgraber> and also building a new wubi live image (forgot that one in my earlier list)
<stgraber> zequence, Riddell: What will the URL be for your respective announcements?
<Riddell> http://www.kubuntu.org/news/kubuntu-12.04.5
<stgraber> draft of the announcement: http://pad.ubuntu.com/12-04-5-announcement
<Riddell> groovy
<Riddell> stgraber: when do you want to release it?
<stgraber> hopefully still today, or at least today for North America. My hope is for within the next 6 hours
<stgraber> but that entirely depends on testing
 * stgraber does the usual wiki mangling for the point release
<Riddell> groovy, I've marked kubuntu as ready
<stgraber> yay!
<rcj> stgraber, no respin planned for cloud images, just fyi but you probably figured that. :)
<Riddell> but it's only me who's tested them so could do with some others, hoping for some helpers later on
<stgraber> rcj: yeah, I figured you weren't affected by crazy windows or X issues :)
<stgraber> Riddell: same thing for Edubuntu, I'm the only tester for this point release, though I'm not too concerned as it's not massively different from 12.04.4
<Riddell> stgraber: sgclark is going to be the release contact for Kubuntu this evening, do give her a ping when it goes out so she knows to publish the news story
<sgclark> hello!
<stgraber> Riddell, sgclark: ok, will do!
<stgraber> wiki should be good now except for the list of changes from 12.04.4 which I'm still compiling
<stgraber> cjwatson: if you're still around, DIST=precise cron.source is failing somehow...
<stgraber> actually, let me try to call it the right way first, maybe that'll do the trick :)
<stgraber> hmm, no, this is the right way (looking at bash history from what infinity did for 14.04.1)
<stgraber> ok, let's try an ugly workaround for now
<stgraber> who's around from Ubuntu Studio?
<zequence> stgraber: I am
<zequence> stgraber: Our release link http://ubuntustudio.org/2014/08/ubuntu-studio-12-04-5-point-release
<stgraber> zequence: thanks
<stgraber> ok, so we just need to wait for Edubuntu to finish building + me to do a quick re-test on both and then hopefully jibel will have somehow tested everything else by then ;)
<jibel> I asked someone to test wubi, and I'm reviewing desktop images
<stgraber> cool, thanks
<highvoltage> cool
<highvoltage> stgraber: I also just finished my workshop but will be driving home in a few mins. everything ok?
<stgraber> highvoltage: yeah, the 12.04.5 candidate images for Edubuntu just finished building, downloading them now
<highvoltage> it's weird it feels like last week that 12.04.4 was released. time flies too fast.
<highvoltage> ah I'm thinking of the 14.04 point release
<stgraber> yeah, we had 14.04.1, alpha-2 of 14.10 and 12.04.5 really close by
<jibel> and B1 in 3 weeks
<jibel> stgraber, alternate is okay but I didn't test LTSP
<jibel> stgraber, I'm taking a break now and be back later to review desktop and DVD
<jibel> and hopefully update results of Wubi
<mlankhorst> is the alternate cd built?
<jibel> mlankhorst, yes and tested
<mlankhorst> works?
<jibel> mlankhorst, after installation I've a desktop, so the test is positive :)
<mlankhorst> good
<jibel> mlankhorst, thanks for your help.
<mlankhorst> np
<jibel> stgraber, I won't have results for Mac. Installation fails on the Mac used by the team
<stgraber> jibel: ok
<stgraber> jibel: we'll see if someone else can give us a positive result for it, otherwise we'll just skip +mac I guess
<stgraber> xnox: around?
<stgraber> right, so wubi is wrong and we'll need another iso-only respin for that
<stgraber> xnox is currently busy (just called him) but should be able to come online and get a new build in the next 30min or so
<stgraber> I'll try to build it myself here though as it doesn't seem to be very difficult to do
<stgraber> Riddell, sgclark, zequence, jibel: sorry but this will mean another mass rebuild hopefully in the next hour. Note that this is only going to be the ISO and not the livefs, so a simple boot test to confirm your iso isn't corrupted will be sufficient.
<stgraber> affected products are: edubuntu dvd, kubuntu desktop, ubuntu desktop, ubuntu dvd and ubuntu studio dvd
<jibel> stgraber, and a test of wubi of course
<stgraber> xnox: pycrypto download url is broken and you need to have grub-pc installed apparently...
<stgraber> and it now failed for yet another reason... retrying the whole thing again
<stgraber> yay, got a wubi.exe
<stgraber> and that does say 12.04.5!
<xnox> stgraber: hey
<xnox> stgraber: online now
<xnox> stgraber: oh =( yeah pycrypto i was getting it from a new location recently.
<xnox> =)
<xnox> stgraber: and i guess i owe doing testing past respin....
<xnox> yeap, my 281 locall signed binary says .4 & 280 =(
<xnox> i did what ev did the other time. upload wrong revision wubi and go off motor cycling.
<xnox> sorry.
<stgraber> xnox: also, pylauncher was pretty unhappy here, I had to port it from os.system to subprocess.call for it to work
<stgraber> anyway, pushed both fixes back to the branch in case anyone ever needs to do that again
<stgraber> and now very much hoping someone from IS has a minute to sign that thing
<xnox> stgraber: top contributor to wubi! Congrats, so I'm guessing you will be building it from now on =) 2 years of that was enough for me ;-)
<xnox> ev handed over to me, when he build it with wrong version..... history seems to repeat itself
<stgraber> jibel, zequence, Riddell, sgclark: ok, so what do you prefer, another testing blitz in an hour or so and release today or just go get some rest and we pick this up tomorrow and release a day late?
<jibel> stgraber, I don't mind retrying in 1h
<sgclark> does not matter to me
<jibel> and it's just 8:30AM on Baker Island we have plenty of time to retry and release on the 7th
<stgraber> ok, good, so I'll ping all of you as soon as I get hold of someone at Canonical IS to sign that new wubi
<stgraber> jibel: in case you can get someone to pre smoke-test it for you: http://people.canonical.com/~stgraber/wubi-12.04.5.exe
<sgclark> I don't think many will be around for testing on our part today, late already for most
<stgraber> jibel: it's not signed so Windows may complain about it
<stgraber> sgclark: so since we won't be rebuilding the livefs, you'll just need someone to boot the two affected images and make sure they're not corrupt.
<jibel> stgraber, I'll wait the iso just in case someone has the funny idea to put the previous version or sign it with the wrong key and who knows what else can happen now
<sgclark> stgraber: where are these images? sorry. thought I was just doing a post :)
<stgraber> sgclark: queuebot will announce them here when they're built and you'll be able to download them from http://iso.qa.ubuntu.com/qatracker/milestones/320/builds but I should have enough time to give you a hand with testing those whenever we're actually ready to build them
<sgclark> ok thanks
<stgraber> going away for a few minutes (food), hoping to get a response from IS by the time I get back
<stgraber> xnox: at some point between ev and you, I've been doing wubi builds, but that's a part of my life I prefer to pretend never happened :)
<stgraber> we've got a signed wubi: https://chinstrap.canonical.com/~rfinnie/wubi-12.04.5-signed.exe
<stgraber> moving it into place and starting the rebuilds
<stgraber> images are rebuilding now, ETA is ~15min
<stgraber> jibel, zequence, Riddell, sgclark: ^
<mlankhorst> will it still be ready in time for today? :P
<stgraber> jibel: new md5sum is 9a83deb1fa55e4b4811730880ce71788
<stgraber> mlankhorst: for me, sure, for Europeans, probably not :)
<jibel> 1h to release on the 7th in France
<mlankhorst> yeah
 * xnox goes for the dvds
<stgraber> and of course as usual edubuntu will publish last :)
<sgclark> ok so which are the two affected?
<stgraber> sgclark: the two I rebuilt, Kubuntu Desktop amd64 and Kubuntu Desktop i386
<stgraber> sgclark: http://cdimage.ubuntu.com/kubuntu/precise/daily-live/20140807.1/
<sgclark> ty
<stgraber> sgclark: that's precise-desktop-amd64.iso and precise-desktop-i386.iso
<xnox> hm.
 * xnox is trying to run wubi....
<stgraber> xnox: does it at least say 12.04.5 now?
<xnox> it fails to unpack for me, but i have newer wubi here installed again. Let me reclone pristine windows 7.
<stgraber> hmm, the .exe did start fine here
 * stgraber grabs the smallest iso he can find to test
 * xnox is slowly cloning a fresh 30GB win7 VM
<jibel> I asked nuclearbob to verify wubi on a real windows host
<jibel> yay alternate ltsp passed
<stgraber> signature is valid here and it appears to start, though that's a Windows server that's running out of disk space so it's not going very far :)
<stgraber> jibel: that's impressive, it usually always fails for a reason or another! :)
<stgraber> well, there was an obvious fail with LTSP but I fixed it two days ago (usual upload to switch it to the new kernels)
<jibel> stgraber, usually it fails because it picks the wrong nic
<jibel> lets do another round of desktop and dvds
 * stgraber grabs Edubuntu and re-tests those two one more time
<stgraber> well, first have to wait for them to sync to cdimage I guess...
<jibel> stgraber, do we agree to say if an image boots and installation is successful then all the test passed on previous image are still valid?
<stgraber> jibel: yes
<stgraber> livefs is identical so if it's not corrupt, we're good
<jibel> good
<xnox> dvd/i386 is all good for wubi
<xnox> (in a fresh windows7 vm)
<stgraber> yay!
<xnox> ubuntu amd64 desktop & dvd boot in UEFI modes fine.
<jibel> and in bios mode too :)
 * xnox likes trusty hwe stack. Got widescreen in qemu =) 
<jibel> ubuntu desktop is ok, untested screen reader and vmware easyinstall
<stgraber> finally getting there! :)
<jibel> Mac images are untested. Only test we did, didn't pass the partitioning. It's a no-go for QA
<stgraber> ok, I won't be releasing them then
 * xnox has no macs =(
<stgraber> if someone complains about it and does testing for us, we can always release them later
 * xnox grabs studio images
<stgraber> xnox: thanks! I haven't heard from the studio guys in a while so I was actually planning on doing the spot check for them once I'm done with Edubuntu.
 * xnox ponders about how pointless it is to GPG sing MD5SUMS file
<xnox> well SHA256SUMS is also signed, so it's alright.
<stgraber> yeah, I wouldn't really recommend anyone use MD5SUMS to check authenticity, using it to check integrity is fine though (but then you don't care about the signed one)
<xnox> i like studio theme, but i'm getting OCD about all the minor ux bugs that i fixed in ubiquity since, in precise.
<stgraber> :)
<xnox> live session is fine on amd64, finishing up install and then will do i386.
<stgraber> edubuntu amd64 live and ltsp are good, doing a standard install to confirm the media is clean
<jibel> ubuntu dvd amd64 is ok
<sgclark> kubuntu amd64 good, now testing i386
<stgraber> I'm doing pre-publishing of everything that's on the tracker except for ubuntu mac images
<xnox> i can draw a doodle in gimp post ubuntustudio installation -> perfect.
<xnox> stgraber: we are not respining livefs for openssl security fix just pushed out....?!
<xnox> where just is 2h ago.
<xnox> (for updates, 3h for security pocket)
<stgraber> nope
<xnox> good =)
<stgraber> if we had to respin every time there was an openssl security fix... :)
<xnox> ... we'd never be able to release </troll> =)
<stgraber> pre-publishing done
<stgraber> xnox: ok, so what did you test so I update the tracker with those?
<xnox> stgraber: yes.
<xnox> studio i386 in progress, will finish soon.
<xnox> i've updated tracker with green test results for things i've tested.
<stgraber> oh, I see, marking that one ready then
<xnox> ubuntu dvds should be ready
<xnox> as well
<stgraber> I'll let jibel flip the magic switch for those since he's around :)
<jibel> done
<stgraber> cool, so just waiting for studio i386, kubuntu i386 and both edubuntus (which take a bloody long time to install...)
<stgraber> I'll soon start final publishing of everything to let time for cdimage mirrors and bittorrent to catch up, by the time that's done, I should be done with edubuntu
<jibel> 13 contributors have provided 290 results and covered 217 testcases
<xnox> will we have to test torrents as well.... or they are now "can be assumed to be operational"
<jibel> and 1 contributor is a bot
<stgraber> xnox: I usually load a bunch in my client here and wait to see when they start working. The server is freakishly slow so it needs a good hour for the initial hashing.
<stgraber> so with that said, my current ETA for release is midnight UTC (1 hour and 40min from now).
<stgraber> Riddell, sgclark, zequence: ^
<sgclark> ok. Riddell is long asleep by now I suspect but I will be here, almost done with i386
<xnox> ubuntu studio dvd i386 is ready, all good.
<sgclark> kubuntu i386 good
<stgraber> ok, beginning publishing now
<stgraber> 1.5h should be plenty for bittorrent to catch-up
<jibel> testing report sent
<stgraber> jibel: perfect, thanks for staying up so late!
<jibel> I've had my share of testing for today
<jibel> stgraber, if you don't need me for anything else I'm heading to bed
<jibel> good night everyone !
<stgraber> jibel: nope, all good, good night!
<xnox> yeah, me too. good night. sorry for the mistake =(
<stgraber> xnox: good night! Thanks for helping with the testing :)
<stgraber> rcj: FYI, release in 1h15 (midnight UTC)
<rcj> stgraber, sounds good, thanks.
<stgraber> and at last, we've got test results for everything.
<stgraber> I just pushed out the images to the mirrors, so that should be syncing about now and bittorrent should have enough time to catch up in the next 45min
#ubuntu-release 2014-08-08
<stgraber> bdmurray: if you're still around, can you update meta-release for 12.04.5?
<bdmurray> stgraber: okay
<stgraber> cjwatson: when you have a moment, can you update https://help.ubuntu.com/community/UbuntuHashes with the 12.04.5 hashes? thanks
<stgraber> and I think that's all that's left on the list
<stgraber> rcj, sgclark, zequence, Riddell: Just waiting for my announcement to show up out there and then you'll be able to release yours.
<sgclark> yay ty
<bdmurray> stgraber: done
<rcj> stgraber, thanks for the update
<stgraber> bdmurray: thanks
<stgraber> just waiting for IS to find a way to accept my e-mail to ubuntu-announce, once that's out we'll finally be done :)
<shadeslayer_> stgraber: yeah, pretty sure Riddell has gone off to sleep :P
<stgraber> I sure would hope so :) But I usually keep the flavour lead in the loop anyway so they can easily catch up when they're back
<stgraber> (I suspect zequence also went to bed a while back)
<shadeslayer_> stgraber: well, I see your email on https://lists.ubuntu.com/archives/ubuntu-release/2014-August/002973.html , should flavors be good to go?
<stgraber> shadeslayer_: no, I'm waiting for it to show up on ubuntu-announce
<shadeslayer_> sgclark: ^
<shadeslayer_> ah
<stgraber> I've got someone from IS looking into it now, so shouldn't take too long
 * shadeslayer_ heads off to sleep, sgclark is on it for Kubuntu
 * sgclark hovers over the publish button
<stgraber> rcj, sgclark, zequence, Riddell: the announcement is finally out!
 * sgclark hits publish
<sgclark> thanks!
<rcj> stgraber, thanks
<xnox> stgraber:  lol "X-Ubuntu: ubuntu-12.04.3-is-finally-out-EOW-time" =) s/3/5/ ?! =)))))))
<stgraber> xnox: oh yeah, copy/pasted from the last time I made a release, forgot to bump to 12.04.5, though the end mostly still applies (except I only wish I was EOW) :)
<stgraber> sure plan on sleeping in a bit tomorrow though ;)
<xnox> yeah ;-)
<xnox> stgraber: good night.
<stgraber> thanks, you too!
<jamespag`> infinity, when you have time can you review my approach on bug 1338768 - I'm ready to upload to trusty-proposed if this is acceptable.
<ubot93> bug 1338768 in golang-pty-dev "[SRU] Update to 1.0.1 release" [High,New] https://launchpad.net/bugs/1338768
<highvoltage> jibel: bots are people too!
<jamespage> slangasek, infinity: ^^ packageset for trusty update of docker.io
<jamespage> hoepfully that meets the SRU teams requirements
<slangasek> jamespage: do you happen to know if golang-context-dev/src is supposed to be removed from utopic in favor of golang-context?
<cjwatson> slangasek: oh hai we're blocked on you for RTM setup now :)
<slangasek> cjwatson: driver, release manager set
<cjwatson> aha
<slangasek> :-)
<cjwatson> slangasek: we also need to puppet you through +initseries
<cjwatson> probably best done in person
<slangasek> cjwatson: hmm, ok; I'll be there in 5
<cjwatson> ta
<jamespage> slangasek, lemme check but I think that is the case
<jamespage> slangasek, golang-context (src) -> golang-context-dev (binary all)
<jamespage> so yes that can be removed - I'll file a bug
<cjwatson> slangasek: http://paste.ubuntu.com/7988230/
<slangasek> cjwatson, wgrant: did you know you're generating accept mails for all packages going into ubuntu-rtm?
<cjwatson> slangasek: yes, we've stopped the copies and are fixing that
<cjwatson> we only got up to binutils before jamespage told us :)
<cjwatson> sorry about that
<slangasek> ;-)
<cjwatson> the copies performed before C-c were http://paste.ubuntu.com/7988658/
<bdmurray> Shouldn't http://changelogs.ubuntu.com/meta-release contain 14.04.1 LTS for trusty?
<infinity> bdmurray: Yeah, it should.
#ubuntu-release 2014-08-09
<baytrail> Is the release team aware of this bug https://bugs.launchpad.net/ubuntu-release-notes/+bug/1351826 which prevents upgrading from 12.04 LTS to 14.04.1 LTS since 2 weeks?
<ubot93> Launchpad bug 1351826 in ubuntu-release-notes "14.04.1 release notes provide incorrect upgrade info" [Undecided,Confirmed]
<baytrail> http://changelogs.ubuntu.com/meta-release-lts is missing a Trusty LTS section, that's the reason why no upgrade is being offered.
#ubuntu-release 2014-08-10
<xnox> Please demote gnutls26 to universe
<ScottK> xnox: Done
#ubuntu-release 2015-08-03
<micahg> Please reject my first hplip upload to trusty, wasn't cleaned
<slangasek> has anyone started rebuilds for boost?  I notice uhd needs rebuilt for new boost, because gnuradio FTBFS for log4cpp rebuild
<slangasek> oh, right. hey, new binaries for review
<slangasek> :P
<slangasek> xnox: does this look like a boost bug to you? https://launchpad.net/ubuntu/+source/fatrat/1.2.0~beta2-0ubuntu11/+build/7750690
<slangasek> doko: ok, I've started batch uploading libraries; many of the packages will Just Work, but those with symbols files are bound to fail.  I'll revise my script to hold back packages that include symbols files; do you have any suggestions for batch-fixing of these? (https://launchpadlibrarian.net/213449479/buildlog_ubuntu-wily-amd64.atlas-cpp_0.6.2-4.1ubuntu1_BUILDING.txt.gz)
<doko> slangasek, s/std::basic_string/std::__cxx11::basic_string/ will get you some updates. but not the ones where the return type for the string type is enocded ([abi:cxx11])
<slangasek> doko: ok.  btw, since we now have per-library transition trackers for the library renames, should we maybe drop the libstdc++6 one?  since that's not a transition that will ever "complete" anyway, given the inexact matches
<doko> sure
<slangasek> ok, pushed (but the tracker currently takes quite a while to process all the transitions, so web won't be updated for a few hours)
<xnox> slangasek: it's a Qt4 moc's bug that it fails to parse BOOST_JOIN, because moc is not a good enough cpp, this is fixed in QT5...
<xnox> slangasek: one should use, e.g. #ifndef Q_MOC_RUN ... #endif to "fix" it.
<slangasek> xnox: ok; for now I'll just drop the package from wily
<xnox> slangasek: Divide and conquer
<xnox> slangasek: we could fix them all by recompiling qt4 with this:
<xnox> http://pkgs.fedoraproject.org/cgit/qt.git/tree/qt-everywhere-opensource-src-4.8.0-rc1-moc-boost148.patch?id=f0ce6564e29e22eac504c538698517bdcef80061;id2=060db3c767b670dc1e168252644c937abc9fe607
<slangasek> xnox: right; the fact that it's qt4 tells me approximately how well-maintained and relevant it is however, so that puts it in the set of things I'm not going to let be in the critical path of the transition.  it's now a wily-proposed-only FTBFS That someone can fix
<xnox> slangasek: ok.
<xnox> slangasek: this is not the only package where i have seen this happening at though. And fixing it at moc level overall will be best, than patching these falling leaf things.
<xnox> i'll do that, and trigger the rebuild of things that failed with that.
 * xnox goes to find coffee
<xnox> hm, we have those qt4 patches in place already.
<doko> slangasek, go to bed and tell Laney and me where to continue
<andol> Any chance that anyone in here cares about the http://releases.ubuntu.com/vivid/ FOOSUMS don't appear to match up with their corresponding FOOSUMS.gpg? http://paste.ubuntu.com/11994117/. In addition to the BAD signature reported by gpg there is also the oddness of the FOOSUMS file appearning newer than their correspdoning signatures files.
<infinity> andol: Grr.  Will fix.  I blame whoever is mucking in my trees to drop new snappy releases in.
<infinity> rsalveti: ^-- Who did that?
<andol> infinity: Thanks.
<infinity> andol: Thanks for catching it.
<infinity> andol: Should be happier now.
<andol> Yepp, yepp
<rsalveti> infinity: I believe I did that, but looking at my logs I did call sign-cdimage, not sure what happened, sorry
<rsalveti> will make sure this doesn't happen again
<infinity> rsalveti: The simpler thing is just to drop your files in and call "checksum-directory ."
<infinity> rsalveti: And double-check against the published version to make sure nothing broke before you sync-mirrors.
<rsalveti> infinity: cool, thanks
<infinity> rsalveti: Also, can we ever drop the compat symlinks I had to add for that blog post that pointed at the wrong path?  I guess we can for wily, but never for vivid?
<infinity> rsalveti: I was going to write proper snappy support into cdimage at some point so this all made sense, but yay time.
<rsalveti> slangasek: can we drop the compat symlinks?
<rsalveti> don't remember what caused it
<rsalveti> but if it's just because of a blog post, sure, unless it's a post from mark :-)
<infinity> rsalveti: I don't remember who the blog post was from, but it was vaguely "official", hence the symlinks. :P
<infinity> rsalveti: It doesn't bug me if they stay there forever for vivid, just want to make sure no docs will reference them (other than the offending blog post) going forward, so we don't have to perpetuate the hack.
<rsalveti> yeah, for wily we can for sure remove it
<slangasek> doko_: I already did go to bed, and handed you the script on #distro for you to continue with... :)  doesn't look like there've been any new libraries uploaded since this morning, however.  that's fine, I can pick these up again, it's mostly scriptable by now
<slangasek> rsalveti: yes, no objection from me to removal of the symlinks
<slangasek> who maintains ben? Laney?
<Laney> slangasek: fs(mall)vo
<slangasek> Laney: ok, so... if I'm noticing it not scaling so well in the face of all the C++ ABI transitions... is that you? :)
<Laney> slangasek: I can't be blamed for the upstream code
<Laney> slangasek: You can run it with sh -x or something to see if it's a problem with the way we are invoking it
<slangasek> ben appears to be a binary executable
<Laney> there's a runner
<slangasek> the runner isn't what's taking 99% CPU and 70% memory for 3 hours
<Laney> schroot -c trusty-transitions; /srv/transitions/<mumble>/go
<Laney> if it's the one instance of 'ben tracker' then fair enough
<Laney> but we also loop over 'ben monitor' to generate the .txt output
<Laney> and that could probably go if this part doesn't scale well
<slangasek> it's the ben tracker that's the hit
<Laney> We might try the latest upstream code (probably easiest a wily environment) to see if it's improved
<Laney> and if not then mehdi is who you want
<Laney> if so then we need to upgrade
<slangasek> ok, well I'm not shaving that yak right now; still working on getting the libraries themselves uploaded
<slangasek> (which I'm sure will only make ben's performance worse)
<Laney> yeah... that would be a backport to trusty which I'm not sure would be very fun
<Laney> oh also, there's a package so the initial yak might not have to be so hairy
<slangasek> replicating the transitions environment as a wily test env is enough of a yak already
<slangasek> Laney: maybe an easier question: why is pion still showing up on http://people.canonical.com/~ubuntu-archive/transitions/html/log4cpp-g++5.html ?
<slangasek> and fixed my batch script to do something sensible now with -dbg packages
<slangasek> so another batch of uploads coming
<Laney> slangasek: At a guess: the -dev package matches your -bad
<slangasek> Laney: libpion-dev Depends: liblog4cpp5-dev, liblog4cpp5v5.  Ben doesn't have any smarts to match on package name boundaries?
<doko_> crap,
<doko_> rejecting
<slangasek> um?
<slangasek> 'dch -r -D wily' :)
<doko_> too late here again ...
<slangasek> Laney: so if ben doesn't have any smarts for making depends fields match on package name boundaries, but /you/ do, I'd be happy to take a tried-and-true regexp and use it in my script for autogenerating these transitions files... instead of having them all be subtly wrong
<slangasek> monitor/ongoing/dh-python2.ben has a promising candidate: (^| )(pkg1|pkg2)\s*([,(]|$)
<slangasek> that misses ':arch', but that's easily added
<Laney> slangasek: I don't mean that - I mean that your regexp is a match for the string "liblog4cpp5-dev" which is in Depends of libpion-dev
<Laney> I thought that ben already split at package boundaries for these queries but if people have been hacking around it then maybe not?
<slangasek> Laney: ok, so my 'bad' is .depends ~ /liblog4cpp5\b/
<slangasek> which obviously matches liblog4cpp5-dev, but
<slangasek> anyway I'll try the dh-python2 approach
<slangasek> (blind, since it'll take forever to regen)
<slangasek> oh, I guess the horribly broken dbus-c++ one probably doesn't help performance
<slangasek> Laney: ok, I think - and this is just a guess here - that ben's performance may improve now that the config no longer includes two broken trackers with a null regexp matching every package in the archive
<slangasek> sorry, looks like an earlier iteration of the code I was using to autogenerate them choked badly on packages with '+' in the name :P
<slangasek> oh hey look, ben finished in < 20m instead of > 3h
<slangasek> Laney, doko: here's the current state of the art of my auto-library-mangling script; at this point it works pretty reliably for everything but symbols files - and for packages with symbols files, it aborts and leaves you with a working directory you can use to fix those up: http://paste.ubuntu.com/11996364/
<doko> slangasek, would you mind sending this to debian-devel too?
<slangasek> doko: when I get a chance; I'm currently still trying to get us to the point that we can unblock gcc-5 in Ubuntu
<slangasek> anyway, if anyone wants to help with this transition, they could hack that script to run it for some of the packages needing symbols file updates
<slangasek> so far I have csound and ctpp2
<slangasek> (that need attention, I mean)
<doko> slangasek, how do you want to handle the auto removals which were done in debian testing? I assume we should do something similar, but I don't know how
<slangasek> doko: we have an autoremoval job for archive admins, but it looks like it hasn't been run in at least 15 days
<slangasek> doko: for now, I have a blacklist that I'm using: http://paste.ubuntu.com/11996394/
<doko> slangasek, can I see the issues with csound and ctpp2? or should I build these myself?
<slangasek> this script has Ubuntuisms in it btw, won't quite work for Debian
<slangasek> doko: it's symbols files changes, I've only added them to the blacklist so I can skip over them and churn through the others
<doko> ok
<slangasek> so feel free to claim one for looking
<doko> both
<slangasek> ok
<doko> slangasek, could you check getfem++? needed by csound
<slangasek> doko: I'm up to 'f' now, you should have it soon
<doko> ta
<ari-tczew> can someone accept source package "jersey1" @wily-proposed? missing B-D is already in archive
<infinity> ari-tczew: The dep-wait would have cleared on its own if you waited a bit.
<ari-tczew> infinity: also automatically, ok
<slangasek> C++ libraries that are currently FTBFS and need investigation: clanlib libcrypto++ fbreader dcmtk
<slangasek> (I haven't looked at these at all beyond seeing that there are build failure emails; they could all be simple things)
<doko> I would love to nuke cdbs
 * slangasek sources some plutonium
<slangasek> clanlib reuploaded
<doko> wtf is d-shlibmove?
<slangasek> heh
<slangasek> flac, geographiclib also have symbols files
<doko> afk now, ctpp2 in the works, but I hate cdbs
<slangasek> just noticed the script needs to be smartened for binary packages with 'c2a' in the name
<slangasek> (yes, we still have a bunch of those around)
<infinity> slangasek: Hey, why not?  We still have binaries with '1g' in the name.
<infinity> Or, rather, just 'g'.
<slangasek> doko: getfem++ uploaded now
<slangasek> infinity: yeah, but those are libraries written in C, where stable ABIs exist :)
<slangasek> infinity: I'm pretty sure most of the c2a libs are old GNOME abandonware
<infinity> Very stable, in the case of libz1.
<infinity> Which could drop the 'g' if someone actually renamed the library package to be policy-compliant.
<infinity> I wonder why no one's ever bothered.
<infinity> Oh, probably because of thousands of versioned deps.
<slangasek> yep
<infinity> But now that we have versioned Provides, that could be sorted.
<slangasek> do we?
<infinity> Yup.
<slangasek> in stable apt + dpkg?
<infinity> Provides: zlib1g (= 1.2.3) does what you'd expect.
<infinity> Not sure which versions of packaging tools are needed to make it happy.  Would have to check.
<infinity> slangasek: Bah.  Only in utopic's apt.  jessie is good, trusty is not.
<infinity> slangasek: But post-16.04, renaming zlib1g could totally be a thing.
#ubuntu-release 2015-08-04
<slangasek> man, what's with the sort order on http://people.canonical.com/~ubuntu-archive/transitions/
<slangasek> xnox: are you driving no-change rebuilds for boost1.58?
<slangasek> I have a stack of ABI-breaking libraries /on top/ of gnuradio whose build-deps are currently uninstallable because of boost->libzeep->gnuradio, so if nobody is batching those up I suppose I should take a look soon
<slangasek> OTOH I should also double-check that these gnuradio revdeps are actually libraries and not just plugins or something
<slangasek> anyone have the url to the last full-archive rebuild test? (main+universe)
<slangasek>  looks like this might be it - https://launchpad.net/ubuntu/+archive/test-rebuild-20150402
<slangasek> Package: libgdome2-cpp-smart0v5
<slangasek> Conflicts: libgdome2-cpp-smart0c2a, libgdome2-cpp-smart0, libgdome2-cpp-smart0c2
<slangasek> latest script revision, smarts added to handle c2/c2a -> v5 renaming. http://paste.ubuntu.com/11997246/
<slangasek> should kdepimlibs have gotten a package name transition already?  it shows up in my to-be-converted list
<slangasek> wow, so hdf5's C++ library has a symbols file where every single symbol is marked 'optional' and new symbols are not build failures.  ok then!
<slangasek> ... and furthermore there's a version script, which doesn't match any of the new symbols
<slangasek> ugh who let gadap into the archive (library package builds only .a, which is used by other packages in the archive)
<infinity> slangasek: #debian-ftp is over there.
 * infinity points.
<infinity> slangasek: Though, it seems to only have one r-build-dep, so it could be worse...
<slangasek> infinity: yes, it's still a pain for abi transitions
<infinity> slangasek: Don't worry, Go will save us all from this evil C++.
<infinity> slangasek: Also, can you be a dear and review ubuntu-drivers-common/trusty?
<infinity> I suppose I should make sure it passes its testsuite first...
<infinity> Oh look, it passes.
<infinity> bdmurray: You around?
<bdmurray> infinity: yep
<infinity> bdmurray: Too late, I think arges is on the case.
<infinity> slangasek: Disregard the pleading for review.
<bdmurray> infinity: when is this point release?
<infinity> bdmurray: Thursday.
<bdmurray> infinity: okay, I was just thinking about meta-release changes and being out on Friday
<infinity> bdmurray: Ahh, yeah.  Who else has commit to that?  We really need to spread it around a bit more.
<infinity> ... not that it's accurate anyway right now.
<infinity> Whee.
<infinity> bdmurray: lucid still claims to be Supporter: 1 in meta-release-lts.
<infinity> And in meta-release
<infinity> And, not shockingly, -development.
<infinity> bdmurray: I must have missed bugging you about EOL on that one.
<infinity> bdmurray: Then again, no one ever changed it to 10.04.4 either, so it seems lucid is full of meta-release fail. :)
<arges> infinity: ok accepted ubuntu-drivers-common into trusty-proposed
<infinity> arges: Ta!
<bdmurray> infinity: I'll have a look at fixing that.
<slangasek> infinity: ok disregarding
<slangasek> seb128: did you look at reverse-depends before removing xbmc from wily?  xbmc-pvr-addons, at least, should also go
<slangasek> (or be renamed or something
<slangasek> )
<bdmurray> infinity: wrt meta-release its cjwatson, mvo and me
<infinity> bdmurray: Yeah, should probably add me to that list, since two of those people are not directly involved in the release process anymore.
<bdmurray> infinity: I'll submit an RT for you since its a group change on a server and I know the details.
<infinity> bdmurray: Ta.
<infinity> bdmurray: Then tell me what branch I'm supposed to check out. :P
<bdmurray> infinity: ~ubuntu-core-dev/meta-release/ubuntu/
<infinity> bdmurray: Well, based on the path, I assume lots and lots of us have commit to that...
<infinity> bdmurray: So, there's clearly a second step here that involves changelogs.u.c
<bdmurray> infinity: yeah, there is some manual copying around on the server
<infinity> bdmurray: Check.
<slangasek> robru: I'm about to trigger mass-rebuilds for tinyxml, because I found some intersection between that transition and the libjsoncpp one
<slangasek> robru: so http://people.canonical.com/~ubuntu-archive/transitions/html/tinyxml-g++5.html may be worth looking at in a little bit
<robru> slangasek: oh hey. sorry I'm late going to lunch, the creds leak situation turned out to be worse than I thought (in addition to the fixes I told you, it's also leaking tokens when debugging is enabled). so I've only just fixed this, just about to lunch now
<slangasek> ok
<robru> slangasek: thanks for the tip though
<slangasek> looking into the ogre-1.8 FTBFS
<slangasek> (by way of a convoluted chain of dependencies that will not be expanded here)
<robru> slangasek: ok sorry about that, what am I looking at on that page there?
<robru> slangasek: I see a whole lot of red X's. that's good, right?
<slangasek> robru: it's good that you see them but not good that they're there
<robru> heh
<robru> slangasek: so I should just drill down into the build logs and figure out what the failures are?
<slangasek> robru: you'll notice a double dose of them in arm64, ppc, and (to a lesser extent) ppc64el; those are ignoreable for now and just mean that the builders for those archs are a little behind.  For the ones with x in the amd64 column, yes, drill down and figure out the cause of failure
<robru> slangasek: ah I was just about to ask if there was a distinction between "failing on all arches" and "failing on some arches", you read my mind ;-)
<slangasek> robru: particularly for packages that have XubuntuY version numbers, it's worth looking whether there's a newer version in Debian that might fix the failure (merges.ubuntu.com)
<slangasek> robru: for packages that a reasonable fix is possible, prepare a source package and submit it to sponsorship queue (which in this case means: open bug on package, upload debdiff, subscribe ubuntu-sponsors) and you can also ping here for uploads
<slangasek> robru: for unseeded packages where a fix seems untractable, it's often reasonable to remove the package from wily and wait for a fix from Debian; feel free to propose removals where you think this is appropriate
<robru> slangasek: oh man that sounds like a crusty workflow. can't just dput to my ppa or something?
<slangasek> robru: and if you find packages that are failing to build because their build dependencies are uninstallable, that may indicate that we need to traverse a different part of the dep chain or retry the builds etc
<slangasek> robru: no, the sponsors don't want to be redownloading a full package from a ppa :)
<slangasek> interchanging debdiffs is more efficient
<robru> slangasek: k I'm not great with debdiffs but I'll figure it out. should I be attempting to reproduce these failures locally in sbuild or something?
<slangasek> robru: generally yes
<robru> alright
<slangasek> as for debdiffs, the command is 'debdiff' to create a diff between two source packages (.dscs)
<infinity> robru: "Not great with debdiffs"?  After you build that source package you would have uploaded to your ppa, "debdiff old.dsc new.dsc > new.debdiff" done.
<robru> infinity: well I don't have old.dsc at the moment ;-)
<infinity> For bonus points, read the debdiff too. :P
<infinity> robru: How are you lacking old.dsc?
<infinity> robru: Oh.  If you're using UDD/bzr for this and trusting the branches to be accurate, stop that.
<robru> infinity: because I literally *just* started looking at this and I don't have anything on my system at all.
<infinity> robru: pull-lp-source $package && hack, hack, hack && debuild -S && debdiff old new.
<slangasek> robru: 'pull-lp-source'
<robru> slangasek: infinity: thanks. last time I tried asking around for how to download source packages nobody seemed to know and I ended up writing some hack to fudge sources.list to make 'apt-get source' download from other archives.
<slangasek> I guess you didn't ask the right people ;)
<robru> slangasek: no apparently not. but they were core devs oddly
<cjwatson> pull-lp-source knowledge has been percolating outwards for a while.  I think most people have heard of it now but that was less so a year or so ago
<robru> now I need to figure out how to set up sbuild ;-)
<cjwatson> https://wiki.ubuntu.com/SimpleSbuild
<robru> thanks
<infinity> Sadly, pull-debian-source is in a bit of a state, with Debian's APIs in flux.  Need to fix that to use ftpmaster's new shiny on all releases.
<infinity> But pull-lp-source is definitely love.
<robru> oh man, sbuild wants to pull in exim4. Can it, like, not?
<infinity> robru: apt-get install nullmailer sbuild
<robru> infinity: thanks
<infinity> robru: Or some real MTA of choice, if you want to mail stuff.
<robru> infinity: nah, happy gmail user
<infinity> (sbuild likes to mail out build logs, but this feature is perhaps of questionable value to the average dev)
<robru> yep, sounds useless to me
#ubuntu-release 2015-08-05
<michi> robru: ping
<slangasek> xnox: I see that ogre-1.8 hard-codes a dependency on libboost1.55; is there a reason it doesn't depend on current libboost?  Is it because boost leaks into its abi?
<slangasek> robru: ^^
<slangasek> hmm, so grep-dctrl -w doesn't match packages with multiarch qualifiers after them.  Bug, or misfeature?
<slangasek> oops, no, I'm talking nonsense; -w works correctly and I had a failure elsewhere
<robru> michi: pong
<michi> robru: never mind, figured it out...
<michi> Thanks anyway!
<robru> michi: hehe, you're welcome
<ted> Is there a doc somewhere on using live-build
<ted> I've tried the docs, which didn't really get me anywhere. And now I've got lp:livecd-rootfs
<ted> But that's not really making my life easier.
 * ted thought this was gonna be easyâ¦ last week
<doko> slangasek, why the transition for hunspell? it only has references to the new libstdc++, but no new cxx11 symbols
<davmor2> infinity: for when you get on could you add netboot to the 14.04.3 test run please, I'll test it in the meantime so it is out of the way :)
<doko> slangasek, ahh, because we don't avoid renames when there are references to cxx11 symbols in libstdc++ only
<cjwatson> ted: https://lists.ubuntu.com/archives/ubuntu-devel/2011-June/033458.html might be helpful
<davmor2> infinity, slangasek: so a friend did a do-release-upgrade on his server and got 14.04.3 that shouldn't happen should it?
<slangasek> doko: is hunspell one that I transitioned?  I don't find hunspell listed at https://people.debian.org/~doko/logs/gcc5-20150701/
<doko> ahh, no, seb 128. was maybe on the list, because it was uploaded to the ppa
<robru> slangasek: morning! so i see http://people.canonical.com/~ubuntu-archive/transitions/html/tinyxml-g++5.html is quite a bit shorter, what should I do next?
<slangasek> robru: take a look at the next package on the list that you haven't already looked at :)
<robru> slangasek: so eg bullet has red Xs on all arches but when I click through to the log it's all green: https://launchpad.net/ubuntu/+source/bullet/2.83.5+dfsg-1build1 I'm a bit confused
<slangasek> robru: yes; that's an annoying bug in the transition tracker, it appears to not get the right results when wily has a binary package depending on the lib, but wily-proposed no longer has that binary
<slangasek> Laney might have more insight there
<slangasek> but, it's a bug in the report, not in the package
<robru> slangasek: ok so the green builds on lp are authoritative.
<robru> slangasek: so does cegui need to be rebuilt again? you mentioned last night that you fixed the libsilly bug but the cegui build log shows the same failure
<slangasek> robru: no, the red x doesn't say whether the package is /built/ it's supposed to say whether the package has been /transitioned/.  The transition tracker only tells you "this is the latest version of the package in the archive, and the last built binary still depends on the old library" (which is false here).  Launchpad tells you "the latest version of the package built successfully".  To get the
<slangasek>  true answer you have to check the set of binary ...
<slangasek> ... packages built by that latest version and see that they don't actually depend on the library
<slangasek> robru: I fixed libsilly in Debian, which causes a delay for it getting fixed in wily-proposed since it takes time before the package can be synced from Debian.  I've synced libsilly now, it's being built, and I'll requeue cegui-mk2 once the build-dep is available
<robru> ah ok
<robru> slangasek: so it looks like the next one is gazebo. seems you didn't rebuild that one?
<slangasek> robru: you already looked at crtmpserver?
<robru> slangasek: it was green in lp ;-)
<slangasek> robru: which does not tell you that the transition is done
<slangasek> wow, we have log4cplus, log4cxx, and log4cpp? brilliant
<slangasek> robru: I've just checked the archive; 'apt-cache show crtmpserver-libs' shows that the package still depends on the wrong tinyxml package after a rebuild, which means the package needs manual changes
<robru> slangasek: then how did the build succeed? lol
<slangasek> robru: that's what you need to look at
<slangasek> xnox: fwiw your mygui migration missed the references to the binary package names in the .symbols files
<infinity> davmor2: People should be getting 14.04.3 in lsb_release by now, yes.  ISOs are built from updates, so base-files already says .3
<infinity> stgraber: Can we manually add the "netboot" cases somehow?  I don't want to reupload d-i just to make them show up. :P
<stgraber> yep, one sec
<stgraber> infinity: ^
<infinity> davmor2: And stgraber sorted out your netboot needs.
<infinity> stgraber: Ta.
<davmor2> infinity: phew :)
<slangasek> doko: I have a build failure showing C++ ABI incompatibilities in the ois package, which wasn't in your list; do you have some idea why? https://launchpad.net/ubuntu/+source/cegui-mk2/0.7.6-3.3build1/+build/7759424
<doko> slangasek, not yet rebuilt ois.
<doko> maybe it failed to build
<slangasek> ok
<doko> slangasek, and in general for any library with a transition in it's b-d's the list may be incomplete
<slangasek> ok
<infinity> davmor2: Can you try to hunt down some community folks for the flavours that don't appear to have any results yet?
<davmor2> infinity: I can
<infinity> davmor2: Barring any last minute show-stoppers, I think these will be the final images (I might respin powerpc/ppc64el server for one package update, but if I do, the rest won't get touched)
<davmor2> infinity: nice
<davmor2> infinity: so far so good too :)
<davmor2> infinity: apparently #ubuntu-gnome don't test a release once it is out only new releases /me shrugs shoulder at that one
<infinity> davmor2: Huh?
<infinity> davmor2: I suspect you're talking to the wrong people, then.
<infinity> darkxst: *poke*
<infinity> darkxst: 14.04.3 testing? :)
<davmor2> infinity: that's what I'm assuming :)
<Laney> slangasek: I don't know more - it's supposed to deduplicate but maybe gets that wrong
 * Laney is away for the rest of the week but put a quick update on the pad
<davmor2> infinity: xubuntu's guy is <flocculant> and it sounds like he is just starting
<Laney> if nobody else does I'll work on moar icu stuff next
<infinity> davmor2: There's something unsettling about that IRC nick...
<davmor2> infinity: I've asked him to join this channel incase there are critical issues.
<davmor2> stgraber: have you got anyone for testing edubuntu?
<stgraber> davmor2: highvoltage said he'd look into it
<davmor2> stgraber: awesome thanks
<slangasek> Laney: not sure what 'deduplicate' would mean here; the right rule should be "new source package exists, has binaries on this architecture, and none of those binaries depend on the old lib"
<slangasek> if it's doing anything at all, it appears to be doing something else
<davmor2> infinity: and that leave mythbuntu and I've no idea on them :)
 * tgm4883 checks backlog
<tgm4883> davmor2: what do we need to do?
<tgm4883> davmor2: oh, 14.04.3 testing already?
<davmor2> tgm4883: yeap
<tgm4883> davmor2: is release tomororw?
<davmor2> tgm4883: http://iso.qa.ubuntu.com/qatracker/milestones/344/builds
<davmor2> tgm4883: it is
<tgm4883> davmor2: on it
<davmor2> tgm4883: thanks
<davmor2> infinity: the gnome and xubuntu guys are both having issues with zsync is there anything that can be done about it?
<infinity> davmor2: I suppose that depends on what the issue is.
<infinity> davmor2: But I've heard good things about wget.
<davmor2> <octoquad> cdimage.ubuntu.com: Connection timed out
<davmor2> <octoquad> could not read control file from URL http://cdimage.ubuntu.com/ubuntu-gnome/trusty/daily-live/20150805/trusty-desktop-amd64.iso.zsync
<cjwatson> That sounds not terribly related to zsync per se.
<infinity> Yeah, that's more of a network issue.
<infinity> It works when you can connect to it (just tried here).
<infinity> Lemme see if it works if I down the VPN.  Maybe someone's broken something.
<davmor2> infinity: yeap struggling to connect from my server
<infinity> Works here with and without VPN.
<infinity> So, not much I can personally do.
<davmor2> flocculant> davmor2: our cdbuild log has for the last 2 days had "ssh: connect to host goldenapple.canonical.com port 22: Connection timed out"
<infinity> But if they grab some traceroutes and throw them at #canonical-sysadmin, someone might be able to help.
<cjwatson> davmor2: that would just mean that our internal list of cdimage mirrors to trigger is out of date with the ones that are actually current
<cjwatson> it's not going to cause the kind of error shown above
<davmor2> hmmm I can't actually connect to cdimages at the moment
<infinity> davmor2: Which cdimage IP(s) can people not connect to?
<infinity> davmor2: There might be something to escalate here on our end.
<tgm4883> davmor2: do you guys have a list of who to contact for flavors?
<infinity> tgm4883: There's the manifest, which has a couple of contacts for each.
<infinity> http://iso.qa.ubuntu.com/qatracker/series/42/manifest
<infinity> Perhaps davmor2 wasn't aware of that. :)
<infinity> davmor2: ^
<davmor2> infinity: nope jibel normally handles all of this :)
<davmor2> and balloons I guess
<tgm4883> ok cool, I am on there
<davmor2> infinity: oh so you test netboot do you ;)
<infinity> davmor2: I'm "responsible" for it.
<infinity> davmor2: Those are the "who owns it" names, not the "who tests it".
<davmor2> infinity: ah fair enough :)
<infinity> davmor2: And I do test it a fair bit.  Just usually not much on x86, since you guys cover that well.
<davmor2> infinity: awesome I was kind getting concerned about test the arm stuff :)
<bladernr_> has 14.04.3 released yet?  the archives say yes ;-)
<bladernr_> bladernr@klaatu:~/Downloads/atsuya$ cat /etc/os-release |grep VERSION
<bladernr_> VERSION="14.04.3 LTS, Trusty Tahr"
<tgm4883> Mythbuntu testing done
<infinity> bladernr_: Consider it an easter egg.
<infinity> bladernr_: The ISOs are built from the archive, so base-files gets updated before the "official" release happens.
<bladernr_> infinity: that's what I thought, thanks for confirming my suspicions (for a brief moment, I was afraid I had -proposed active)
<davmor2> infinity: http://paste.ubuntu.com/12009049/ and http://paste.ubuntu.com/12009039/ so it looks like something is flakey on the www
<infinity> davmor2: I have no way of knowing which IP that second attempt was.
<infinity> davmor2: This is more likely one cdimage frontend that has an issue, given that you can get to another one just fine and they all live on the same network, I believe.
<davmor2> infinity: that's what I'm assuming
<infinity> Although, now that I say that, I only get one DNS response.  I could have sworn there were a few.
<infinity> Maybe it's a server-side round-robin...
<infinity> Ahh, yes it is.
<infinity> And, indeed, goldenapple looks bust.
<infinity> davmor2: So, the good(?) news is that if they wait a few minutes, they'll get the other IP.  Probably.
<infinity> davmor2: But yeah, reporting to IS to either fix the lame machine or take it out of DNS.
<davmor2> infinity: announced it on #canonical-sysadmin no vanguard though
<infinity> davmor2: I whined in #is-outage@canonical, someone will notice.
<davmor2> infinity: :)
<davmor2> infinity: you've done this before I can tell :)
<slangasek> dpatch!  dieeeee
<slangasek> doko: I see gdal built; should spatialite be given back?
<doko> slangasek, no, postgis needs to be published first (built without gdal as well)
<slangasek> ok
<infinity> davmor2: IS is pulling goldenapple out of DNS rotation to investigate, so things should clear up "soon".
<davmor2> yay
<slangasek> doko: postgis looks published
<doko> slangasek, the one thing I'm not late on is the archive ... https://launchpad.net/ubuntu/+source/spatialite/4.3.0-1build2
<slangasek> hah, ok
<slangasek> sorry I got confused and was looking at gdal instead of spatialite
<doko> yes, after that I have to restore postgis and gdal
<doko> aptitude now built, and libreoffice rebuilt. would be nice if desktop images cold be tried
<doko> slangasek, openimageio has b-d on g++-4.9. can you rebuild that, and rename if necessary?
<infinity> davmor2: Curious.  netboot/arm64 has no defined tests.  Perhaps someone should copy and paste the default one in there.
<infinity> davmor2: Not that it matters deeply, we "release" netboot regardless.
<infinity> (And it's not actually tied to point releases)
<slangasek> doko: do you have a pointer to scripts that will tell me if it needs a rename?
<doko> slangasek, objdump -T | grep cxx11 ...
<slangasek> ok
<doko> once you built the package
<davmor2> infinity: so the tests we run are as follows on netboot, install desktop, install server.  Once you are happy that both install and run pass the tests as that covers them all
<doko> now looking at  openexr
<davmor2> yay finally got vmware player to work \o/
<infinity> davmor2: !x86 should just be the install minimal case (as it is for ppc)
<infinity> davmor2: I'm just inept at manipulating iso tracker testcases, so was suggesting that a QA type (*cough*) might want to make arm64 netboot look like ppc netboot.
<davmor2> infinity: talk to jibel I have no idea how it works and doubt I have access either
<infinity> davmor2: Heh.
<infinity> stgraber: ^ :P
<davmor2> infinity: don't forget I used to work with the iso.tracker before it was the iso.tracker :)
<davmor2> infinity: in those days you wrote out steps in wikipages
<infinity> davmor2: I've intentionally avoided learning how it works, cause I'm afraid I'll forget something useful if I do.
<davmor2> infinity: https://fm-coresites-assets.s3.amazonaws.com/whitelines_new/wp-content/uploads/2014/11/homer-simpson-every-time-i-learn-something-new1.jpg
<infinity> davmor2: Exactly that.
<stgraber> infinity: all the netboot links seem busted, not really feeling like fixing them all now
<stgraber> those that work don't point to -updates, so you're still going to get the wrong thing
<infinity> stgraber: I'm less concerned about the links.  Honestly, if people testing don't know how to find the thing they're testing, I question the quality of their test results too.
<stgraber> infinity: should be all better now
<infinity> stgraber: Probably don't need the desktop ones for armhf/arm64 (at least, not as mandatory)
<infinity> Pretty sure the desktop is broken on at least one of them. :P
<slangasek> doko, xnox: so uhd ftbfs with type conversion errors.  I understand the message but have no idea how to fix.  Anyone with C++ chops want to take a look?  https://launchpad.net/ubuntu/+source/uhd/3.7.3-1ubuntu1/+build/7764394
<slangasek> (nothing changed in the code here, just in the language spec apparently)
<Laney> slangasek: I mean that it's meant to be able to handle partial suites and if it doesn't then it'll be a bug
<slangasek> I thought we pre-merged the packages files for it so it didn't have to handle the partial suites at all
<Laney> until it got upstream support for that, yes
<slangasek> doko: I see spatialite is done building
<doko> yes, will revert my gdal removals ...
<slangasek> cheer
<slangasek> s
<doko> and its 11pm here
<slangasek> doko: do you want me to take care of gdal?
<doko> no, uploading
<slangasek> haha, libcec2->libcev5, oops
<slangasek> guess I should fix that script
<infinity> slangasek: Close enough.
<infinity> Oh neat.  Massive thunderstorm just came out of nowhere.  If I stop talking for a while, I'm probably not dead, but my electricity might be.
<Laney> oho, just seen who the maintainer of lucene++ is
<doko> bah, all the buildds blocked ...
<Laney> juju add-unit buildd
<slangasek> this etherpad is making me angry
<slangasek> having to reconnect between every single edit
<doko> yes, annoying
<cjwatson> Laney: soon :-/
<doko> infinity, could you have a look at https://launchpadlibrarian.net/213711445/buildlog_ubuntu-wily-powerpc.openexr_2.2.0-1ubuntu2_BUILDING.txt.gz ?
<cjwatson> doko: suspect that would be rather more useful if it catted test-suite.log on failure
<cjwatson> dear scalingstack, actually update your images so that I can finally get gem2deb to build, kthx
<Laney> make check VERBOSE=1 # iirc
<cjwatson> yes
<doko> anyway, too tired now, and travelling tomorrow
<cjwatson> well I use VERBOSE=1 dh_auto_test in my packages but same deal
<cjwatson> oh, there we go, at least lgw01 is upating
<cjwatson> *updating
<cjwatson> yep, both
<cjwatson> reset spree!
 * Laney wonders if the new debhelper maintainers would add that
<cjwatson> I guess now would be a bad time for a mass give-back of dep-waits
<cjwatson> maybe tomorrow
<infinity> cjwatson: I have no problems with doing it now.  It's not going to block .3 in any way.  Or are you more concerned about accidentally making the C++ transition worse instead of better?
<cjwatson> I'm more worried about backing up the build queues even worse while people are actually waiting for stuff.
<cjwatson> Kind of a pain if you're trying to push through a multi-layered transition.
<infinity> cjwatson: The only queue currently is arm64.  It'll drain soonish.  I can do a mass give back of -FDC after that.
<cjwatson> -D is the one that bothers me because of the wrongness of 132's dep-wait handling.
<infinity> cjwatson: Wrongness of dep-wait handling implies that F might also be D in disguise, though.
<cjwatson> But I guess some of them probably ended up as failures.
<cjwatson> Yeah.
<infinity> cjwatson: Hence I was just going to do the lot.
<cjwatson> https://launchpad.net/ubuntu/+source/gem2deb/0.20.2/+build/7742800 \o/
<cjwatson> cue something else exploding now that something with build profiles might manage to make it through to wily ...
<infinity> cjwatson: Does your cargo-cult mean we don't need scary SRUs, or do we still need that for other bits of infra?
<cjwatson> We might need it for other bits.
<infinity> cjwatson: They're still on my TODO, but my TODO has been pretty gross.
<cjwatson> I have a suspicion germinate is going to be sad.
<cjwatson> I'll sort it out tomorrow if so.
<infinity> cjwatson: Kay.  I'm more comfy with trusty having the "final" version of the implementation anyway.
<infinity> cjwatson: The half-baked one we shipped is asking for trouble.
<cjwatson> precise is more questionable, but we can put stuff in infra-only PPAs/CAT/blah.
<infinity> For precise infra, I'd prefer backports, yes.
<cjwatson> My cargo-cult plus my changes to Launchpad to use python-debian instead (and the fact that LP uses a python-debian from PyPI rather than the archive) make it less scary.
<infinity> If we cared about precise users and profiles, I'd say the patches that were floated that flat-out ignore profiles would be the better SRUs.
<cjwatson> It's possible we can get away without changing python-apt in precise.
<infinity> I'd really rather not have precise infra at all, but wishes and reality so rarely align.
<cjwatson> Sadly the edict about trusty on metal makes that a long-term project.
<infinity> cjwatson: Well, we're already running a backport of trusty's apt/python-apt on ftpmaster, I assume that can be true of any infra that needs it.
<infinity> cjwatson: So, SRUs to trusty and a re-backport should serve us.
<cjwatson> ftpmaster shouldn't actually need it though.
<infinity> cjwatson: No, but it has a backport was my point. :)
<cjwatson> LP no longer uses those bits of python-apt, and if germinate goes wrong it can be worked around.
<cjwatson> Right, true, though that was safe for ftpmaster because we had a very clear idea of which bits of apt/python-apt it needed.
<infinity> I don't remember why it has a backport.  source cachine?
<cjwatson> Yes.
<infinity> caching*
<cjwatson> Which actually hasn't been SRUed to trusty yet.
<cjwatson> I think.
<infinity> Oh.  That should be fixed.
<infinity> I think we've verified that in the field quite successfully by now. :P
<cjwatson> Every so often I try but get gazumped by a security update or something.
<infinity> gazumped = trumped by a gazelle?
<cjwatson> https://en.wikipedia.org/wiki/Gazumping
<infinity> I refuse to believe this is actually a word.
<infinity> Oh, it's yiddish.  Suddenly, it all makes sense.
<slangasek> infinity: it's only UK english, it doesn't count
<cjwatson> wiktionary thinks it's possibly derived from Hebrew via Yiddish
<cjwatson> Yeah, that
<slangasek> dear Internet I demand that you have created  a "gazumpty dance" parody for my viewing pleasure
<slangasek> Internet I am disappoint
<Daviey> oh dear, rule #34.
<infinity> slangasek: A cross between the humpty dance, the Horah, and possibly hamsterdance?
<slangasek> pretty sure that's not covered by rule #34, but ymmv
<slangasek> infinity: that would work
<infinity> slangasek: I'll get right on it after the point release.  Please register a domain.
<darkxst> infinity, I have not heard of any issues (other than zsync problems)
<infinity> darkxst: Kay.  We're just a bit sparse on test results in the tracker. :)
<infinity> darkxst: Granted, you have until tomorrow to tell me it's all good.  But you probably have until a few hours from now to tell me it's horribly broken so we can fix it. :P
<infinity> utlemming: (Not that I care if you are or aren't on the tracker, but) are you guys on track for a 14.04.3 cloud release tomorrow?
<infinity> utlemming: I realise you "release" every 23 minutes anyway, perhaps we should stop pretending you do point releases. :P
<darkxst> infinity, the previous build should have been mostly complete
<utlemming> infinity: we do informal point releases....just a pointer switch anyway
<utlemming> infinity: but we only pretend because otherwise people ask "where's dot whatever"
<infinity> utlemming: Yup.  Even long time users don't really seem to understand that a "point release" is really just a moment in time in the archive.
<infinity> utlemming: With the exception of installation media, of course, but as you spin your images constantly, that's a bit of a non-issue for you.
<infinity> utlemming: Anyhow, original question, then, do you have things you've tested and will be happy to bless as ".3" tomorrow?
<utlemming> infinity: yes, we do
<darkxst> infinity, but looking, seem i386 testing has been sparse
<infinity> utlemming: Excellent.  Thanks.
<utlemming> infinity: we're good on our end and will have something to call .3
<infinity> utlemming: For bonus points, I fixed that live-build bug you forgot to SRU, so your images should not have a broken initctl/dpkg-whateveritwas anymore. :P
<utlemming> infinity: oh, nice, thank you kindly :)
<infinity> utlemming: Assuming you're using the archive live-build, and not still a fork.  I can't keep track.
<utlemming> infinity: depends on the release. We started using upstream with live-builders for Vivid
<infinity> utlemming: "upstream" meaning Ubuntu, or pulling in a newer Debian version?
<infinity> utlemming: If you need a new version, I wouldn't be at all opposed to you helping to merge it in Ubuntu.  Hint, hint.
<utlemming> infinity: upstream for Ubuntu. For Vivid and later, we use launchpad builders
<utlemming> infinity: hint noted
<infinity> It's one of the ugliest merges, because upstream insists on renaming functions and variables every seven minutes. :/
<infinity> So pretty much none of our patches ever forward-port without excessive alcohol and tears.
<utlemming> infinity: I noticed...its one of the reasons we dropped our fork. I don't think normal excessive alcholo is strong enough for that merge. You need genuine absynthe for that.
<infinity> utlemming: Hallucination might help, I agree.
<darkxst> infinity, quick test of 14.04.3, just booted to a VT
<infinity> darkxst: i386?
<darkxst> (into fresh installed system) gdm was never even started
<darkxst> infinity, amd64
<infinity> darkxst: That's... Curious, given that you had solid tests on the previous image.
<infinity> And nothing really should have changed to break you.
 * infinity grabs a gnome image.
<darkxst> infinity, second boot worked fine
<infinity> darkxst: ...
<infinity> darkxst: Is it possible your computer hates you?
<darkxst> infinity, its Vmware
<infinity> So, yes.
<infinity> darkxst: I have no vmware to test, but I'll spin it up on qemu and see if I can reproduce.  If not, I'm blaming vmware.
<infinity> Oh, hey, I have a spare laptop here, I can even test real hardware.
<infinity> Which is slightly more important to get right.
<darkxst> infinity, vmware is not a buggy pos like vbox
<infinity> darkxst: Heh.  No, but all three of the common virt solutions seem to have their own special quirks.
<infinity> darkxst: Anyhow, I'm grabbing an ISO to see what I can see.
<infinity> My life tonight is nothing but testing, I think.
<infinity> And chicken.  I need to eat all the chickens.
<slangasek> with or without avian flu?
<infinity> slangasek: Not actually picky at this point.  A neighbor is frying chicken, and I'm starving.  The combination of those two truths isn't leading to rational thought.
<slangasek> alrighty then
<infinity> Aaaand, 92% into this download, I realise I'm downloading wily, not trusty.
<infinity> Derp.
<infinity> The important thing is that my mom says I'm smart.
<slangasek> ok how is gdal less installable now than it was two hours ago?
<infinity> slangasek: So, I'm no expert, but I'm going to go with "something changed".
<slangasek> hmm maybe I should dist-upgrade that chroot
<infinity> darkxst: Anything special about your install?  I'm just doing default clicks through on a laptop and on a qemu VM right now.
<darkxst> infinity, no it was just defaults
<infinity> darkxst: qemu version rebooted to gdm first shot.  Still waiting on the real metal install to finish being a slowpoke.
 * infinity realises he has no idea how to use gnome-shell...
<infinity> darkxst: Real laptop install rebooted into gdm too.
<infinity> darkxst: So, either you have a racy bug that sucks to reproduce, a vmware-specific bug, that install just plain failed somehow, or your computer hates you.
<infinity> darkxst: Not sure which explanation is more pleasant.
#ubuntu-release 2015-08-06
<darkxst> infinity, ok, guess its not a huge issue anyway, given live session and 2nd+ boots work fine
<infinity> darkxst: It's not a blocker, I'd say, but it would still be nice to know WTF happened.
<infinity> darkxst: Can you reproduce on a fresh install on the same VM?
<darkxst> infinity, it happened twice
<darkxst> third re-install seems to have booted ok
<darkxst> infinity, so maybe it is something racy, vmware does boot incredibly fast
<infinity> darkxst: If it's racy, just rebooting a dozen times should show it up.  It might be a race between upstart events and jobs or something, though I'd also suspect that's not a regression from 14.04.2 then, but just bad luck. :/
<infinity> darkxst: Bad luck that your system is just the wrong speed to race it, I mean.  Or that some update got 10ms faster or 10ms slower, perturbing the bug that was already there.
<slangasek> ok, what the heck are opencolorio and openimageio that they warrant circular build-deps on each other
<infinity> slangasek: I vaguely recall having to break that loop on every bootstrap.
<slangasek> yeah, I would consider adding a build profile, except that doesn't help for the soname transition problem
<slangasek> and therefore I do not care
<slangasek> in fact I'm inclined to drop the dependency from opencolorio-tools to libopenimageio and not re-add it
<infinity> slangasek: Oh, also, there's a mass retry in progress to see if it unsticks any of the bad failures/dep-waits from previous lp-buildd/sbuild versions.  If any of that gets in your way, feel free to score up C++ stuff (or holler if you don't have the permissions to do so...)
<slangasek> infinity: I was amused to find that in fact, TB seems to confer magic buildd powers
<slangasek> so yeah, I've been rescoring what I need, while ignoring all the new build failure mails for things that failed long ago ;)
<infinity> slangasek: TB might own buildd-admins...
<infinity> slangasek: Indeed it does.
<infinity> And they're a member too.
<infinity> Which might be a mistake.
<infinity> But meh.
<infinity> jackyu: Hey!  Are you guys testing kylin 14.04.3 over the next 8 hours while I sleep? :)
<jackyu> infinity, sure. doing now^...
<infinity> jackyu: We were considering respinning your ISOs for the fix for https://bugs.launchpad.net/ubuntukylin/+bug/1380981 but weren't sure if you'd started testing already, etc.
<ubot93> Error: Could not gather data from Launchpad for bug #1380981 (https://launchpad.net/bugs/1380981). The error has been logged
<infinity> jackyu: If you'd like us to land that before you start, I think cyphermox and I can still find the time before bed.
<infinity> jackyu: Your call.
<jackyu> infinity, we are testing now. But we'd like to retest the new one.
<jackyu> infinity, so, please respin it
<infinity> jackyu: Well, if you don't mind a 1hr (or less) delay to merge this and respin, I'm happy to do it.  I just didn't want to do it without asking first.
<infinity> jackyu: Kay.  Will do.
<jackyu> infinity, yes, in call just now^
<jackyu> infinity, got it, thanks.
<infinity> jackyu: Respinning now.
<infinity> cyphermox: Looks like we're getting the kylin fix after all.
<infinity> If it turns out that the fix for that bug breaks the 20150806 image somehow, if you also test 20150805, we can release the old one, since the only difference is that one bootloader language change.
<infinity> jackyu: ^
<infinity> jackyu: But it's a direct backport of the fix we used for wily, so it should work.
<infinity> jackyu: There's your new builds.
<slangasek> doko: fwiw the answer is that openimageio doesn't build cleanly with g++ 5 because it has code that monkeys with the internals of std::string
<doko> nice
<slangasek> http://paste.ubuntu.com/12011886/
<slangasek> can be disabled via ifdef, but I'll check for an upstream fix first
<slangasek> http://paste.ubuntu.com/12011904/
<slangasek> so... sorta?
<doko> looks ok
<doko> Laney, slangasek: openimageio now fails with opencv mess (Laney, could you fix?)
<slangasek> oh seriously?  I *just* succeeded in building it locally
<slangasek> doko: and no, Laney has said he's off today
<doko> I'll have a look, have to prepare for travel too
<slangasek> I can take a brief look before I turn into a pumpkin
<slangasek> what does openimageio block?
<slangasek> half of opencv depends on new package names and half on old package names
<doko> opencolorio  and blender
<doko> yes, that's what I saw as well
<slangasek> opencolorio and blender, which is only seeded in ubuntustudio (which doesn't do non-LTS releases), shouldn't there be some main libraries that are higher priority?
<doko> I was looking at failing autopkg tests for gcc-5. fine if you override these ...
<slangasek> yes, we can probably override those.  I'm more concerned about getting the rebuilds done for the stacks of package name changes in main
<doko> then probably a test rebuild of main for amd64 only would be good at this point
<slangasek> uploading opencv
<slangasek> doko: opencv has a self-build-dep; maybe can be worked around be removing the broken binaries from wily-proposed
 * slangasek gets some sleep
<zhhuabj_> bdmurray, hi
<jackyu> infinity, Ubuntu Kylin is ready:).
<sil2100> slangasek, infinity, doko: we need the wily touch seeds updated
<sil2100> Hello release team! Does anyone know why in the ubuntu-touch-seeds in the sdk-libs-dev we actually hard-dep on a specific boost version?
<ogra_> sil2100, the seed history (and bzr blame) can tell you ... it seems ot have been added with the whole block surrounding it for scope stuff
<ogra_> sil2100, looks like it comes from pete-woods ... best to ask him
<pete-woods> ogra_, sil2100: it was for scopes, yes. there's no specific dependency on a specific version of boost, so if there's a meta/virtual package that should be there instead, please do change it
<pete-woods> my package-fu is weak
<ogra_> well, not sure how sane that is ... buut you could indeed just seed libboost-dev instead ... thouogh then you will likely not catch ABI incompatibilities
<pete-woods> sure, please let people who actually know about packaging make the call. I just added the version that the pure c++ scopes were using
<ogra_> well, "packaging" is kind of moot, since we talk about frameworks here, this is all kind of special anyway
<ogra_> but we dont have any other versioned deps in the framework seed so it could work i guess
<sil2100> That's what I wanted to propose
<sil2100> Simply depping in the seed for libboost-dev, then we would unblock some things and avoid breakage when the main boost libraries change
<ogra_> sil2100, yeah, looking at the rest of the seed that seems sane to me
<sil2100> Ok, proposing
<sil2100> ogra_, slangasek: https://code.launchpad.net/~sil2100/ubuntu-seeds/ubuntu-touch-remove-boost-hard-version-dep/+merge/267177
<sil2100> ogra_, slangasek: this should at least unblock the qtcreator-plugin-ubuntu parts that are blocked in -proposed
<davmor2> infinity, cyphermox: So I've tested now most of what I can on server/desktop/netboot the images look good, I've also used the dell install to drop the xps back to the default 14.04.2 release that was on the it and upgraded and that is fine too \o/
<cyphermox> davmor2: great
 * cyphermox zsyncs kylin again to test the debian-cd fix
<slangasek> sil2100: follow-up comment posted to the merge
<sil2100> slangasek: thanks, looking!
<zhhuabj> arges, hi, around
<cyphermox> infinity: if you hadn't had an ok for it yet, I verified that kylin booting in UEFI now properly defaults to zh_CN
<infinity> cyphermox: They marked the images ready last night, so they seem to agree.
<cyphermox> yeah
<davmor2> infinity: anything else you need from me?
<arges> zhhuabj: hi
<infinity> davmor2: studio could use some testing.  Not entirely sure if maybe zequence forgot when the point release was and took a vacation. :P
<infinity> davmor2: But I'd hate to see them miss the point release if some quick smoke tests show the images are okay.
<infinity> Riddell: kubuntu testing seems a bit sparse, do you have more on the way, or is it "good enough"?
<Riddell> let me ask testers
<sil2100> slangasek: ok, confirmed and your proposition makes sense, updated the MR
<zhhuabj> arges, hi chris, I have a patch need to SRU, could you help me ? https://bugs.launchpad.net/ubuntu/+source/mysql-5.5/+bug/1273462
<ubot93> Launchpad bug 1273462 in lsb (Ubuntu Trusty) "Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists" [High,In progress]
<arges> zhhuabj: i'll take a look in a bit
<cjwatson> infinity: aha, that germinate change for build profiles, turns out I already did it a month or two back and deployed it to publisher machines
<cjwatson> infinity: but not to nusakan, hence recent failures, so doing that now
<cjwatson> Well, now-ish, need an RT first for git
<infinity> cjwatson: Indeed, I remember you doing that.  When you talked about germinate and profiles yesterday, I assumed you'd found a new bug.
<cjwatson> infinity: I'm just old.
<infinity> cjwatson: Join the club.
<infinity> cjwatson: Also, the buildd queues are clearing/cleared nicely, if you wanted to check if your new dep-wait parser is behaving any better.
<cjwatson> infinity: I haven't done any systematic checks; the spot checks I did look better
<davmor2> infinity: amd64 done
<davmor2> infinity: i386 downloading
<arges> zhhuabj: hey, i'm looking at this a bit more closely, I think having others review it too will help. I'll update the bug with my comments.
<cjwatson> ok, germinate upgraded on nusakan
<anon212230> Just wondering, are there any rules as to age when you are contributing to Ubuntu? I am a teen and I would like to do some QA test cases, but I don't know if I could...
<anon212230> Can anybody confirm?
<wxl> anon212230: ultimately a question for ubuntu-quality but no there are no such rules. have fun and thanks in advance :)
<anon212230> Thanks
<wxl> are all the seeds for all flavors under version control in one particular place?
<arges> zhhuabj: commented on bug 1273462, i'm not comfortable sponsoring until a proper regression potential analysis is done.
<ubot93> bug 1273462 in lsb (Ubuntu Trusty) "Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists" [High,In progress] https://launchpad.net/bugs/1273462
<cjwatson> wxl: https://code.launchpad.net/ubuntu-seeds
<wxl> thanks cjwatson
<wxl> argh somewhere in the last 3 revisions infinity did, lubuntu trusty got oversized https://code.launchpad.net/~lubuntu-dev/ubuntu-seeds/lubuntu.trusty
<wxl> oh no wait
<wxl> the last one
<wxl> just changing from lts-utopic to lts-vivid
<wxl> not sure why that would make that much of a difference
<apw> wxl, how much bigger did it get, teh kernel tends to grow quite quickly
<wxl> yeah well could have been the kernel then as that did change
<wxl> let me figure that out apw
<wxl> apw: it's not much. 13M, but it's enough to push it over.
<zequence> infinity: Yes, sorry I had missed that
<zequence> Let's see
<zequence> I'm going to mark ready.
<zequence> Thanks apw and davmor2 for testing :)
<davmor2> infinity: done
<infinity> wxl: Not sure there's much we can do about that on release day, sadly.
<wxl> yeah well c'est la vie infinity. i don't blame you anyways.
<infinity> wxl: But, much like my argument about HWE alternates being useless, people who need CD-sized ISOs probably aren't the same people who *need* HWE, so they don't need 14.04.{2,3} install media.
<infinity> wxl: So, I'd say test and mark ready, and if we can shrink for .4, yay.  If we can't, it's not world-ending to tell people with CD drives to use 14.04/14.04.1
<wxl> thanks infinity
<infinity> zequence: It's a good thing you have friends. :)
<infinity> Bah, how did no one fix https://bugs.launchpad.net/ubuntu/+source/tex-common/+bug/1236951 in trusty yet?  That's a bit embarrassing.
<ubot93> Launchpad bug 1236951 in tex-common (Ubuntu Trusty) "package tex-common 4.04 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 1" [High,Confirmed]
<apw> infinity, perhaps because it is marked for .2 and once a thing is in the past it is gone in the LP reports
<infinity> apw: Oh, that certainly wouldn't help its case.
<infinity> apw: I just noticed cause it's (still) in the release notes.
 * infinity retargets.
<infinity> stgraber: Are you happy to mark Edubuntu ready based on current testing?
<infinity> superm1 / tgm4883: Ditto for you and Myth.
<tgm4883> infinity: there weren't any rebuilds since I tested yesterday?
<infinity> tgm4883: Nope.
<tgm4883> infinity: then we're good to go
<infinity> darkxst: You cool with marking GNOME ready?
<infinity> darkxst: It passed all my tests, but my bar is low for flavours, I just want them to boot/install/reboot and not set my laptop on fire. :P
<infinity> (The no fire bit is important)
<stgraber> infinity: yep
<stgraber> infinity: I was hoping highvoltage would do it, but I can certainly do it myself now
<infinity> stgraber: A little late now, but all the server links seemed to be lacking /trusty/
<infinity> Oh, hello queuebot.
<stgraber> :)
<infinity> darkxst: *nudge*
<infinity> ScottK: You around to make the call on Kubuntu 14.04.3?
<infinity> darkxst: Failing a response, I'm going to mark GNOME ready in a few minutes, since I tested it myself. :)
<infinity> Riddell: Did anything come of your asking testers things?
<infinity> Riddell: Okay, I'm going to start pushing images (including yours) anyway.  If you come back and tell me "NO, STAHP, OURS SUCKS" before I release, I'll delete yours for you. :P
<davmor2> infinity: \o/
<davmor2> infinity: is that it we are done with iso's?
<infinity> davmor2: Unless you'd really like to respin and retest them all before lunch.
<davmor2> infinity: wow trippy I can go back in time Lunch was 6 hours ago already ;)
<infinity> davmor2: One can never have too many lunches.
<davmor2> infinity: jibel is more eloquent in his mails but I'm not jibel so people got thanked, heart felt at that too :)
<infinity> davmor2: You could have just copy and pasted one of his previous mails, and subbed in the right values for the testers. :P
<infinity> davmor2: Oh, you didn't do his usual "list all the testers" thing.
<davmor2> infinity: no idea where he gets all the info from, I'm assuming admin
<infinity> davmor2: I'm guessing there's a fancy API call to the ISO tracker.  Or maybe just a magic link somewhere.
<infinity> stgraber: Where does jibel scrape the milestone tester list from?
<davmor2> got it
 * infinity runs to buy more caffeine.
<davmor2> I'm going night all
<stgraber> infinity: probably http://iso.qa.ubuntu.com/qatracker/reports/testers
<flocculant> now that's all done and dusted - wily daily for Xubuntu is still stuck on yesterday, must be something awry - usually builds ~10:00
<infinity> flocculant: I have mirror syncing disabled on cdimage right now while I prep the point release, you might just be stuck in that.
<flocculant> mmk - was that disabled hours 10 hours ago?
<infinity> flocculant: Oh.  No.  Your issue is something else, then. :P
<flocculant> :)
<infinity> flocculant: Ask after the point release is out.
<infinity> No can multitask right now.
<flocculant> okey doke - I'll try and remember tomorrow
<infinity> flocculant: Oh.
<infinity> flocculant: http://people.canonical.com/~ubuntu-archive/cd-build-logs/xubuntu/wily/daily-live-20150806.log
<infinity> flocculant: Was a germinate bug.  Colin fixed that, tomorrow will be fine.
<flocculant> infinity: ok thanks - I did see the logs, but ignored it while I was looking at trusty
<slangasek> oh, debian/README.symbols, that's not actually a symbols file at all is it
<infinity> slangasek: gcc -o foo foo.c -lREADME ?
<slangasek> -fno-strict-README
<infinity> FUNROLLREADME
<slangasek> which is funny because usually you have to roll the readme the other way
<kirkland> can someone please delete this upload to vivid ^
<infinity> kirkland: I can delete petname from all series', if you like.
<infinity> utlemming: Feel free to pull the trigger on the cloud 14.04.3 bits.
<utlemming> infinity: ack, doing so now
<slangasek> it seems arm64 is the long pole in the tent for rebuilds.  is this the actual capacity we have right now and I'm noticing it because we're throwing a lot more than usual at the builders, or are there any problems currently affecting arm64?
<cjwatson> slangasek: the former IMO
<cjwatson> I mean I haven't measured but it fits my instinct
<cjwatson> it's a particularly long pole due to a mass give-back, and there may well have been more failures to give back in the first place on arm64 ...
<slangasek> right
<cjwatson> x86 and arm have lots more parallelism obviously, and the power builders are just plain faster
<ScottK> infinity: ^^^
<cjwatson> slangasek: hopefully obviously, the answer will be scalingstack, I just wish it had been ready before this transition
<infinity> I wish it had been ready a year ago, but wishes never work out.
<infinity> Those poor arm64 builders do alright, given what we throw at them, but the capacity certainly has scaling issues.
<infinity> And ppc64el would be done if one hadn't crashed overnight and another gotten stuck on a hung build for a day.  Oh well.
<cjwatson> Oh, I didn't notice the hung build.
<infinity> cjwatson: Yeah, that same "kill sucks when running in chroot=sudo mode" bug.  Oh well.
<infinity> cjwatson: I'm all for investigating leveraging schroot at some point, so long as we don't derp it up.
<infinity> THough, there must be a way to make chroot=sudo DTRT too.
<cjwatson> Yeah.  I feel like I've spent more than enough time on buildd recently though ...
<infinity> cjwatson: It's hardly critical.  It only hangs up once in a while.  Just, of course, happens on every give-back. :)
<infinity> cjwatson: With the move to scalingstack, at least it won't kill 25% of the capacity when it happens.
<infinity> In fact, with decent overcommit, it would, in theory, kill 0%, or close enough to it.
<cjwatson> manage-builders tells us about stuff that's hung, eventually, but its lower threshold is a day.
<infinity> cjwatson: Yeah, and a day is probably a fine threshold for scalingstack, cause losing a little VM slice for a day is meh.
<infinity> cjwatson: For the 4 ppc64el or 5 arm64 builders, it's a bit more dire, but I tend to notice eventually. :P
<cjwatson> slangasek: FYI the haskell transition will be migratable by tomorrow, but it's all stuck together with icu which is of course blocked on gcc-5.
<cjwatson> Hopefully Debian won't switch to ghc 7.10 before gcc-5 is done ...
<slangasek> that... seems preferable
<infinity> cjwatson: I'm guessing the Debian release team might stab someone if they upload ghc 7.10
<cjwatson> infinity: that's the sense I've got, yes
<infinity> utlemming: cloud-images is still missing the http://cloud-images.ubuntu.com/releases/14.04.3/release/ path that release notes typically expect.  Is that me being impatient, or did your end break?
<utlemming> infinity: no, that's me
 * utlemming fixes
<utlemming> infinity: done, try again
<infinity> utlemming: Looks like it has some things now.
<infinity> utlemming: I assume the filenames are 14.04 (rather than 14.04.3) because you don't actually do point releases, it's just a symlink to the latest rolling update?
<utlemming> infinity: correct
<infinity> Alright.  Shiny.
<utlemming> infinity: I learned my lesson about making point releases in the file names with 12.04.1. Apparently automated things break when you change file names.
<infinity> utlemming: Yeah.  Servery people do so love stable interfaces to automate against.  I guess cloudy people are the same. :P
<infinity> It's really the only reason d-i has a current/ symlink too, IMO.
<infinity> Cause any human can sort out "bigger number is newer", computers are a bit dumber.
<infinity> Especially computers programmed by humans.
<utlemming> infinity: until the singularity
<infinity> utlemming: I have every confidence that computers programmed by computers will be even more stupid.
<utlemming> infinity: we can only hope
<infinity> utlemming: It'll be some generations, anyway.  AI is one thing, messy creative thought is another.
<infinity> utlemming: And, honestly, if I were a computer programming another computer, I'd consider creativity a flaw, not a goal.  Human brains are gross and irrational.
<slangasek> infinity: so you're saying that when computers start to program other computers, they'll be writing in javascript?
<infinity> slangasek: wat.
<slangasek> infinity: none of that messy creativity
<slangasek> just cut'n'paste from one pastebin or stackexchange to another until it works ;)
<infinity> slangasek: No, I meant wat: https://www.destroyallsoftware.com/talks/wat
<slangasek> oh
<infinity> .. which doesn't load anymore.
<slangasek> sorry, that has become so ingrained in my vocabulary that I forgot the reference ;)
<infinity> The internet has failed me.
<infinity> slangasek: It was part of my Internet vocabulary long before that talk, but the talk definitely made me associate it with javascript. :P
<infinity> WHY, FINGERS, WHY?!
<infinity> WHY DO YOU INSIST ON MAILING THINGS TO UBUNTU-ANNOUNCE@LISTS.DEBIAN.ORG?
<slangasek> what is pkgkde_symbolshelper?
<infinity> slangasek: The only way to deal with C++ symbols files without clawing your eyes out.
<slangasek> does it deal with them by ignoring that they have changed?
<infinity> No, it's just a tool for yanking dpkg-gensymbols output from build logs and tooling it into symbols files.
<infinity> What you choose to do with it after that is entirely your fault (ie: ignoring ABI breaks)
<slangasek> because libkolabxml1 sure has a symbols file that lists references to std::basic_string, and it's not FTBFS
<slangasek> and I don't see anything in the build log that even tells me that pkgkde_symbolshelper is *doing* anything
<slangasek> and debian/rules is empty of hatefulness
<slangasek> ... and the symbols file isn't copied into the binary package
<infinity> Oh, right, there's a buildtime component to that thing, I always forget that.  I have no idea what that does, and don't use it.
<infinity> I only use the build log mangly symbol file updatey bits.
<slangasek> what it does is add a path override to dpkg-gensymbols
<slangasek> and then... nothing?  I don't know
<slangasek> so I think pkgkde_symbolshelper's dpkg-gensymbols implementation is currently broken
* infinity changed the topic of #ubuntu-release to: Released: Trusty 14.04.3, Vivid 15.04, Wily Alpha 2 | Archive: wily open | Wily Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis
<robru> xnox: jamespage: anybody working on this ceph failure? https://launchpad.net/ubuntu/+source/ceph/0.94.2-0ubuntu2
<bdmurray> infinity: Were you going to use your new superpowers for metarelease or shall increment the number?
<infinity> bdmurray: Go ahead.  You still need to larn me what I do on the actual system after updating bzr.
<infinity> bdmurray: And I think I might be too tired to actually care right now.
<bdmurray> infinity: 'kay
<infinity> cjwatson: Can you abuse UbuntuHashes for me?  I'm not sure if I have access, or if SSO trying for 5 minutes to log me in means "no".
<cjwatson> infinity: Think so.  Let me remember my routine for making it less painful to do
<infinity> cjwatson: Oh wow.  It finally logged me in after, quite literally, 5 minutes.
<infinity> cjwatson: And no, I don't have edit permissions. :P
<cjwatson> cjwatson@nusakan:~/cdimage/www$ find -L simple full -name MD5SUMS 2>/dev/null | grep 14.04.3 | xargs cat | grep 14.04.3 | sed 's/\(.*\) \*\(.*\)/|| \1 || \2 ||/'
<cjwatson> plus the itsalltext firefox extension
<cjwatson> and a bit of manual rearranging
<cjwatson> I'm sure I had something neater last time, but this'll do
<cjwatson> and wubi.exe but anyway
<cjwatson> infinity: No Lubuntu for powerpc?  There was one for .2 apparently
<wxl> cjwatson: nopey nope nope
<cjwatson> ok
<infinity> cjwatson: Huh.  So there was.  And no there isn't.
<cjwatson> infinity: done
<infinity> cjwatson: Ta.
<bdmurray> infinity: it's safe to release SRUs for trusty now?
<infinity> bdmurray: Oh, yes.  Go nuts.
<darkxst> infinity, your not likely to get answers from me at 4am in the morning ;) but yes the images were ready!
<infinity> darkxst: Well, good.  Cause they're released now. :)
<darkxst> infinity, yes I saw!
#ubuntu-release 2015-08-07
<slangasek> oh look, metview no longer FTBFS because of c++ problems, it has moved on to being FTBFS because of fortran problems
<slangasek> that's progress, I think?
<slangasek> someone understand why this haskelly thing is FTBFS on powerpc?  I don't *think* powerpc buildds suddenly lost the as command: https://launchpad.net/ubuntu/+source/mediawiki2latex/7.20-1build1/+build/7768918
<slangasek> wow, ok, d-shlibs is even crazier than I last remembered
<slangasek> in case anyone else needs to know: the way you make d-shlibs behave is by passing d-shlibmove a --v5 argument
<slangasek> (because obviously the thing to do each time there's a C++ ABI transition is to make your helper tool grow another option)
<michi> robru: ping
<michi> sil2100: Could you lend a hand with this one? https://requests.ci-train.ubuntu.com/static/dashboard.html#?q=ubuntu%2Flanding-041
<michi> No changes to code. I had the autopkg test dependencies wrong and would like the test to pass.
<sil2100> michi: looks like a sane change not requiring QA - you want that released now?
<michi> Yes, if you would please. I will have to top-approve first though?
<michi> The package isnât going to make it until the autopkg test passes.
<michi> I shouldnât have added an autopkg test in the first place, and everything would fine. Serves me rightâ¦ ;)
<sil2100> Top approve it and change the status to 'Publish without QA'
<sil2100> :)
<sil2100> michi: 'Publish without QA' means 'I tested the package that didn't need QA and it's ready for release'
<michi> Working on it. Canât find the bloody MR nowâ¦
<michi> Oh, christ...
<michi> I siloâd the MR to merge into devel not the one to merge into trunk :(
<michi> My apologies for wasting your time.
<sil2100> michi: no worries, I just noticed that too
<michi> Will be back in an hour or soâ¦
<sil2100> Rebuild, check if it's cool again and set the status to 'Publish without QA' - we'll notice it then and release
<michi> sil2100: Thanks for that! Iâts building now.
<michi> Iâll ping you when itâs done.
<michi> sil2100: I think we should be good to go now: https://requests.ci-train.ubuntu.com/static/dashboard.html#?q=ubuntu%2Flanding-047
<sil2100> michi: did you switch the status to Publish without QA?
<michi> I believe I did. Checking...
<michi> Ah, no.
<michi> I set it to âNo QA needed".
<michi> How do I change it now?
<michi> sil2100: Ah, worked it outâ¦ âEdit..."
<michi> Just changed it.
<sil2100> o/
<michi> sil2100: :(  From queuebot: Silos: ubuntu/landing-047 (michi) Can't publish: Packaging changes need manual ACKing. (persistent-cache-cpp)
<sil2100> michi: reviewing and publishing
<michi> Ah, sweet, thanks!
<sil2100> (it's a message for us, not for you, so don't worry when you see this)
<michi> OK, I had no idea. Still learning the ropes...
<michi> Whatâs the âsilo dirtyâ about?
<michi> Ah, thatâs just noice.
<michi> Those are two silos I abandoned a few hours ago.
<michi> Three, actually.
<michi> sil2100: Whohoo! \o/
<michi> queuebot: Silos: ubuntu/landing-047 (michi) Migration: persistent-cache-cpp is in the Proposed pocket. (persistent-cache-cpp)
<michi> Thanks for your help!
<sil2100> Np! A dirty silo means that it needs to be rebuilt as something landed for the project you have in the silo
<sil2100> michi: so the project in the silo needs to be rebuilt to include the changes from the archive
<michi> Aha.
<sil2100> michi: you want the two other silos abandoned?
<michi> So, I just hit rebuild?
<michi> 30, 32, and 41 are rubbish.
<michi> Trash them, please.
<michi> So, do I need to rebuild 47?
<michi> Doesnât look like it.
<michi> Dashboard says âin the proposed pocketâ. So I assume that means things are fine.
<sil2100> https://code.launchpad.net/~sil2100/ubuntu-seeds/ubuntu-touch.wily-add-iw/+merge/267370 <- could anyone review this seed-addition soon? It's a simple and small addition though
<slangasek> qt-gstreamer is on the list of packages with symbols changes for g++5, and is hit by the qt4+boost issue.  package has non-trivial reverse-dependencies (both qt4 and qt5 binaries are seeded).  any kubuntuers able to take a look at this?  Riddell, ScottK?
<slangasek> fwiw if I disable the qt4 build it still ftbfs by failing to find /usr/lib/x86_64-linux-gnu/gstreamer-1.0/include/gst/gstconfig.h, so there's some failure to properly pkgconfig here as well
<ScottK> slangasek: I don't have time to work on it, but I did pass it on to #kubuntu-devel to see if someone could.
<slangasek> ScottK: cheers
<slangasek> ScottK: if someone picks it up, feel free to point them at me for braindump
<ScottK> Sure thing.
<robru> anybody know anything about libgconfmm-2.6-dev and libglademm-2.4-dev? do they need an ABI transition for g++5?
<slangasek> Laney: ^^ I know you're off, but as you're connected maybe you have a quick answer
<Laney> slangasek: which ^^?
<Laney> robru or you?
<robru> Laney: oh I assumed he was talking about gconf and glade
<Laney> well, I don't know is the answer to you, sorry :(
<robru> Laney: I'm working with slangasek on this (as he's training me) so we're sort of the same person as far as this question is concerned.
<Laney> robert_ancell might know slightly more about the gnome-mm stack
<robru> Laney: alright
<Laney> otherwise, -> monday, leave a note in the pad or something
<robru> Laney: ok thanks
<slangasek> ah yes, robert_ancell; now I found the mail thread I was looking for
<slangasek> something about reverting to glibmm 2.44
<slangasek> utlemming: open-vm-tools in wily-proposed has new build-dependencies that haven't gone through MIR; could you please take care of this?  It's a blocker for the icu transition (and from there to gcc-5)
<utlemming> slangasek: ack, it was on my todo...I'll get the MIR filed shortly
<slangasek> utlemming: thanks
<slangasek> Reverse-Depends: mediawiki2latexguipyqt
<slangasek> I see your latexguipyqt and raise you a huitzilopochtli
<infinity> slangasek: At least I can unpack what mediawiki2latexguipyqt means.  I'm pretty sure you made the second one up.
<slangasek> infinity: I call
<slangasek> used in a sentence: I was really miffed when the Aztec god Huitzilopochtli gazumped that nice split-level in the shire
<infinity> *laugh*
<infinity> barry: Is there some discussion I'm missing around this copy-package MP?
<infinity> barry: Why would I want copy-package to not fail on missing source?
<slangasek> barry's using copy-package a bit for python3.5 ppa test rebuilds
<slangasek> he appears to have opinions about its behavior ;)
<barry> yep :)
<slangasek> I have a countervailing opinion
<slangasek> the current behavior should remain the default
<barry> i have a wrapper around copy-package which tries to first copy from -proposed.  the wrapper has to know whether that fails or not so it can fall back to copying from wily in that case
<barry> if it doesn't fail hard (exit !0) then the wrapper doesn't know
<infinity> I like to know when I typo a package name.
<infinity> barry: I'm not against proper error handling, I'm disputing the default.
<barry> *but* if you're copying a bunch of them, you probably don't want it to fail hard on the first one
<barry> infinity: doesn't matter much to me if we switch the sense
<infinity> barry: --fail-immediately might want to be --skip-missing to invert the default behaviour.
<barry> infinity: i can do that
<barry> infinity: i'll ping you when i've updated the mp
<barry> infinity: oh right, one thing about that.  if find_latest_published_source() fails currently it just tracebacks, so i think it's still better to catch the exception and return False in the default case.  then if --skip-missing is given, it'll print the error and continue
<infinity> barry: Yeahp, agreed.  See above, re: not against proper error handling. :)
<barry> infinity: :)
<infinity> barry: My #1 beef with python programmers is ignoring error handling because "hey, tracebacks are totally user friendly".
 * barry is a vegetarian and has no beef
<infinity> Or you have more beef, because you don't eat it?
<barry> infinity: the new mp taste like chicken
<utlemming> slangasek: MIR filed via Bug #1482777
<ubot93> bug 1482777 in open-vm-tools (Ubuntu) "[MIR] open-vm-tools 9.10.2 build dependencies: xml-security-c and xerces-c" [Undecided,New] https://launchpad.net/bugs/1482777
<slangasek> utlemming: cheers
<infinity> barry: I see no new MP.
<barry> infinity: i just updated the existing one
<barry> infinity: https://code.launchpad.net/~barry/ubuntu-archive-tools/exit-status/+merge/267385
<infinity> Hrmph.  You'd think I would have gotten email about that.
<barry> of course not, because launchpad
<infinity> barry: Shouldn't "print(error)" be outside the if block?
<infinity> barry: Seems weird to yell at me when succeeding, but fail silently.
<barry> infinity: yeah, that probably makes sense
<barry> infinity: updated
<utlemming> infinity, slangasek: so xe-guest-utilities has sat for a few weeks awaiting to be de-newed. Any chance that could be looked at?
<infinity> barry: Taking it for a test-drive.
<slangasek> utlemming: hmm.  didn't I sponsor that upload?  should probably have a different reviewer
<infinity> barry: Merged.
<infinity> slangasek: Yeah, I told him I'd review it after the point release was out.  Will I hate myself for saying that?
<utlemming> infinity: invariably
<slangasek> heh
<doko> whoever accepted uhd, please fix the arm64 ftbfs
<doko> slangasek, gfortran transition started, however some packages already migrated to wily, and are broken
<doko> your metview now builds again with some effort
<doko> afk now again
<slangasek> doko: I hardly think accepting a package into the archive puts the archive admin on the hook for fixing the remaining FTBFS... :)
<slangasek> doko: metview> glad to hear it, thanks
<infinity> doko: I tend to not bin-new until all 6 arches are built to avoid potential transition skew, which I suspect is doko's complaint.
<infinity> Err, slangasek ^
<slangasek> what transition skew would there be?
<infinity> Oh, no idea in this case.  Didn't look.
<slangasek> you mean if somebody started firing off revdep rebuilds before the other archs were done?
<infinity> But yes, that.
<infinity> Sweet, arm64 is trying to build armv7 ASM.
<infinity> That'll end well.
<slangasek> right; at the moment there's a massive pile of stuff that needs doing and I'm pretty much just doing whichever bit I have in front of me at the moment
<slangasek> which includes newing bits of libs that I know unblock parts of the stack
 * infinity side-eyes launchpad's 76.6MB debdiff from the old version.
<slangasek> does that mean you're looking at uhd?
<barry> infinity: awesome, thanks
<infinity> slangasek: It means I looked that far. :P
<infinity> slangasek: Looking deeper.
<infinity> That's the relevant diff: http://paste.ubuntu.com/12025342/
<infinity> A bit less then 76MB
<infinity> s/then/than/
<infinity> n$ readelf --dyn-syms armhf/usr/lib/arm-linux-gnueabihf/libuhd.so.003 | wc -l
<infinity> 1666
<infinity> That's got to win some sort of award.
<infinity> slangasek: Okay, uhd breakage hacked around in my PPA, and confirmed that the hack didn't alter any public symbols on armhf, so calling it good.  Will binary copy to -proposed shortly.
<slangasek> infinity: spiff
#ubuntu-release 2015-08-08
<doko> slangasek, anything specific to look at today?
<slangasek> doko: well, ldc ftbfs because llvm3.5 uses the old abi, if you want to look at that
<doko> ok
<slangasek> ^^ once cauchy is published, calligra can be retried
<doko> bad network here, will head over to the conference place
<doko> slangasek, was timblserver from experimental a good idea? changes the version number in the -dev package and requires sourceful changes to the rdepends
<doko> hmm, looks like we need some ocaml rebuilds too ...  apt-get install frama-c-base  fails
<slangasek> do we get a tzdata update for North Korea? :)
<slangasek> /Â«PKGBUILDDIRÂ»/gen/asm-x86.h:225:5: error: narrowing conversion of '-1' from 'int' to 'char' inside { } [-Wnarrowing]
<slangasek> yes, that's a reasonable error message to see in an armhf build log
<slangasek> desktop images currently not buildable against the stack in -proposed
<slangasek> triggering libcolumbus rebuilds for the above
<infinity> slangasek: NK tzdata?  Hrm?
 * infinity reads the tzdata list.
<infinity> slangasek: So, to answer your question, yes, it looks like Paul will be pushing a new tzdata upstream ASAP.
<infinity> slangasek: I'm somewhat curious, personally, about the intersection of people in NK who have a computer, run Ubuntu, and care about the timezone, but I'll package it up when it lands, just in case. :P
<slangasek> infinity: that's good, we wouldn't want Kim Jong-Un to hire an astrologer to sue all Linux for crimes against the state
<slangasek> TZ=Asia/Crazytown date
<infinity> slangasek: I don't think that's what astrologers do...
<slangasek> infinity: it was an astrologer that sent the previous C&D against tzdata, wasn't it?
<infinity> slangasek: Also, I'm finding it harder and harder to criticize Kim Jong-Un, the more Canada's PM behaves just like him.  Look after your own house first, and all that.
<slangasek> heh
<infinity> slangasek: I, uhm, completely missed this C&D...
<slangasek> orly
<infinity> slangasek: All I see it the usual "news reports crazy timezone changes, here are some patches" discussions.
<slangasek> it was big news for two days a couple years ago
<slangasek> then the astrology software company in question learned not to get too big for its britches
<infinity> Oh.  That's sounding familiar.
<infinity> I thought you meant recently, in relation to Korea.  I'm not awake yet.
<infinity> tzdata commits are a fascinating history lesson.
<infinity> +# The term "Summer Time" was introduced by Herbert Samuel, Home Secretary; see:
<infinity> +# Viscount Samuel. Leisure in a Democracy. Cambridge University Press
<infinity> +# ISBN 978-1-107-49471-8 (1949, reissued 2015), p 8.
#ubuntu-release 2015-08-09
<slangasek> infinity: so, livecd-rootfs creates images using the tasks?
<slangasek> that seems to make it somewhat problematic to try to build a test image from wily-proposed, since the old libraries are all still available in wily with the Task header
<ianorlin> although what about other flavors seeding language packs that don't want the video ?
<slangasek> (I'm open to suggestions for how to work around this so we can build a test image before copying to wily)
<slangasek> ianorlin: is that a response to me?
<ianorlin> yes at least if I understand correctly
<slangasek> sorry, I don't see what your comment about language packs and video has to do with tasks and proposed
<ianorlin> nevermind I was offtopic and thinking of something else oops
<infinity> slangasek: We can put a uses-metapackages version of livecd-rootfs in a PPA, and build the livefses in same PPA.
<infinity> slangasek: Honestly, I've been considering switching back to all-meta-all-the-time anyway, since we have to switch from tasks to meta for LTS point releases, which is painful if no one's tested installing with metas.
<infinity> slangasek: It would also fix some of the "libraries never autoremove on SOVER bump" issues that installing with tasks can cause.
<ogra_> oh, the transition has reached the desktop image
 * ogra_ notices a pile of builf failure mails 
<ogra_> *build
<doko> ogra_, you can upgrade to the wily-proposed desktop
<doko> so what does fail?
<bluesabre> is there a new ubiquity release planned before b1? there's a few new commits since the last release 2 months ago :)
<slangasek> infinity: ah... in fact I though there was a grand plan to make the latest version of livecd-rootfs install the same way as for point releases, didn't realize that hadn't happened yet.  Could we do that now?
<infinity> slangasek: We can try.  The fundamental problem (and the reason I haven't done it) is that tasks make better decisions about alternate deps.
<infinity> slangasek: See the *_HINTS variables in the trusty version to see what I mean.  Tasks are explicit in the exact package set you want, metapackages don't do so well at that.
<slangasek> ^^ please don't accept qt-gstreamer, I've just noticed it's an unnecessary change and am backing this one out
<slangasek> well, this one is special.  "Encountered a section with no Package: header"? https://launchpad.net/ubuntu/+source/qt-gstreamer/1.2.0-2ubuntu1/+build/7777315
<doko> slangasek, looks like the biggest blocker is kde now, however everything in universe. couldn't reach Riddell the last days, and important packages are not yet in their preparation ppa
<slangasek> doko: why is any of this still in a ppa, rather than in wily-proposed?
<doko> why do you ask me? I only were asking for batched uploads, not everything at once.
<wgrant> slangasek: qt-gstramer -2ubuntu2 built successfully. Is something you changed likely to have fixed the sbuild thing?
<wgrant> Hm, only failed on armhf, weiiiird.
<slangasek> doko: I'm asking you because you apparently know of the existence of a staging ppa which I've heard nothing about, and everything else is already landing in the archive
<slangasek> wgrant: yeah, not related to the package afaics
<doko> http://qa.kubuntu.co.uk/ppa-status/frameworks/build_status_5.13.0_wily.html
<slangasek> heh, some kind of record... smokegen exports 5 symbols and 4 of them changed for g++5
<doko> ;p
#ubuntu-release 2016-08-08
 * RAOF continues to not be an archive admin.
 * RAOF continues to need to resolve that situation.
<mwhudson> yes please, an AA in my timezone (ish) would be useful at times :-)
<Mirv> thanks doko. yes still some problem somewhere..
<Mirv> RAOF: right, sounds familiar to me from some months ago..
<Mirv> seb128: morning! if you're about, please try if you can find some time to get this Qt & KDE transition through.. we're now down to very small selection of update_output.txt I think
<Mirv> not counting eg amd64 list that lists some kde language packs, the update_output.txt claims for example i386: camitk-actionstatemachine, camitk-imp, itksnap, jacktrip, kde-spectacle, kubuntu-desktop, kubuntu-full, libcamitk4, libcamitk4-dev, lubuntu-qt-desktop, lxqt-config, nifti2dicom, nifti2dicom-dbg, nomacs, plasma-discover, qnifti2dicom, reminders-app
<Mirv> it's starting to be really hard for me to see any problems with those, but for reminders-app I believe it should be removed as I asked in bug #1606531 - it's the only package still depending on transitional package qtdeclarative5-quicklayouts-plugin removed in yakkety-proposed
<ubot5> bug 1606531 in reminders-app (Ubuntu) "RM: transitional QML module packages" [Undecided,New] https://launchpad.net/bugs/1606531
<Mirv> others have picked up Qt 5.6 dependency during build time so they'd need to migrate too, but I don't see any problems with them
<Mirv> lxqt-config needed rebuild to transition to libkf5screen7 from libkf5screen6
<Mirv> lubuntu-desktop refuses to install because of some (weird?) problem in installing usb-modeswitch, but I can't see why lubuntu-desktop itself would be required to migrate at the same time
<Mirv> maybe that's noise in update_output, I've never been good in parsing that file
<Mirv> but reminders-app (source and binaries) needs to be removed from yakkety, so please do that
<Mirv> we'd definitely need a more eastern archive admin..
<Ukikie> Mirv: Howdy.
<Mirv> Ukikie: oh hi!
<Mirv> ok, so Lubuntu and Kubuntu seeds need to be updated to not depend on obsolete packages
<Mirv> meanwhile, archive admins still please remove reminders-app from yakkety
<sil2100> We still had that in the archives?
<Mirv> sil2100: yes, I've asked for its removal at bug #1606531
<ubot5> bug 1606531 in reminders-app (Ubuntu) "RM: transitional QML module packages" [Undecided,New] https://launchpad.net/bugs/1606531
<Mirv> I have updated Kubuntu and Lubuntu meta packages and plasma-discover's erronous transitional packages.
<Mirv> I'm still worried about the remaining packages in update_output.txt and would welcome help in understanding the list and if any of it is serious or not
<cjwatson> LocutusOfBorg: Thanks for dealing with Haskell.
<LocutusOfBorg> cjwatson, please wait for it to finish before thanking me ;)
<cjwatson> LocutusOfBorg: Are you working in order on http://people.canonical.com/~ubuntu-archive/transitions/ghc.html ?  Some surprisingly high-up red there.
<cjwatson> LocutusOfBorg: Oh, it normally takes a week or so, I wasn't rushing you :)
<LocutusOfBorg> actually I took a different approach
<LocutusOfBorg> see in update_excuses what was uninstallable
<LocutusOfBorg> and rebuild them
<cjwatson> I find that inordinately hard on my brain.
<LocutusOfBorg> now, I'm sorting the unbuildable packages and retrying them in the right order
<cjwatson> The transition tracker is a much easier format.
<LocutusOfBorg> yes, I know thanks, but I prefer to see logs, and understand them this time
<LocutusOfBorg> next time for sure I'll see the tracker and trust it ;)
<LocutusOfBorg> the main goal is to understand things now
<cjwatson> It is true that there are a couple of things on the tracker that you have to know to ignore.
<cjwatson> agda* on some architectures and xcffib (due to lack of versioned-provides support in that ben instance) IIRC.
<LocutusOfBorg> actually I could build-and-retry-build until stuff is sorted out I guess
<LocutusOfBorg> each time waiting for dinstall
<LocutusOfBorg> but I prefer the slow "check-each-package" method
<LocutusOfBorg> BTW the graphic might have one single big "retry all builds" button instead of clicking on each architecture
<cjwatson> I just use ubuntu-build for that.
<LocutusOfBorg> and also one "no change rebuild and upload" :)
<cjwatson> And a script for that :)
<LocutusOfBorg> yep me too
<cjwatson> LocutusOfBorg: The problem with not going in order by layers is that you can end up duplicating builds if something in a higher layer fails on some architectures.
<LocutusOfBorg> but it might unify the "rebuild messages"
<cjwatson> I don't care about that.
<cjwatson> LocutusOfBorg: e.g. there's a lot of noise from haskell-vector failing to build on a few arches, which needs to be sorted out before rebuilding anything that b-ds on it
<LocutusOfBorg> true
<cjwatson> Exciting that it manages to run out of memory on the big arches.
<Mirv> cjwatson: can you remove src:reminders-app and its binaries from yakkety?
<cjwatson> sorry, I know you're looking around desperately for an AA but I think that's more phone context than I have time to import into my brain at the moment ...
<cjwatson> well, maybe this one is simple, moment
<Mirv> cjwatson: it is simple, no reverse depends and has lived only in click space since 2014
<Mirv> has an old transitional dependency being dropped, so it would be time to get rid of it for good
<cjwatson> Mirv: ok, done that one but I'm not going to look at the rest of that bug at the moment
<Mirv> cjwatson: no problem, none of that other is urgent
<Mirv> and sorry for sounding desperate, it's just because I am :)
<Mirv> but making progress too
<cjwatson> LocutusOfBorg: you probably want to chase up haskell-vector with #debian-haskell if you haven't already; the discrepancy in which arches it manages to succeed on between Debian and Ubuntu is odd, but maybe it needs to be just a whitelist of arches with good enough compiler support or something instead
<LocutusOfBorg> actually I'm retrying them
<LocutusOfBorg> lets see how they go
<cjwatson> I doubt that will make any difference, but ICBW.
<LocutusOfBorg> moved to #-haskell
<Mirv> when some archive admin reads the whole today's backlog, I'd like to add I don't know if there's any fix for fulfilling camitk's powerpc dependency which fails to build in proposed due to something not related to these landings: https://launchpad.net/ubuntu/+source/camitk/4.0.0~beta-2build1 -> https://launchpad.net/ubuntu/+source/insighttoolkit4/4.10.0-dfsg1-2ubuntu1
<Mirv> so I'd like to ask considering any measures needed for getting the transition done regardless
<LocutusOfBorg> camitk is not a blocker for the transition I guess
<LocutusOfBorg> Mirv, do you have another opinion? AFAIR I did the rebuilds correctly, and they wre stuck because of qt transition
<LocutusOfBorg> no need to retry itk4
<Mirv> LocutusOfBorg: well they show up in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt , and I noticed it built in release pocket but not in proposed, so it would block
 * Mirv needs to go for 45mins now
<Mirv> LocutusOfBorg: but yes I think the release pocket camitk should work fine and I have it installed on my yakkety-proposed, I'm just wondering about the update_output.txt
<Mirv> so maybe that's noise
<LocutusOfBorg> they show up there, because the qt is not over
<LocutusOfBorg> for sure you don't need to remove powerpc, since it is already removed, neither retry itk4 there
<LocutusOfBorg> a no change rebuild against qt for every arch might be needed, but please talk to qt folks
<LocutusOfBorg> I can say, from *my* itk4 side, everything should be good and in place
<Mirv> LocutusOfBorg: there's no qt folks but me
<LocutusOfBorg> oh... ok :)
<Mirv> LocutusOfBorg: ok, I'll try to fix everything else and see if that keeps visible in the output.txt or not in the easy autohinter section
<LocutusOfBorg> thanks, but AFAIK you might need a  no-change rebuild for it and itksnap
<LocutusOfBorg> and nifti2dicom
<LocutusOfBorg> (I didn't try the above, I don't know how you uploaded the transition and which packages needs rebuilds)
<Mirv> why is btw publisher runs taking >1h nowadays at times? and almost never the 15-20mins it used to be
<Laney> Mirv: looks like there are quite some issues remaining
<acheronuk> Mirv: a package for frameworks backport took 3hrs to publish on LP yesterday. despite people saying it's fine, it's clear there is some big issue with the publisher
<Mirv> Laney: yep, help would be welcome fixing those. many are being fixed, but there is for example /usr/bin/ld.gold: --secure-plt: unknown option on powerpc that comes from GCC6, and I don't know how to even workaround that https://launchpadlibrarian.net/277744096/buildlog_ubuntu-yakkety-powerpc.ubuntu-ui-toolkit_1.3.2030+16.10.20160726.4_BUILDING.txt.gz
<Mirv> acheronuk: ack.
<Mirv> Laney: and I don't know what would be actually wrong with many of the packages that LocutusOfBorg mentioned, I'm trying a no-change rebuild now even though I can't find anything wrong with the packages and I have them installed on my yakkety-proposed
<Mirv> acheronuk: I think it's been getting worse and worse, but there has been some amount of issues for weeks
<Laney> Mirv: camitk is the new insighttoolkit4 no?
<Laney> Mirv: And the previous one didn't build on powerpc/ppc64el either, so that shouldn't matter
<LocutusOfBorg> my transition is fine
<acheronuk> Mirv: definitely. that was just an extreme example yesterday, but indeed it's been frequently > 1hr for many weeks now and even perhaps degrading more
<LocutusOfBorg> at least AFAICT
<Laney> LocutusOfBorg: Which one?
<LocutusOfBorg> insighttoolkit4 rebuilds
<Mirv> Laney: it build depneds on libinsighttoolkit4. so yes I think those shouldn't matter, but can you explain why they are shown in the update_output.txt among with packages that actually have installibility problems? in the Trying easy from autohinter section.
<Mirv> LocutusOfBorg: for better or no change, now the rebuilds (I did in a silo) are copied over.
<LocutusOfBorg> ok
<Laney> I think this ffmpeg is going to clear out some of them (libwebp5 -> 6)
<Mirv> ok, and we're getting the kde langpack updates right now too. but that leaves that one powerpc problem preventing ubuntu-ui-toolkit rebuild to fix a s390x problem that would prevent the whole promotion, at minimum
<Mirv> ..unless you could force ubuntu-ui-toolkit-autopilot/s390x uninstallability (coming from the upstart problem and newest removals for s390x for it) to get this inch forward before world breaks again
<cjwatson> acheronuk: What package name?
<Mirv> cjwatson: for example https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-073/+sourcepub/6786564/+listing-archive-extra
<Mirv> that's probably 1.5h by now
<Mirv> since build finished
<cjwatson> I want specifically acheronuk's example from yesterday.
<Mirv> ok
<cjwatson> Anyway, the thing is normally that it isn't anything very specific, it's death by a thousand cuts.
<acheronuk> cjwatson:  kxmlgui in https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/staging-frameworks I think?
<acheronuk> maybe LP rounds to hrs after a point, but it did clearly say when still unpublished "Finished 3 hours ago (took 3 minutes, 48.5 seconds)"
<cjwatson> The >1hr run just recently seems to have been mostly due to some very large libreoffice publications which took a long time to shift around internally.
<acheronuk> seems quite consistently closer to the 1hr than the old 20 (ish) mins nowadays. i.e. when it publishes in the 20 mins or so it used to, it's a surprise, rather than the norm
<cjwatson> The Kubuntu PPAs are some of our largest, so you're going to see a somewhat skewed view.
<cjwatson> Looking for the kxmlgui case.
<acheronuk> cjwatson: yes, I know is a perception thing as well
<cjwatson> acheronuk: As I suspected, the kxmlgui case is an anomaly.  There's a weekly window where we do more time-consuming cleanup and when the normal publisher doesn't run, and you happened to run into that.
<cjwatson> Starts at 0559 on Sundays and normally takes a few hours.
<cjwatson> Unrelated to Mirv's question.
<acheronuk> cjwatson: understood, and I except things like can/do happen. just that on top of the quite clear degrading of the times over the last few weeks/months made that one stand out!
<cjwatson> Anyway, as far as I can tell there are no easy fixes.  We do have a plan to restructure things so that we can scale much better, but it is quite a large piece of work so no timescale yet.
<cjwatson> That's "diskless PPAs", so we'd start serving files out of the cloud and wouldn't have to rely so much on shifting lots of files onto a single giant system.
<acheronuk> cjwatson: again, understood. sometimes there is a simple cause and a simple fix. sometimes, like this as it sounds, it's not that easy.
<acheronuk> it's just a tad frustrating when trying to build anything together with a complicated/long dependency tree
<cjwatson> Definitely.
<cjwatson> This is a case of suffering from our own success.
<cjwatson> And I don't mind looking into it because sometimes there is an obvious cause.
<cjwatson> I would love to get time for diskless PPAs.  With any luck it will be months not years ...
<ogra_> can someone bump the score on https://code.launchpad.net/~ogra/+snap/kernel-test-snap/+build/2573 ? it tells me it will start in 20min since about 3h now ... (and i'm having the same issue with all arm builds since friday)
<cjwatson> ogra_: done
<ogra_> thanks ... is there an archive rebuild going on ?
<cjwatson> no
<ogra_> (since this happens since friday already)
<ogra_> (also for arm64)
<cjwatson> arm64 and armhf are the same builder pool.
<ogra_> ah
<cjwatson> Maybe we need to make another attempt to get approval for more Moonshot hardware now that we're actually using it.
<ogra_> +1
<ogra_> well, something changed since friday, before my arm builds were rather fast
<ogra_> ARGH ... and i forgot to bzr push before triggering the build ... sigh
<cjwatson> ogra_: Just looks like more builds happening really.
<ogra_> hmm, k
<ogra_> cjwatson, could you bump https://code.launchpad.net/~ogra/+snap/kernel-test-snap/+build/2575 too ? sorry, the firt one was actually wasted
<ogra_> *first
<cjwatson> See, now you're not stuck in traffic, you *are* traffic ;-)
<cjwatson> done
<ogra_> haha
<LocutusOfBorg> cjwatson, do you happen to know what is going on there? https://launchpad.net/ubuntu/+source/haskell-http-link-header/1.0.1-1build3/+build/10569477
<cjwatson> LocutusOfBorg: Nope.
<cjwatson> LocutusOfBorg: You could try cancelling it and seeing if it works on a different builder; sagari has somewhat different hardware from the others.
<LocutusOfBorg> that was my wondering.
<LocutusOfBorg> rescheduling, but I can't force a particular builder
<cjwatson> No, but you have an 8/9 chance
<LocutusOfBorg> fair enough :p thanks
<cjwatson> (I can force it if I have to, but it's cumbersome so I'd rather not bother)
<LocutusOfBorg> nah, it is fine
<Mirv> can someone figure out why usb-modeswitch refuses to install on yakkety-proposed? it's a real mystery to me.
<Mirv> oh, ok, the -data has Breaks on usb-modeswitch << 2.4.0
<Mirv> so that breaks installing lubuntu-qt-desktop, shown also in update_output.txt but should be noise since it's not related to Qt and KDE upgrading
<Mirv> does anyone know, that if update_output.txt does list eg lubuntu-qt-desktop there as being uninstallable, will it need manual intervention from archive admin via hints if I'd like Qt & KDE to migrate?
<Mirv> oh, but, new lubntu-qt-desktop is required so that its erronous dependencies on obsolete KDE packages would be dropped :(
<Mirv> cyphermox: would it be a really quick job for you to update usb-modeswitch in Ubuntu, ie sync with Debian, so that ^ blocker for Qt and KDE transition would be gone?
<Mirv> it starts to seems I need to fix all of proposed for all packages before this is going to work :(
<cyphermox> most definitely not a quick job right now
<Mirv> hmm, I wonder if I could revert usb-modeswitch-data then
<cyphermox> and I really don't understand why it's a blocker for anything, it really shouldn't be, especially not Qt/KDE stuff
<Mirv> cyphermox: because lubuntu-qt-desktop depends on installability of usb-modeswitch, and lubuntu-qt-desktop needs to be updated to drop KDE dependencies that are broken
<Mirv> so if lubuntu-qt-desktop cannot be installed, update_output.txt claims it's Qt's / KDE's fault
<Mirv> also lubuntu-qt-desktop could temporarily lose its usb-modeswitch dep, that'd be another workaround
<Mirv> I'll just go and do something if no-one wants to help
<xnox> ..
<xnox> please remove dbus-cpp... should be for yakkety
<cyphermox> Mirv: I would suggest you revert -data, it's the best thing to do
<Laney> Is it intentional that component-mismatches wants to promote the first alternative of an or-ed dependency group if one of the others is in main already?
<Laney> i.e. should I fix the report or the package?
<Mirv> cyphermox: ok, thank you
<cjwatson> Laney: component-mismatches doesn't care what's already in main; it does a from-scratch analysis with germinate
<cjwatson> Laney: making it care about the current component overrides would produce weird hysteresis, I think
<cjwatson> (and would be difficult anyway ...)
<Laney> cjwatson: Righto.
<Mirv> still not anyone willing to decipher the update_output.txt remaining problems? so I was interested in why in the autohinter section eg camitk / itksnap would be listed, and also if there's any possibility of ignoring s390x installability issue of ubuntu-ui-toolkit-autopilot for one time if it seems the real fix would take another week or so.
<Mirv> throughout the day I've been able to progress on my own though in many places, but it may be I'm at the end of the road now
<Laney> Mirv: I uploaded ffmpeg and some other bits to progress it somewhat (should fix camitk)
<Mirv> Laney: ok, thank you. what was the problem with it?
<Laney> webp transition
<Mirv> oh so probably somewhere from the depths of that libinsighttoolkit
<Laney> I forgot the chain, but something in there was depending on libwebp5
<Laney> No doubt there are one or two other bits left for that one; didn't check
<Mirv> anyway, it may be that the UITK s390x issue would be the last one after things settle, but I can't rebuild UITK because of powerpc GCC6 issue, and I can't seem to find a workaround to force it. a real fix would probably be something in qtbase, updating of which would relaunch thousands of autopkgtests and probably find both flaky tests and gcc6 issues, postponing this migration by another week or
<Mirv> three
<Laney> which hint block are you looking at?
<Mirv> Laney: easy: 260+0: a-56:a-31:a-31
<Laney> ok, let's see
<jbicha> if you need webp first, more uploads are needed https://people.canonical.com/~ubuntu-archive/transitions/html/auto-libwebp.html
<Laney> just need a minute to set up the script on snakefruit, since my PC is out of reach
<Laney> yep
<jbicha> bug 1610066
<ubot5> bug 1610066 in gst-plugins-bad1.0 (Ubuntu) "gst-plugins-bad1.0 ftbfs on yakkety" [High,New] https://launchpad.net/bugs/1610066
<Mirv> now search for "easy: 245+0: a-47:a-30:a" but actually just search for qtbase in reverse, the last hit is the best looking hint block
<Mirv> I need to rest now.
<Laney> Mirv: I think the plasma-discover depends on packagekit >= 1.0 is going to cause you trouble
<seb128> not close to see the end of that transition...
<seb128> Laney, did you get a reply from the unity8 team about click and yakkety?
<Laney> No.
<Laney> Nothing useful
<seb128> :-/
<Laney> I'm not happy about this being pushed back again after it was agreed
<seb128> I don't think any agreement was changed
<seb128> the phone team is not planning devices on yakkety and is fine getting that to regress
<seb128> the issue is the new usecase of our (desktop) team wanting unity8 on the default install this cycle now
<Laney> So a new requirement is making the previous agreement insufficient
<seb128> yes
<seb128> well it's up to us
<seb128> we can declare that we don't need click
<seb128> it's just that today we only have click as a working package installer in unity8
<Laney> We have to either do it, or undo what's happened in proposed
<seb128> no gnome-software working nor snaps dash integration
<Laney> Assuming this plasma dependency is legitimate, that implies some work there
<seb128> willcooke, ^ we need to make a call on that
<willcooke> seb128, on what exactly?  Your "no g-s working.." comment has confused me
<seb128> willcooke, read the backlog from 16:59 on
<willcooke> I did, I'm still not sure what you're asking
<willcooke> is it "do we move to PK 1.0" in 16.10?
<seb128> willcooke, but summary is that the pkgkit 1.0 transition in yakkety-proposed blocks other things including qt/kde stack
<seb128> yes
<willcooke> in which case, yes
<willcooke> yes we move
<willcooke> end of
<seb128> k
<willcooke> tedg is hoping to land support in u8 by EOW
<seb128> so no way to install packages today under unity8-desktop
<seb128> which is fine
<seb128> k
<Laney> if it generates pressure to get the work done faster
<Laney> ;-)
<seb128> dobey said it was some thousand lines of code to review and was probably not going to be that easy
<seb128> but let's see
<Laney> it's the right call for our team imho
<Laney> thanks!
 * Laney gives Mirv a shoulder massage
<seb128> Laney, either that, or it creates pressure on our team to fix things that we broke
<Laney> sorry
<willcooke> attent_e looked at what was needed to get g-s working under u8 too
<seb128> but yeah, I agree we should do it
<seb128> just be ready to get some heat for breaking things
<willcooke> but if ted_g is working on a u8 native option, so much the better
<seb128> and have to figure a way out
<Laney> It's not as if there hasn't been an interminable amount of warning about this problem
<seb128> right
<seb128> well as said we (desktop) are in charge now of seeding that new session and getting it to work
<willcooke> Laney, +1 - we've been talking about it from before this cycle even started
<seb128> so it's selftwarning at this point
<seb128> but we haven't really been on top of that work (yet)
<seb128> anyway the session is what it is
<seb128> then we can start discussing bugs between unity8 team and us
<seb128> Laney, willcooke, thanks for pushing and acking, I think landing it now is the right thing, we delayed enough
<Laney> seb128: merci
<seb128> the number of transitions/work that still need to land start being a bit concerning but I guess we can sort out after feature freeze starts
<wxl> infinity: a member of our lubuntu team has created merge proposals to implement qt-driven images for lubuntu. this is the future of lubuntu, so it would be really great to have. what's the timeline on this? https://code.launchpad.net/~tsimonq2/ubuntu-cdimage/lubuntu-next-image/+merge/301203 https://code.launchpad.net/~tsimonq2/livecd-rootfs/lubuntu-next-image/+merge/301202
<bdmurray> tjaalton: Could you have a look at bug 1610434?
<ubot5> bug 1610434 in xorg-lts-xenial (Ubuntu) "Ubuntu GNOME Trusty HWE upgrade fails to install libwayland-egl1-mesa-lts-xenial" [High,Triaged] https://launchpad.net/bugs/1610434
<doko_> we need somebody to track the OpenGLes build failures on arm64 ... and remove the packages which don't build anymore
<doko_> this is a blocker for transitions, e.g. https://launchpad.net/ubuntu/+source/tulip/4.8.0dfsg-2build4
#ubuntu-release 2016-08-09
<Mirv> thanks Laney & co, good that there is a decision wrt to packagekit
<Saviq> trainguards, can someone please retry those builds for us https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-001/+build/10582957 https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-001/+build/10583028 - it's a flaky test it seems
<Saviq> now https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-001/+build/10583430 is something completely different - any idea where's libsystem-settings-dev gone Â¿? http://pastebin.ubuntu.com/22780559/
 * Saviq â -release
<Saviq> oh grr, I'm already here...
<Saviq> so yeah, @all, any idea what's happened with libsystem-settings-dev in proposed amd64? it's there for i386 http://pastebin.ubuntu.com/22780603/
<Saviq> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-073/+build/10540325 says it should be there, so it got lost somewhere Â¿?
<Mirv> Saviq: :D retrying
<Mirv> Saviq: the log says it's not being installed (due to something), not that it wouldn't be there. the problem is that slangasek deleted https://launchpad.net/ubuntu/yakkety/amd64/libsystemsettings-dev but did not delete https://launchpad.net/ubuntu/yakkety/amd64/libsystemsettings1 . theory is he was only supposed to remove s390x of each src:ubuntu-system-settings package, but ended up deleting
<Mirv> libsystemsettings-dev on amd64 too
<Saviq> Mirv, well, yeah I checked that it's not there... at least apt policy says so, any idea how to fix? do we need to reupload src:ubuntu-system-settings, or will that bring s390x back...
<Mirv> Saviq: we'd need ubuntu-system-settings with https://code.launchpad.net/~timo-jyrinki/ubuntu-system-settings/stop_s390x_problems_depend_on_upstart/+merge/302143 added
<Saviq> only where... https://requests.ci-train.ubuntu.com/#/tickets?active_only&search=ubuntu-system-settings
<Saviq> biab
<Mirv> 060 is the priority according to trello logs
<tseliot> apw: hey, can you approve nvidia-367 in yakkety NEW, please?
<LocutusOfBorg> cjwatson, FYI we should be good until level 10
 * LocutusOfBorg haskell side
<ogra_> so haskell is actually a game ! i knew it seeing all these masses of uploads every cycle !!
<Laney> karma factory
 * ogra_ waits to see the haskell-endboos package uploaded
<ogra_> *endboss
<LocutusOfBorg> lol
<LocutusOfBorg> the princess in another castle (citation needed)
<LocutusOfBorg> s/in/is in/
<ginggs> transition tracker tetris
<Mirv> seb128: Laney: so is the ETA for unlocking transition earlier end of this week? I'm pondering whether to explode potential can of GCC6 worms by a qtbase and qtdeclarative updates or whether to do this one transition first. copying those would trigger thousands of autopkgtests again.
<Mirv> s/earlier/earliest/
<Laney> I would wait if I were you
<Mirv> Laney: ok then
<Mirv> there's no hurry with those as such
<Mirv> there may be a UITK s390x fix now happening, while leaving camitk itksnap jacktrip nifti2dicom nomacs still there (ffmpeg? webp?) plus the lubuntu-qt-desktop/muon/plasma-discover regarding pkg-kit 1.0
<Mirv> well the landers will be in a painful situation, but the pain won't stop until the migration is done anyway
<Laney> Mirv: If you want to do the packagekit stuff you can, btw
<Mirv> I can do monkey work, but otherwise not familiar at all with packagekit
<Laney> It is monkey work
<Mirv> I see "upload click to drop the packagekit backend binary" bug #1496292 but it was unclear to me reading yesterday's discussion if that should be done or if need to wait for the Unity 8 feature first
<ubot5> bug 1496292 in packagekit (Ubuntu) "Needs to be ported to packagekit 1" [High,Confirmed] https://launchpad.net/bugs/1496292
<Laney> Mirv: The decision was to do it, and have a gap before the new feature is ready
<Laney> So drop that, find any reverse dependencies and mutilate those until they give in
 * Mirv goes monkeying click, ubuntu-touch seed and unity8-desktop-session
<cjwatson> there's an existing MP for the click stuff
<cjwatson> please use it rather than monkeying independently
<Mirv> ok
<Mirv> from February, nice
<cjwatson> (I don't like it much, but it's not wrong in itself)
<cjwatson> https://code.launchpad.net/~unity-api-team/click/drop_packagekit/+merge/285225
<cjwatson> my disapprove vote is "I don't like this direction", not "this patch is wrong"
 * cjwatson links the bug
 * Mirv did the same
<Laney> Thanks, I was just digging that up
<Laney> It would have been better to give it the D-Bus interface that mvo worked on. Not sure why that approach wasn't pursued, but I don't propose to re-open that discussion now. :)
<cjwatson> That's what I wanted too, but you can see my attempt to argue that in the MP above
<cjwatson> And I don't really get to both mostly-abandon the project and control its direction :-)
<Mirv> https://code.launchpad.net/~timo-jyrinki/unity8-desktop-session/drop_click_packagekit_plugin/+merge/302389
<Mirv> https://code.launchpad.net/~timo-jyrinki/ubuntu-seeds/ubuntu-touch.yakkety_drop_packagekit_plugin_click/+merge/302390
<Mirv> the click seems to build alright
<Mirv> so the ubuntu-system-settings wrong binaries removal is now starting to hurt, I'm trying to fastlane u-s-s rebuild into archives but without bringing the removed s390x binaries back (ie merge that one MP manually)
<happyaron> hi, anyone can look at the SRU queue of xenial for network-manager?
<sil2100> Laney: hey! Are you the one working on the libwebp transition? https://people.canonical.com/~ubuntu-archive/transitions/html/auto-libwebp.html
<sil2100> Or maybe anyone else is tracking it?
<Laney> sil2100: a bit, why?
<sil2100> Laney: was just wondering if maybe some help is needed there
<Laney> sil2100: There's 2 KDE/Qtish ones that are left, that I didn't touch yet until I've examined update_output.txt a little bit
<sergiusens> slangasek hi there, can you let that guy in please? ^
<slangasek> Mirv, Saviq: ugh; did ubuntu-system-settings get sorted already?  it is possible to recover the binaries (sorry, I thought I had ^Ced my wrong deletion in time but apparently not), if that would help
<slangasek> sergiusens: looking
<slangasek> sergiusens: can you confirm (on the bug) whether the packaging QA has already been done, or is yet to be done, per https://wiki.ubuntu.com/SnapcraftUpdates ?
<sergiusens> slangasek that usually happens with the binary debs that end up built in -proposed
<slangasek> sergiusens: ok
<sergiusens> slangasek I ask elopio to clarify that part of the wiki
<slangasek> sergiusens: accepted
<sergiusens> slangasek thanks
<Mirv> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-ui-toolkit would need to be run with --all-proposed to pick up a fixed unity8
<Mirv> slangasek: yes that one is fixed
<Mirv> same for http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-system-settings
<slangasek> Mirv: ubuntu-ui-toolkit shows no blocking test failures
<slangasek> for ubuntu-system-settings, I guess it's the unity8 tests that need rerun?
<slangasek> (retriggered)
<Mirv> slangasek: does not? the same unity8 tests are red for ui-toolkit too. http://people.ubuntu.com/~timo-jyrinki/uitk.png
<Mirv> cjwatson: Laney: sil2100: it seems that the click branch https://code.launchpad.net/~unity-api-team/click/drop_packagekit/+merge/285225 was unfortunately not enough for click's own autopkgtests: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#click
<slangasek> Mirv: ok, let me hit refresh in my browser and look again ;)
<slangasek> Mirv: hey, lookie there. ok.
<slangasek> Mirv: retriggered for both
<Mirv> slangasek: ok :) thanks, --all-proposed is generally now needed since so much is in proposed. that click issue is one of the remaining blockers, although now landed it fails its own autopkgtests.
<bdmurray> slangasek: Could you have a look at my update-manager upload in the trusty SRU queue?
<slangasek> bdmurray: looking
<slangasek> bdmurray: I don't understand the code change; does 'universal_newlines=True' implicitly trigger decode()?
<slangasek> bdmurray: ok, the documentation tells me that "yes"
<bdmurray> slangasek: yes
<slangasek> accepted
<coreycb> bdmurray, hello, when you have a moment can you take a look at releasing python-keystonemiddleware for xenial?  bug 1533724 has been verified.
<ubot5> bug 1533724 in Ubuntu Cloud Archive "[SRU] keystone-signing folders fill /tmp and seriously slow down reboots" [Medium,Triaged] https://launchpad.net/bugs/1533724
<bdmurray> coreycb: done
<coreycb> bdmurray, thanks
<mwhudson> can someone delete juju-mongodb2.6 from yakkety-proposed?
<mwhudson> the package in release was deleted a couple of days ago
<mwhudson> (see https://bugs.launchpad.net/ubuntu/+source/juju-mongodb2.6/+bug/1610778)
<ubot5> Launchpad bug 1610778 in juju-mongodb2.6 (Ubuntu) "please remove this package from yakkety" [Undecided,In progress]
#ubuntu-release 2016-08-10
<Mirv> Laney: one day later, we're back to clean update_output.txt but now with UITK s390x fixed
<Mirv> the familiar packages are still listed there
<Trevinho> relase team, could you please unblock the sync from ppas in https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text= ?
<seb128> Trevinho, it's a SRU team job, not a release team one
<seb128> but yeah it would be nice if our main desktop SRUs weren't let sitting in the queue :-)
<seb128> though it seems not much have been reviewed for a week, we are feeling that pitti is on holidays :p
<Trevinho> seb128: I know... but there's no sru team channel :)
<seb128> right, but they are on #ubuntu-devel
<seb128> Trevinho, https://wiki.ubuntu.com/StableReleaseUpdates has a publishing schedule and arges on shift for today, you might maybe convince him to do some reviews if he's not on vac
<Trevinho> yeah, I noticed that... but i guess it's still early for him
<seb128> yeah
<Laney> Mirv: OK, looking - at least ffmpeg needs to go green
<Laney> Seems to be having trouble on armhf, but somebody already retried that
<Laney> And vlc too
<Mirv> Laney: I retried them yes, but they might be some real problems too
<Laney> Yes
<Mirv> does that https://code.launchpad.net/~timo-jyrinki/click/dont_use_@_in_testscontrol/+merge/302514 make sense to land? since the packagekit plugin is still mentioned in debian/control, "@" in debian/tests/control is my guess of causing that autopkgtest failure http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#click
<Mirv> Laney: anyway, with some copies to yakkety-proposed I just did, and that click branch, I'm officially out of ideas. for example, I don't understand that camitk that doesn't seem to be webp related, and all insighttoolkit4 related rebuilds have been done
<Laney> insightoolkit4 isn't in the hint that you're looking at
<Laney> there's a bigger one further up
<Laney> Which is mainly blocked on ffmpeg and webp stuff as far as I can tell right now
<Mirv> oh, ok
<Mirv> sil2100: ^ you'll be interested too, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<Laney> Mirv: do you have access to snakefruit.canonical.com?
<Mirv> well I may have fixed some rtaudio migration issues with rebuilds now too, even if maybe unneeded. that's because I was looking at the lower hint and saw jacktrip.
<Mirv> Laney: no.
<Laney> ok, but you can still use the script I was going to show you at home
<Laney> https://bazaar.launchpad.net/~laney/ubuntu-archive-tools/update-output-helper/download/head:/updateoutputhelper-20150813155719-m20yfaytzwyju4hk-1/update-output-helper
<Laney> this is something I wrote a year or two ago to help with figuring out update_output.txt issues
<Laney> do: update-output-helper -u; update-output-helper <the 'trying easy from' hint you are looking at>
<Laney> then it gives you an apt command that you put the broken packages into, to see why they aren't installable
<Mirv> wow
<sil2100> wow
<Mirv> the bigger hint section seemed worse since it has more packages uninstallable
<Laney> you don't always get to choose though
<Laney> if there are entangled transitions
<Mirv> with that I can see webp would be involved, but I couldn't decipher the ffmpeg out of it. (I gave the apt command all the hundred+ packages)
<Laney> if you are using the script, look at the smaller one
<Mirv> (http://pastebin.ubuntu.com/22893716/ is what I got)
<Laney> it's easier to try one package at a time
<Laney> Mirv: I use it like this https://paste.ubuntu.com/22893833/
<Mirv> sure is it if there are not hundreds of them. with the smaller hint section I at least "correctly" (incorrectly) get insighttoolkit, rtaudio, plasma-discover-updater, and libwebp6
<Laney> Iterate by adding the packages that it tells you are a problem
<Mirv> but that is also incorrect since muon-notifier/muon-updater have already been updated to not depend on the disappearing plasma-discover-updater
<Mirv> Laney: right.
<Laney> /usr/bin/ld.gold: --secure-plt: unknown option
<Laney> what's that?
<Mirv> it's a GCC6 feature.
<xnox> why use gold?
<Mirv> I'm disabling the gold on powerpc because of that for Qt 5, as suggested by do_ko
<xnox> Mirv, why are you even use gold anywhere? all/most speed improvements of gold are long time in ld, and thus using gold is pointless everywhere.
<xnox> the old dogma that "gold" is so much better, is not quite true any more.
<xnox> anyway, /me goes back fighting with firefox
<Laney> Trying a test build of ffmpeg on porter-armhf
<Laney> don't know about vlc/s390x, looks like it's going to timeout
<xnox> i'm still on firefox, so haven't looked into vlc yet.
<Laney> doko did an upload to make it use -O2
<Laney> but looks like the build is hung to me, no output for 30 minutes or so
<Laney> i'll brb
<sil2100> Laney: yeah, I see the armhf ffmpeg build dies reliably, one tests core-dumps with a Bus error
<Mirv> xnox: I'd need to dig up Debian's git to see if there's any general reason or if it's an old habit
<xnox> Mirv, right, also is gold upstream default?
<xnox> that would be interesting, if it is.
<Mirv> xnox: yes it's the default it seems
<Mirv> (if available)
<doko> Laney, yes it's this issue, but -O3 is still passed. apparently I didn't read the configury stuff correctly
<Laney> doko: alright, thanks
<Laney> sil2100: passes on porter-armhf, of course :(
<sil2100> :|
<sil2100> Now this is annoying
<xnox> Laney, porter box is read armhf, builders are arm64 virtual machines....
<xnox> *real
<Laney> shrug
<sil2100> I could try building that in an armhf chroot but that would take ages
<Laney> I wonder if I can get access to one of those
<Laney> via my autopkgtest account probably
<xnox> Laney, if there is arm64 porter box, try armhf chroot on that? (if any are available...)
<Mirv> ok click fix, try two now in archives
<Laney> xnox: trying to remember how to work lxd :)
<xnox> Laney, i have not managed to get lxd work cross-arch =/ it tries to setup network and blows on netlink or some such.
<Laney> I think pitti says it sort of works, but is flaky
<Laney> maybe enough for this
<Mirv> yeah, vlc s390x failed the second time
<Mirv> this time claiming ICE though
<Laney> same as always
<Mirv> oh it was the earlier time too, ok
<Mirv> force build on gcc5... not much ideas
<Laney> d_oko is on it
<Mirv> oh, ok
<Laney> xnox: I'm in, muhahaha
<Laney> oh yeah, it died
<LocutusOfBorg> cjwatson, what about removing haskell-http-link-header on powerpc? it was never built on Debian, it built once for Ubuntu and now it is not building anymore, probably an hw issue on some powerpc machines, I prefer it to be kicked out since the probable patch is in the next ghc
<LocutusOfBorg> BTW transition up to level 17 :)
<cjwatson> I don't object but I'm buried in other stuff right now.
<LocutusOfBorg> I hope any other archive admin can help here ^^ slangasek :)
<LocutusOfBorg> I don't want the next haskell-levels to use that binary in some obscure way, and have to remove many of them in the next few days
<cjwatson> oh, wait, it's just NBS in -proposed isn't it
<cjwatson> that's trivial
<LocutusOfBorg> yes
<cjwatson> or not NBS but ... whatever
<LocutusOfBorg> never went to release
<cjwatson> LocutusOfBorg: removed
<LocutusOfBorg> ta
<cjwatson> BTW I'd recommend retrying build failures before doing unnecessary source uploads
<cjwatson> it's not very much effort to check for and it reduces the very large amount of noise on -changes a bit
<cjwatson> e.g. haskell-wai-app-static, all architectures had previously failed on 3.1.5-1build3 so you could have just retried them all rather than uploading 3.1.5-1build4
<LocutusOfBorg> you are right, not sure how I missed that
<LocutusOfBorg> indeed a bug in my script
<LocutusOfBorg> thanks, will check
<LocutusOfBorg> I usually: copy paste the level from transition tracker, remove the stuff that is not red, cat file |cut -f 1 -d " " |cut -f 1 -d "[" > list
<LocutusOfBorg> and then ubuntu-build and rebuild in case
<LocutusOfBorg> damn, there seems to be no return value from ubuntu-build :( so I can't just issue a rebuild in case there was no give-back issued
<Mirv> sil2100: Laney: this would be readily built in case you come to a conclusion it could be acceptable for now for ffmpeg: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-073/+sourcepub/6792728/+listing-archive-extra
<sil2100> Mirv: hm, I would feel bad disabling all the tests just because of one core-dumping
<Mirv> right, that's also an option, if there's just one.
<Mirv> I don't know though how to query architecture in those .mak files to skip some single alaw related lavftest
<Mirv> anyway, those are options if wanted to go forward in trying the migration
<Trevinho> arges: hey, you here?
<arges> Trevinho: yes
<Trevinho> arges: hey
<Trevinho> arges: could you review the SRU queue for unity packages?
<arges> Trevinho: sure
<Trevinho> arges: basically sync from https://requests.ci-train.ubuntu.com/#/ticket/1737 and https://requests.ci-train.ubuntu.com/#/ticket/1778
<Trevinho> arges: thanks
<Trevinho> pkg src I care more are frame, compiz and unity.
<LocutusOfBorg> damn, I tried haskell-http-conduit in a qemu armhf pbuilder environment, everything is good and testsuite passes
<arges> Trevinho: i messed with bug 1350523, just to confirm frame is fixed in yakkety?
<ubot5> bug 1350523 in frame "compiz assert failure: compiz: device.cpp:147: float frame_device_get_window_resolution_x(UFDevice): Assertion `status == UFStatusSuccess' failed." [Medium,In progress] https://launchpad.net/bugs/1350523
<Trevinho> arges: yes
<arges> Trevinho: and could you add the SRU template to that bug (makes it easier to review) thanks
<Trevinho> arges: sure
<Trevinho> done
<Trevinho> not that it's possible to reproduce it in a certain way...
<seb128> Trevinho, well then point to the e.u.c entry or ask to test for no regression at least
<bdmurray> tjaalton: I've worked around the libwayland-egl1-mesa issue from bug 1610434 by adding it to the list of metapackages, however now a couple of other packages were not upgraded and I'm not sure whether or not to worry about it.
<ubot5> bug 1610434 in xorg-lts-xenial (Ubuntu) "Ubuntu GNOME Trusty HWE upgrade fails to install libwayland-egl1-mesa-lts-xenial" [High,Triaged] https://launchpad.net/bugs/1610434
<bdmurray> slangasek: I've found multiple bad translations of a string in ubuntu-release-upgrader which are causing tracebacks e.g. https://errors.ubuntu.com/problem/50c8f7b892dd75b531ac7d68a07ec11541387013
<slangasek> :/
<bdmurray> Is that fixable via an SRU or are the translations separate?
<slangasek> bdmurray: do we have some way to detect such mismatches at package build time?
<slangasek> I imagine those translations are in ubuntu-release-upgrader, but maybe they're in the langpacks
<bdmurray> slangasek: I don't think there is anything currently setup to detect the mismatch.  This does seem like a familiar problem though so how could we do that?
<ginggs> hi, would someone remove the armhf binaries from wine-development, please?
<sergiusens> arges or slangasek later in the day can you release the lock on snapcraft 2.14/xenial-proposed so it gets to -updates?
<arges> sergiusens: i can do it
<slangasek> bdmurray: for other format string types (such as C format strings), I know there are tools to check compatibility at build time.  For python format strings I'm not sure what we have; maybe barry or cjwatson would know
<slangasek> sergiusens: ^^ your on-call SRU team member for today :)
<slangasek> ginggs: what about arm64?
<slangasek> ginggs: n/m, I see it's built but not reflected yet on p-m
<arges> sergiusens: done
<ginggs> slangasek: yup, the builds take a little longer on arm. LP: #1611922 for the reason
<ubot5> Launchpad bug 1611922 in wine-development (Ubuntu) "FTBFS on armhf" [Undecided,New] https://launchpad.net/bugs/1611922
<slangasek> ginggs: this same version of wine-development appears to have built successfully on armhf in Debian. why do we want it removed instead of fixed?
<ginggs> slangasek: it would be great to get it fixed, but i don't see it happening soon
<barry> bdmurray, slangasek: you want to extract i18n strings from python code?  modern xgettext should be able to do that, if they're marked with _('')
<slangasek> barry: validation that the translations don't have mismatched format strings
<slangasek> which is something that we really want to catch at build time instead of tripping over at runtime
<slangasek> I know we've hardened LP translation support against this sort of problem before, but don't know if/how it applies in the python case
<barry> i thought msgfmt did that, but it's been a while
<Saviq> can someone please restart the regressions here with all-proposed https://requests.ci-train.ubuntu.com/static/britney/ticket-1771/landing-001-yakkety/excuses.html? it's still Qt 5.6 migration that didn't happen
<cjwatson> slangasek: right, msgfmt checks this provided that xgettext detected it as a format string and emitted an appropriate flag in the .po file
<cjwatson> .pot file I mean
 * cjwatson pokes around
<cjwatson> No python-format flag there ...
<cjwatson> Ah, it's because xgettext doesn't know which language check-new-release-gtk is in
<cjwatson> Maybe
<cjwatson> I see at least one oops there (for hr) that was fixed in lp:ubuntu-release-upgrader on 2015-02-12, so there may be something to look into there too
<cjwatson> slangasek,barry: right, so with http://paste.ubuntu.com/22958656/, that string is correctly marked as fuzzy once the translation files are updated in the usual way, which will cause it not to be used
<cjwatson> slangasek,barry: however somebody should look at how to sort it out properly for the other Python programs in that package, which don't all have convenient .py symlinks that we can abuse for this purpose :)
<cjwatson> bdmurray: ^-
<tjaalton> bdmurray: ok, I'll have a look tomorrow
<bdmurray> tjaalton: thease the packages that weren't upgraded - http://pastebin.ubuntu.com/22929072/
<bdmurray> tjaalton: e.g. xserver-xorg-video-r128-lts-vivid was installed but the same lts-xenial package didn't get installed
<tjaalton> bdmurray: mouse is no more, and r128/mach64 were not part of -video-all in wily either
<bdmurray> tjaalton: but they were in utopic/vivid though right?
<tjaalton> probably
<bdmurray> I think the object of HWE support is to get people off the lts-u/v/w (which they'd have if they just installed from 14.04.2...) packages on to lts-x.
<tjaalton> actually the metapackages were identical in vivid/wily
<bdmurray> What are the metapackages for the HWE stack then?
<tjaalton> utopic didn't pull r128 either
<tjaalton> xserver-xorg-video-all-lts-foo
<tjaalton> oh, it's -ati that depends on r128/mach64
<tjaalton> guess apt is just stupid then
<bdmurray> the hwe support code doesn't have xserver-xorg-video-all-lts-foo as a metapackage, adding that will probably fix things up
<tjaalton> or maybe because the depends were demoted to Suggests
<tjaalton> what support code?
<tjaalton> xserver-xorg-lts-foo should pull it
<tjaalton> and -input-all-lts-foo
<bdmurray> https://bazaar.launchpad.net/~ubuntu-core-dev/update-manager/main/view/head:/hwe-support-status#L51
<bdmurray> well, if xserver-xorg-lts-foo should pull it in, I don't know what happened...
<tjaalton> it's fine to not pull in -r128/-mach64
<bdmurray> it's fine to remove the vivid version and not pull in the xenial version?
<tjaalton> the reason was that -ati demoted the depends to suggests
<tjaalton> i bet noone has such hw
<tjaalton> mach64 is from -94
<bdmurray> okay, I just don't want to strand someone
<tjaalton> r128 (for Rage) is 95-99
<slangasek> "i bet no one has such hw"> too late for that thought
<slangasek> if that was our position we should have not shipped those binary packages at all in the hwe stacks
<slangasek> since we *have* created them, we should make sure anyone who has installed them, rightly or wrongly, gets the correct upgrade path
<tjaalton> so a new -ati-lts-xenial then?
<tjaalton> bdmurray: probably needs a new bug
<tjaalton> for sru
<bdmurray> tjaalton: I'll submit the bug shortly
<infinity> tjaalton: If that's where the deps came from, yeah.
<infinity> bdmurray: The upgrader should probably also be making sure video-all and input-all are installed.  Consider it similar to how we ensure flavour-desktop is installed after release upgrade, just a sanity check.
<tjaalton> bdmurray: should I wait or upload it tomorrow?-)
<bdmurray> tjaalton: your tomorrow works for me
<tjaalton> cool
<infinity> bdmurray: The other options is dpkg -l \*-lts-wily | gawk '/^ii/ {print gsub("-lts-wily","-lts-xenial",$2); print $2}' | xargs apt-get install
<infinity> bdmurray: Which is gross, but also catches the weird virtualbox-lts-* junk.
<infinity> Oh, that should be /^.i/ not /^ii/
<bdmurray> tjaalton: bug 1611982
<ubot5> bug 1611982 in xorg-lts-xenial (Ubuntu) "HWE upgrade from vivid to xenial removes support for r128 and mach64" [Undecided,New] https://launchpad.net/bugs/1611982
#ubuntu-release 2016-08-11
<tjaalton> bdmurray: thanks, I'll move it to x-x-v-ati-lts-xenial
<tjaalton> and uploaded ^
<happyaron> hi, anyone can look at the SRU queue of xenial for network-manager?
<LocutusOfBorg> any archive admin, please remove gitit on arm64 (will be probably removed in Debian too, to let haskell migrate) same failure here
<LocutusOfBorg> and also please accept haskell-yesod-auth-oauth2
<alf_> Hi! unity-system-compositor is blocked in proposed due to autopkgtest build problems in unity8 (http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#unity-system-compositor). The problems are not related to unity-system-compositor. Is there a way to unblock this without waiting for unity8 to fix its test?
<alf_> Laney: Hi! Is ^^ something you could help with?
<Mirv> ^ needs rerun with --all-proposed
<Laney> ok
<alf_> Laney: Mirv: thanks!
<Laney> it is running
<dbarth_> hey bdmurray, are you the vanguard for the verification process today?
<dbarth_> i have this patch siloed with an SRU fix; went through the citrain qa: https://requests.ci-train.ubuntu.com/#/ticket/1669
<dbarth_> i'm re-running the automated tests for it, after a rebuild and manual check
<dbarth_> my question: do i need a verification-needed tag? or can proceed with -done thanks to citrain/qa ?
<bdmurray> dbarth_: I don't see anything in xenial-proposed fixing that so verification seems premature.
<dbarth_> bdmurray: ok thanks; so it needs to land there; i'll see with the ci process
<Mirv> I think that one armhf is more like stuck than in progress http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ffmpeg ?
<Mirv> stuck / stale lock file or such
<Mirv> hmm it seems I can craft the request url too. I don't know however why the armhf was run with "versionless" package
<Mirv> a missing dpkg-dev (from the test log) is a bit suspicious too
<infinity> Mirv: Rerunning.
<bdmurray> slangasek: Could you review that update-manager upload since its mine?
<slangasek> bdmurray: yes
<slangasek> bdmurray: your bug ref is marked as a duplicate of another bug, do you want to swap them in LP?
<slangasek> hmm probably not swap, probably un-dupe?
<bdmurray> slangasek: yeah, I forgot I'd referenced that bug.
<slangasek> bdmurray: ok, accepted. the test case should also verify that if you didn't have a libwayland-egl1-mesa before, hwe-support-status doesn't try to pull it in?
<bdmurray> slangasek: yeah, that'd make sense
<Mirv> ok the webp transition is now complete and ffmpeg works too, which were according to Laney the blockers for migration. could US timezone see to fixing any remaining issues, or at least identifying them?
<Mirv> or if some extra migration hints for example would be needed. I remember that in the past some manual hinting of "try all of these together" was eventually needed.
<Mirv> ok one thing at least: please ignore kopete tests for https://launchpad.net/ubuntu/+source/kde-runtime - it's part of the webp transition
<Mirv> I mean, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kde-runtime
<Mirv> maybe kdevelop too but I restarted the ppc64el
<Mirv> slangasek: ^
<Mirv> after those, please stare at the update_output.txt
<Mirv> good night
<bdmurray> slangasek: there is also an update-notifier SRU for Trusty that could use a review
<slangasek> Mirv: so I'm not seeing how the webp (which I assume is libwebp) transition is complete, or how kopete should be ignored because it's part of it given that there is no kopete package in yakkety-proposed
<slangasek> bdmurray: I'm confused by the test case - why wouldn't "log in" be sufficient to get you the updated motd?
<slangasek> and what is 4) "observe a message"  - observe it where?
<bdmurray> slangasek: on the terminal you ran the update in, there is a cat of the stamp file which contains the message
<slangasek> ah
<slangasek> fwiw I think you should be able to do just step 5) without 3) or 4)
<slangasek> anyway, accepted
<bdmurray> slangasek: what would call the hwe-eol script? just the process of logging in?
<Mirv> slangasek: http://people.canonical.com/~ubuntu-archive/transitions/html/auto-libwebp.html this had four items earlier. so kopete tests under kde-runtime: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kde-runtime (kde-runtime itself is no-change rebuild)
<slangasek> bdmurray: yes, pam_motd triggers the call to update-motd
<slangasek> Mirv: so you're asking to bypass the kopete failure as a least-bad option for unblocking the transition, not because the kopete test is a false-positive caused by the transition?
<Mirv> slangasek: and we're talking about the transition of ~everything (Qt, KDE, webp, ...) which we've been trying to get done for two weeks now, and it's all interlinked with each other
<Mirv> slangasek: I'm asking because generally yofel has asked to ignore all failing Kubuntu tests at the moment since they don't have manpower to debug them. it seems like a recompilation error they'd need to investigate latest when they want to upgrade it.
<Mirv> slangasek: it's not likely that is enough to unblock the transitions, there have been tens of earlier fix uploads and all kde tests ignored that were failing
<Mirv> but at least it might get a better update_output.txt again
<slangasek> ugh. ok.
<slangasek> kopete overridden
<Mirv> any help in getting the transition done and touch landings for all teams less painful would be appreciated, but we'll continue tomorrow again
<tedg> So the libwebp transition page says that it's good, but it is still in proposed.
<tedg> Is there something that needs to be done there?
<tedg> Or, more importantly, is there a way that I should know something needs to be done there?
<slangasek> tedg: the transition page tells you that all the binaries have been rebuilt for the new library name in -proposed; for knowing why they're still in -proposed instead of in devel requires parsing http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html, which Mirv already did some analysis of.  Currently the known blocker is kde-runtime needing to get past some failing
<slangasek> tests
<slangasek> (audiocd-kio test got a bit wedged on ppc64el, I've retriggered it now)
<tedg> slangasek: Ah, so the deps under a package on excuses are not recursive, just the package itself. Then you have to click on those to see if all their deps are building.
<slangasek> there's no recursion there, yes.  Not sure what you mean wrt "building" though
<tedg> I mean passing, not building. Sorry.
<kirkland> slangasek: remind me...where did we end up on the request to restore the symlink from /etc/motd to the motd?
<yofel> slangasek: if you see any kde packages versioned 15.12.3 broken by the migration, please just accept those getting broken. We'll update all applications to 16.04.3 once the current transition patch is done
<yofel> and fix any remaining issues at that point
<yofel> *transition batch
<slangasek> kirkland: I think we didn't reach a conclusion because we had a set of mutually incompatible requirements, and the only way to resolve this was by getting a consensus together with Debian?
<slangasek> yofel: ack
<kirkland> slangasek: ah, okay
<kirkland> slangasek: where's the best place to document such a discussion?
<slangasek> kirkland: a page on wiki.debian.org to document a design, and then a discussion on debian-devel@lists.debian.org, might be the path forward
<kirkland> slangasek: what could possibly go wrong?  :-P
<kirkland> slangasek: okay, I can do that, and will if that's the right approach.  pardon me if it feels heavy handed for, literally creating a symlink, as a distro package :-)
<slangasek> kirkland: I mean a design for the whole shebang, not just for the symlink :)
<kirkland> slangasek: ah -- that includes update-motd, or is that already sufficiently designed?
<slangasek> including update-motd
<kirkland> slangasek: ah, you mean pam_motd
<slangasek> which is designed, but not documented for Debian's purposes
<kirkland> slangasek: defining what pam_motd *should* do
<slangasek> so Debian people keep changing things on the edges and fraying
<kirkland> slangasek: got it
<kirkland> slangasek: okay, let me document my thoughts in a google doc, first
<kirkland> slangasek: then we can move to debian wiki
<kirkland> slangasek: reminder, I've got no privs (and probably negative karma) in the Debian community
<xnox> kirkland, like everyone in debian community =) in general =)
<kirkland> xnox: LoL :-)
<xnox> slangasek, valgrind-mpi needs to be placed into universe somehow please =)
<xnox> (similar to boost-mpi bits, source in main, most things in main, that package into universe)
<slangasek> xnox: done
<xnox> tah
<ginggs> hi! any archive-admins around to remove some binaries blocking migration please? LP: #1606469 and LP: #1612180
<ubot5> Launchpad bug 1606469 in deal.ii (Ubuntu) "Remove deal.ii binaries from archs where it is missing build-deps" [Undecided,New] https://launchpad.net/bugs/1606469
<ubot5> Launchpad bug 1612180 in wine-development (Ubuntu) "Please remove wine-developement binaries on armhf" [Undecided,New] https://launchpad.net/bugs/1612180
<bdmurray> infinity: Review pending SRUs I notice wily is still active in LP
<ginggs> thanks slangasek
<ginggs> slangasek: could we also look at removing all packages that build with free pascal on powerpc? LP: #1562480
<ubot5> Launchpad bug 1562480 in glibc (Ubuntu) "fp-compiler not installable on powerpc since glibc 2.23" [High,New] https://launchpad.net/bugs/1562480
<slangasek> hmm, I thought someone was working on fixing that
<ginggs> slangasek: i chatted to infinity briefly about it at debconf; my understanding is that even if the problem did get fixed, fpc would need to be re-bootstrapped and all the packages rebuilt on powerpc anyway - at the moment none of the packages are usable on powerpc
<slangasek> ah
<cjwatson> bdmurray: Some builders are still on wily (RT#92640), so we need to retain the capability to build updates for them.
<bdmurray> cjwatson: ah, okay
#ubuntu-release 2016-08-12
<Mirv> so did you get any analysis on what's blocking the transitions still? the update_output.txt hint sections do not seem any clearer to me today.
<slangasek> Mirv: a new pillow synced in (courtesy of doko's Debian upload) that has set things back for the moment and prevents seeing what else might be blocking
<Mirv> ok thanks slangasek for the pointer
<Mirv> and new glibc is causing a 1000 package queue to each architecture
<acheronuk> as a result of glibc https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830912
<ubot5> Debian bug 830912 in fakeroot "fakeroot complains about missing acl_* symbols" [Normal,Open]
<acheronuk> so 100's of repetitions of
<acheronuk> dlsym(acl_get_file): /usr/lib/x86_64-linux-gnu/libfakeroot/libfakeroot-sysv.so: undefined symbol: acl_get_file
<acheronuk> dlsym(acl_set_fd): /usr/lib/x86_64-linux-gnu/libfakeroot/libfakeroot-sysv.so: undefined symbol: acl_set_fd
<acheronuk> in buildlogs
<xnox> so we need to fix fakeroot it seems
<xnox> why does it not link with libacl ?!
<Mirv> I wonder if non-glibc autopkgtests could be prioritized, otherwise another day will be wasted in not-transitioning
<Mirv> I'd also have my own landings causing thousands of autopkgtests triggered, but I'm pending on landing them to give a chance for the migrations..
<Mirv> but I guess I need to start new landings on top of earlier non-landed landings because I'd also need to do some OTA updates
<Mirv> (non-landed to yakkety)
<xnox> Mirv, yeah and we have a lot of customers wanting new glibc and only a week before feature freeze. It's not like glibc is un-important update either.
<Mirv> xnox: yay! :)
<Mirv> it was three weeks until feature freeze when I started hoping for Qt release pocket migration :)
<Mirv> hopefully autopkgtests would become more scaling at some point
<oSoMoN> dear release team, could I please get some feedback on https://launchpad.net/bugs/1600176 ?
<ubot5> Launchpad bug 1600176 in webbrowser-app (Ubuntu) "[SRU] webbrowser-app bug fixes" [High,New]
<jamespage> cpaelzer, ok dpdk and ovs all uploaded an built
<cpaelzer> jamespage: yeah, but sadly they block in update excuses
<cpaelzer> jamespage: I already started a local adt to debug my test
<cpaelzer> jamespage: some of the tools changed names, I hope it is that simple - but at the same time I have to finish something for smoser before I leave
<cpaelzer> jamespage: I'll give you a ping once I had a deeper look into the failing dep8 test
<cpaelzer> jamespage: also for obvious reasons the dependen ovs 2.5 tests fail - do we need to do something special to mark those two uploads as belonging together?
<LocutusOfBorg> cjwatson, this might be a good moment to make haskell migrate :)
<LocutusOfBorg> not sure what is missing
<LocutusOfBorg> autopkgtest for haskell-hoogle: i386: Test in progress
<LocutusOfBorg> this is "in progress" since some days, meh
<LocutusOfBorg> everything "not considered" brings to that test
<ogra_> can someone please bump the score for https://code.launchpad.net/~snappy-dev/+snap/pi2-kernel/+build/2796
<ogra_> (arm builds are a pain recently :/ )
<cpaelzer> jamespage: I found and fixed the issue in the dpdk dep8 test
<cpaelzer> jamespage: I run it through a full adt once more now, but for prepping - does that already have to be a 16.07-0ubuntu2 to avoid collisions?
<jamespage> cpaelzer, yes
<cpaelzer> jamespage: the git repo is already updated at the same location with an 16.07-0ubuntu2, so is the deb_dpdk packaging repo to stay in sync. But I'll give you a ping once it passed the full adt just to be 100% sure and avoid another reupload
<cpaelzer> jamespage: ok, all three dep8 tests passed on the new version
<dbarth> bdmurray: hey again, the packages for the SRU ref. by https://bugs.launchpad.net/gnome-control-center-signon/+bug/1565772 are now in the UNAPPROVED queue
<ubot5> Launchpad bug 1565772 in gnome-control-center-signon (Ubuntu Xenial) "[SRU] Allow plugins to decide which username to set on new accounts" [Critical,Confirmed]
<dbarth> CI says you have manual controls to move them to -proposed for the verification to start
<bdmurray> dbarth: that's correct, I'll try and have a look today.
<dbarth> bdmurray: thanks
<infinity> slangasek: ^-- Simple review.  As suggested, only addition, not removal, but I *suspect* snapd might be the only consumer (as they're the ones who added it), so maybe UBUNTU_CODENAME can go away in yakkety soon.  We might need to keep it in xenial forever (or have snapd declare a >= dep on base-files, ick)
<infinity> Oh, err, other way, I guess base-files would need a << Breaks on snapd once it's fixed.
<infinity> Double-ick.
<infinity> So probably easier to just keep both in xenial.
<slangasek> infinity: accepted
<infinity> slangasek: Ta.
<bdmurray> infinity: it occured to me that maybe the meta-release file should point to old-release.ubuntu.com instead of archive.ubuntu.com for the UpgradeTool lines for unsupported releases...
<infinity> bdmurray: That seems quite plausibly true.
<infinity> bdmurray: Though, that needs to happen after the backup happens.
<bdmurray> infinity: What backup?
<infinity> bdmurray: The backup to old-releases...
<infinity> bdmurray: ie: wily isn't there yet, which I'll get sorted soon.
<bdmurray> infinity: Sure, so it might be a two step process. Set Supported to 0 then, update UpgradeTool sometime
 * infinity nods.
<bdmurray> Okay, I'll fix it for the old-old releases then.
<wxl> slangasek: thanks for getting the lxqt images spun up. will those appear on the testing tracker at all? or at least be made available to appear on the tracker?
<slangasek> wxl: the changes I made didn't get them added to the tracker, that needs to be done separately
<wxl> slangasek: who would i contact about that?
<slangasek> wxl: well.  I could do it, but not at the moment :)  please follow up to the email thread
<wxl> slangasek: k thx :)
<Ukikie> Speaking of cdimage merge proposals...
#ubuntu-release 2016-08-13
<jbicha> yade's s390x autopkgtest for pyqt5 is holding up progress
<slangasek> pyqt5 causes a regression in yade autopkgtests on s390x; I'm letting yade be broken (force-badtest) to try to let the qt transition progress, or at least see what else is left
<Mirv> slangasek: http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#unity-scope-click would need --all-proposed to pick up fixed unity8
<Mirv> ^ or any other archive admin, please rerun those failed tests with --all-proposed
<Mirv> or is the hint itself actually that specified the older versions:
<Mirv>  Version mismatch, pyqt5 5.6+dfsg-1build1~1 != 5.7+dfsg-1
<Mirv>  Version mismatch, unity-scope-click 0.1.1+16.10.20160705-0ubuntu2 != 0.1.1+16.10.20160808-0ubuntu1
<Mirv> my guess is that yes the hint should be updated regarding those two versions and the unity-scope-click's failed unity8 tests should be rerun with --all-proposed
<LocutusOfBorg> cjwatson, hi, the testsuite for haskell is good, but the package didn't migrate :(
<LocutusOfBorg> I think the transition tracker is in the nice shape
<jbicha> the qt transition is waiting for linux 4.6?
<wxl> slangasek: do you know any reason why our lubuntu-next images don't seem to have built (looking at logs)
#ubuntu-release 2017-08-07
<slangasek> doko: according to http://people.canonical.com/~ubuntu-archive/proposed-migration/artful/update_output_notest.txt pillow (via the libwebp transition) is entangled with perl
<slangasek> it's also entangled with qtwebengine-opensource-src, which is dep-wait in artful-proposed
<slangasek> so I think that gets dealt with by a temporary downgrade and no-change rebuild, since tying this to the Qt 5.9 transition would be unfun++
<slangasek> ... except, well, qtwebengine-opensource-src FTBFS, so digging into that
<cpaelzer> hi, I wanted to ask for bug 1540323 - it is hanging around a while and I want to ensure it isn't forgotten this cycle
<ubot5> bug 1540323 in ubuntu-virt (Ubuntu) "ubuntu-virt is not generated from seeds" [Undecided,Triaged] https://launchpad.net/bugs/1540323
<cpaelzer> The TL;Dr is for an AA to please remove src:ubuntu-virt and all binary packages it builds from Artful.
-queuebot:#ubuntu-release- New binary: winff [i386] (artful-proposed/universe) [1.5.5-3] (no packageset)
-queuebot:#ubuntu-release- New binary: winff [armhf] (artful-proposed/universe) [1.5.5-3] (no packageset)
-queuebot:#ubuntu-release- New binary: winff [amd64] (artful-proposed/universe) [1.5.5-3] (no packageset)
-queuebot:#ubuntu-release- New binary: winff [arm64] (artful-proposed/universe) [1.5.5-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted cheshire-clojure [amd64] (artful-proposed) [5.7.1-1]
-queuebot:#ubuntu-release- New: accepted math-numeric-tower-clojure [amd64] (artful-proposed) [0.0.4-1]
-queuebot:#ubuntu-release- New: accepted python-wither [amd64] (artful-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted winff [arm64] (artful-proposed) [1.5.5-3]
-queuebot:#ubuntu-release- New: accepted winff [i386] (artful-proposed) [1.5.5-3]
-queuebot:#ubuntu-release- New: accepted math-combinatorics-clojure [amd64] (artful-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted winff [amd64] (artful-proposed) [1.5.5-3]
-queuebot:#ubuntu-release- New: accepted medley-clojure [amd64] (artful-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted winff [armhf] (artful-proposed) [1.5.5-3]
-queuebot:#ubuntu-release- New: accepted at-at-clojure [amd64] (artful-proposed) [1.2.0-1]
-queuebot:#ubuntu-release- New: accepted core-match-clojure [amd64] (artful-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted java-jmx-clojure [amd64] (artful-proposed) [0.3.4-1]
-queuebot:#ubuntu-release- New: accepted libundead [amd64] (artful-proposed) [1.0.7-1]
-queuebot:#ubuntu-release- New: accepted libundead [i386] (artful-proposed) [1.0.7-1]
-queuebot:#ubuntu-release- New: accepted weechat-el [amd64] (artful-proposed) [0.3.1-2]
-queuebot:#ubuntu-release- New: accepted bdfproxy [amd64] (artful-proposed) [0.3.9-1]
-queuebot:#ubuntu-release- New: accepted lazymap-clojure [amd64] (artful-proposed) [3.1.1-1]
-queuebot:#ubuntu-release- New: accepted polygen [amd64] (artful-proposed) [1.0.6.ds2-16]
-queuebot:#ubuntu-release- New: accepted java-classpath-clojure [amd64] (artful-proposed) [0.2.3-1]
-queuebot:#ubuntu-release- New: accepted libundead [armhf] (artful-proposed) [1.0.7-1]
<slangasek> apw_: I think your commit of a 'block-all source' hint was accidental; reverting it
<apw_> slangasek, *beep* yes, please kill that
<LocutusOfBorg> per is candidate, thanks slangasek :)
<LocutusOfBorg> can anybody please ignore libreoffice/s390x to make debhelper migrate?
<LocutusOfBorg> any archive admin, can please remove visp on i386? it has been removed long time ago in debian too
<LocutusOfBorg> perl/gsl are blocked by it and I can't parse britney output, because of it (lots of false positive
<LocutusOfBorg> )
<LocutusOfBorg> apw, ^^
<LocutusOfBorg> also, please ignore libffi-platypus-perl/amd64 test
<LocutusOfBorg> with the above two, perl should be ready for britney
<LocutusOfBorg> or really close
-queuebot:#ubuntu-release- New binary: gnome-shell-extension-tilix-dropdown [amd64] (artful-proposed/universe) [5-1] (no packageset)
<LocutusOfBorg> nobody wants to help me in clicking the silo qt publish button?
<mitya57> LocutusOfBorg, hi!
<LocutusOfBorg> welcome back mitya57 <3
<LocutusOfBorg> I hope I didn't mess too much with the silo
<jbicha> LocutusOfBorg: one idea would be to make a new silo without qtwebengine?
<mitya57> LocutusOfBorg, arenât we still blocked by ubuntu-ui-toolkit removal?
<mitya57> jbicha, what is wrong with qtwebengine?
<mitya57> Without it will mean without some other packages too, like pyqt5.
<mitya57> (You are talking about silo 2819 aka Qt 5.9, right?)
<jbicha> ok, I guess you just need an AA admin then
<LocutusOfBorg> qtwebengine is sad on two architectures
<LocutusOfBorg> so, the publish fails
<LocutusOfBorg> we need an AA, indeed
<jbicha>  Publish failed: Failed to build (artful/qt3d-opensource-src-gles, artful/qtdeclarative-opensource-src-gles, artful/qtlocation-opensource-src-gles, artful/qtmultimedia-opensource-src-gles, artful/qtwebengine-opensource-src)
<LocutusOfBorg> also all the -gles packages needs to be removed
<LocutusOfBorg> that one yes
<mitya57> We can always copy everything manually, i.e. using copy-package from lp:ubuntu-archive-tools
<mitya57> But we need an AA to remove the -gles ones, yes.
<LocutusOfBorg> doko, sync gsl?
-queuebot:#ubuntu-release- Unapproved: libvirt (trusty-proposed/main) [1.2.2-0ubuntu13.1.20 => 1.2.2-0ubuntu13.1.21] (kubuntu, ubuntu-desktop, ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: libvirt (xenial-proposed/main) [1.3.1-1ubuntu10.12 => 1.3.1-1ubuntu10.13] (ubuntu-server, virt)
<doko> LocutusOfBorg: please don't. will trigger rebuilds again
<LocutusOfBorg> will also need new queue
<LocutusOfBorg> this is why I asked :)
<doko> slangasek: remove the version from -proposed for now?
<doko> and it's broken anyway ...
<doko>  trying to overwrite '/usr/lib/x86_64-linux-gnu/libgslcblas.so.0.0.0', which is also in package libgsl23:amd64 2.4+dfsg-3
<doko> dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
-queuebot:#ubuntu-release- Unapproved: rejected xorg-server [source] (xenial-proposed) [2:1.18.4-0ubuntu0.4]
-queuebot:#ubuntu-release- Unapproved: xorg-server (xenial-proposed/main) [2:1.18.4-0ubuntu0.3 => 2:1.18.4-0ubuntu0.4] (desktop-core, xorg)
-queuebot:#ubuntu-release- Unapproved: rejected xorg-server [source] (xenial-proposed) [2:1.18.4-0ubuntu0.4]
-queuebot:#ubuntu-release- Unapproved: xorg-server (xenial-proposed/main) [2:1.18.4-0ubuntu0.3 => 2:1.18.4-0ubuntu0.4] (desktop-core, xorg)
<ahoneybun> heyo could anyone look at : https://code.launchpad.net/~aaronhoneycutt/ubiquity-slideshow-ubuntu/artful3
<ahoneybun> cyphermox: maybe? ;)
<cyphermox> of course
<cyphermox> someone else was pointing me at it before
<ahoneybun> greyland I believe
<cyphermox> yep
<cyphermox> ahoneybun: I apologize, reviewing html just tends to not quite get my full attention quickly
<ahoneybun> I started from the bottom on it
<ahoneybun> cyphermox: it's all good
-queuebot:#ubuntu-release- Unapproved: rejected miral [sync] (zesty-proposed) [1.3.3+17.04.20170714.1-0ubuntu1]
<ahoneybun> I'm sure it will have those div errors but I'm not sure how you fixed them
<ahoneybun> all tests show that they are ok as is
<cyphermox> did you try to build it? the unclosed div failures would happen there
 * cyphermox merges the code now
<ahoneybun> no but I did merge mine into the main and it gave no errors
<ahoneybun> I don't remember how to build that
<ahoneybun> I don't understand what the build does differnt
<ahoneybun> *different
<ahoneybun> must be that lintian crap
<cyphermox> ok, let me look at it for a second and I'll explain how to build it and what the errors mean if there are any
<ahoneybun> alrightly
<ahoneybun> thanks
-queuebot:#ubuntu-release- Unapproved: accepted gnome-applets [source] (zesty-proposed) [3.22.0-2ubuntu0.2]
<tsimonq2> mitya57: copy-package won't work, remember the weird compilation error when compiling using a Qt lower than 5.8?
<tsimonq2> mitya57: We need to copy binaries from what I can tell
<tsimonq2> mitya57: And yes we'll still need to take care of ubuntu-ui-toolkit, but I figure we keep having to update packages in the PPA with newly updated things (telegram-desktop anyone?) so landing it in -proposed even if it stays there for a week or two isn't that bad of an idea in my eyes.
-queuebot:#ubuntu-release- New binary: libjs-emojify [amd64] (artful-proposed/none) [1.1.0+dfsg-1] (no packageset)
<cyphermox> ahoneybun: do you run ./test-slideshow ?
<cyphermox> ahoneybun: I'd have some fixes to apply so the spacing is the same between slides, etc.
<ahoneybun> Yep
<ahoneybun> which spacing?
<slangasek> xnox: what do you know today wrt systemd and autopkgtests?  I'm ignoring the perl systemd test failure to get perl as a candidate, but I guess a generally passing test would make everyone happier
<tkamppeter> Hi, I have a problem with ippusbxd. It is stuck in artful-proposed, probably because it does not build on the exotic PPC64 arch. See http://people.canonical.com/~ubuntu-archive/proposed-migration/artful/update_excuses.html#ippusbxd
<tkamppeter> Anyone can help me to get it into the artful release?
<nacc> tkamppeter: i'm looking (i can try and reproduce and debug it on a machine in the lab if need be)
<nacc> tkamppeter: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865026
<ubot5> Debian bug 865026 in libusb-1.0-0-dev "libusb.h: __linux usage makes ippusbxd FTBFS on ppc" [Serious,Fixed]
<tkamppeter> nacc, this would be great. Please do so.
<nacc> tkamppeter: it might just need a rebuild now
<nacc> tkamppeter: i'll trigger it
<tkamppeter> OK.
<tkamppeter> The Debian bug shows exactly what the log of the failed ippusbxd build shows.
<nacc> tkamppeter: yep, the build that failed in LP was using -1, so it just needs to rerun using -2 (now in artful)
<nacc> tkamppeter: and it just succeeded :)
<tkamppeter> I have seen the successful build, too. Thank you very much.
<nacc> tkamppeter: yw
<cyphermox> ahoneybun: basically, padding-top; or spacing between paragraphs, or use of * instead of ul/li tags, etc ;)
<cyphermox> spacing around the icon at the bottom right of slides too
<cyphermox> just so that everything looks consistent
<slangasek> doko: LocutusOfBorg highlighted vips/i386 for removal because "it has been removed a long time ago in Debian" but that's not true and it looks like the build failure is simply due to using wrong math compiler flags on i386 ( vpMath::equal(regular_sumSquare, sse_sumSquare, std::numeric_limits<double>::epsilon()) ).  Do you know offhand what the correct compiler flags are these days for sane
<slangasek> floating point on i386?
<cyphermox> ahoneybun: my suggestion: http://paste.ubuntu.com/25264527/
<doko> slangasek: you could try with -ffloat-store
<slangasek> doko: will do, thanks
<slangasek> doko: also, looks like this package FTBFS in Debian with illegal instruction, so there's some other problems there, heh
<ginggs> slangasek: swarmoflocusts was referring to visp not vips
<doko> slangasek: at a first glance, I don't see any obvious math configury in the vips build log
<slangasek> ginggs: yes, sorry, transposition typo on my part there
<slangasek> doko: visp, as ginggs says
<slangasek> finger race condition with dvorak keymap
<slangasek> doko: thanks, confirmed success with -ffloat-store
-queuebot:#ubuntu-release- Unapproved: postfix (xenial-proposed/main) [3.1.0-3 => 3.1.0-3ubuntu0.1] (core)
<wallyweek> Hello everyone!
<wallyweek> I'm looking for help to migrate mame package from proposal to release
<wallyweek> can anyone help me please? :)
<wallyweek> update_excuses says it's a valid candidate
<wallyweek> but it's still stuck after 2 days
<nacc> wallyweek: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt implies that src:mame breaks mess-desktop-entries
<nacc> wallyweek: that is the mame from the new package
<wallyweek> I see
<wallyweek> but mess-desktop-entries was in mess package
<wallyweek> which is long gone now
<nacc> wallyweek: hrm? mess-desktop-entries is in artful still
<wallyweek> mess was already a transitional package back in version 0.182
<nacc> wallyweek: it's a binary and source package name
<wallyweek> ok, I found it, even if I can't figure out where it comes from... :/
<wallyweek> I'll have a closer look
<wallyweek> Please, , what should I do should I find it's to be removed from repo?
<nacc> wallyweek: hrm? you mean mess-desktop-entries should be removed?
<wallyweek> I'll talk about this with Jordi Mallach (we are both maintainers in Debian) and see
<wallyweek> but it could be an option
<wallyweek> mess doesn't exist anymore since source merge occured into mame
<wallyweek> so I see no reason for mess-desktop-entries to be in repo
<nacc> wallyweek: right, binary mess does exist, though
<nacc> wallyweek: you're referring to src:mess?
<wallyweek> nacc: no, I'm referring to binary mess and mess-data
<wallyweek> nacc: both mame and mess already shared source, they were built with different tag in the same makefile
<nacc> wallyweek: ah i see
<nacc> wallyweek: yeah, it seems like mess and mess-data could have been deleteda fter 16.04?
<wallyweek> nacc: yes, they could have been
<nacc> wallyweek: but even so, that won't fix this issue (afaict), mess-desktop-entries is from src:mess-desktop-entries
<nacc> wallyweek: unless you mean it also can be deleted if mess is deleted?
<wallyweek> nacc: yes, that's what I mean
<nacc> wallyweek: if so, i'd file a bug and subscribe ~ubuntu-archive
<wallyweek> nacc: ok!
<wallyweek> nacc: thank you for your help, I'll try to sort this out before FF
<nacc> wallyweek: np, sorry for being a bit dense :)
-queuebot:#ubuntu-release- New binary: blag-fortune [amd64] (artful-proposed/universe) [1.2-1] (no packageset)
<doko> tsimonq2: could you or some other kubuntu guy look at calligra? last package blocking the gsl transition
<valorie> doko: it's very late for acheronuk and clivejo
<valorie> and I believe that tsimonq2 is at work
<valorie> :(
<valorie> santa_ doesn't seem to be around either
<doko> well, please forward it
<valorie> I will, thanks
-queuebot:#ubuntu-release- New binary: gjs [ppc64el] (artful-proposed/main) [1.49.90-0ubuntu0~artful1] (desktop-extra, mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gjs [amd64] (artful-proposed/main) [1.49.90-0ubuntu0~artful1] (desktop-extra, mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gjs [i386] (artful-proposed/main) [1.49.90-0ubuntu0~artful1] (desktop-extra, mozilla, ubuntu-desktop)
<valorie> I'll drop a note to the list as well
<acheronuk> doko: looking
-queuebot:#ubuntu-release- New: accepted blag-fortune [amd64] (artful-proposed) [1.2-1]
-queuebot:#ubuntu-release- New: accepted libjs-emojify [amd64] (artful-proposed) [1.1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted gnome-shell-extension-tilix-dropdown [amd64] (artful-proposed) [5-1]
-queuebot:#ubuntu-release- New binary: gjs [arm64] (artful-proposed/main) [1.49.90-0ubuntu0~artful1] (desktop-extra, mozilla, ubuntu-desktop)
<valorie> oooo, what are you doing up so late, acheronuk?
<jbicha> oops
<jbicha> could an Archive Admin reject gjs for now?
<acheronuk> valorie: not quite 1am yet!
-queuebot:#ubuntu-release- Unapproved: logcheck (trusty-proposed/main) [1.3.16 => 1.3.16ubuntu0.1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: gjs [armhf] (artful-proposed/main) [1.49.90-0ubuntu0~artful1] (desktop-extra, mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: logcheck (xenial-proposed/main) [1.3.17 => 1.3.17ubuntu0.1] (ubuntu-server)
#ubuntu-release 2017-08-08
<tsimonq2> doko: Looks like acheronuk got it, yep I was at work.
 * valorie knows all, sees all
<tsimonq2> Creepy!
-queuebot:#ubuntu-release- New binary: insighttoolkit4 [ppc64el] (artful-proposed/universe) [4.12.0-dfsg1-1ubuntu2] (no packageset)
<slangasek> jbicha: a binary reject of gjs?
<jbicha> slangasek: yes please
<slangasek> jbicha: that's not usual; what's the status of fixing the source?
<jbicha> the unusual version number is because that upload was intended for a ppa
<slangasek> jbicha: so should I also remove the source from artful-proposed?
<jbicha> we're discussing the mozjs52 transition at tomorrow's Desktop meeting so I accidentally jumped the gun
-queuebot:#ubuntu-release- New: rejected gjs [amd64] (artful-proposed) [1.49.90-0ubuntu0~artful1]
-queuebot:#ubuntu-release- New: rejected gjs [armhf] (artful-proposed) [1.49.90-0ubuntu0~artful1]
<jbicha> I think it's fine to leave the source there for now
-queuebot:#ubuntu-release- New: rejected gjs [ppc64el] (artful-proposed) [1.49.90-0ubuntu0~artful1]
-queuebot:#ubuntu-release- New: rejected gjs [arm64] (artful-proposed) [1.49.90-0ubuntu0~artful1]
-queuebot:#ubuntu-release- New: rejected gjs [i386] (artful-proposed) [1.49.90-0ubuntu0~artful1]
<slangasek> jbicha: but you don't need it there and you're not getting the binaries back - so I've gone ahead and removed it anyway
<slangasek> package in -proposed that is expected to never migrate> zot
<jbicha> if we didn't care about s390x, the binaries might have been fine, but thanks!
<slangasek> it might technically be possible to resuscitate both source and binaries later without a rebuild, but tbf who cares, it's cheaper for you to reupload and let the NEW process work than to get someone to fish things out of the librarian
<tsimonq2> slangasek: Could you please badtest libreoffice/s390x in artful triggered by debhelper/10.7.2ubuntu2 so debhelper can migrate? From what I remember it's a kernel regression that's unrelated to debhelper. I asked acheronuk to retrigger libreoffice/s390x with itself as a trigger at the beginning of the day today and it fails.
<slangasek> tsimonq2: there are a mix of passes and failures for libreoffice/s390x recently; I'm going to need some more evidence that it's a testbed problem
<slangasek> tsimonq2: n/m, I found my previous hint for i386+s390x about this issue
<slangasek> tsimonq2: providing a reference to an existing hint in lp:~ubuntu-release/britney/hints-ubuntu is usually the most efficient way to get me to ack a badtest :)
<slangasek> (done)
-queuebot:#ubuntu-release- New binary: insighttoolkit4 [s390x] (artful-proposed/universe) [4.12.0-dfsg1-1ubuntu2] (no packageset)
<tsimonq2> slangasek: Thanks!
<ahoneybun> cyphermox: working on your idea
<ahoneybun> that does not look better lol
-queuebot:#ubuntu-release- Unapproved: lxd (xenial-backports/main) [2.15-0ubuntu6~ubuntu16.04.1 => 2.16-0ubuntu2~ubuntu16.04.1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lxd (zesty-backports/main) [2.15-0ubuntu6~ubuntu17.04.1 => 2.16-0ubuntu2~ubuntu17.04.1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (xenial-backports) [2.16-0ubuntu2~ubuntu16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (zesty-backports) [2.16-0ubuntu2~ubuntu17.04.1]
-queuebot:#ubuntu-release- New binary: courier-unicode [amd64] (artful-proposed/universe) [2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: courier-unicode [ppc64el] (artful-proposed/universe) [2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: courier-unicode [s390x] (artful-proposed/universe) [2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: courier-unicode [arm64] (artful-proposed/universe) [2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: courier-unicode [i386] (artful-proposed/universe) [2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: courier-unicode [armhf] (artful-proposed/universe) [2.0-1] (no packageset)
<ginggs> would someone please update the winff hint? maybe 'force-badtest winff/all/armhf' is best, since it hasn't passed since trusty
<LocutusOfBorg> hello slangasek what about doing the qt5.9 dance instead of trying to patch 5.7 against the new gcc?
<LocutusOfBorg> it is ready to land, just needing an AA
-queuebot:#ubuntu-release- Unapproved: magnum (zesty-proposed/universe) [4.1.0-0ubuntu1 => 4.1.3-0ubuntu0.17.04.1] (no packageset)
<acheronuk> LocutusOfBorg: I would guess he's asleep now. I'm test building 5.7.1 in a ppa with opensuse/gentoo's patch, but I agree that getting 5.9 transition landed with be far preferable
-queuebot:#ubuntu-release- Unapproved: ubuntu-image (xenial-proposed/universe) [1.1+16.04ubuntu3 => 1.1+16.04ubuntu4] (no packageset)
<mitya57> tsimonq2, I am personally fine with having it stuck in proposed for a week or two, but others may get not very happy about it.
<mitya57> So far I think that if someone still needs ubuntu-ui-toolkit for their packages, *they* should take care of updating it to 5.9.
<mitya57> And I do not know which packages we are talking about. If it is just checkbox, then we can revert to the pre-Qt version of it.
-queuebot:#ubuntu-release- New binary: xml-rpc-el [amd64] (artful-proposed/none) [1.6.12-2] (no packageset)
-queuebot:#ubuntu-release- New binary: debpaste-el [amd64] (artful-proposed/none) [0.1.5-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: landscape-client (trusty-proposed/main) [14.12-0ubuntu5.14.04 => 14.12-0ubuntu6.14.04] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: packagekit (xenial-proposed/main) [0.8.17-4ubuntu6~gcc5.4ubuntu1.1 => 0.8.17-4ubuntu6~gcc5.4ubuntu1.2] (kubuntu, ubuntu-desktop)
<tsimonq2> mitya57: I remember Qt being in -proposed for a month and a half when Unity 8 was still actively developed... one or two weeks is nothing right now ;)
<tsimonq2> mitya57: But yeah, this transition will be unusual because we're working out the Unity 8 stuff. The next Qt transition *should* be easier.
-queuebot:#ubuntu-release- Unapproved: accepted landscape-client [source] (trusty-proposed) [14.12-0ubuntu6.14.04]
<cpaelzer> ping on bug 1540323 for an aa to remove packages
<ubot5> bug 1540323 in ubuntu-virt (Ubuntu) "ubuntu-virt is not generated from seeds" [Undecided,Triaged] https://launchpad.net/bugs/1540323
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (xenial-proposed) [1.1+16.04ubuntu4]
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (trusty-proposed/partner) [1:20170711.1-0ubuntu0.14.04.1 => 1:20170808.1-0ubuntu0.14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (zesty-proposed/partner) [1:20170711.1-0ubuntu0.17.04.1 => 1:20170808.1-0ubuntu0.17.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20170711.1-0ubuntu0.16.04.1 => 1:20170808.1-0ubuntu0.16.04.1] (no packageset)
<xnox> Laney, slangasek - please hint util-linux s390-tools to go in together.
<slangasek> xnox: what kind of hint are you looking for?  AIUI s390-tools is tied to net-snmp transition
<slangasek> which means it's tied to the big transition
<xnox> slangasek, it is tied, I do not see it tried together with the rest. E.g. util-linux and s390-tools are not tried together, despite both being valid candidates.
<xnox> slangasek, as far as i can tell the two are installable in both -proposed and -release and thus those two leaf packages can migrate irrespective of the big transition.
 * xnox is possibly wrong, but the only uninstallable currently listed in output is due to not trying the two together.
-queuebot:#ubuntu-release- Unapproved: accepted pollinate [source] (xenial-proposed) [4.25-0ubuntu1~16.04.1]
<slangasek> xnox: it's not tried together with the rest because util-linux doesn't need to go in together, it only needs to go in after (because of the one-way breaks)
<slangasek> xnox: so no manual hinting needed, we just need to get p-m to pass the stone
<xnox> hm.
<xnox> ok.
<xnox> slangasek, any idea why http://people.canonical.com/~ubuntu-archive/transitions/ocaml.html ocaml is no longer installable? is that also in the big transition of doom now?
<slangasek> xnox: according to http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt output, ocaml is not tied in
-queuebot:#ubuntu-release- New binary: libgtop2 [amd64] (artful-proposed/main) [2.37.90-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libgtop2 [ppc64el] (artful-proposed/main) [2.37.90-0ubuntu1] (ubuntu-desktop)
<coreycb> hi release team, i synced sphinx from experimental and it's causing problems. can we reject it from artful-proposed and stick with 1.5.6-2 for now?
-queuebot:#ubuntu-release- New binary: libgtop2 [i386] (artful-proposed/main) [2.37.90-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libgtop2 [s390x] (artful-proposed/main) [2.37.90-0ubuntu1] (ubuntu-desktop)
<slangasek> addressed coreycb's request
-queuebot:#ubuntu-release- New binary: libgtop2 [arm64] (artful-proposed/main) [2.37.90-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted pollinate [source] (trusty-proposed) [4.25-0ubuntu1~14.04.1]
-queuebot:#ubuntu-release- New binary: libgtop2 [armhf] (artful-proposed/main) [2.37.90-0ubuntu1] (ubuntu-desktop)
<ginggs> would someone please update the winff hint? maybe 'force-badtest winff/all/armhf' is best, since it hasn't passed since trusty
<ginggs> slangasek: ^ seeing you are around :)
<slangasek> ginggs: /all/ hinting means that if and when the test is fixed we don't pick it up. the solution with least collateral damage is LP: #1700668, if you can convince Laney of the design ;)
<ubot5> Launchpad bug 1700668 in britney "make it easier to reset baseline for autopkgtests that regress in release" [Undecided,New] https://launchpad.net/bugs/1700668
<slangasek> we need a tool added to ubuntu-archive-tools that scans update_excuses for all regressions and matches them to existing badtest hints for a different version
<slangasek> anyone want to write that? :)
<ginggs> slangasek: elbrus cares about autopkgtests, so if it does start to pass on armhf i think he'll let us know
<ginggs> but yeah, we do need a general solution
<slangasek> I don't assume elbrus would notify us to remove a hint that's letting us ignore failures
<slangasek> doko: ah, thanks for the pillow delete - let me also resurrect the no-change rebuild, then
<xnox> slangasek, somehow i'm not sure how i can help with migrations. I think i will work on making ocaml stack installable and migratable again the bits that got synced/updated. but that is about it.
<xnox> and the systemd adt regresions.
<slangasek> xnox: well, for example, anything that's listed on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt as broken by the big migration, but not listed on http://people.canonical.com/~ubuntu-archive/proposed-migration/artful/update_output_notest.txt , needs sorting out what tests are failing
<doko> xnox: you could look at lp: #1709396
<ubot5> Launchpad bug 1709396 in gcc-7 (Ubuntu) "gcc-7/i386|armhf 12.1.2 FTBFS" [Undecided,New] https://launchpad.net/bugs/1709396
<slangasek> xnox: (but ignore all the kde stuff there, because that's just waiting on tests to finish for qtwebengine-opensource-src)
<slangasek> doko: I now have a "clean" autopkgtest of linux on armhf against new binutils/gcc showing a build failure; can you confirm this is a kernel bug, not a toolchain bug?
<xnox> doko, or shall i fix linux/zfs s390x given that i ported that?
<slangasek> hinting that will re-unblock binutils
<slangasek> xnox: also valuable :)
<slangasek> xnox: we've overridden that test for now, but obviously we need kernels to be uploadable
<slangasek> xnox: mysql-5.7 also needs sorting (i386 test failure)
<slangasek> tdaitx: you want to take a corner of this puzzle?
<doko> slangasek: afaics this is the first build of one of the user space tools built using GCC 7, triggered by a warning turned into an error by the build process
<slangasek> doko: so the message is correct / has precedent, and the kernel needs fixing. thanks, hinting
<tdaitx> slangasek, which one you are referring to?
<slangasek> tdaitx: the mega-transition clogging up proposed-migration; see above for a list of possible +1 maintenance tasks to work on
<tdaitx> sure
<slangasek> tdaitx: if you take one, please let us know which it is :)
<tdaitx> will start on that after lunch
<xnox> slangasek, please clean http://people.canonical.com/~ubuntu-archive/nbs.html
<doko> xnox: done
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (trusty-proposed) [1:20170808.1-0ubuntu0.14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (zesty-proposed) [1:20170808.1-0ubuntu0.17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20170808.1-0ubuntu0.16.04.1]
<xnox> http://people.canonical.com/~ubuntu-archive/architecture-mismatches.html is odd no?
-queuebot:#ubuntu-release- Unapproved: accepted postfix [source] (xenial-proposed) [3.1.0-3ubuntu0.1]
<slangasek> a small tool that may help people deciphering the transition: https://code.launchpad.net/~vorlon/ubuntu-archive-tools/migration-blocked-by-tests
<tsimonq2> slangasek: awesome! :D
<slangasek> further enhancement would be to make that script track down which source package's failing test is at issue
<slangasek> skiptest'ing pillow (it was a candidate once before, we don't need to wait for re-testing).  that should clear a lot of the underbrush
<cyphermox> anyone already looking at libgtk2-perl?
<cyphermox> (failing test there)
<cyphermox> ahoneybun: what do you mean does not look better? maybe we should communicate by screenshot... I mean, if you're happy with the current state of the slideshow as it is in your original merge, I'll just upload that, but it really does look really bad to me here when running test-slideshow.
<cyphermox> nevermind about libgtk2-perl, the test was not run with the same version
<slangasek> anyone know offhand what's eating the buildd queue?
<slangasek> oh hey look, pillow et al. migrated
<tsimonq2> Lots of private jobs... :|
<slangasek> rbalint1: hi, what can we say about grok? (libevent transition)
<infinity> slangasek: iz livepatch.
<slangasek> infinity: k
<slangasek> rbalint1: looks like a wrong version comparison for gperf, is there a fix in flight anywhere?
<slangasek> xnox: so you just uploaded hhvm? wasn't the version in -proposed already ready to migrate?
<slangasek> claiming watchcatd
<cyphermox> looking at picviz
<cyphermox> or has that already been taken?
<xnox> slangasek, the one in proposed was not good enough, and not if ftbfs with gcc-7
<slangasek> xnox: 'not good enough' how?  was it not a candidate for migration with perl etc?
<tsimonq2> Could someone on the SRU team please look at bug 1133477 and bug 1708619? The former of which is important to have because without it, there's potential data loss in Nautilus and Caja, and the latter is a regression in the audio applet in Lubuntu from 16.10 to 17.04 which should get fixed soon...
<ubot5> bug 1133477 in gvfs (Ubuntu Xenial) "[SRU] cut-n-paste move files got stuck forever" [Undecided,Fix committed] https://launchpad.net/bugs/1133477
<ubot5> bug 1708619 in indicator-sound-gtk2 (Ubuntu Zesty) "[SRU] sound settings does nothing - sound menu of the indicator applet" [Undecided,In progress] https://launchpad.net/bugs/1708619
<tsimonq2> Both of which have been uploaded to the queues already, I just think the former is extremely important and worth poking about (the latter is less important but still annoying). :)
<rbasak> tsimonq2: I'm EOD now, but please poke me tomorrow (it's my SRU day tomorrow) if you don't get a review before then.
<tsimonq2> rbasak: Ok, thank you.
<slangasek> rbalint: where would I find API docs for libevent explaining the changes from 2.0 to 2.1?  ev_arg and ev_flags seem to have disappeared without a trace
<rbasak> I say that, but I'm still working, unwinding my stack :-/
-queuebot:#ubuntu-release- New source: python-certbot-apache (xenial-proposed/primary) [0.14.2-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: python-acme (xenial-proposed/universe) [0.4.1-1 => 0.14.2-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-letsencrypt (xenial-proposed/universe) [0.4.1-1 => 0.4.1-1ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-certbot-apache (zesty-proposed/universe) [0.10.2-1 => 0.14.2-0ubuntu0.17.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-certbot (zesty-proposed/universe) [0.10.2-1 => 0.14.2-0ubuntu0.17.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-letsencrypt-apache (xenial-proposed/universe) [0.4.1-1 => 0.4.1-1ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-certbot-nginx (zesty-proposed/universe) [0.10.2-1 => 0.14.2-0ubuntu0.17.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-acme (zesty-proposed/universe) [0.10.2-1 => 0.14.2-0ubuntu0.17.04.1] (no packageset)
-queuebot:#ubuntu-release- New source: python-certbot-nginx (xenial-proposed/primary) [0.14.2-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- New source: python-certbot (xenial-proposed/primary) [0.14.2-0ubuntu0.16.04.1]
<xnox> i wish gtk2 and qt4 were dead =)
<acheronuk> +1
<tsimonq2> +1
<tsimonq2> xnox: I'd like to eventually see if we could get Qt 4 off of all the images (well, Kubuntu and Lubuntu Next) and see if we could get it out of the archive after that.
<tsimonq2> But I think I'll do a better analysis when 18.10 opens for development.
<tsimonq2> Meanwhile, Lubuntu will kill GTK 2 shortly, I don't think it would be off to suggest that 18.10 will be that cycle.
<tsimonq2> s/off/far off/
<tsimonq2> xnox: But Qt 4 will be quicker than GTK 2 from what I can tell :P
<acheronuk> libreoffice-kde is still Qt4 :(
<tsimonq2> acheronuk: Maybe in the next year, something can be done to fix that...
<acheronuk> yep. could get quite close to no KDE4 on our iso if not for that
<tsimonq2> For sure
<Ukikie> -1
<tsimonq2> Ukikie: oh?
<rbalint> slangasek: there is whatsnew-2.1.txt.gz but this change is not covered, i rely on git history to understand the change
<rbalint> slangasek: if you haven't started fixing the affected package i will do it and don't wait for Debian maintainers
<slangasek> rbalint: I hadn't made any progress, feel free to take it (watchdogd)
<rbalint> slangasek: ok, i take it then
<slangasek> rbalint: sorry, watchcatd not watchdogd :)
<rbalint> slangasek: yes, i got it :-)
<slangasek> grok upload fixed
<cyphermox> picviz done
<cyphermox> I'd do lldpd now
<slangasek> mdeslaur, rbasak: any insights into the mysql-5.7/i386 autopkgtest failure?
<rbasak> slangasek: I was going to ask someone upstream but he's on vacation until Monday.
<slangasek> rbasak: k. do you have any more info beyond what's currently in the log?
<rbasak> "Failing test(s): main.mysql_upgrade"
<rbasak> I think that test has been unstable in the past.
<slangasek> retrying it
<slangasek> and yes, it does seem to be the same error seen previously with 5.7.18-0ubuntu1
<rbasak> https://anonscm.debian.org/cgit/pkg-mysql/mysql.git/commit/?id=b89cf68d7517c4400a4bd76b6d2a49d24518a8ed may be relevant. It'll be in the next merge.
<slangasek> rbasak: hinted for now, thanks
<rbasak> (which was actually blocked on my review, and I'd +1 but we got trumped by security because I was slow :-
<rbasak> (
<cyphermox> slangasek: has update-output-helper never been merged into ubuntu-archive-tools yet?
<slangasek> cyphermox: no, I was never able to wrap my head around its usage to the point where I found it consistently helpful, so I haven't ever merged it
<cyphermox> ok
<cyphermox> well it was broken now anyway due to authenticating package sources
<slangasek> acheronuk: thanks for cleaning up the qtwebengine-opensource-src mess.  There is a failing autopkgtest now, http://autopkgtest.ubuntu.com/packages/k/kdepim-addons/artful/armhf - is there any chance this is introduced by qtwebengine, or is it a false positive?  (And if it is a real regression, should we care or should we just hint it in knowing that 5.9 is around the corner?)
<slangasek> qtwebengine is possibly the only package currently blocking wrt tests.  we also need gcc-7 ready to go again, webauth (available in the next run), watchcatd, hhvm (which could be removed), and then we might actually be done?
<slangasek> that, and a kernel unblocked (apw?)
-queuebot:#ubuntu-release- New binary: insighttoolkit4 [armhf] (artful-proposed/universe) [4.12.0-dfsg1-1ubuntu2] (no packageset)
<mwhudson> so why the heck is python-urllib3 not migrating
<mwhudson> ah it needs to migrate with requests i think
<mwhudson> which is blocked by python-pydap tests failing
<slangasek> mwhudson: because of some sort of s390x-specific breakage, AFAICS from update_output
<mwhudson> slangasek: how do you get that?
<slangasek> mwhudson: the uninstallables count is only increased for s390x
<mwhudson> skipped: python-urllib3 (0, 23, 9)
<mwhudson>     got: 92+0: a-7:a-7:a-7:i-59:p-6:s-6
<mwhudson> ?
<slangasek> mwhudson: ah, I refresh and I get a different list. so this is actually the funny business of reporting arch: all packages against a random arch
<mwhudson> yeah i think so
<mwhudson> i still don't understand update_output but it's definitely not going to migrate without requests also migrating
<slangasek> right
#ubuntu-release 2017-08-09
 * mwhudson afk for a bit
<jbicha> slangasek: please consider ignoring test failures for current version of nemo & cinnamon-control-center
<jbicha> their tests are failing because of https://bugs.debian.org/810866
<ubot5> Debian bug 810866 in gedit-plugins "gedit-plugins: not installable due to Depends: python3 (< 3.5)" [Grave,Open]
<jbicha> actually: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868473
<ubot5> Debian bug 868473 in dh-acc "dh-acc: Incorrect usage of doit (Dh_Lib)" [Important,Open]
<mwhudson> something in proposed breaks python-pydap really badly
<mwhudson> or maybe it's just that the version of python-pydab in proposed is broken
<mwhudson> can someone mark mash/1.1.1-2build1/armhf as badtest?
<mwhudson> hm this is a bad timezone for finding release team people
<mwhudson> infinity: around? or slangasek
<slangasek> mwhudson: done
<mwhudson> thanks
<mwhudson> now looking at watchcatd which ftbfs from libevent changes?
<slangasek> jbicha: sorry, no time to look at that right now
<slangasek> mwhudson: yeah I asked rbalint about that earlier and he said he would look at it
<mwhudson> oh ok
<mwhudson> otherwise it seems to be ns3 (depends on gcc7 migrating to migrate?) and linux blocking the perl stuff?
<slangasek> mwhudson: yeah more or less
<mwhudson> ahh boo i got python-pydap/armhf to pass just too late for the last britney run
<mwhudson> (for requests)
<rbalint> slangasek: I've nmu-d watchcatd in Debian and now it builds
<slangasek> rbalint: thanks.  Can you post the source so we can upload without waiting for LP to pick it up from Debian?
<slangasek> (maybe not relevant since gcc-7 will be a while yet... so don't go to too much effort)
<acheronuk> slangasek: did that test against qtwebengine fix on a retry? I see no regression there now
<slangasek> acheronuk: it did
<acheronuk> :)
<cpaelzer> Hi I had a gating message on SRU phasing for the SRU on bug 1705132
<ubot5> bug 1705132 in Ubuntu Cloud Archive ocata "Large memory guests, "error: monitor socket did not show up: No such file or directory"" [Medium,Fix committed] https://launchpad.net/bugs/1705132
<cpaelzer> The case is checked, the bug updated for documentation and the SRU phasing should be ramped up again
<cpaelzer> anyone here atm who can do so for me?
 * mwhudson wtfs at the pytest-pylint autopkgtest failure
<mwhudson> oh probably needs all-proposed=1
<mwhudson> next: why dos udisks2 fail all the time on ppc64el
-queuebot:#ubuntu-release- New sync: xchat (artful-proposed/primary) [2.8.8-8]
<locutus_> good morning, mitya57 I'm copying manually stuff from silo (qt)
<locutus_> if I understand correctly, we will need anyway to have them approved by an AA
<apw> if the silo says you have stuff that means a new review, yes, it needs to be done before
<locutus_> mm I don't understand the answer, sorry!
 * locutus_ is trying to setup his BNC
<apw> cpaelzer, i think i can do that ... do you know what level it had reached ?
<cpaelzer> apw: yes the sru page states that
<cpaelzer> 40% it was
<cpaelzer> http://people.canonical.com/~ubuntu-archive/phased-updates.html
<cpaelzer> you set 60% now is that correct apw?
<apw> i did not do anything yet
<cpaelzer> hmm on the link I sent it is at 60% now
<cpaelzer> it was at "0 formerly 40%" this morning still
<cpaelzer> apw: maybe another sru member did that without updateing the bug or IRC?
<apw> perhaps indeed
<cpaelzer> apw: while I have your ear - might I ask if you are an archive admin as well?
<locutus_> fortunately he is :)
<cpaelzer> I'm looking for some attention to bug 1540323 for days (weeks actually)
<ubot5> bug 1540323 in ubuntu-virt (Ubuntu) "ubuntu-virt is not generated from seeds" [Undecided,Triaged] https://launchpad.net/bugs/1540323
<cpaelzer> about removing src:ubuntu-virt
<cpaelzer> If you can't look at that now I'm fine but if you'd have a hint how/where to ask better for attention that would be highly welcome
<cpaelzer> I let the bug with AA subscribed for a few weeks and then pinged here, but I assume that tasks is a less fun one so people avoid it :-)
<cpaelzer> locutus_: btw are freed from the borg now, what happened?
<locutus_> [12:08:51] * LocutusOfBorg (LocutusOfB@gateway/shell/panicbnc/x-nassxcdmfxswyxjt) has joined
<locutus_> I just need to understand how to connect to that BNC
<locutus_> you can't leave borg community
<cpaelzer> umm there are examples ...
<cpaelzer> anyway - if there is anything I can do better on the need for AA support please let me know
<cpaelzer> leaving a while for lunch now
<locutus_> indeed, some few examples
<apw> cpaelzer, ok confirmed the archive thinks that is at 60% so we will ignore it
<apw> cpaelzer, removed
-queuebot:#ubuntu-release- New: accepted courier-unicode [amd64] (artful-proposed) [2.0-1]
-queuebot:#ubuntu-release- New: accepted courier-unicode [armhf] (artful-proposed) [2.0-1]
-queuebot:#ubuntu-release- New: accepted courier-unicode [ppc64el] (artful-proposed) [2.0-1]
-queuebot:#ubuntu-release- New: accepted debpaste-el [amd64] (artful-proposed) [0.1.5-2]
-queuebot:#ubuntu-release- New: accepted courier-unicode [arm64] (artful-proposed) [2.0-1]
-queuebot:#ubuntu-release- New: accepted courier-unicode [s390x] (artful-proposed) [2.0-1]
-queuebot:#ubuntu-release- New: accepted courier-unicode [i386] (artful-proposed) [2.0-1]
-queuebot:#ubuntu-release- New: accepted xml-rpc-el [amd64] (artful-proposed) [1.6.12-2]
<cpaelzer> thank you apw
<locutus_> lots of qt fails, nice
<LocutusOfBorg> switch ended, now I'm using bnc :)
<LocutusOfBorg> back to the borg community
<tsimonq2> Qt 5.9.1 looks to be in -proposed \o/
<LocutusOfBorg> I moved some transitions to finished, and boost to old
<LocutusOfBorg> they were all at 100%
<tsimonq2> mitya57: Should libqt5core5a have Provides: qtbase-abi-5-9-0 or Provides: qtbase-abi-5-9-1?
<doko> ... further delaying the perl transition
<fossfreedom_> tsimonq2: does QT 5.9 change in anyway how we style QT apps to look like GTK apps ? with QT 5.7 we had to use QT_QPA_PLATFORMTHEME=gtk2
<tsimonq2> fossfreedom_: imho GTK 2 apps look so much better under 5.9
<tsimonq2> fossfreedom_: So yes, from what I can tell it does change things, but it's better than before :)
<LocutusOfBorg> doko, qtwebengine? we can remove and let the previous one migrate
<fossfreedom_> tsimonq2:  the same environment variable=value ?
<LocutusOfBorg> it will take some hours to build so who cares?
<tsimonq2> fossfreedom_: I'm running 5.9 here, let me test it out...
<tsimonq2> fossfreedom_: Yep, same variable from what I can tell
<sil2100> mwhudson, doko, slangasek: looking at the pyzmq autopkgtest failures, I think those need to be re-run with all proposed, since I see the python3 test dependencies pull in python3.5
<sil2100> I'll give it a try
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (xenial-proposed) [1.3.1-1ubuntu10.13]
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (trusty-proposed) [1.2.2-0ubuntu13.1.21]
-queuebot:#ubuntu-release- Unapproved: accepted logcheck [source] (trusty-proposed) [1.3.16ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted logcheck [source] (xenial-proposed) [1.3.17ubuntu0.1]
<fossfreedom_> tsimonq2: thanks
<LocutusOfBorg> apw, I did sync xchat from debian, because I think when a packages gets removed from artful it isn't autosyncd anymore, is this correct?
<tsimonq2> fossfreedom_: np :)
<tsimonq2> rbasak: poke on SRUs in bug 1133477 and bug 1708619 :)
<ubot5> bug 1133477 in gvfs (Ubuntu Xenial) "[SRU] cut-n-paste move files got stuck forever" [Critical,Fix committed] https://launchpad.net/bugs/1133477
<ubot5> bug 1708619 in indicator-sound-gtk2 (Ubuntu Zesty) "[SRU] sound settings does nothing - sound menu of the indicator applet" [Undecided,In progress] https://launchpad.net/bugs/1708619
<rbasak> tsimonq2: ah, thanks. I'm processing SRUs at the moment. I'll take those ones next.
<tsimonq2> rbasak: Thanks!
<rbasak> gnome-flashback: GNOME Flashback application
<rbasak> WTF kind of description is that?
<tsimonq2> Is it... an application? A DE? O_o
<rbasak> Looks like it has improved a little in Debian
<rbasak> Description: helper application for the GNOME Flashback session
<tsimonq2> oh gotcha
<rbasak> Someone has been there before me: Debian bug 843143 :)
<ubot5> Debian bug 843143 in src:gnome-flashback "Please put a short description in the description" [Normal,Fixed] http://bugs.debian.org/843143
<sil2100> pyyaml regressions seem to be transient, this should be good after rerun/ignore
<rbasak> tsimonq2: wow. Thank you for driving this (gvfs; yet to look at the other).
<slangasek> doko: hi, I see gcc-7/arm64 is building again; what happened to the first build?
<LocutusOfBorg> I saw it kicked on some previous upload, I retried and it went fine
<LocutusOfBorg> (I didn't touch it this time)
<slangasek> sil2100: the pyzmq triggers I see in the queue from you don't have --all-proposed.  also, pyzmq is marked badtest already for the artful version, I'm going to update the hint
<tsimonq2> rbasak: You're welcome. I hope the SRU docs are complete enough. ;)
<sil2100> slangasek: ACK, I run it with all-proposed=1, thought it was correctly accepted by autopkgtests
<slangasek> sil2100: as I mentioned yesterday, a script that analyzes update_excuses and makes recommendations of hints to bump would be helpful
<rbasak> tsimonq2: still reading up. That's a good thing :)
<tsimonq2> rbasak: :)
<sil2100> slangasek: would be good to have something like that, is it on anyone's plate already?
<sil2100> slangasek: oh, and I was wondering what's the better way of doing things - if I see some autopkgtest failure is transient or resolvable through all-proposed, should I just re-run or poke for someone to hint it in?
<slangasek> sil2100: I don't think it's on anyone's plate, I asked for it out loud here yesterday for the first time
<slangasek> sil2100: if it's transient and resolvable, I always prefer that we resolve it. but if the previous version has been hinted, we should check if the new version should also be hinted
<sil2100> Ok, depending how my SRU shift later today goes I might glue up a quick script for that as you mentioned
<rbasak> tsimonq2: indicator-sound-gtk2 should be 12.10.0.1-0ubuntu5.17.04.1, as 12.10.0.1-0ubuntu5 also exists in Xenial.
<rbasak> To avoid future version string gymnastics if a Xenial SRU is needed.
<tsimonq2> rbasak: oic
<tsimonq2> rbasak: Ok, I'll need a sponsor to do another upload... want me to get another uploaded package correcting this or would you be able to do it?
<rbasak> I'm taking a break, then have a meeting. I'll sort it, though it may be later.
<tsimonq2> Ok.
<tsimonq2> rbasak: Thanks!
<rbasak> tsimonq2: the gvfs fix looks good to me superficially, though I think the surgery involved in the fix deserves a closer review which will take me more time. I'll look again later. Thank you again for driving both of these.
-queuebot:#ubuntu-release- Unapproved: rejected indicator-sound-gtk2 [source] (zesty-proposed) [12.10.0.1-0ubuntu5.1]
<tsimonq2> rbasak: You're welcome, and yeah, it's quite a bit of surgery :P
<ogra_> slangasek, sil2100 unless you are actually building 17.10 ubuntu core images i think the header on http://cdimage.ubuntu.com/ubuntu-core/16/edge/current/ is wrong
 * ogra_ just noticed ... 
<slangasek> ogra_: can you file a bug on ubuntu-cdimage please?
<ogra_> slangasek, bug 1709644
<ubot5> bug 1709644 in Ubuntu CD Images "http://cdimage.ubuntu.com/ubuntu-core/16/edge/current/ advertises as 17.10 while in fact being UbuntuCore 16" [Undecided,New] https://launchpad.net/bugs/1709644
<slangasek> ogra_: ta
<ahasenack> hi guys, the libvirt package has a remark about a freeze here: http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html
<ahasenack> what is that about?
<ahasenack> "Not touching package due to block request by freeze (contact #ubuntu-release if update is needed)"
<nacc> ahasenack: update_excuses is not used for a released release
<nacc> ahasenack: beyond a place to see the tests passed
<ahasenack> so can I ignore that remark?
<ahasenack> in this case (!artful)
<slangasek> ahasenack: yes, all packages are "frozen" from the perspective of proposed-migration for SRUs
<ahasenack> ok, got it
<ahasenack> thanks
<nacc> ahasenack: iirc, you want to use the SRU page itself to figure out the 'external' status
<nacc> http://people.canonical.com/~ubuntu-archive/pending-sru.html
<nacc> external to yourself, that is
<ahasenack> that doesn't confirm if the package is in proposed already or not
<nacc> ahasenack: by version, it does?
<nacc> there is a -proposed column
<ahasenack> does that get updated when the package has finally landed in -proposed? When apt can see it?
<slangasek> ahasenack: it is updated by cron, timestamp of the current report is at the top
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-drivers-common [source] (zesty-proposed) [1:0.4.22.1]
-queuebot:#ubuntu-release- Unapproved: indicator-sound-gtk2 (zesty-proposed/universe) [12.10.0.1-0ubuntu5 => 12.10.0.1-0ubuntu5.17.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted indicator-sound-gtk2 [source] (zesty-proposed) [12.10.0.1-0ubuntu5.17.04.1]
<slangasek> Laney: it occurs to me that the only gcc-7 build we're waiting on is arm64, which we don't autopkgtest; so in principle we could trigger the autopkgtests for gcc-7 now if there was a sane entry point for this
-queuebot:#ubuntu-release- Unapproved: mongodb (xenial-proposed/universe) [1:2.6.10-0ubuntu1 => 1:2.6.10-0ubuntu1.1] (mozilla)
<slangasek> doko, Laney: ah, and I see the justification for using libreoffice as an autopkgtest for gcc-* is "and libreoffice as an example for a libgcc user."  maybe we should pick a user of libgcc whose tests are a bit more reliable?
<slangasek> LocutusOfBorg: um why are you uploading the Qt5.9 transition on top of the perl transition?
<slangasek> infinity: ping
<slangasek> tsimonq2: hi
<slangasek> tsimonq2, LocutusOfBorg: I have removed qtwebengine-opensource-src from -proposed and re-synced the version that was previously there.  The Qt5.9 transition MUST NOT start until the current perl+gcc transition is finished.
<tsimonq2> slangasek: hi
<slangasek> tsimonq2: hi, so I know we had talked about scheduling the Qt transition, but I guess we never explicitly communicated about the need to let the toolchain transition first?
<tsimonq2> slangasek: I... didn't think the transitions would conflict... I also thought Perl was very close to being done if not done already and there would be no issue with doing Qt after GCC so that there were no unneeded uploads fixing things thay were already fixed in 5.9 when 5.9 lands shortly after
<slangasek> tsimonq2: yeah, no; qtwebengine was already in -proposed and entangled because of libevent
<slangasek> tsimonq2: I've used a blunt hammer to reset it so we can finish the perl transition, but it means qt bits might be ftbfs and otherwise broken for a little bit in -proposed until we finish
<tsimonq2> slangasek: What did you do to reset it? Just curious
<slangasek> tsimonq2: remove-package && copy-package -e $version --force-same-destination
<tsimonq2> slangasek: No I mean which packages? I know the tooling
<slangasek> tsimonq2: qtwebengine-opensource-src is the only one
<slangasek> also, I didn't yet remove it hard enough, looks like I might have to kick some more binaries around
<tsimonq2> slangasek: Ok, is qtwebengine the only one there was an issue with?
<slangasek> yes
<tsimonq2> slangasek: Ok, well if that's the only conflicting package and that has been dealt with, then what's the problem with continuing the Qt transition?
<slangasek> tsimonq2: it's been dealt with by reverting that package in -proposed; I wouldn't think your transition will continue without it?
<tsimonq2> slangasek: Yes it's a blocker, but it'll maybe take a few weeks to sort out all the failing KDE autopkgtests
<tsimonq2> (and other tests)
<slangasek> right
<slangasek> there's no problem with all of that continuing
<slangasek> but if there are other packages to be uploaded that currently have versions in -proposed that aren't migrating, please check first whether they're affected by the related transition
<slangasek> and all of this should be a moot point in a day, I hope
<slangasek> if it's not, I will become progressively grumpier ;)
<tsimonq2> slangasek: So then is there ETA for the GCC transition? (days, weeks, months?)
<slangasek> tsimonq2: as soon as gcc-7/arm64 finishes and the kernel is ready to migrate.
<tsimonq2> slangasek: Oh, so a week or two barring no serious issues, is that estimate off?
<slangasek> tsimonq2: see above, if this stretches out more than another day it's because things have gone wrong.
<tsimonq2> slangasek: Oh, gotcha.
<tsimonq2> slangasek: And yeah, now I know to be more careful when landing transitions (i.e. check all of that before asking a sponsor (eventually me, myself, and I) to land a transition)
<tsimonq2> slangasek: But it would have been nice to know all of this when I asked about a good time for the Qt transition. I think I might have asked multiple times and but gotten no definitive answer as to why I shouldn't have continued...
<tsimonq2> But eh, we're already past that.
<slangasek> tsimonq2: sure; as far as I understood you were still blocked waiting on some of the unity removals so I wasn't explicit about the need to wait for perl+gcc+libevent+libwebp+net-snmp
<tsimonq2> slangasek: ack
<bdmurray> tjaalton: Can you update your copy of ubuntu-archive-tools so bugs receive the new verification-needed-$release tag?
<tjaalton> bdmurray: oops, sure..
<bdmurray> tjaalton: thanks!
-queuebot:#ubuntu-release- Unapproved: accepted xorg-server [source] (xenial-proposed) [2:1.18.4-0ubuntu0.4]
-queuebot:#ubuntu-release- New binary: poppler [ppc64el] (artful-proposed/main) [0.57.0-0ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: poppler [i386] (artful-proposed/main) [0.57.0-0ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: poppler [amd64] (artful-proposed/main) [0.57.0-0ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: poppler [arm64] (artful-proposed/main) [0.57.0-0ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: poppler [armhf] (artful-proposed/main) [0.57.0-0ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: poppler [s390x] (artful-proposed/main) [0.57.0-0ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: erlang-asciideck [ppc64el] (artful-proposed/none) [0.0+git20170714.48cbfe8b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: erlang-asciideck [s390x] (artful-proposed/none) [0.0+git20170714.48cbfe8b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tss2 [ppc64el] (artful-proposed/universe) [1045-1] (no packageset)
-queuebot:#ubuntu-release- New binary: scram [ppc64el] (artful-proposed/universe) [0.14.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: scram [s390x] (artful-proposed/universe) [0.14.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cpath-clojure [amd64] (artful-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: crypto-random-clojure [amd64] (artful-proposed/universe) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: erlang-asciideck [arm64] (artful-proposed/universe) [0.0+git20170714.48cbfe8b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: erlang-asciideck [i386] (artful-proposed/universe) [0.0+git20170714.48cbfe8b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: crypto-equality-clojure [amd64] (artful-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: erlang-asciideck [armhf] (artful-proposed/universe) [0.0+git20170714.48cbfe8b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: erlang-asciideck [amd64] (artful-proposed/universe) [0.0+git20170714.48cbfe8b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: clj-tuple-clojure [amd64] (artful-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fast-zip-clojure [amd64] (artful-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: maven-reporting-api [amd64] (artful-proposed/universe) [3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: instaparse-clojure [amd64] (artful-proposed/universe) [1.4.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tss2 [amd64] (artful-proposed/universe) [1045-1] (no packageset)
-queuebot:#ubuntu-release- New binary: clj-yaml-clojure [amd64] (artful-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: scram [i386] (artful-proposed/universe) [0.14.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tss2 [s390x] (artful-proposed/universe) [1045-1] (no packageset)
-queuebot:#ubuntu-release- New binary: maven-reporting-exec [amd64] (artful-proposed/universe) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tss2 [i386] (artful-proposed/universe) [1045-1] (no packageset)
-queuebot:#ubuntu-release- New binary: raynes-fs-clojure [amd64] (artful-proposed/universe) [1.4.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tss2 [armhf] (artful-proposed/universe) [1045-1] (no packageset)
-queuebot:#ubuntu-release- New binary: riddley-clojure [amd64] (artful-proposed/universe) [0.1.14-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hiccup-clojure [amd64] (artful-proposed/universe) [1.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: scram [arm64] (artful-proposed/universe) [0.14.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tss2 [arm64] (artful-proposed/universe) [1045-1] (no packageset)
-queuebot:#ubuntu-release- New binary: scram [armhf] (artful-proposed/universe) [0.14.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: scram [amd64] (artful-proposed/universe) [0.14.0-1] (no packageset)
#ubuntu-release 2017-08-10
-queuebot:#ubuntu-release- New: accepted scram [amd64] (artful-proposed) [0.14.0-1]
-queuebot:#ubuntu-release- New: accepted scram [armhf] (artful-proposed) [0.14.0-1]
-queuebot:#ubuntu-release- New: accepted scram [ppc64el] (artful-proposed) [0.14.0-1]
-queuebot:#ubuntu-release- New: accepted scram [arm64] (artful-proposed) [0.14.0-1]
-queuebot:#ubuntu-release- New: accepted scram [s390x] (artful-proposed) [0.14.0-1]
-queuebot:#ubuntu-release- New: accepted scram [i386] (artful-proposed) [0.14.0-1]
-queuebot:#ubuntu-release- New: accepted poppler [amd64] (artful-proposed) [0.57.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted poppler [armhf] (artful-proposed) [0.57.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted poppler [ppc64el] (artful-proposed) [0.57.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted poppler [arm64] (artful-proposed) [0.57.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted poppler [s390x] (artful-proposed) [0.57.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted poppler [i386] (artful-proposed) [0.57.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted tss2 [amd64] (artful-proposed) [1045-1]
-queuebot:#ubuntu-release- New: accepted tss2 [armhf] (artful-proposed) [1045-1]
-queuebot:#ubuntu-release- New: accepted tss2 [ppc64el] (artful-proposed) [1045-1]
-queuebot:#ubuntu-release- New: accepted tss2 [arm64] (artful-proposed) [1045-1]
-queuebot:#ubuntu-release- New: accepted tss2 [s390x] (artful-proposed) [1045-1]
-queuebot:#ubuntu-release- New: accepted tss2 [i386] (artful-proposed) [1045-1]
-queuebot:#ubuntu-release- New: accepted erlang-asciideck [amd64] (artful-proposed) [0.0+git20170714.48cbfe8b-1]
-queuebot:#ubuntu-release- New: accepted erlang-asciideck [armhf] (artful-proposed) [0.0+git20170714.48cbfe8b-1]
-queuebot:#ubuntu-release- New: accepted erlang-asciideck [ppc64el] (artful-proposed) [0.0+git20170714.48cbfe8b-1]
-queuebot:#ubuntu-release- New: accepted erlang-asciideck [arm64] (artful-proposed) [0.0+git20170714.48cbfe8b-1]
-queuebot:#ubuntu-release- New: accepted erlang-asciideck [s390x] (artful-proposed) [0.0+git20170714.48cbfe8b-1]
-queuebot:#ubuntu-release- New: accepted erlang-asciideck [i386] (artful-proposed) [0.0+git20170714.48cbfe8b-1]
-queuebot:#ubuntu-release- New: accepted libgtop2 [amd64] (artful-proposed) [2.37.90-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libgtop2 [armhf] (artful-proposed) [2.37.90-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libgtop2 [ppc64el] (artful-proposed) [2.37.90-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libgtop2 [arm64] (artful-proposed) [2.37.90-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libgtop2 [s390x] (artful-proposed) [2.37.90-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libgtop2 [i386] (artful-proposed) [2.37.90-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted clj-tuple-clojure [amd64] (artful-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted cpath-clojure [amd64] (artful-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted crypto-random-clojure [amd64] (artful-proposed) [1.2.0-1]
-queuebot:#ubuntu-release- New: accepted hiccup-clojure [amd64] (artful-proposed) [1.0.5-1]
-queuebot:#ubuntu-release- New: accepted maven-reporting-api [amd64] (artful-proposed) [3.0-1]
-queuebot:#ubuntu-release- New: accepted raynes-fs-clojure [amd64] (artful-proposed) [1.4.6-1]
-queuebot:#ubuntu-release- New: accepted clj-yaml-clojure [amd64] (artful-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted fast-zip-clojure [amd64] (artful-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted maven-reporting-exec [amd64] (artful-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted crypto-equality-clojure [amd64] (artful-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted riddley-clojure [amd64] (artful-proposed) [0.1.14-1]
-queuebot:#ubuntu-release- New: accepted instaparse-clojure [amd64] (artful-proposed) [1.4.7-1]
-queuebot:#ubuntu-release- New binary: fast-zip-visit-clojure [amd64] (artful-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: specter-clojure [amd64] (artful-proposed/universe) [1.0.2-2] (no packageset)
<slangasek> bjf, apw: the transition is ready to go now except for linux; I'm going to drop the tag long enough to let autopkgtests start and then I'll re-set it, but it would be good to have a decision ASAP on letting that package transition
-queuebot:#ubuntu-release- New: accepted fast-zip-visit-clojure [amd64] (artful-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted specter-clojure [amd64] (artful-proposed) [1.0.2-2]
-queuebot:#ubuntu-release- New binary: jellyfish1 [amd64] (artful-proposed/none) [1.1.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dpdk [ppc64el] (artful-proposed/main) [17.05.1-2] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: dpdk [i386] (artful-proposed/main) [17.05.1-2] (kubuntu, ubuntu-desktop, ubuntu-server)
<slangasek> bjf, apw: ok well that didn't go quite according to plan, I overlooked that linux is special cased and doesn't actually get autopkgtest runs triggered by proposed-migration so it immediately became a candidate and has migrated :/  Since the only autopkgtest regressions are the build failure with gcc-7, if there are no other bugs I think we should roll with this
-queuebot:#ubuntu-release- New binary: dpdk [amd64] (artful-proposed/main) [17.05.1-2] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: dpdk [arm64] (artful-proposed/main) [17.05.1-2] (kubuntu, ubuntu-desktop, ubuntu-server)
<cpaelzer> jamespage: the new sync of DPDKis in a-p as discussed https://launchpad.net/ubuntu/+source/dpdk/17.05.1-2
<cpaelzer> jamespage: but as you can see currently held at the new queue which blocks you from bringin the new OVS in
<cpaelzer> anyone around who can help with the new queue in that case
<cpaelzer> It is the common case where this is only a sync and things are already through the new queue in Debian
-queuebot:#ubuntu-release- New: accepted dpdk [amd64] (artful-proposed) [17.05.1-2]
-queuebot:#ubuntu-release- New: accepted dpdk [i386] (artful-proposed) [17.05.1-2]
-queuebot:#ubuntu-release- New: accepted dpdk [arm64] (artful-proposed) [17.05.1-2]
-queuebot:#ubuntu-release- New: accepted dpdk [ppc64el] (artful-proposed) [17.05.1-2]
-queuebot:#ubuntu-release- New: accepted jellyfish1 [amd64] (artful-proposed) [1.1.11-1]
<cpaelzer> whoever that was - thanks!
<apw> slangasek, that is fine, i think we are happy with it as we can be.  as you say the gcc thing is going to affect the next upload not this one
<LocutusOfBorg> thanks slangasek for the fixes! somewhat I read that copy-package was requiring an AA intervention for being accepted
<LocutusOfBorg> I even mentioned it here
<LocutusOfBorg> I'm going to reupload now that the migration is completed :)
<LocutusOfBorg> slangasek, I'm redoing the gmime rebuilds, for some reasons your "rebuild against gmime3" picked up the old 2.6
<mwhudson> omg pytest migrated
<apw> mwhudson, 830odd somethings migrated
<LocutusOfBorg> slangasek, I asked to process gmime2.6 from debian new queue
<LocutusOfBorg> I'm thinking about asking you to promote in main, and demote the current gmime in universe
<LocutusOfBorg> so we can end this transition, and when Debian switches the default again, we can think about promoting it again
<LocutusOfBorg> what do you think?
<mwhudson> apw: yeah indeed
<LocutusOfBorg> mmm there is a better solution
<LocutusOfBorg> patch grilo-plugins to work with gmime3 and forget about the 2.6, all the stuff is in universe fortunately
<apw> cpaelzer, they get a more relaxed approach as they ahve passed New in debian yes, but it still takes a human
<LocutusOfBorg> apw, any news wrt xchat in new queue?
<apw> LocutusOfBorg, xchat again ?
<LocutusOfBorg> yes, I started maintaining it
<LocutusOfBorg> I fixed all the CVEs, and the outstanding issues
<LocutusOfBorg> and reintroduced in debain
<LocutusOfBorg> debian
<LocutusOfBorg> but for some reasons, the autosync didn't ppick it
<apw> it is likely blacklisted as it has been removed
<apw> confirmed as it has been deleted it auto blacklists a new sync
<acheronuk> what is the issue in GCC7 that needs fixing?
<LocutusOfBorg> apw, will you do some magic please?
<LocutusOfBorg> acheronuk, basically AFAIK it breaks the kernel builds
<acheronuk> oh. just trying to work out if some build failures I'm getting are a related issue
<LocutusOfBorg> http://autopkgtest.ubuntu.com/packages/linux/artful
<LocutusOfBorg> http://autopkgtest.ubuntu.com/packages/linux/
-queuebot:#ubuntu-release- New: accepted xchat [sync] (artful-proposed) [2.8.8-8]
-queuebot:#ubuntu-release- New binary: xchat [ppc64el] (artful-proposed/none) [2.8.8-8] (no packageset)
-queuebot:#ubuntu-release- New binary: xchat [i386] (artful-proposed/none) [2.8.8-8] (no packageset)
-queuebot:#ubuntu-release- New binary: xchat [amd64] (artful-proposed/none) [2.8.8-8] (no packageset)
-queuebot:#ubuntu-release- New: rejected insighttoolkit4 [armhf] (artful-proposed) [4.12.0-dfsg1-1ubuntu2]
-queuebot:#ubuntu-release- New: rejected insighttoolkit4 [s390x] (artful-proposed) [4.12.0-dfsg1-1ubuntu2]
-queuebot:#ubuntu-release- New: rejected insighttoolkit4 [ppc64el] (artful-proposed) [4.12.0-dfsg1-1ubuntu2]
<apw> ^ ftbfs on other arches and superceeded source ...
-queuebot:#ubuntu-release- New binary: xchat [armhf] (artful-proposed/none) [2.8.8-8] (no packageset)
-queuebot:#ubuntu-release- New binary: xchat [arm64] (artful-proposed/none) [2.8.8-8] (no packageset)
<LocutusOfBorg> apw, I know it is superseeded, I didn't sync again, hopefully it will start automatically
<LocutusOfBorg> will have a look thanks
<LocutusOfBorg> oh you are talking about itk4
<LocutusOfBorg> yes, I'm looking with upstream to fix it
<LocutusOfBorg> and Debian
<LocutusOfBorg> I did test in ppa the new castxml, but I failed in enabling proposed, so the build went good for other reasons (gcc-6)
<apw> LocutusOfBorg, if you are answering for xchat, the comment was for insighttoolkit4
-queuebot:#ubuntu-release- New binary: xchat [s390x] (artful-proposed/none) [2.8.8-8] (no packageset)
<LocutusOfBorg> yes, got it
<LocutusOfBorg> actually xchat has two new uploads in debian
<LocutusOfBorg> will they be autosyncd?
<LocutusOfBorg> (this is why I wrongly got the superseeded source against xchat)
<apw> LocutusOfBorg, it appears to be blacklisted because it was most recently removed, so i think it will, i think
<LocutusOfBorg> so you removed that block?
<LocutusOfBorg> I'll wait 24h and see then :)
<apw> 6 i think
<LocutusOfBorg> I fixed a nasty bug and two CVEs, this is why I'm wondering about it
<LocutusOfBorg> (the non-utf8 by default issue)
<apw> well luckily it is devel so cves are not in of themselves quite so urgent
<ginggs> LocutusOfBorg: xchat should auto sync again now after the manual sync.  it is not listed here http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt (i'm not sure where the auto blacklist for removed packages lives)
<ginggs> but the auto blacklist for removed packages seems to be cleared after a manual sync without manual intervention
<LocutusOfBorg> thanks, now it is even built everywhere lets wait some hours
<apw> ginggs, in the source for auto-sync
<ginggs> apw: ah ok, thanks. so if package-was-removed then do-not-sync, and once package is manually sync'd then package-was-removed is no longer true ?
<apw> it looks at the last publication record, and if that is Deleted with reason it assumes you intended it gone (to my reading)
<apw> once a sync is manually done the last record is a Published so it should not match
-queuebot:#ubuntu-release- New: accepted xchat [amd64] (artful-proposed) [2.8.8-8]
-queuebot:#ubuntu-release- New: accepted xchat [armhf] (artful-proposed) [2.8.8-8]
-queuebot:#ubuntu-release- New: accepted xchat [ppc64el] (artful-proposed) [2.8.8-8]
-queuebot:#ubuntu-release- New: accepted xchat [arm64] (artful-proposed) [2.8.8-8]
-queuebot:#ubuntu-release- New: accepted xchat [s390x] (artful-proposed) [2.8.8-8]
-queuebot:#ubuntu-release- New: accepted xchat [i386] (artful-proposed) [2.8.8-8]
<apw> LocutusOfBorg, ^
<LocutusOfBorg> <3
<LocutusOfBorg> btw strangely enough I got already emails of people thanking me for bringing it back
<smb> LocutusOfBorg, as long as you guys are not taking away hexchat... I just don't want to do another change... :-P
<LocutusOfBorg> smb, I don't plan to :)
<LocutusOfBorg> apw, autopkgtest for linux/unknown: armhf: Regression
<LocutusOfBorg> (mumactl)
<apw> LocutusOfBorg, that means it got lost, i would recommend a retry
<Ukikie> LocutusOfBorg: But why?
<LocutusOfBorg> apw, isn't kernel autopkgtest broken?
<LocutusOfBorg> isn't ignore better?
<LocutusOfBorg> well, somebody sorted it out in the meanwhile
<LocutusOfBorg> ta
-queuebot:#ubuntu-release- Unapproved: logrotate (trusty-proposed/main) [3.8.7-1ubuntu1.1 => 3.8.7-1ubuntu1.2] (core)
-queuebot:#ubuntu-release- Unapproved: logrotate (zesty-proposed/main) [3.8.7-2ubuntu3 => 3.8.7-2ubuntu3.1] (core)
<slashd> sil2100, Do you have a moment to approve the upload of "logrotate" for Trusty, Xenial and Zesty ?
-queuebot:#ubuntu-release- Unapproved: logrotate (xenial-proposed/main) [3.8.7-2ubuntu2.16.04.1 => 3.8.7-2ubuntu2.16.04.2] (core)
<sil2100> slashd: I can take a look at it in 15 mins :)
<slashd> sil2100, thanks ;)
-queuebot:#ubuntu-release- Unapproved: libsdl2 (trusty-proposed/universe) [2.0.2+dfsg1-3ubuntu1.1 => 2.0.2+dfsg1-3ubuntu1.2] (no packageset)
<sil2100> slashd: hm, I'll need to wait a bit, debdiff not generated yet
<slashd> sil2100, ok no worries
<tjaalton> infinity: the xenial release notes say that 16.04.3 is supported for five years..
<tjaalton> https://wiki.ubuntu.com/XenialXerus/ReleaseNotes
<apw> that i am sure is intended to mean from the initial GA of xenial
<apw> not that is what the words appear to actually say
<tjaalton> it's confusing a certain vendor at least, since the lts-stack page does say the stack is only supported for 6mo
<tjaalton> tseliot: you fixed the page?
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.26.10~14.04 => 2.27~14.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapd (zesty-proposed/main) [2.26.10+17.04 => 2.27+17.04] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.26.10 => 2.27] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: qtwebengine-opensource-src [amd64] (artful-proposed/universe) [5.9.1+dfsg-2build2] (kubuntu)
<tjaalton> ah, dropped .3
<tseliot> tjaalton: yes
<tseliot> tjaalton: we talked about it in #ubuntu-devel
<tjaalton> ok
<slashd> sil2100, how long it takes for the debdiff to be generated ? does it means I'll have to request the approval tomorrow ?
<sil2100> slashd: no, it's done now, but it was generating really long - I'm reviewing it inbetween stuff
<slashd> sil2100, oh ok, much appreciated
<sil2100> Funny, since the diff is really small, duh
<sil2100> Maybe it was busy
-queuebot:#ubuntu-release- New binary: qtwebengine-opensource-src [i386] (artful-proposed/universe) [5.9.1+dfsg-2build2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted logrotate [source] (zesty-proposed) [3.8.7-2ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: accepted logrotate [source] (xenial-proposed) [3.8.7-2ubuntu2.16.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted logrotate [source] (trusty-proposed) [3.8.7-1ubuntu1.2]
<slashd> sil2100, ^^ thanks
<sil2100> yw o/
<blackboxsw> bdmurray: good morning.  I was wondering if you are the person to ping related to getting a recent cloud-init  package upload queued for SRU testing?
<blackboxsw> we have a package update for xenial and zesty that has around 10 bug fixes that we would to start SRU verification testing if possible. https://trello.com/c/CAjwe8LX/273-cloud-init-sru-zesty-xenial
<bdmurray> blackboxsw: Are you refering to this? https://launchpad.net/ubuntu/zesty/+queue?queue_state=1&queue_text=cloud-init
<blackboxsw> bdmurray: yep that's the ticket, didn't know the process of how to bring that up and I knew smoser queued the content/request last week
<bdmurray> blackboxsw: I talked to smoser about last week and said that I thought the upload looked more like a new upstream microrelease than a stable release update with only bug fixes.
<blackboxsw> bdmurray: ok.  Does that mean we need to provide additional documentation to you on those existing microfeature bugs so that it's possible to queue the SRU request?  I thought cloud-init had a SRU verification exception if a micro-feature is introduced because of our existing integration testing we perform on target releases.
<bdmurray> blackboxsw: No special case has been created for cloud-init - https://wiki.ubuntu.com/StableReleaseUpdates#Documentation_for_Special_Cases
<blackboxsw> ahh rharper corrected me on this that it was curtin
<bdmurray> blackboxsw: Also see https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases
<blackboxsw> bdmurray: excellent, thx for the link. As you can tell, my first cloud-init SRU rodeo (been involved only in the SRU verification side so far)
<bdmurray> blackboxsw: no problem
<jbicha> AAs, please review LP: #1709764 to complete the libgtop2 transition
<ubot5> Launchpad bug 1709764 in slmon (Ubuntu) "Please remove slmon from Ubuntu" [Undecided,New] https://launchpad.net/bugs/1709764
<jbicha> ooh, this is causing major problems now for autopkgtests :( https://bugs.debian.org/868473
<ubot5> Debian bug 868473 in dh-acc "dh-acc: Incorrect usage of doit (Dh_Lib)" [Important,Open]
<jbicha> https://codesearch.debian.net/search?q=path%3Adebian%2Ftests%2Fcontrol+dh-acc&perpkg=1
<jbicha> I think we're going to need to revert that debhelper change or modify it, I commented on the Debian bug
-queuebot:#ubuntu-release- Unapproved: zfs-linux (zesty-proposed/main) [0.6.5.9-5ubuntu4.1 => 0.6.5.9-5ubuntu4.2] (core)
<LocutusOfBorg> apw, can we please force-bad winff/armhf? it has been failing since a lot of time
<LocutusOfBorg> I don't think anybody will have a look
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (zesty-proposed) [0.6.5.9-5ubuntu4.2]
<LocutusOfBorg> (at least not me :p)
<ginggs> LocutusOfBorg: winff hint is already in apw's hints, just needs a version bump
<LocutusOfBorg> oh, the missing feature somebody was discussing here yesterday, thanks
<LocutusOfBorg> jbicha, I *think* relaxing debhelper
<LocutusOfBorg> is better
<LocutusOfBorg> two reasons: 1) we already have a delta
<LocutusOfBorg> 2) we do not introduce a new one :)
<LocutusOfBorg> serious 2 point: seems more a debhelper regression to me
<LocutusOfBorg> OTOH, fixing abi is probably preferrable, less autopkgtests, faster migration, trivial patch
<jbicha> warnings about compat 11 seems awfully agressive to me, won't people check their code before bumping the compat level anyway?
<jbicha> I'
<jbicha> m thinking of dh_missing in particular
<LocutusOfBorg> sure, and for sure it has to be emitted only when the new compat is used
<LocutusOfBorg> but again, moving abi to the new syntax needs to be done, right now I would bump that bug to RC
<jbicha> it's definitely RC for Ubuntu
<LocutusOfBorg> so, lets fix abi-checker and upload?
<LocutusOfBorg> I can do it
 * LocutusOfBorg is doing it
-queuebot:#ubuntu-release- Unapproved: accepted nvme-cli [source] (xenial-proposed) [0.5-1ubuntu0.2]
<LocutusOfBorg> ${path}'_report.xml'
<LocutusOfBorg> not sure if this is correct
<LocutusOfBorg> meh, that documentation seems to be correct, the bug was preventing it from doing the right thing
<LocutusOfBorg> https://anonscm.debian.org/git/debhelper/debhelper.git/commit/?id=e2c420df3aa600c6af1c734970227c2ee2a90e90
<LocutusOfBorg> so this is not a retro-incompatible change, but rather a bug fix that breaks things
<LocutusOfBorg> I uploaded in my ppa
<elbrus> ginggs: regarding my question on #debian-release
<elbrus> which was; vorlon: does Ubuntu every autopkgtest "trigger" on two packages at the same time, i.e. it needing two packages from the proposed pocket at the same time (e.g. due to dependecies I guess)
<elbrus> I don't mean manually, does it ever need automatically two
<elbrus> or indeed, is a combination ever needed and why/when
<elbrus> and shouldn't that be automated then
<ginggs> elbrus: afaik, adding additional triggers is only done manually
<elbrus> in which cases does that help?
<elbrus> and does that help britney to migrate the package?
<elbrus> if not triggered by britney in the first place
-queuebot:#ubuntu-release- Unapproved: accepted packagekit [source] (xenial-proposed) [0.8.17-4ubuntu6~gcc5.4ubuntu1.2]
<ginggs> elbrus: when autopkgtests need other things in -proposed, i.e. they should migrate together, but they do not have explicit depends on the newer versions
<ginggs> elbrus: yes, it definitely helps the packages migrate
<ginggs> helps = they would not migrate without the additional triggers
<slangasek> LocutusOfBorg: wrt gmime it would probably be best if you consult the desktop team
<elbrus> so britney takes manual triggers into account even if it didn't create it?
<slangasek> ye
<elbrus> do you have an example?
<slangasek> elbrus: yes
<ginggs> elbrus: sometimes the packages really should be depending on the newer version in debian/tests/control
<elbrus> one could consider that a bug?
<slangasek> example> well, it's simply the architecture of the britney policy we have in place
<ginggs> elbrus: some cases are bugs and should be reported, yes
<LocutusOfBorg> slangasek, not needed, gmime now provides the 3 binding, and the two rdeps in main are compatible with it
<LocutusOfBorg> once the old one is accepted in unstable, everything will sort out by itself
<LocutusOfBorg> and if debian does a transition to 3, even better
<LocutusOfBorg> but since two sources are around, I just care that the one in main has rdeps in main
<LocutusOfBorg> jbicha, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-costamagnagianfranco-locutusofborg-ppa/?format=plain
<LocutusOfBorg> once nemo appears here, I'll know if it is fixed or not
<LocutusOfBorg> I appreciate if you can double-look my perl foo
-queuebot:#ubuntu-release- Unapproved: accepted mongodb [source] (xenial-proposed) [1:2.6.10-0ubuntu1.1]
<LocutusOfBorg> ${path}.'_report.xml' this seems better
<slangasek> so how did pulling in an upstream patch to the ARM asm break the ppc64el build? ;P https://launchpad.net/ubuntu/+source/ffmpeg/7:3.3.3-2
-queuebot:#ubuntu-release- New binary: node-seq [amd64] (artful-proposed/none) [0.3.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (zesty-proposed/main) [4.10.0-32.36] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (zesty-proposed) [4.10.0-32.36]
-queuebot:#ubuntu-release- New binary: qtwebengine-opensource-src [i386] (artful-proposed/universe) [5.9.1+dfsg-2ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-91.114~14.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (vivid-proposed/main) [3.19.0-91.99] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-128.177] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-91.114] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [amd64] (xenial-proposed/main) [4.11.0-14.20~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.10.0-32.36~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (vivid-proposed) [3.19.0-91.99]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.10.0-32.36~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [amd64] (xenial-proposed) [4.11.0-14.20~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-91.114]
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-91.114~14.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-128.177]
<tsimonq2> Hm, why are half the amd64/i386 builders idle but yet there's an hour long build queue?
<tsimonq2> Oh
<tsimonq2> duh
<tsimonq2> I was looking at the wrong arches, sorry
-queuebot:#ubuntu-release- Unapproved: accepted python-acme [source] (zesty-proposed) [0.14.2-0ubuntu0.17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted python-certbot [source] (zesty-proposed) [0.14.2-0ubuntu0.17.04.1]
-queuebot:#ubuntu-release- New binary: qtwebengine-opensource-src [amd64] (artful-proposed/universe) [5.9.1+dfsg-2ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted python-certbot-nginx [source] (zesty-proposed) [0.14.2-0ubuntu0.17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted python-certbot-apache [source] (zesty-proposed) [0.14.2-0ubuntu0.17.04.1]
<slangasek> /usr/include/ITK-4.10/vcl_compiler.h:79:4: error: #error "Dunno about this gcc"
<slangasek> should be #error "Â¯\(ã·)/Â¯"
-queuebot:#ubuntu-release- New: accepted qtwebengine-opensource-src [amd64] (artful-proposed) [5.9.1+dfsg-2build2]
-queuebot:#ubuntu-release- New: accepted qtwebengine-opensource-src [amd64] (artful-proposed) [5.9.1+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted qtwebengine-opensource-src [i386] (artful-proposed) [5.9.1+dfsg-2build2]
-queuebot:#ubuntu-release- New: accepted qtwebengine-opensource-src [i386] (artful-proposed) [5.9.1+dfsg-2ubuntu1]
<LocutusOfBorg> slangasek, lol
<slangasek> LocutusOfBorg: are you looking at the new insighttoolkit4 build failure already?
<LocutusOfBorg> slangasek, yes, together with upstream and debian
<slangasek> ok
<LocutusOfBorg> this is a castxml failure
 * slangasek nods
<LocutusOfBorg> I requested upstream help
<LocutusOfBorg> btw abi-checker-fooo should be fixed, not sure if you have a smart way of kicking failed autopkgtests
<slangasek> I'll keep my hands off then, thanks
<slangasek> "smart way" - you mean selectively retrying ones related to dh_acc?
<LocutusOfBorg> how do you find the related to dh_acc?
<slangasek> I don't have a good way, sorry
<LocutusOfBorg> this is what I try to make smart :)
<LocutusOfBorg> oh ok
-queuebot:#ubuntu-release- Unapproved: accepted python-acme [source] (xenial-proposed) [0.14.2-0ubuntu0.16.04.1]
<LocutusOfBorg> I hoped around grepping on logs directory
<slangasek> other than looking at all regressions reported and walking the logs to find references to dh_acc
<slangasek> logs directory> it's not a directory, it's swift
<LocutusOfBorg> https://github.com/CastXML/CastXML/issues/87#issuecomment-321462465
<LocutusOfBorg> for castxml
<slangasek> so you have all the same access over http that I do ;)
<LocutusOfBorg> if you want to help...
<LocutusOfBorg> ack
<LocutusOfBorg> (I don't know what swift is, and I'm happy to avoid such knowledge :p )
<slangasek> honestly I was looking at just retrying all current failures
<slangasek> the queue is small currently
<LocutusOfBorg> before lets abi-foo maybe migrate
<slangasek> ok
<LocutusOfBorg> otherwise you will need to add a special trigger everywhere?
<LocutusOfBorg> also, qt transition is mostly a lock-in stuff, is it ok to retry against proposed?
<slangasek> well, retry-autopkgtest-regressions --all-proposed...
<LocutusOfBorg> I don't know if k* and libk* foo patches will be retro-compatible for building with qt 5.7
<Laney> I'd rather add a trigger on the new version ...
<Laney> but YMMV I guess
<slangasek> generally speaking yes, but that would involve analysis
<slangasek> :)
<slangasek> I don't like --all-proposed as a rule
<LocutusOfBorg> we can add that trigger to every failed test
<LocutusOfBorg> I propose to make it migrate and then retry in 12h all the failed tests
<LocutusOfBorg> I'll do it as soon as it migrates
<LocutusOfBorg> btw to spot regressions in release, a nice feature would be to run against release tests randomly, and report if something breaks there
<LocutusOfBorg> sometimes you see the previous autopkgtest run of a particular package being 6 months old, and this doesn't help too much
 * LocutusOfBorg goes to sleep
<jbicha> I believe ci.debian.net does regular re-runs of everything
<slangasek> yeah, but those also aren't real CI, so...
<Laney> yes I would just add it to everything, or alternatively wait for the thing to migrate and then re-trigger
-queuebot:#ubuntu-release- Unapproved: update-manager (zesty-proposed/main) [1:17.04.5 => 1:17.04.6] (core)
-queuebot:#ubuntu-release- Unapproved: mesa (xenial-proposed/main) [17.0.7-0ubuntu0.16.04.1 => 17.0.7-0ubuntu0.16.04.2] (core, xorg)
<rbasak> bdmurray: thank you for accepting the certbot packages. I had been meaning to self accept after double checking them but hadn't got round to it yet.
<rbasak> bdmurray: the missing packages are in NEW I think?
-queuebot:#ubuntu-release- Unapproved: libxfont (xenial-proposed/main) [1:1.5.1-1ubuntu0.16.04.1 => 1:1.5.1-1ubuntu0.16.04.2] (core, xorg)
<tjaalton> bdmurray: hi, I've just uploaded a new mesa that adds a dummy pkg for libgles1-mesa, and a fix for libxfont1-dev that moves some docs to the correct place, fixing a file conflict with the newer libxfont-dev
<tjaalton> would be nice to get them in before the weekend, since I'm not supposed to ack them myself tomorrow..
<bdmurray> tjaalton: stuff can be accepted into -proposed on Friday, just not into -updates
<tjaalton> yeah but reviewing my own uploads?
<bdmurray> tjaalton: ah, yes that's not ideal
-queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (xenial-proposed) [17.0.7-0ubuntu0.16.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted libxfont [source] (xenial-proposed) [1:1.5.1-1ubuntu0.16.04.2]
<tjaalton> whee, thanks
-queuebot:#ubuntu-release- Unapproved: update-manager (xenial-proposed/main) [1:16.04.8 => 1:16.04.9] (core)
-queuebot:#ubuntu-release- New binary: sambamba [amd64] (artful-proposed/none) [0.6.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: swath [amd64] (artful-proposed/universe) [0.5.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: sambamba [i386] (artful-proposed/none) [0.6.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pymeasure [amd64] (artful-proposed/none) [0.4.5-1] (no packageset)
#ubuntu-release 2017-08-11
<slangasek> infinity: do you know of any reason that libc6-dbgsym would be missing for the most recent version in artful?
-queuebot:#ubuntu-release- Unapproved: libvirt (xenial-proposed/main) [1.3.1-1ubuntu10.13 => 1.3.1-1ubuntu10.14] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: libvirt (zesty-proposed/main) [2.5.0-3ubuntu5.4 => 2.5.0-3ubuntu5.5] (ubuntu-server, virt)
<LocutusOfBorg> autopkgtest for snapd/2.27+17.10: amd64: Pass, armhf: Always failed, i386: Regression â» , ppc64el: Pass, s390x: Always failed
<LocutusOfBorg> please ignore on i386 or forcebad or update the hint?
<apw> LocutusOfBorg, why ?
<LocutusOfBorg> apw, seems broken in release, I'm running a test
<apw> LocutusOfBorg, i have poked the package owner who thinks that is transitory and retrying
<LocutusOfBorg> still failing AFAICS
<infinity> tjaalton: I think it's poor messaging to tell vendors that the HWE stack is only supported "for 6mo".  In fact, moving to the rolling model was meant to fix that.
<infinity> tjaalton: The HWE stack is now supported for the life of the LTS, it just so happens that the versions increment.
<infinity> tjaalton: (but hey, we only support vim or firefox or glibc if you're on the latest version we ship too)
<tjaalton> infinity: well, "supported" in this case means they need to adjust when it rolls
<infinity> tjaalton: Or, perhaps worded differently, anyone who thinks we support snapshots of package sets in time is wrong (and, indeed, I've seen much evidence that larger vendors think we support everything on a given ISO, even if they never run apt after install).
<infinity> tjaalton: Sure, yes.  The HWE stack isn't *stable*, but it is *supported*.
<infinity> I wish it could be both, but the former sort of runs counter to the point of it.
<tjaalton> right, bad wording on my part
<tjaalton> "6mo lifespan" was what they said
<infinity> tjaalton: Also, speaking of Certain Vendors(tm) who I won't talk smack about in a public channel, is there any chance of getting them to ship their drivers in the distro so they can get per-kernel CI for free? :P
<apw> infinity, the bit about that wording that is worrying is it would be reasonable to interpret that 16.04.3 is supported for 5 years from its release
<infinity> I mean, it's not just major kernel versions where we break DKMS.  Sometimes is Just Happens because of an intrusive backport on a stable branch.
<tjaalton> infinity: we'll see about that
<infinity> apw: Oh, sure, I wasn't taking issue with fixing the 16.04.3 wording, I was taking issue with Timo's follow-up comment that HWE is supported for 6mo. ;)
<infinity> tjaalton: I mean, I'd love it shipped in the distro, but if that can't happen, I'd honestly be open to working with them to get them hooked into some CI with us, and also help them get a proper apt archive for their stuff.
<infinity> tjaalton: Cause that level of breakage reflects poorly on us both.
<tjaalton> sure does
<tjaalton> things are on the planning phase atm
<infinity> tjaalton: Worst case, if they weren't comfy with us distrbuting (and the broad license that would have to go with that), stuffing their things in a private PPA and running some private autopkgtest jobs against it for new kernels would probably work.
<tjaalton> alright
<infinity> tjaalton: Oh, and while I'm tying up loose ends from the point release... Any movement on the unforunate nouveau rendering bug?
<tjaalton> infinity: no, the reporter refuses to file it upstream
<tjaalton> "what's the point"
<tjaalton> so, meh
<infinity> File it for them?
<infinity> I mean, it affects lots of people, I assume.
<tjaalton> it'd just rot
<infinity> Does the bug exist in current mesa too, or only on that stable branch?
<tjaalton> yeah current upstream is broken too
<infinity> Fun.
<tjaalton> I talked to them
<tjaalton> the bug is limited to this older gen GF
<tjaalton> apparently
<tjaalton> which the devs don't havce
<tjaalton> have
<tjaalton> GF7, released in 2005
<tjaalton> https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1704596/comments/7
<ubot5> Ubuntu bug 1704596 in mesa (Ubuntu) "Mesa 17 (Ubuntu 16.04 HWE) breaks the dash's blur (dash and launcher are black)" [Undecided,Invalid]
<infinity> tjaalton: Ahh, the lack of hardware on which to test certainly makes it more problematic.
<infinity> tjaalton: I'd offer to help if I had anything of that generation, but I'm pretty sure I don't.
<tjaalton> also, they'd need apitrace of it, not gonna run ubuntu
<tjaalton> anyway, since it has a working blob..
<infinity> For now.
<tjaalton> there's another on a 10y old radeon where gtk3 tooltips are corrupted, has a proposed patch already I think
<infinity> But grudgingly also agreed that 12yo hardware isn't our biggest concern.
<tjaalton> exactly
<infinity> I wonder if maybe these sorts of things are more appropriately quirked in higher level UI bits.
<infinity> I mean, sure, game rendering would still suck, but playing games on 12yo hardware is kinda "you get what you (don't) pay for".
<infinity> But it's not uncommon for one of our competitors to, eg, look at your model/generation of card and just turn off some pretty.
<tjaalton> there are some quirks shipped with mesa
<infinity> Ahh, I meant more at a unity/gnome-shell level where they can just say "oh, you have crap hardware, you don't get shadows", etc.
<infinity> Which could just be an age cutoff because, frankly, rendering shadows under 30 windows is hideously taxing on old GPUs too, even when it's not buggy.
<tjaalton> ah, right
<LocutusOfBorg> apw, how do you feel about demoting camitk to proposed until the gcc-7 ITK sadness is sorted out, so we can progress with dbus and qt5.9 transition?
<apw> it doesn't sound liek the sort of thing that has a wide range of users, but i see it has some reverse-depends too
<LocutusOfBorg> all of them blocked by the insighttoolkit4/gdcm/castxml sadness?
<apw> LocutusOfBorg, i am not unsympathetic, i am unable to build a kernel any more because of gcc-7
<LocutusOfBorg> The removal of insighttoolkit4 will also cause the removal of (transitive) reverse dependencies: ants camitk elastix fw4spl ginkgocadx itksnap nifti2dicom otb plastimatch vmtk
<LocutusOfBorg> this is what I would demote for some days, it is broken and blocking other things...
<LocutusOfBorg> castxml is ongoing by upstream/debian and will probably unblock all of them
<LocutusOfBorg> apw, I can agree your frustration wrt kernel and gcc-7
<LocutusOfBorg> I tried to help, but I failed :/
<apw> LocutusOfBorg, so just castxml and its reverse depends would unblock you ?
<LocutusOfBorg> apw, e5dfa3f902b9a642ae8c6997d57d7c41e384a90b wrt linux?
 * LocutusOfBorg leaves for lunch
<LocutusOfBorg> apw, I think so, yes
<apw> LocutusOfBorg, yep one of many fixes we will need to find and apply
<apw> i have dropped 4.11
<apw> i have dropped 4.11 back to gcc-6, and we'll fight that battle on 4.12
<LocutusOfBorg> apw, 4.12.5 should contain mostly all of them AFAICS
<apw> yeah 4.12 is looking good
<LocutusOfBorg> if you want I can craft a patchset to make the current one build with gcc-7
<apw> LocutusOfBorg, na, we've good a 4.12 which builds just fine, thanks
<LocutusOfBorg> ack
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-92.115] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-92.115]
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-92.115~14.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux [s390x] (artful-proposed/main) [4.12.0-11.12] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-92.115~14.04.1]
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (artful-proposed/main) [4.12.0-11.12] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: linux-firmware (xenial-proposed/main) [1.157.11 => 1.157.12] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (xenial-proposed/partner) [163.0.0-0ubuntu1~16.04.0 => 166.0.0-0ubuntu1~16.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (zesty-proposed/partner) [163.0.0-0ubuntu1~17.04.0 => 166.0.0-0ubuntu1~17.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gnutls26 (trusty-proposed/main) [2.12.23-12ubuntu2.8 => 2.12.23-12ubuntu2.9] (core)
-queuebot:#ubuntu-release- Unapproved: gnutls28 (zesty-proposed/main) [3.5.6-4ubuntu4.1 => 3.5.6-4ubuntu4.2] (core)
-queuebot:#ubuntu-release- Unapproved: gnutls28 (xenial-proposed/main) [3.4.10-4ubuntu1.3 => 3.4.10-4ubuntu1.4] (core)
<dpb1> hi bdmurray, please reject https://launchpad.net/ubuntu/zesty/+queue?queue_state=1&queue_text=cloud-init, the merge and upload is invalid, thanks for catching
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.27]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (zesty-proposed) [2.27+17.04]
<apw> ^ rejected per the uploader
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (trusty-proposed) [2.27~14.04]
<bdmurray> dpb1: will do
<bdmurray> apw: Are they going to verify their last upload?
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (zesty-proposed) [0.7.9-233-ge586fe35-0ubuntu1~17.04.1]
<bdmurray> dpb1: The xenial one too?
<dpb1> bdmurray: yes, both of them
<apw> bdmurray, i hear they are yes, which is why i am holding that one in the queue, well was before it became junk
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (xenial-proposed) [0.7.9-233-ge586fe35-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: zfs-linux (xenial-proposed/main) [0.6.5.6-0ubuntu17 => 0.6.5.6-0ubuntu18] (no packageset)
<slangasek> jbicha: do you have any plans to investigate the mongodb/arm64 build failure?
<jbicha> slangasek: not really, sorry :( I synced the package earlier because I believe server guys wanted s390x support
<slangasek> ah, then this is cpaelzer's problem ;)
<slangasek> jbicha, cpaelzer: well, both the artful and the artful-proposed versions are now FTBFS with gcc-7; I'm not going to remove binaries to unblock a package that I know is FTBFS...
<jbicha> current stable release of mongodb is 3.4.7 released this week, the Debian package hasn't been updated in a while
-queuebot:#ubuntu-release- New binary: linux [armhf] (artful-proposed/main) [4.12.0-11.12] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [arm64] (artful-proposed/main) [4.12.0-11.12] (core, kernel)
 * tsimonq2 wonders why lots of private jobs are done at once, clogging the build queues :(
<slangasek> sometimes that happens because of security updates
-queuebot:#ubuntu-release- Unapproved: update-notifier (xenial-proposed/main) [3.168.4 => 3.168.5] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: linux [amd64] (artful-proposed/main) [4.12.0-11.12] (core, kernel)
<acheronuk> those jobs are holding up: https://launchpad.net/ubuntu/+source/cmake/3.9.1-1 on amd64 so cmake-data package will not be built, so going to get FTBFS on anything that uses cmake (on !x86) until it clears :(
<acheronuk> tsimonq2: ^^
<tsimonq2> Yep, sort of why I'm sad at long build queues :(
<slangasek> I can certainly bump cmake builds' priorities
<slangasek> done, though amd64 is still 25 minutes out apparently
<slangasek> (estimated)
<acheronuk> thanks. just rubbish timing that synced now
-queuebot:#ubuntu-release- New binary: linux [i386] (artful-proposed/main) [4.12.0-11.12] (core, kernel)
<cpaelzer> slangasek: jbicha: how did I earn the honor to be my problem - wit hmy s390 bagde?
<slangasek> cpaelzer: yes ;)
<cpaelzer> hmm :-/
<cpaelzer> I shouldn
<cpaelzer> 't have checked IRC before sleeping today :-)
 * cpaelzer is taking a not what this is about
<cpaelzer> jbicha: if you have some background on "the server guys wanted s390x" please feel free to send me
<cpaelzer> I can find out if otherwise
-queuebot:#ubuntu-release- New binary: sagemath [i386] (artful-proposed/universe) [7.6-3ubuntu3] (no packageset)
<jbicha> cpaelzer: LP: #1595242
<ubot5> Launchpad bug 1595242 in MongoDB Charm "mongodb xenial s390x packages are needed (blocks ceilometer)" [Undecided,Confirmed] https://launchpad.net/bugs/1595242
<dpb1> cpaelzer: let's chat monday -- I'll add this detail to a card in TODO
-queuebot:#ubuntu-release- New: accepted linux [amd64] (artful-proposed) [4.12.0-11.12]
-queuebot:#ubuntu-release- New: accepted linux [armhf] (artful-proposed) [4.12.0-11.12]
-queuebot:#ubuntu-release- New: accepted linux [ppc64el] (artful-proposed) [4.12.0-11.12]
-queuebot:#ubuntu-release- New: accepted linux [arm64] (artful-proposed) [4.12.0-11.12]
-queuebot:#ubuntu-release- New: accepted linux [s390x] (artful-proposed) [4.12.0-11.12]
-queuebot:#ubuntu-release- New: accepted linux [i386] (artful-proposed) [4.12.0-11.12]
-queuebot:#ubuntu-release- New binary: sagemath [amd64] (artful-proposed/universe) [7.6-3ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New: accepted node-seq [amd64] (artful-proposed) [0.3.5-2]
-queuebot:#ubuntu-release- New: accepted sambamba [amd64] (artful-proposed) [0.6.6-1]
-queuebot:#ubuntu-release- New: accepted swath [amd64] (artful-proposed) [0.5.5-2]
-queuebot:#ubuntu-release- New: accepted python-pymeasure [amd64] (artful-proposed) [0.4.5-1]
-queuebot:#ubuntu-release- New: accepted sambamba [i386] (artful-proposed) [0.6.6-1]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (artful-proposed/main) [4.12.0-11.12] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (artful-proposed) [4.12.0-11.12]
#ubuntu-release 2017-08-12
-queuebot:#ubuntu-release- New binary: libgepub [ppc64el] (artful-proposed/universe) [0.5.2-0ubuntu1] (ubuntugnome)
-queuebot:#ubuntu-release- New binary: libgepub [arm64] (artful-proposed/universe) [0.5.2-0ubuntu1] (ubuntugnome)
-queuebot:#ubuntu-release- New binary: libgepub [amd64] (artful-proposed/universe) [0.5.2-0ubuntu1] (ubuntugnome)
-queuebot:#ubuntu-release- New binary: libgepub [i386] (artful-proposed/universe) [0.5.2-0ubuntu1] (ubuntugnome)
-queuebot:#ubuntu-release- New binary: libgepub [s390x] (artful-proposed/universe) [0.5.2-0ubuntu1] (ubuntugnome)
-queuebot:#ubuntu-release- New binary: libgepub [armhf] (artful-proposed/universe) [0.5.2-0ubuntu1] (ubuntugnome)
-queuebot:#ubuntu-release- New sync: bibledit (artful-proposed/primary) [5.0.145-1]
-queuebot:#ubuntu-release- New binary: sbt [amd64] (artful-proposed/universe) [0.13.13-2] (no packageset)
<LocutusOfBorg> can anybody please ignore camitk test results? they are broken because of gcc, as well as cmake-extras and shark
<LocutusOfBorg> cmake-extras is fixed in my new upload, the other two needs fixes from debian
<LocutusOfBorg> (they are both RC buggy, but I don't want them to stop cmake to transition)
<LocutusOfBorg> sagemath can be accepted, it has been build where it was before :)
<LocutusOfBorg> thansk slangasek for fixing it
-queuebot:#ubuntu-release- New binary: libjaylink [ppc64el] (artful-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libjaylink [s390x] (artful-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libjaylink [amd64] (artful-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libjaylink [armhf] (artful-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libjaylink [arm64] (artful-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libjaylink [i386] (artful-proposed/universe) [0.1.0-1] (no packageset)
<doko> tsimonq2: why are you syncing the ada packages with updating the gnat package before? that doesn't really help ...
<tsimonq2> doko: I wasn't aware of the gnat issue before syncing it (or rather, asking LocutusOfBorg to sync it for me), then LocutusOfBorg filled me in on why it was FTBFS. Apologies, my mistake.
-queuebot:#ubuntu-release- New binary: exec-maven-plugin [amd64] (artful-proposed/universe) [1.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libxmlada [s390x] (artful-proposed/universe) [17.1.2017-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libxmlada [ppc64el] (artful-proposed/universe) [17.1.2017-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libxmlada [amd64] (artful-proposed/universe) [17.1.2017-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libxmlada [i386] (artful-proposed/universe) [17.1.2017-4] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-bloom [amd64] (artful-proposed/universe) [0.5.26-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted sagemath [amd64] (artful-proposed) [7.6-3ubuntu3]
-queuebot:#ubuntu-release- New: accepted sagemath [i386] (artful-proposed) [7.6-3ubuntu3]
-queuebot:#ubuntu-release- New: accepted bibledit [sync] (artful-proposed) [5.0.145-1]
-queuebot:#ubuntu-release- New: accepted ros-bloom [amd64] (artful-proposed) [0.5.26-3]
-queuebot:#ubuntu-release- New: accepted exec-maven-plugin [amd64] (artful-proposed) [1.6.0-1]
-queuebot:#ubuntu-release- New: accepted sbt [amd64] (artful-proposed) [0.13.13-2]
-queuebot:#ubuntu-release- New: accepted libgepub [amd64] (artful-proposed) [0.5.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libgepub [armhf] (artful-proposed) [0.5.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libgepub [ppc64el] (artful-proposed) [0.5.2-0ubuntu1]
-queuebot:#ubuntu-release- New binary: libxmlada [arm64] (artful-proposed/universe) [17.1.2017-4] (no packageset)
-queuebot:#ubuntu-release- New: accepted libgepub [arm64] (artful-proposed) [0.5.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libgepub [s390x] (artful-proposed) [0.5.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libgepub [i386] (artful-proposed) [0.5.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libjaylink [amd64] (artful-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted libjaylink [armhf] (artful-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted libjaylink [ppc64el] (artful-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted libjaylink [arm64] (artful-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted libjaylink [s390x] (artful-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted libjaylink [i386] (artful-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted libxmlada [amd64] (artful-proposed) [17.1.2017-4]
-queuebot:#ubuntu-release- New: accepted libxmlada [i386] (artful-proposed) [17.1.2017-4]
-queuebot:#ubuntu-release- New: accepted libxmlada [s390x] (artful-proposed) [17.1.2017-4]
-queuebot:#ubuntu-release- New: accepted libxmlada [arm64] (artful-proposed) [17.1.2017-4]
-queuebot:#ubuntu-release- New: accepted libxmlada [ppc64el] (artful-proposed) [17.1.2017-4]
#ubuntu-release 2017-08-13
<slangasek> LocutusOfBorg: sagemath will still be stuck in -proposed however, because another breaking package made it into artful while it was removed <shrug>
-queuebot:#ubuntu-release- New binary: gprbuild [ppc64el] (artful-proposed/universe) [2017-4] (no packageset)
-queuebot:#ubuntu-release- New binary: gprbuild [s390x] (artful-proposed/universe) [2017-4] (no packageset)
-queuebot:#ubuntu-release- New binary: gprbuild [i386] (artful-proposed/universe) [2017-4] (no packageset)
-queuebot:#ubuntu-release- New binary: gprbuild [amd64] (artful-proposed/universe) [2017-4] (no packageset)
-queuebot:#ubuntu-release- New binary: gprbuild [arm64] (artful-proposed/universe) [2017-4] (no packageset)
-queuebot:#ubuntu-release- New binary: gprbuild [armhf] (artful-proposed/universe) [2017-4] (no packageset)
-queuebot:#ubuntu-release- New: accepted gprbuild [amd64] (artful-proposed) [2017-4]
-queuebot:#ubuntu-release- New: accepted gprbuild [armhf] (artful-proposed) [2017-4]
-queuebot:#ubuntu-release- New: accepted gprbuild [ppc64el] (artful-proposed) [2017-4]
-queuebot:#ubuntu-release- New: accepted gprbuild [arm64] (artful-proposed) [2017-4]
-queuebot:#ubuntu-release- New: accepted gprbuild [s390x] (artful-proposed) [2017-4]
-queuebot:#ubuntu-release- New: accepted gprbuild [i386] (artful-proposed) [2017-4]
-queuebot:#ubuntu-release- New binary: libaunit [s390x] (artful-proposed/universe) [17.2017-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libgmpada [ppc64el] (artful-proposed/universe) [1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libaunit [armhf] (artful-proposed/universe) [17.2017-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libaunit [ppc64el] (artful-proposed/universe) [17.2017-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libaunit [amd64] (artful-proposed/universe) [17.2017-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libaunit [i386] (artful-proposed/universe) [17.2017-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libgmpada [i386] (artful-proposed/universe) [1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libaunit [arm64] (artful-proposed/universe) [17.2017-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libgmpada [s390x] (artful-proposed/universe) [1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libgmpada [amd64] (artful-proposed/universe) [1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libgmpada [arm64] (artful-proposed/universe) [1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libtemplates-parser [s390x] (artful-proposed/universe) [17.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libgmpada [armhf] (artful-proposed/universe) [1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: sparse [ppc64el] (artful-proposed/universe) [0.5.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libtemplates-parser [ppc64el] (artful-proposed/universe) [17.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: sparse [amd64] (artful-proposed/universe) [0.5.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libtemplates-parser [amd64] (artful-proposed/universe) [17.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: sparse [i386] (artful-proposed/universe) [0.5.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libtemplates-parser [i386] (artful-proposed/universe) [17.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: sparse [s390x] (artful-proposed/universe) [0.5.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: sparse [arm64] (artful-proposed/universe) [0.5.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libtemplates-parser [arm64] (artful-proposed/universe) [17.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: sparse [armhf] (artful-proposed/universe) [0.5.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libtemplates-parser [armhf] (artful-proposed/universe) [17.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libncursesada [amd64] (artful-proposed/universe) [6.0.20170708-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libtexttools [amd64] (artful-proposed/universe) [2.1.0-10] (no packageset)
-queuebot:#ubuntu-release- New binary: libncursesada [ppc64el] (artful-proposed/universe) [6.0.20170708-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libflorist [amd64] (artful-proposed/universe) [2017-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libflorist [s390x] (artful-proposed/universe) [2017-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libncursesada [i386] (artful-proposed/universe) [6.0.20170708-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libtexttools [ppc64el] (artful-proposed/universe) [2.1.0-10] (no packageset)
-queuebot:#ubuntu-release- New binary: libflorist [ppc64el] (artful-proposed/universe) [2017-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libtexttools [i386] (artful-proposed/universe) [2.1.0-10] (no packageset)
-queuebot:#ubuntu-release- New binary: libncursesada [arm64] (artful-proposed/universe) [6.0.20170708-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libflorist [i386] (artful-proposed/universe) [2017-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libncursesada [s390x] (artful-proposed/universe) [6.0.20170708-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libncursesada [armhf] (artful-proposed/universe) [6.0.20170708-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libtexttools [arm64] (artful-proposed/universe) [2.1.0-10] (no packageset)
-queuebot:#ubuntu-release- New binary: libflorist [arm64] (artful-proposed/universe) [2017-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libtexttools [armhf] (artful-proposed/universe) [2.1.0-10] (no packageset)
-queuebot:#ubuntu-release- New binary: libflorist [armhf] (artful-proposed/universe) [2017-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libtexttools [s390x] (artful-proposed/universe) [2.1.0-10] (no packageset)
-queuebot:#ubuntu-release- New binary: opentoken [amd64] (artful-proposed/universe) [6.0b-7] (no packageset)
-queuebot:#ubuntu-release- New binary: opentoken [ppc64el] (artful-proposed/universe) [6.0b-7] (no packageset)
-queuebot:#ubuntu-release- New binary: opentoken [i386] (artful-proposed/universe) [6.0b-7] (no packageset)
-queuebot:#ubuntu-release- New binary: opentoken [arm64] (artful-proposed/universe) [6.0b-7] (no packageset)
-queuebot:#ubuntu-release- New binary: opentoken [s390x] (artful-proposed/universe) [6.0b-7] (no packageset)
-queuebot:#ubuntu-release- New binary: opentoken [armhf] (artful-proposed/universe) [6.0b-7] (no packageset)
<LocutusOfBorg> the gnat-7 packages should be ready now ^^
<LocutusOfBorg> thanks doko :)
<LocutusOfBorg> I syncd after the activity on -ftp, with a retry ready to go
-queuebot:#ubuntu-release- New binary: libxmlezout [amd64] (artful-proposed/universe) [1.06.1-10] (no packageset)
-queuebot:#ubuntu-release- New binary: libxmlezout [i386] (artful-proposed/universe) [1.06.1-10] (no packageset)
-queuebot:#ubuntu-release- New binary: libxmlezout [arm64] (artful-proposed/universe) [1.06.1-10] (no packageset)
-queuebot:#ubuntu-release- New binary: libxmlezout [ppc64el] (artful-proposed/universe) [1.06.1-10] (no packageset)
-queuebot:#ubuntu-release- New binary: libxmlezout [armhf] (artful-proposed/universe) [1.06.1-10] (no packageset)
-queuebot:#ubuntu-release- New binary: libxmlezout [s390x] (artful-proposed/universe) [1.06.1-10] (no packageset)
#ubuntu-release 2018-08-06
-queuebot:#ubuntu-release- Unapproved: squashfs-tools (xenial-proposed/main) [1:4.3-3ubuntu2.16.04.2 => 1:4.3-3ubuntu2.16.04.3] (core)
<stgraber> slangasek: ^ I think I've got the paperwork in order for this one
-queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (bionic-proposed/main) [1:0.5.2 => 1:0.5.2.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: xorg-lts-transitional [ppc64el] (cosmic-proposed/universe) [3:14.2] (ubuntukylin)
-queuebot:#ubuntu-release- New binary: xorg-lts-transitional [amd64] (cosmic-proposed/universe) [3:14.2] (ubuntukylin)
-queuebot:#ubuntu-release- New binary: xorg-lts-transitional [armhf] (cosmic-proposed/universe) [3:14.2] (ubuntukylin)
-queuebot:#ubuntu-release- New binary: xorg-lts-transitional [arm64] (cosmic-proposed/universe) [3:14.2] (ubuntukylin)
-queuebot:#ubuntu-release- New binary: xorg-lts-transitional [i386] (cosmic-proposed/universe) [3:14.2] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: fwupdate (cosmic-proposed/main) [12-2 => 12-3] (core)
-queuebot:#ubuntu-release- Unapproved: fwupdate (cosmic-proposed/main) [12-2 => 12-3] (core)
-queuebot:#ubuntu-release- New binary: fwupdate [armhf] (cosmic-proposed/main) [12-3] (core)
-queuebot:#ubuntu-release- New binary: unibetacode [amd64] (cosmic-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: unibetacode [i386] (cosmic-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: unibetacode [s390x] (cosmic-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: utf8gen [i386] (cosmic-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: utf8gen [s390x] (cosmic-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: utfcheck [i386] (cosmic-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: utfcheck [s390x] (cosmic-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gamemode [amd64] (cosmic-proposed/universe) [1.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: unibetacode [ppc64el] (cosmic-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: utf8gen [ppc64el] (cosmic-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: utfcheck [ppc64el] (cosmic-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: unibetacode [arm64] (cosmic-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: utfcheck [amd64] (cosmic-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: utf8gen [amd64] (cosmic-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fwupdate (cosmic-proposed/main) [12-2 => 12-3] (core)
-queuebot:#ubuntu-release- New binary: moksha.common [amd64] (cosmic-proposed/universe) [1.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: utf8gen [arm64] (cosmic-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: utfcheck [arm64] (cosmic-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: unibetacode [armhf] (cosmic-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: utfcheck [armhf] (cosmic-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: utf8gen [armhf] (cosmic-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (cosmic-proposed) [4.17.0-7.8]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (cosmic-proposed) [4.17.0-7.8]
<coreycb> infinity: sil2100: hi, would one of you be able to take a look at accepting keepalived from the xenial unapproved queue?
<sil2100> coreycb: hey! Sure, I'll be taking care of my SRU shift shortly
<coreycb> thanks sil2100 !
<LocutusOfBorg> somebody please accept xorg-lts-transitional ?
-queuebot:#ubuntu-release- Unapproved: accepted keepalived [source] (xenial-proposed) [1:1.2.24-1ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-390 (bionic-proposed/restricted) [390.48-0ubuntu3 => 390.77-0ubuntu0.18.04.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: nvidia-prime (bionic-proposed/main) [0.8.8 => 0.8.8.1] (ubuntu-desktop)
<blackboxsw> sil2100: any chance we can publish cloud-init 18.3-9-g2e62cb8a-0ubuntu1~16.04.2  from -proposed into -updates the previous SRU  (18.3-9...16.04.1) had aged about 3 weeks before we found a trivial bug that needed fixing. https://bugs.launchpad.net/cloud-init/+bug/1784685
<ubot5> Ubuntu bug 1784685 in cloud-init "Oracle: cloud-init openstack local detection too strict for oracle cloud" [High,Fix committed]
<blackboxsw> the only change between cloud-init 18.3-9-g2e62cb8a-0ubuntu1~16.04.1 and .16.04.2 is the cherry picked bug fix for the above bug
<blackboxsw> same with 18.04.1 and 18.04.2, just a cherry pick
<blackboxsw> all verification logs are attached to SRU process bug https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1777912
<ubot5> Ubuntu bug 1777912 in cloud-init (Ubuntu Bionic) "sru cloud-init (18.2-4-g05926e48-0ubuntu1) to (18.3-9ubuntu1)" [Medium,Fix committed]
<LocutusOfBorg> trying: php-doctrine-dbal
<LocutusOfBorg> can anybody please tell me why it is not migrating?
<LocutusOfBorg> no ABI changes, testsuite is good
<LocutusOfBorg>     got: 13+0: a-6:a-1:a-3:i-1:p-1:s-1
<LocutusOfBorg>     * amd64: php-doctrine-bundle, php-doctrine-orm
<LocutusOfBorg> but they are installable
<apw> LocutusOfBorg, because php-doctrine-bundle depends on php-doctrine-dbal ?
<LocutusOfBorg> apw, aaaaaand?
<LocutusOfBorg> britney is not smart enough to understand they are installable together?
<LocutusOfBorg> BTW please hint:
<LocutusOfBorg> autopkgtest for sagetex/3.0+ds-6: amd64: Pass, armhf: Regression â»
<LocutusOfBorg> sagemath is now removed on armhf, so sagetex can't pass testsuite
<apw> LocutusOfBorg, ok ... if i am doing this right, this is because ... to update -dbal we would have to update php-doctrine-event-manager, and if we do that it would fail the php-doctrine-event-manager contstraint Breaks: php-doctrine-common (< 2.9~~)
-queuebot:#ubuntu-release- New binary: python-ceilometermiddleware [amd64] (cosmic-proposed/universe) [1.3.0-0ubuntu1] (openstack)
<apw> and that is not ready to migrate, so ... it cannot migrate
<LocutusOfBorg> hmmm, I don't know why they are installble to me with -t cosmic-proposed, let me check
<apw> -t to waht
<LocutusOfBorg> apt-get install -t cosmic-proposed of the packages
<apw> apt-get ?  because it would install the package failing tests ?
<LocutusOfBorg> oh.... the common is not ready
<LocutusOfBorg> thanks
<tjaalton> infinity: xorg-lts-transitional is in new, I dropped all the packages that the wip bug would remove
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-release-upgrader [source] (bionic-proposed) [1:18.04.22]
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (bionic-proposed/main) [1:18.04.21 => 1:18.04.22] (core)
<LocutusOfBorg> and I rebuilt virtualbox-hwe against the new 18.04 transitional package
<LocutusOfBorg> tjaalton, do you think you can give me a "provided" metapackage, so I don't have to hardcode version in virtualbox-hwe?
<LocutusOfBorg> xserver-xorg-dev-hwe-16.04 -> xserver-xorg-dev-hwe-18.04 is PITA to maintain
<tjaalton> you mean -dev-hwe-18.04 would Provides -16.04?
<LocutusOfBorg> tjaalton, something like this, even if it sounds bad too
<tjaalton> hmm no that'd be wrong. you'd need it in x-x-dev
<tjaalton> and then it'd not work too well..
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (bionic-proposed) [1:18.04.22]
<stgraber> can someone review squashfs-tools in xenial-proposed? should be a pretty straightforward SRU that'll unblock LXD and anyone else trying to unpack a recent Ubuntu squashfs on xenial
-queuebot:#ubuntu-release- New binary: wsclean [s390x] (cosmic-proposed/universe) [2.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: s-tui [amd64] (cosmic-proposed/none) [0.7.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wsclean [ppc64el] (cosmic-proposed/universe) [2.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: barclay [amd64] (cosmic-proposed/none) [2.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: jaxrpc-api [amd64] (cosmic-proposed/none) [1.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gatk-native-bindings [amd64] (cosmic-proposed/none) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: wsclean [arm64] (cosmic-proposed/universe) [2.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wsclean [amd64] (cosmic-proposed/universe) [2.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wsclean [i386] (cosmic-proposed/universe) [2.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wsclean [armhf] (cosmic-proposed/universe) [2.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-30.32] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-30.32]
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-30.32] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [4.15.0-1019.19] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [4.15.0-1019.19]
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1013.16] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1013.16]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-30.32]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-30.32~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-30.32~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-30.32~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-30.32~16.04.1]
-queuebot:#ubuntu-release- New binary: python-os-traits [amd64] (cosmic-proposed/main) [0.9.0-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.5 => 2.525.6] (desktop-core)
-queuebot:#ubuntu-release- New binary: dbus-glib [amd64] (cosmic-proposed/main) [0.110-3] (core)
-queuebot:#ubuntu-release- New binary: dbus-glib [s390x] (cosmic-proposed/main) [0.110-3] (core)
-queuebot:#ubuntu-release- New binary: dbus-glib [i386] (cosmic-proposed/main) [0.110-3] (core)
-queuebot:#ubuntu-release- New binary: libpgobject-util-pseudocsv-perl [amd64] (cosmic-proposed/universe) [2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: trace2dbest [amd64] (cosmic-proposed/universe) [3.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sl-modem [amd64] (cosmic-proposed/multiverse) [2.9.11~20110321-13] (no packageset)
-queuebot:#ubuntu-release- New binary: dbus-glib [ppc64el] (cosmic-proposed/main) [0.110-3] (core)
-queuebot:#ubuntu-release- New binary: sl-modem [i386] (cosmic-proposed/multiverse) [2.9.11~20110321-13] (no packageset)
-queuebot:#ubuntu-release- New binary: dbus-glib [armhf] (cosmic-proposed/main) [0.110-3] (core)
-queuebot:#ubuntu-release- New binary: dbus-glib [arm64] (cosmic-proposed/main) [0.110-3] (core)
<ehashman> rbasak: ping
<ehashman> would like to chat with some people about https://bugs.launchpad.net/ubuntu/+source/nodejs/+bug/1779863 , maybe it will be easier on IRC
<ubot5> Ubuntu bug 1779863 in nodejs (Ubuntu Cosmic) "Ubuntu nodejs package isn't ABI compatible with mainline nodejs." [Medium,In progress]
<tsimonq2> ehashman: bug 1770655 is potentially related.
<ubot5> bug 1770655 in nodejs (Ubuntu) "nodejs is at 8.10 while 8.11 is a security release." [High,Confirmed] https://launchpad.net/bugs/1770655
<ehashman> I think I saw that one earlier
<ahasenack> ehashman: it's very late for rbasak now, he is in the uk
<ehashman> ahasenack: thanks :)
<ahasenack> welcome
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [source] (bionic-proposed) [3.28.3-0ubuntu0.18.04.2]
<ehashman> ahh I found some relevant backscrool
<ehashman> reading from here: https://irclogs.ubuntu.com/2018/07/25/%23ubuntu-release.html#t13:20
#ubuntu-release 2018-08-07
<ehashman> re: https://irclogs.ubuntu.com/2018/07/25/%23ubuntu-release.html#t13:56 the issue is that node vendors upstream openssl (and since it's 1.0 and upstream, it doesn't have symbol versions), and then node exports those symbols as part of *its* ABI (cc apw)
<ehashman> and I agree that this is bonkers and I am trying to help them figure out a better strategy...
<ehashman> because the symbols are unversioned, that makes this bug particularly sticky. my goals are to get this fixed in node upstream by helping them figure out a better ABI strategy (that will probably take a stable release cycle), to get this fixed in Debian by upgrading to node 10.x (since we want to drop openssl 1.0 support in buster and that kills two birds with one stone), and
<ehashman> to hopefully fix this in Ubuntu by patching node 8.x there to use the right major version of openssl, because right now we have a massive ABI mismatch in which we have unversioned symbols in upstream from 1.0 vs versioned, incompatible symbols in 1.1... in its current state, you can't compile or run native extensions against ubuntu's nodejs
<ehashman> infinity: this also may be of interest to you as you were commenting in said backscroll
<ehashman> for the average nodejs user I'd say this renders nodejs in Ubuntu totally broken (since they will want to be able to use stuff they npm install against system node, similar to python users downloading stuff with pip and expecting it to work)
<tjaalton> any archive admin: xorg-lts-transitional needs to move out of NEW
-queuebot:#ubuntu-release- New binary: nsync [s390x] (cosmic-proposed/none) [1.20.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: poezio [s390x] (cosmic-proposed/universe) [0.11+git20180805-1] (no packageset)
-queuebot:#ubuntu-release- New binary: poezio [ppc64el] (cosmic-proposed/universe) [0.11+git20180805-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nsync [amd64] (cosmic-proposed/universe) [1.20.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nsync [ppc64el] (cosmic-proposed/universe) [1.20.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: poezio [i386] (cosmic-proposed/universe) [0.11+git20180805-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nsync [arm64] (cosmic-proposed/universe) [1.20.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: poezio [amd64] (cosmic-proposed/universe) [0.11+git20180805-1] (no packageset)
-queuebot:#ubuntu-release- New binary: poezio [arm64] (cosmic-proposed/universe) [0.11+git20180805-1] (no packageset)
-queuebot:#ubuntu-release- New binary: poezio [armhf] (cosmic-proposed/universe) [0.11+git20180805-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: samba (trusty-proposed/main) [2:4.3.11+dfsg-0ubuntu0.14.04.14 => 2:4.3.11+dfsg-0ubuntu0.14.04.15] (core)
-queuebot:#ubuntu-release- Unapproved: samba (xenial-proposed/main) [2:4.3.11+dfsg-0ubuntu0.16.04.13 => 2:4.3.11+dfsg-0ubuntu0.16.04.14] (core)
-queuebot:#ubuntu-release- Unapproved: open-vm-tools (bionic-proposed/main) [2:10.2.0-3ubuntu3 => 2:10.3.0-0ubuntu1~18.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- New binary: dovecot [s390x] (cosmic-proposed/main) [1:2.3.2.1-1ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: dovecot [ppc64el] (cosmic-proposed/main) [1:2.3.2.1-1ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: dovecot [amd64] (cosmic-proposed/main) [1:2.3.2.1-1ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: dovecot [i386] (cosmic-proposed/main) [1:2.3.2.1-1ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: dovecot [arm64] (cosmic-proposed/main) [1:2.3.2.1-1ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: dovecot [armhf] (cosmic-proposed/main) [1:2.3.2.1-1ubuntu1] (ubuntu-server)
<tsimonq2> So, it seems Qt is blocked on ffmpeg, which needs its ppc64el test sorted out...
<tsimonq2> I can't seem to make heads or tails of this failure... harumph.
<acheronuk> and the remaining FTBFS stuff against ffmpeg 4 fixed or kicked to the kerb
<tsimonq2> Right, I was just sorting through these... hmmm
<acheronuk> some have fixes in debian bugs, some have a fix bus doesn't apply well to the current patched source, some could maybe just be booted to -proposed.....
<acheronuk> lovely!
<tsimonq2> I've reached my time limit for today... I'm going to bed; maybe later I'll go through and fix some of these RC bugs in Debian, and try to get a list of things that need booting to -proposed.
<tsimonq2> Help fixing that ppc64el test failure would be appreciated, though.
<tsimonq2> Ciao o/
<acheronuk> strigi can be removed from archive when amarok in -proposed can go to -release
<acheronuk> tsimonq2: thanks
<apw> ehashman, that is a tricky problem, as anyone already installing nodejs and using it has the oposite problem; slangasek ^^
-queuebot:#ubuntu-release- Unapproved: accepted rax-nova-agent [source] (bionic-proposed) [2.1.15-0ubuntu1~18.04.0]
<tjaalton> apw: can you push xorg-lts-transitional through NEW?
<tjaalton> would be one less step in getting xserver update to cosmic..
<apw> tjaalton, if they are transitionals for something, how come they are New ?
<tjaalton> apw: new package names
<apw> right, but if they are transitionals they should be old names by definition
<tjaalton> bionic has the old names, -hwe-16.04 -> stock
<tjaalton> this is for the next stack which doesn't even exist yet
<apw> so we are making transitionals for something which doesn't even exist ?
<tjaalton> traditionally it would be removed from the devel series at this point, and reintroduced to the next lts
<apw> so i am confused how this will un
<apw> unblock anything
<apw> tjaalton, but i assume you are saying you are about to introduce these into bionic ?
<tjaalton> in a few months
<tjaalton> once there's something to backport
<apw> so this upload is about actually removing the 16.04 ones really
<tjaalton> there are drivers that haven't been rebuilt for the new abi, because I want the gone, but that bug hasn't seen any action since may
<apw> it is the removal of the 16.04 ones in this upload that lets us migrate ?
-queuebot:#ubuntu-release- Unapproved: rejected catfish [source] (bionic-proposed) [1.4.6-0ubuntu0.18.04.1]
<tjaalton> aiui if the dep can't be installed, then the transitional isn't installalbe
<tjaalton> or would become uninstallable with the xserver from proposed
<tjaalton> that's why
<apw> tjaalton, right, so i think we are saying we have 16.04 transitionals pointing to things which go away if xorg migrates, and
<apw> this new transitionals doesn't reference them at all ?
<tjaalton> so this new pkg actually removes all the drivers that haven't been rebuilt
<tjaalton> so actually, to unblock I could just readd the -hwe-16.04 names
<tjaalton> apw: right
<apw> i am wondering if removing this thing from -release makes as much sense
<tjaalton> the idea was to allow upgrades from lts with hwe stack to an interim release
<apw> but i guess it is safe to do that as much with this one if we decide the dangling is embaressing
<tjaalton> avoids an sru
<apw> right and they should exist for sure once this all exists in bionic ... just feels a bit odd to have it before they exist
<tjaalton> sure
<apw> but, we can argue about that as much as we can about the -hwe-16.04 ones existing poinlessly now
<apw> and as safely in either pocket
<tjaalton> well, for the unblock I can just go back to old names and only drop the drivers
<tjaalton> either way
-queuebot:#ubuntu-release- New: accepted xorg-lts-transitional [amd64] (cosmic-proposed) [3:14.2]
-queuebot:#ubuntu-release- New: accepted xorg-lts-transitional [armhf] (cosmic-proposed) [3:14.2]
-queuebot:#ubuntu-release- New: accepted xorg-lts-transitional [ppc64el] (cosmic-proposed) [3:14.2]
-queuebot:#ubuntu-release- New: accepted xorg-lts-transitional [arm64] (cosmic-proposed) [3:14.2]
-queuebot:#ubuntu-release- New: accepted xorg-lts-transitional [i386] (cosmic-proposed) [3:14.2]
<apw> tjaalton, ^
<tjaalton> apw: thanks
<tjaalton> if you have more cycles to spare, there's always bug 1772588 ;)
<ubot5> bug 1772588 in xserver-xorg-video-trident (Ubuntu) "Remove obsolete X11 drivers from the archive" [Undecided,New] https://launchpad.net/bugs/1772588
-queuebot:#ubuntu-release- New: accepted barclay [amd64] (cosmic-proposed) [2.1.0-2]
-queuebot:#ubuntu-release- New: accepted boohu [arm64] (cosmic-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted boohu [i386] (cosmic-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted boohu [s390x] (cosmic-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted boohu [amd64] (cosmic-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted boohu [ppc64el] (cosmic-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted boohu [armhf] (cosmic-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted dbus-glib [amd64] (cosmic-proposed) [0.110-3]
-queuebot:#ubuntu-release- New: accepted dbus-glib [armhf] (cosmic-proposed) [0.110-3]
-queuebot:#ubuntu-release- New: accepted dbus-glib [ppc64el] (cosmic-proposed) [0.110-3]
-queuebot:#ubuntu-release- New: accepted gamemode [amd64] (cosmic-proposed) [1.2-3]
-queuebot:#ubuntu-release- New: accepted jaxrpc-api [amd64] (cosmic-proposed) [1.1.2-1]
-queuebot:#ubuntu-release- New: accepted moksha.common [amd64] (cosmic-proposed) [1.2.5-1]
-queuebot:#ubuntu-release- New: accepted poezio [arm64] (cosmic-proposed) [0.11+git20180331-1]
-queuebot:#ubuntu-release- New: accepted poezio [ppc64el] (cosmic-proposed) [0.11+git20180331-1]
-queuebot:#ubuntu-release- New: accepted dbus-glib [arm64] (cosmic-proposed) [0.110-3]
-queuebot:#ubuntu-release- New: accepted dbus-glib [s390x] (cosmic-proposed) [0.110-3]
-queuebot:#ubuntu-release- New: accepted libpgobject-util-pseudocsv-perl [amd64] (cosmic-proposed) [2-1]
-queuebot:#ubuntu-release- New: accepted poezio [armhf] (cosmic-proposed) [0.11+git20180331-1]
-queuebot:#ubuntu-release- New: accepted dbus-glib [i386] (cosmic-proposed) [0.110-3]
-queuebot:#ubuntu-release- New: accepted poezio [amd64] (cosmic-proposed) [0.11+git20180331-1]
-queuebot:#ubuntu-release- New: accepted gatk-native-bindings [amd64] (cosmic-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted poezio [i386] (cosmic-proposed) [0.11+git20180331-1]
-queuebot:#ubuntu-release- New: accepted poezio [amd64] (cosmic-proposed) [0.11+git20180805-1]
-queuebot:#ubuntu-release- New: accepted poezio [armhf] (cosmic-proposed) [0.11+git20180805-1]
-queuebot:#ubuntu-release- New: accepted poezio [ppc64el] (cosmic-proposed) [0.11+git20180805-1]
-queuebot:#ubuntu-release- New: accepted s-tui [amd64] (cosmic-proposed) [0.7.5-1]
-queuebot:#ubuntu-release- New: accepted unibetacode [amd64] (cosmic-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted unibetacode [armhf] (cosmic-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted unibetacode [ppc64el] (cosmic-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted utf8gen [amd64] (cosmic-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted utf8gen [armhf] (cosmic-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted poezio [s390x] (cosmic-proposed) [0.11+git20180331-1]
-queuebot:#ubuntu-release- New: accepted poezio [i386] (cosmic-proposed) [0.11+git20180805-1]
-queuebot:#ubuntu-release- New: accepted trace2dbest [amd64] (cosmic-proposed) [3.0.1-1]
-queuebot:#ubuntu-release- New: accepted unibetacode [i386] (cosmic-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted utf8gen [arm64] (cosmic-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted utf8gen [ppc64el] (cosmic-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted utfcheck [amd64] (cosmic-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted utfcheck [armhf] (cosmic-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted poezio [arm64] (cosmic-proposed) [0.11+git20180805-1]
-queuebot:#ubuntu-release- New: accepted unibetacode [arm64] (cosmic-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted utf8gen [i386] (cosmic-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted utfcheck [arm64] (cosmic-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted poezio [s390x] (cosmic-proposed) [0.11+git20180805-1]
-queuebot:#ubuntu-release- New: accepted utf8gen [s390x] (cosmic-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted unibetacode [s390x] (cosmic-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted utfcheck [i386] (cosmic-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted utfcheck [ppc64el] (cosmic-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted wsclean [amd64] (cosmic-proposed) [2.6-1]
-queuebot:#ubuntu-release- New: accepted wsclean [armhf] (cosmic-proposed) [2.6-1]
-queuebot:#ubuntu-release- New: accepted wsclean [ppc64el] (cosmic-proposed) [2.6-1]
-queuebot:#ubuntu-release- New: accepted yubikey-manager [amd64] (cosmic-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted utfcheck [s390x] (cosmic-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted wsclean [i386] (cosmic-proposed) [2.6-1]
-queuebot:#ubuntu-release- New: accepted wsclean [arm64] (cosmic-proposed) [2.6-1]
-queuebot:#ubuntu-release- New: accepted wsclean [s390x] (cosmic-proposed) [2.6-1]
-queuebot:#ubuntu-release- Unapproved: accepted vala [source] (bionic-proposed) [0.40.8-0ubuntu1]
<bluesabre> Unapproved: rejected catfish [source] (bionic-proposed) [1.4.6-0ubuntu0.18.04.1] ? Why was the catfish SRU rejected?
<rbasak> ehashman: o/
<rbasak> ehashman: yeah that was going to be roughly my suggestion. It's quite OK to suggest that the ABI be versioned to differentiate these cases. But how ABI versioning works is dictated by upstream. Ideally these would be accomodated for in the best possible way, automatically, by upstream code.
-queuebot:#ubuntu-release- New binary: gkl [amd64] (cosmic-proposed/universe) [0.8.5+dfsg-1] (no packageset)
<apw> bluesabre, normally you get an email, and if it was done via the tooling (which it should) i believe it puts it in your SRU bug too
<acheronuk> apw: would you have time to look at: https://code.launchpad.net/~rikmills/britney/hints-ubuntu/+merge/347451
<apw> acheronuk, hmmm, that is a bit brutal
<bluesabre> apw: hm, says "Rejected by Åukasz Zemczak: Deprecated by a newer upload." I don't think there has been another bionic upload for it, so guess I need to have it sponsored again?
<acheronuk> apw: either that or I have to keep a delta with debian to skip it as we did. it would be better for me if I could just let it sync in future, but I'll put the delta back if you don't like the hint
<apw> acheronuk, i am mulling, it is more the lack of a way to express what i want
-queuebot:#ubuntu-release- Unapproved: nvidia-settings (bionic-proposed/main) [390.42-0ubuntu1 => 390.77-0ubuntu0.18.04.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: python-uinput [s390x] (cosmic-proposed/none) [0.11.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-uinput [ppc64el] (cosmic-proposed/universe) [0.11.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-uinput [amd64] (cosmic-proposed/universe) [0.11.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-uinput [i386] (cosmic-proposed/universe) [0.11.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-uinput [arm64] (cosmic-proposed/universe) [0.11.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-uinput [armhf] (cosmic-proposed/universe) [0.11.2-1] (no packageset)
<acheronuk> apw: ok. mull at your leisure
 * acheronuk retries test in case it behaves better with Qt 5.11
<acheronuk> not very hopeful, but you never know
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-31.33] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-31.33] (core, kernel)
<acheronuk> still fails
<ehashman> apw: what is the opposite problem in this context
<apw> ehashman: that people already on the releae maybhave things using the ubuntu abi
-queuebot:#ubuntu-release- Unapproved: amd64-microcode (trusty-proposed/main) [3.20180524.1~ubuntu0.14.04.2+really20130710.1 => 3.20180524.1~ubuntu0.14.04.2+really20130710.1ubuntu1] (no packageset)
<ehashman> apw: no, it's not possible. as reported on the bug, the ABI incompat also broke the ability to compile native extensions
<ehashman> that is what the release team seemed worried about
<apw> ehashman, ahh ok, then that piece of information needs to get to slangasek as he was reviewing this change
<ehashman> it is on the bug report
<ehashman> no less than three times
<ehashman> but perhaps I should file a summary comment
<apw> yeah do that, and steve should see this here as well
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-31.33~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [4.15.0-1020.20] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1020.20~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-31.33~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1020.20~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-31.33~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-31.33~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [4.15.0-1020.20]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-31.33]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-31.33]
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1014.17] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1014.17]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/none) [4.15.0-1016.17] (no packageset)
<stgraber> can someone look at squashfs-tools in xenial-proposed queue? relevant to that whole fscaps discussion on ubuntu-devel (fixing unsquashfs on xenial to not strip them)
<blackboxsw> RAOF:  any chance we can publish cloud-init 18.3-9-g2e62cb8a-0ubuntu1~16.04.2  from -proposed into -updates the previous SRU  (18.3-9...16.04.1) had aged about 3 weeks before we found a trivial bug that needed fixing. https://bugs.launchpad.net/cloud-init/+bug/1784685
<ubot5> Ubuntu bug 1784685 in cloud-init "Oracle: cloud-init openstack local detection too strict for oracle cloud" [High,Fix committed]
<blackboxsw> he only change between cloud-init 18.3-9-g2e62cb8a-0ubuntu1~16.04.1 and .16.04.2 is the cherry picked bug fix for the above bug. Same thing with 18.04.1 and 18.04.2, just a cherry pick.
<blackboxsw> all verification logs are attached to SRU process bug https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1777912
<ubot5> Ubuntu bug 1777912 in cloud-init (Ubuntu Bionic) "sru cloud-init (18.2-4-g05926e48-0ubuntu1) to (18.3-9ubuntu1)" [Medium,Fix committed]
<slangasek> ehashman, apw: yes, I've seen the follow-up comments on the bug, I appreciate having that clarified.  I do intend to re-review with an eye towards accepting, in the light of this clarification.  If someone were to fix up the SRU template in the bug description to be accurate, that would save me a step
<ehashman> huzzah
<ehashman> I don't know if I have access
<sil2100> ugh, please ignore the bionic subiquity upload
<sil2100> Miss-dput
-queuebot:#ubuntu-release- Unapproved: subiquity (bionic-proposed/universe) [0.0.29 => 0.0.29+18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected subiquity [source] (bionic-proposed) [0.0.29+18.04.1]
-queuebot:#ubuntu-release- New binary: golang-github-gogo-googleapis [amd64] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gotest.tools [amd64] (cosmic-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-flexmix [amd64] (cosmic-proposed/universe) [2.3-14-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-ulmo [amd64] (cosmic-proposed/universe) [0.8.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-prabclus [amd64] (cosmic-proposed/universe) [2.2-6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-gclus [amd64] (cosmic-proposed/universe) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-trimcluster [amd64] (cosmic-proposed/universe) [0.1-2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: photutils [ppc64el] (cosmic-proposed/universe) [0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: photutils [amd64] (cosmic-proposed/universe) [0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: photutils [i386] (cosmic-proposed/universe) [0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: photutils [arm64] (cosmic-proposed/universe) [0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: photutils [armhf] (cosmic-proposed/universe) [0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: designate [amd64] (cosmic-proposed/main) [1:7.0.0~b3-0ubuntu1] (openstack, ubuntu-server)
<teward> is there a known reason why do-release-upgrade doesn't work for 16.04 -> 18.04 without defining -d in the process?
<teward> (which then properly finds 18.04.1)
<acheronuk> teward: because upgrades have not been enabled yet
<teward> acheronuk: ah, that'd explain it, know what the timeline is for that?
<teward> because I have at least 80 people whining on Ask Ubuntu about it, and I'd like to give people an answer they can live with
<acheronuk> there are some gnome upgrade bugs to be fixed, so when they are sorted
<teward> so "Once they fix GNOME" problems then.
<teward> acheronuk: got a specific list of the bugs so I can watch them?
<teward> or a task list somewhere would work too
<acheronuk> LP #1766890
<ubot5> Launchpad bug 1766890 in ubuntu-release-upgrader (Ubuntu Bionic) "package gnome-menus 3.13.3-6ubuntu3.1 failed to install/upgrade: triggers looping, abandoned" [Undecided,Triaged] https://launchpad.net/bugs/1766890
<acheronuk> that is the main issue I saw mentioned in #ubuntu-meeting at end of last week
<teward> acheronuk: thanks, i'll keep this on my radar.
<slangasek> NB we didn't find any bugs in GNOME there, and the fix is to early-upgrade libc6 to remove any trigger loops
<slangasek> so it's not provably "just a desktop issue" either
<acheronuk> slangasek: right. thanks for clarifying. I'd only given it a cursory look the other day
<teward> slangasek: wouldn't any type of early upgrade necessitate changes in Xenial as well then?  Or would that early-upgrade be done during the d-r-u process?  Just for my curiosity
<teward> (I always clean-install and then transfer data, I never do in-place upgrades, but i"m tired of fifty dupe questions heh)
<slangasek> teward: the upgrader code always runs from the upgrader tarball associated with the target release; that's what's being changed for that bug, the bionic release-upgrader tarball
<teward> ahh, I see.
<teward> makes sense.
<slangasek> this design also makes it possible to fix bugs affecting upgrades from EOL releases we can no longer SRU to, which is handy in general ;)
<slangasek> anyway, juliank was working on that u-r-u change today and I've just re-reviewed his MP and approved it, so that should move forward some tomorrow
<teward> indeed that does, slangasek, hopefully everything works :)
<teward> sorry to prod and ask for details, thanks for sharing the info.
<teward> slangasek: glad to hear that things're moving forward, I assume that there'll be an announcement when the upgrade path is open or something?
<slangasek> I don't believe we do a separate announcement for that
<slangasek> because everybody gets an announcement in their motd and on their desktop
<teward> ah, good point.  I'll look forward to when the upgrade path is available so I don't have to keep watching the same 20 people keep asking the same question over and over again about when the upgrade paths will be available
<stgraber> slangasek: I don't suppose I can have you review that squashfs-tools upload for xenial? :)
<stgraber> you know, since you started that whole fscaps thing :)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [4.15.0-1016.17]
<slangasek> stgraber: my SRU review day is Friday, can it wait until then?
<stgraber> slangasek: yeah, should be fine, maybe someone else will feel like review it before then, will nag you on Friday if nobody does by then
<rbasak> I'm hoping to have time during my SRU day tomorrow.
<stgraber> rbasak: thanks!
<rbasak> But my time is being a little disrupted for personal reasons. I will make it up, but that's why I'm not sure it'll be tomorrow.
<stgraber> should be a pretty quick one, both patches are simple and look obviously true, they both have testcases and have both been in Ubuntu and Debian for a while. The hardest part is making sense of the diff since things get re-ordered to match bionic/cosmic.
<rbasak> ack. I'd do it now but I'm trying to get something else finished right now before I finish for the day.
#ubuntu-release 2018-08-08
-queuebot:#ubuntu-release- New binary: cinder [amd64] (cosmic-proposed/main) [2:13.0.0~b3-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: gnome-control-center (bionic-proposed/main) [1:3.28.2-0ubuntu0.18.04.1 => 1:3.28.2-0ubuntu0.18.04.2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: nsync [ppc64el] (cosmic-proposed/universe) [1.20.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: nsync [s390x] (cosmic-proposed/universe) [1.20.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: nsync [amd64] (cosmic-proposed/universe) [1.20.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: nsync [i386] (cosmic-proposed/universe) [1.20.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: nsync [arm64] (cosmic-proposed/universe) [1.20.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: nsync [armhf] (cosmic-proposed/universe) [1.20.1-2] (no packageset)
<juliank> sil2100: Can we let python-apt go from proposed to release? apport fails a bit on i386, but it does most of the time (fix pending). I want to upload a new python-apt with f/e locking soon, going back to the 1.7 branch, so I'd like the revert to stable 1.6 to go in now so we don't break the py3.7 migration
<juliank> (The new one might cause failures again, I don't know yet)
<juliank> (Fix is a strong word for the apport stuff - it connects to real Launchpad which produces 502 and friends sometimes, hence I'm adding automatic retrying of LP API calls on those errors)
<sil2100> juliank: looking at the apport failure itself, strange thing on the failing case I see
<juliank> sil2100: What's strange? It faisl to install packages from launchpad because launchpad times out
<sil2100> juliank: so test_install_packages_from_launchpad times out? There's no retries done right now, right?
<juliank> sil2100: Yeah, you essentially see the same thing in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/i386/a/apport/20180725_010756_63e4f@/log.gz
<juliank> which was for qterminakl
<sil2100> I was just wondering since the printed out API urls aren't properly urlencoded, just hope they're not used literally as they're printed out
<juliank> Well, it does not time out client side, it times out on the server side and LP gives you the 502 error
<juliank> You must have seen those in the browser too
<sil2100> The printed out urls felt strange to me, but I guess they're probably are properly urlencoded before the actual API call happens
<sil2100> Anyway, yeah, let me hint it
<juliank> yeah, they work fine in the other runs
<LocutusOfBorg> apw, for some reasons php-net-ldap2 migrated again :/
<LocutusOfBorg> instead of kicking it again to proposed, what about ignoring the testsuite? autopkgtest for php-net-ldap2/2.2.0-3ubuntu1: amd64: Regression â» , arm64: Regression â» , armhf: Regression â» , i386: Regression â» , ppc64el: Regression â» , s390x: Regression â»
<LocutusOfBorg> this way we can move forward with php, and not demoting it forever, since it might be just a testsuite bug
<LocutusOfBorg> (the failure is in phpunit changes in testsuite, it doesn't seem to affect the normal usage, but I'm not a php savvy man anymore=
<apw> LocutusOfBorg, sigh, or it should have been blocked in -proposed via a bug
-queuebot:#ubuntu-release- Unapproved: ceph (bionic-proposed/main) [12.2.4-0ubuntu1.1 => 12.2.7-0ubuntu0.18.04.1] (desktop-core, ubuntu-server)
<Laney> sil2100: hey, I'm getting spammed with emails about that new ubuntu-image PR because autopkgtest-web can't post its results back
<Laney> maybe something broke with the recent change to require 2fa and it needs a new token or something? could you help please?
<Laney> if you go to autopkgtest-web0 and run "DEBUG=1 ~/autopkgtest-cloud/webcontrol/update-github-jobs bionic-amd64-ubuntu-image-156-1350dac39be5aa92eadde8c1ebb558e730f4829f" you can see it's getting a 404
<Laney> which according to https://developer.github.com/v3/troubleshooting/ means authentication problem
<LocutusOfBorg> apw, but why blocking a set of packages if just testsuite is broken? isn't an hint better in this case?
<apw> LocutusOfBorg, possibly so, but you seem to be just assuming the test suite is broken, rather than the package is broke
<Laney> "just"
<cpaelzer> to be sure an ordering question
<cpaelzer> dovecot 2.3.2.1 is in c-proposed and there waiting on the new queue
<cpaelzer> I know that later on we will need to push a new dovecot-antispam no change rebuild against the new ABI
<cpaelzer> can I upload the latter already while the former is waiting in new queue?
<cpaelzer> or would the build not pick up the new ABI from dovecot in -proposed
<rbasak> I don't think the rebuild will see the package in the new queue (whether new source or binary).
<cpaelzer> TL;DR if in new queue, is it never the less available and will be pulled on builds
<rbasak> So I think you need to wait.
<rbasak> Oh
<rbasak> OK :)
<cpaelzer> the above was a question
<cpaelzer> the TL;DR
<cpaelzer> add a ?
<rbasak> Oh
<rbasak> Well in that case I think my answer stands.
<cpaelzer> great
<rbasak> I believe binaries in new are invisible to builds.
<rbasak> (since they are not published until accepted)
<cpaelzer> I understand, but the particular binary that the rebuild would need is not in NEW
<cpaelzer> only a few other new binaries that were added to the dovecot source
<rbasak> Is the new binary build dep visible and installable by apt with cosmic-proposed enabled? Eg. can chdist on cosmic-proposed see it?
<rbasak> That's I think the crucial question.
<cpaelzer> no, even though the LP page says "published" the new versions do not show up yet in a system with proposed enabled as of now
 * cpaelzer continues to wait then
<Laney> You could use a versioned build-dep if you wanted
<cpaelzer> to wait until it is available?
<cpaelzer> I guess that is too mcuh for the case here
 * Laney shrugs
<cpaelzer> hehe
<Laney> Just giving you a suggestion that will let it work automatically. If you want to be a human poll(), be my guest.
<cpaelzer> I don't want to change the package, currently is is a sync with a bunch of no change rebuilds
<cpaelzer> the versioned dep would break that
<Laney> No.
<LocutusOfBorg> apw, the new php changed the naming of *test* classes, and the ~15 packages I had to patch, were just lots of sed in the testsuite code
<cpaelzer> no?
<cpaelzer> please explain
<Laney> Make it a buildN version and add a changelog comment saying why you did it
<LocutusOfBorg> but I honestly don't care too much, the package is out of debian testing, so removing is fine too
<LocutusOfBorg> I can open a bug if you hint it
<Laney> autosync only looks at the version, so the diff will still be killed the next time
<apw> cpaelzer, right things in New do not yet exist, as we might reject them
<apw> in an archive pool sense
<cpaelzer> Laney: that is very interesting - so a ...build1 delta will still be sync killed
<mwhudson> i have a shell script that runs curl and grep-dctrl to see when things are /really/ published...
<cpaelzer> didn't know that
<cpaelzer> Thanks ++
<Laney> ð
<sil2100> Laney: hey! Ugh
<sil2100> Laney: ok, didn't know anything about it, I'll look into it today
<Laney> sil2100: thanks
<Laney> There's some ubuntu-autopkg-bot thing that's probably somehow involved
<Laney> Maybe it lost permissions or something
<Laney> LocutusOfBorg: Is this really actually hard to fix? And did it need 5 retries per arch?
-queuebot:#ubuntu-release- Unapproved: protracker (bionic-proposed/universe) [2.3d.r92-1 => 2.3d.r92-1ubuntu0.1] (no packageset)
<LocutusOfBorg> Laney, for me it is hard to fix, and retries were part of a bunch of fixes I did, I just didn't remove the package from the list
<LocutusOfBorg> we got lots of new phpunits in the meanwhile
<LocutusOfBorg> btw the package is unmaintained even upstream, so I don't know, how to fix
<LocutusOfBorg> I fixed the renaming, but testsuite fails after that point
<LocutusOfBorg> I honestly would remove unmaintained upstream packages, in case nobody here or in Debian wants and know how to fix them
<Laney> LocutusOfBorg: I don't have a particular problem with kicking stuff out. I do have a problem with saying that "just" testsuite breakage is fine.
<Laney> I don't think we know if the thing is busted or not given how early it breaks.
<Laney> and I do request people to not submit excessive retries please
<LocutusOfBorg> Laney, ack on all of them
<Laney> Maybe that upload fixes it and you can argue about the removal under less pressure. :P
<LocutusOfBorg> mmm I did that change already...
<LocutusOfBorg> but maybe something else changed in the meanwhile
<Laney> dunno, the error looked pretty clear to me
<LocutusOfBorg> I even looked at the new prototype in phpunit to see differences, and I found that return issue
<LocutusOfBorg> but maybe I crafted a wrong patch
<LocutusOfBorg> oh, hold on, NULL is different from '', probably I changed only the return value and not the parameters passed in the function
<Laney> :>
-queuebot:#ubuntu-release- New binary: r-cran-qap [ppc64el] (cosmic-proposed/universe) [0.1-1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-tsp [ppc64el] (cosmic-proposed/universe) [1.1-6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-qap [s390x] (cosmic-proposed/universe) [0.1-1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-tsp [s390x] (cosmic-proposed/universe) [1.1-6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-gdamore-tcell [amd64] (cosmic-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-qap [amd64] (cosmic-proposed/universe) [0.1-1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-tsp [amd64] (cosmic-proposed/universe) [1.1-6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-juju-collections [amd64] (cosmic-proposed/universe) [0.0~git20180717.9be91dc-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-tsp [i386] (cosmic-proposed/universe) [1.1-6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-qap [i386] (cosmic-proposed/universe) [0.1-1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-ulmo [amd64] (cosmic-proposed/universe) [0.8.4+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-qap [armhf] (cosmic-proposed/universe) [0.1-1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-qap [arm64] (cosmic-proposed/universe) [0.1-1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-tsp [armhf] (cosmic-proposed/universe) [1.1-6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-tsp [arm64] (cosmic-proposed/universe) [1.1-6-1] (no packageset)
<sil2100> Laney: I think the u-i issue should be fixed now, give me a sign if you still get the spam
<Laney> sil2100: sweet!
<Laney> check the PR to see if the results came in
<sil2100> Yep!
<sil2100> So all good
<Laney> ðº
<Laney> good work!
<Laney> was the bot account losing its authorisation right?
<sil2100> Yeah, got kicked out of CanonicalLtd because of missing 2fa
<Laney> that ol thing
<sil2100> So actually it was IS that did most of the work here ;)
<Laney> TEAM!
-queuebot:#ubuntu-release- Unapproved: open-iscsi (xenial-proposed/main) [2.0.873+git0.3b4b4500-14ubuntu3.4 => 2.0.873+git0.3b4b4500-14ubuntu3.5] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New source: python-blazarclient (cosmic-proposed/primary) [2.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: open-iscsi (bionic-proposed/main) [2.0.874-5ubuntu2 => 2.0.874-5ubuntu2.1] (ubuntu-desktop, ubuntu-server)
<LocutusOfBorg> hello, http://autopkgtest.ubuntu.com/packages/s/saods9/cosmic/arm64 can we please hint it?
<LocutusOfBorg> it is regressed in release
-queuebot:#ubuntu-release- New: accepted gkl [amd64] (cosmic-proposed) [0.8.5+dfsg-1]
-queuebot:#ubuntu-release- New: accepted golang-github-gogo-googleapis [amd64] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted gotest.tools [amd64] (cosmic-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted photutils [arm64] (cosmic-proposed) [0.5-1]
-queuebot:#ubuntu-release- New: accepted photutils [i386] (cosmic-proposed) [0.5-1]
-queuebot:#ubuntu-release- New: accepted python-uinput [amd64] (cosmic-proposed) [0.11.2-1]
-queuebot:#ubuntu-release- New: accepted python-uinput [armhf] (cosmic-proposed) [0.11.2-1]
-queuebot:#ubuntu-release- New: accepted python-uinput [ppc64el] (cosmic-proposed) [0.11.2-1]
-queuebot:#ubuntu-release- New: accepted golang-github-gdamore-tcell [amd64] (cosmic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted photutils [amd64] (cosmic-proposed) [0.5-1]
-queuebot:#ubuntu-release- New: accepted photutils [ppc64el] (cosmic-proposed) [0.5-1]
-queuebot:#ubuntu-release- New: accepted python-uinput [i386] (cosmic-proposed) [0.11.2-1]
-queuebot:#ubuntu-release- New: accepted golang-github-juju-collections [amd64] (cosmic-proposed) [0.0~git20180717.9be91dc-1]
-queuebot:#ubuntu-release- New: accepted python-uinput [arm64] (cosmic-proposed) [0.11.2-1]
-queuebot:#ubuntu-release- New: accepted photutils [armhf] (cosmic-proposed) [0.5-1]
-queuebot:#ubuntu-release- New: accepted python-uinput [s390x] (cosmic-proposed) [0.11.2-1]
-queuebot:#ubuntu-release- New: accepted python-ulmo [amd64] (cosmic-proposed) [0.8.4+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-flexmix [amd64] (cosmic-proposed) [2.3-14-1]
-queuebot:#ubuntu-release- New: accepted r-cran-prabclus [amd64] (cosmic-proposed) [2.2-6-1]
-queuebot:#ubuntu-release- New: accepted r-cran-qap [arm64] (cosmic-proposed) [0.1-1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-qap [i386] (cosmic-proposed) [0.1-1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-qap [s390x] (cosmic-proposed) [0.1-1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-tsp [arm64] (cosmic-proposed) [1.1-6-1]
-queuebot:#ubuntu-release- New: accepted python-ulmo [amd64] (cosmic-proposed) [0.8.4-1]
-queuebot:#ubuntu-release- New: accepted r-cran-qap [amd64] (cosmic-proposed) [0.1-1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-qap [ppc64el] (cosmic-proposed) [0.1-1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-gclus [amd64] (cosmic-proposed) [1.3.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-trimcluster [amd64] (cosmic-proposed) [0.1-2.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-qap [armhf] (cosmic-proposed) [0.1-1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-tsp [amd64] (cosmic-proposed) [1.1-6-1]
-queuebot:#ubuntu-release- New: accepted r-cran-tsp [i386] (cosmic-proposed) [1.1-6-1]
-queuebot:#ubuntu-release- New: accepted r-cran-tsp [s390x] (cosmic-proposed) [1.1-6-1]
-queuebot:#ubuntu-release- New: accepted r-cran-tsp [armhf] (cosmic-proposed) [1.1-6-1]
-queuebot:#ubuntu-release- New: accepted r-cran-tsp [ppc64el] (cosmic-proposed) [1.1-6-1]
-queuebot:#ubuntu-release- New: accepted nsync [amd64] (cosmic-proposed) [1.20.1-1]
-queuebot:#ubuntu-release- New: accepted nsync [ppc64el] (cosmic-proposed) [1.20.1-1]
-queuebot:#ubuntu-release- New: accepted nsync [amd64] (cosmic-proposed) [1.20.1-2]
-queuebot:#ubuntu-release- New: accepted nsync [armhf] (cosmic-proposed) [1.20.1-2]
-queuebot:#ubuntu-release- New: accepted nsync [ppc64el] (cosmic-proposed) [1.20.1-2]
-queuebot:#ubuntu-release- New: accepted nsync [arm64] (cosmic-proposed) [1.20.1-1]
-queuebot:#ubuntu-release- New: accepted nsync [arm64] (cosmic-proposed) [1.20.1-2]
-queuebot:#ubuntu-release- New: accepted nsync [s390x] (cosmic-proposed) [1.20.1-2]
-queuebot:#ubuntu-release- New: accepted nsync [s390x] (cosmic-proposed) [1.20.1-1]
-queuebot:#ubuntu-release- New: accepted nsync [i386] (cosmic-proposed) [1.20.1-2]
-queuebot:#ubuntu-release- New binary: budgie-desktop [ppc64el] (cosmic-proposed/universe) [10.4+git20180806.01.933f78fc03d-0ubuntu1] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: budgie-desktop [s390x] (cosmic-proposed/universe) [10.4+git20180806.01.933f78fc03d-0ubuntu1] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: budgie-desktop [amd64] (cosmic-proposed/universe) [10.4+git20180806.01.933f78fc03d-0ubuntu1] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: budgie-desktop [arm64] (cosmic-proposed/universe) [10.4+git20180806.01.933f78fc03d-0ubuntu1] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: budgie-desktop [armhf] (cosmic-proposed/universe) [10.4+git20180806.01.933f78fc03d-0ubuntu1] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: budgie-desktop [i386] (cosmic-proposed/universe) [10.4+git20180806.01.933f78fc03d-0ubuntu1] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- Unapproved: fonts-liberation2 (bionic-proposed/main) [2.00.1-5 => 2.00.1-7ubuntu0.18.04.1] (kubuntu, personal-gunnarhj, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: fonts-liberation (bionic-proposed/main) [1:1.07.4-5 => 1:1.07.4-7ubuntu0.18.04.1] (desktop-core, personal-gunnarhj)
-queuebot:#ubuntu-release- New binary: networking-bagpipe [amd64] (cosmic-proposed/universe) [9.0.0~b3-0ubuntu1] (no packageset)
<GunnarHj> Several packages in cosmic-proposed are blocked on ffmpeg 7:4.0.2-1. Is anybody working on that?
<LocutusOfBorg> hello, anybody please update mariadb hint to mariadb-10.1/1:10.1.34-1ubuntu2
<rbasak> I can't do it, but hear you can send MPs now :)
<rbasak> (but I hear)
-queuebot:#ubuntu-release- New binary: python-thriftpy [ppc64el] (cosmic-proposed/universe) [0.3.9+ds1-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-thriftpy [s390x] (cosmic-proposed/universe) [0.3.9+ds1-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-thriftpy [i386] (cosmic-proposed/universe) [0.3.9+ds1-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-thriftpy [amd64] (cosmic-proposed/universe) [0.3.9+ds1-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-thriftpy [armhf] (cosmic-proposed/universe) [0.3.9+ds1-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-thriftpy [arm64] (cosmic-proposed/universe) [0.3.9+ds1-1ubuntu2] (no packageset)
<tsimonq2> GunnarHj: Yeah, it's a tangled mess at the moment.
<jbicha> I think it would be appropriate to reject budgie-desktop from cosmic NEW because of https://lists.ubuntu.com/archives/ubuntu-desktop/2018-August/005408.html
<tsimonq2> jbicha: I would agree that it's not good that the uploader did that, but I disagree that it is grounds for rejection.
<tsimonq2> If that's the only problem with the package, it's relatively simple to fix.
<jbicha> well anyway, I filed bug 1786107 instead
<ubot5> bug 1786107 in budgie-desktop (Ubuntu) "budgie file conflict with caffeine" [High,New] https://launchpad.net/bugs/1786107
<rbasak> I think it'd be more painful to fix when users have had those files taken over by this other new package
<jbicha> as long as it doesn't leave -proposed, it won't cause much pain. I was just thinking rejecting from NEW keeps it out of -proposed too
<infinity> It's also a nonsensical relationship.
<infinity> It's using a made-up version of caffeine.
<infinity> A versioned breaks/replaces like that is only sane if the target package is removing those files at that version.
<rbasak> Oooh, while you're here, I have one for you.
<rbasak> mysql-server-core-8.0 breaks/replaces mysql-server-core-5.7.
<rbasak> Normally unversioned breaks/replaces are a red flag, AIUI.
<rbasak> But in this case, we seem be artifically inserting one for no real reason. Can this breaks/replaces remain unversioned?
<rbasak> Or perhaps we should move towards mysql-server-core instead?
<rbasak> We once shipped two MySQL versions in one release (Trusty IIRC), but I never want to do that again anyway.
<rbasak> (because though it is technically unversioned it is effectively versioned by the version being in the package name)
<rbasak> infinity: ^
-queuebot:#ubuntu-release- New: rejected budgie-desktop [amd64] (cosmic-proposed) [10.4+git20180806.01.933f78fc03d-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected budgie-desktop [armhf] (cosmic-proposed) [10.4+git20180806.01.933f78fc03d-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected budgie-desktop [ppc64el] (cosmic-proposed) [10.4+git20180806.01.933f78fc03d-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected budgie-desktop [arm64] (cosmic-proposed) [10.4+git20180806.01.933f78fc03d-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected budgie-desktop [s390x] (cosmic-proposed) [10.4+git20180806.01.933f78fc03d-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected budgie-desktop [i386] (cosmic-proposed) [10.4+git20180806.01.933f78fc03d-0ubuntu1]
<infinity> rbasak: An unversioned Breaks/Replaces is a Conflicts, for all intents and purposes, and should be.
<rbasak> I was under the impression that it was mildly preferable to allow the avoiding of deconfiguring before replacement
<rbasak> (this matters more for mysql-server-5.7 vs -8.0)
<infinity> rbasak: (At the dpkg level, it's subtly differnt, and *wrong* for it to be a Breaks/Replaces, as Replaces lets you arbitrarily overwrite files without removing the original package, and not having a version constraint on that can lead to unforseen consequences of file disappearance)
<infinity> rbasak: People using Breaks/Replaces for Conflicting packages are just wrong and got bad advice from somewhere.
<rbasak> OK
<infinity> rbasak: Breaks = I'm compatible with versions outside the given constraint, Replaces = I overwrite files in versions that match the constraint, Conflicts = Fuck this package, I hate it and can't coexist.
<infinity> rbasak: Basically, if your Breaks/Replaces can't be sanely versioned, it's a Conflict.  If your Conflict CAN be versions, it's a Breaks (and maybe B/R if file overlaps).
<fossfreedom> infinity, jbicha quick clarification if poss on the caffeine situation.  If caffeine is split into two packages one for icons, one for the main body, how is that going to help?  On upgrade, both packages will still be installed and will clash with what upstream budgie has done
<infinity> fossfreedom: I'm not sure splitting is the answer here.  It looks like budgie-desktop includes a full version of caffeine.  Correct me if I'm wrong...
<rbasak> fossfreedom: either they're the same files and you should both depend on a package that provides them, or they're entirely different semantaically and you can ideally rename to avoid conflict to permit concurrent installation of the same packages, or declare a Conflicts.
<rbasak> Oh
<infinity> fossfreedom: Which means that budgie-desktop shouldn't be arbitrarily overwriting files from caffeine, it should either just straigh tup conflict with it, or the embedded copy should be namespaced to not conflict.
<rbasak> But also, unembed?
<infinity> fossfreedom: Or, yes, budgie-desktop shouldn't ship any of that, and should just depend on caffeine instead.
<fossfreedom> it has its own caffeine budgie applet now infinity - built in the same source package
<infinity> fossfreedom: Yes.  I see that.  Is it somehow better/different?
<fossfreedom> The difference is that it is native to budgie and as one extra capability not in the appindicator - you can add a timer.  Other than that - similar, using the same icons
<fossfreedom> has
<infinity> fossfreedom: If it's indeed better/different, it should either be namespaced to not conflict, or you should just conflict with caffeine (and stop including it in your desktop seed :P)
<infinity> fossfreedom: The Breaks/Replaces is entirely wrong here, as you don't want to just be overwriting files from other packages, you want to not coexist with them.
<fossfreedom> not really understanding the terminology - "namespaced" ?
<infinity> fossfreedom: Namespaced, as in you could rename the budgie variant "budgie-caffeine" so it doesn't have any file overlaps.
<infinity> fossfreedom: But if they're basically the same thing, I don't see why you'd want both installed at all.
<infinity> fossfreedom: So a Conflict makes more sense.
<LocutusOfBorg> rbasak, I did it once or twice, but I think it is not worth the double effort...
<fossfreedom> hmm - I would have to devise a patch to build a binary - its not something upstream would be interested in doing - they insist all applets to be installed in one go (in this case "budgie-core")
<infinity> fossfreedom: Erm, I'm not suggesting building another binary.
<fossfreedom> Just replacing the breaks/replace with a provides/conflicts/replace ?
<infinity> fossfreedom: I'm suggesting either the caffeine stuff in budgie should be renamed to make it clear it's a budgie fork of caffeine, or budgie-desktop should just "Conflict: caffeine"
<infinity> fossfreedom: Not provides/conflicts/replaces, no.  Just a Conflict.
<fossfreedom> k - we can do that
<LocutusOfBorg> https://code.launchpad.net/~costamagnagianfranco/britney/hints-ubuntu/+merge/3527837
<LocutusOfBorg> rbasak, ^^ do you like it?
<infinity> fossfreedom: provide/conflicts/replaces is a magic trio for interchangeable metapackages (like mail-transport-agent).  Unless you're suggesting budgie-desktop would be an approrpriate thing to get when a GNOME user asked to install caffeine, that would not be appropriate.
<rbasak> It doesn't seem right to me to have the conflict.
<rbasak> They should be concurrently installable. There's no fundamental reason they can't be.
<rbasak> One user might want the caffeine applet and another one the budgie one.
<infinity> rbasak: Making them coinstallable is maybe the better option, but also required either selling upstream on it, or carrying a large local patch.
<infinity> s/required/requires/
<rbasak> IMHO, not being hostile to other packages is part of the packagers responsibility.
<infinity> rbasak: I don't disagree.  Though it seems mostly academic here, as caffeine has no rdeps other than (ironically) ubuntu-budgie-desktop
<rbasak> People use caffeine directly
<rbasak> People also like having multiple desktop environments concurrently installed.
<rbasak> (eg. for a two-user home computer)
<infinity> fossfreedom: Does the budgie version provide all the same functionality as the non-budgie version, just with a few extra bits?
<rbasak> LocutusOfBorg: 404?
<fossfreedom> infinity, all the same functionality + the extra timer capability
<rbasak> What's with the extra 7? :)
<tjaalton> infinity: hi, do you have time to review the x driver removals sometime soon?
<infinity> fossfreedom: Is there any intent to push the extra functionality upstream, or will it stay forked forever?
<infinity> tjaalton: Sometime, but I'm in the middle of 3 discussions right now.
<tjaalton> sure
<tjaalton> but like this week maybe :)
<rbasak> LocutusOfBorg: the MP looks fine. I don't know if the actual intent is sane, but I can't review anyway, remember? I'm not on the release team.
<rbasak> (for the development release)
<fossfreedom> infinity, it isnt a fork - written from scratch by Solus (or a contributor).
<rbasak> fossfreedom: then I think it should take care to install to paths that don't collide.
<infinity> fossfreedom: Err, really?  They rewrote it from scratch and used the same name?
<rbasak> fossfreedom: or the packaging should ensure this is the case, and encourage upstream to take that.
<jbicha> I think the only file names in conflict are the icon names, and there are reasonable reasons to keep the same icon names (to make things slightly easier for icon theme devs)
<fossfreedom> They used the hicolor icon names because that is what some/most iconsets use to provide their caffeine icons.  The hicolor icons is a fallback if the icontheme in use doesnt have a caffeine icon
<rbasak> If you want theme devs to be able to replace the icons, then the icons should be in their own package. Or depend on caffeine to get them.
<rbasak> (or, at the least, they should be provided by _one_ package)
<rbasak> Either they're treated as the same and should be shipped by exactly one package, or they're treated as different and should be shipped at different paths.
<infinity> Eh, they're not even the same icons.
<fossfreedom> icon theme devs are unlikely to provide budgie caffeine icons and "caffeine" icons
<fossfreedom> infinity, yeah - Solus designed their own for the fallback icons.
<infinity> fossfreedom: If it's your intent to keep shipping 'caffeine' as well, for the CLI tools, I'd just stop shipping the budgie icons and make budgie-desktop depend on caffeine.
<infinity> Now that I realise they're really not the same thing.
<fossfreedom> so hold a local patch then?
<infinity> Choosing not to ship two files isn't really a "local patch".
<rbasak> Your sense of "hold a local patch" is exactly what package maintenance is. Your job is to adjust everything to make it comply with distribution expectations. Ideally this is done by sending patches upstream such that both distribution and upstream needs are met by the same code base.
<infinity> Other options include dpkg-divert (please don't), update-alternatives (meh)...
<fossfreedom> They are in the Solus source package - so would need to change the meson.build stuff to not install those icon files
<infinity> fossfreedom: Or change the packaging to not ship them.
<infinity> fossfreedom: You already have a massive override_dh_auto_install, adding two "rm -f" to it wouldn't be hard. :P
<fossfreedom> umm - wait though - a depends on the caffeine package would install the appindicator - so budgie users will see both the native and appindicator at the same time
<infinity> fossfreedom: caffeine is in your desktop seed currently, so that's likely already true?
<fossfreedom> I removed it today from the seeds for cosmic - it is in the seed for bionic - so 18.04 to 18.10 users will travel with the caffeine package installed
<infinity> fossfreedom: Also, caffeine-indicator.desktop has:
<infinity> OnlyShowIn=GNOME;KDE;LXDE;LXQt;MATE;Razor;ROX;TDE;Unity;XFCE;EDE;Cinnamon;Pantheon;
<infinity> Are you one of those?
<fossfreedom> GNOME
<infinity> That seems poorly thought-out. :P
<fossfreedom> I'll send Ikey Doherty around to argue with you :P
<infinity> I've heard that's super fun.
<infinity> And I already know what his reasons would be.
<infinity> Doesn't make 'em right.
<infinity> Oh well.
 * rbasak senses some extensive distro patching coming on
<fossfreedom> It sounds like the least worse solution is a Conflict on caffeine
<infinity> The least bad solution is probably renaming the icons and fixing the two references in the source.
<infinity> Indeed, that means you wouldn't get caffeine icon themes "for free", but... It's not caffeine.
<infinity> And you ship your own icons anyway, so meh?
<rbasak> The Conflicts would unreasonably inflict your insanity on others, which is why I think it's just about the worst solution here.
<fossfreedom> reluctant - users like theming ... so budgie just using a fallback may look odd
<rbasak> So fix your broken desktop then
<fossfreedom> ... no sway with upstream I'm afraid
<rbasak> Then you get to patch.
<rbasak> "Upstream won't like it" is not a valid reason for shipping a bad/hostile distribution package.
<rbasak> The point of packaging is to produce an integrated distribution for users. If upstream is hostile to that integration, then it sucks to be the package maintainer.
<infinity> fossfreedom: Here, while we were talking: http://paste.ubuntu.com/p/gcCvvyjNts/
<infinity> Oh, that's one patched file too many. ;)
<fossfreedom> is your other nickname speedy gonzales ?!
<fossfreedom> going to have a close look - thanks for the patch :)
<wxl> that's not the name i usually give him :/
<wxl> (j/k)
<infinity> fossfreedom: http://paste.ubuntu.com/p/q9m6FGVJ3s/ <-- That might even work.
<infinity> wxl: Meanie.
<wxl> infinity: yep, that's closer ;)
<fossfreedom> cheers. Much appreciated.
<rbasak> stgraber: do you realise some of the unrelated patches in bug 1785499 are changed, including some functional changes?
<ubot5> bug 1785499 in squashfs-tools (Ubuntu Xenial) "Make squashfs-tools in Xenial in sync with Bionic and Cosmic" [High,Triaged] https://launchpad.net/bugs/1785499
<rbasak> stgraber: http://paste.ubuntu.com/p/t37ngVTSTP/ is what I see.
<rbasak> stgraber: eg. line 236/237 and 252/254
<rbasak> stgraber: eg. line 236/237 and 252/253
<stgraber> I hate reading diffs of diffs, one sec
<infinity> rbasak: Just looks rebased to me.
<infinity> rbasak: The patches themselves didn't change.
<stgraber> rbasak: I think it's diff being utterly confusing here, it suggests that write_xattr was in the stickybit patch which it never was
<infinity> (check indentation of +/-)
<rbasak> Oh
<rbasak> I'm sorry.
<stgraber> looking at the individual patches in debian/patches I see the content I'd expect for those patches
<rbasak> Long day. Perhaps I should stop for the day.
<stgraber> I did mention on IRC that the tricky part of reviewing this one is making sense of the diff :)
<rbasak> Usually I'm fine with reviewing a diff of a diff.
<rbasak> I do it all the time. But I've lost it today.
<rbasak> I'll look again with fresh eyes tomorrow.
<stgraber> well, the issue here is that it's diff of diff when some files got re-numbered in debian/patches
<stgraber> and with multiple of those patches touching the same lines
<stgraber> so doesn't make for a pleasant output
<infinity> stgraber: The renumbering is actually tracked here (I assume he used git diff), but the rebasing is unpleasant to read for some, I imagine. :)
<rbasak> Yeah I got git to handle the renumbering for me.
<rbasak> git ubuntu queue sync etc
<rbasak> That paste is three easy commands away :)
<infinity> rbasak: Anyhow, the rebasing looks correct to me, if you want to just review 007 and 008 as the new patches.
<rbasak> I no longer trust my eyes for today.
<rbasak> But accept if you're happy?
<infinity> stgraber: Did you quilt refresh (or similar) while you were in here?
<infinity> stgraber: Some line number changes and an odd context line change are curious.
<infinity> The context line change being most curious, cause how was that not previously fuzzy>
<infinity> Oh, hahaha, that's not in context, it's in the patch header.
<stgraber> infinity: I re-synced the patch content with what's in bionic/cosmic
<stgraber> which look like someone ran a quilt refresh on at some point (possibly the Debian maintainer did)
<infinity> stgraber: So, looks like the only change not accounted for as a refresh or rebase is a 1-liner in 0005-add-fstime.patch
<infinity> -+time_t forced_time = NULL;
<infinity> ++time_t forced_time = (time_t)0;
<stgraber> yeah, apparently that was changed in a more recent version of that patch... not sure why though the two should be identical in this case.
<infinity> Changed twice, even.
<infinity>   * debian/patches/0005-add-fstime.patch: Fix -Wint-conversion warning by
<infinity>     initializing the time_t variable with (time_t)-1 instead of NULL
<infinity>   * debian/patches/0005-add-fstime.patch: initializing the time_t variable
<infinity>     with (time_t)0 instead of (time_t)-1 to avoid creating all filesystems
<infinity>     on "Wed Dec 31 23:59:59 1969"
<infinity> stgraber: I don't object to backporting that fix too, but it should be mentioned in the changelog, IMO.
<stgraber> haha, yeah I can see how -1 would be a bad idea :)
<stgraber> sure, let me update the changelog quickly
<infinity> stgraber: Ta.
<infinity> Is squashfs upstream dead, or do we just never update?
<rbasak> The time_t one was the first one I saw. Then I started interpreting every line as a real change without noticing it wasn't a double-barreled diff change prefix
<rbasak> Anyway, thank you for taking over.
 * rbasak goes to bed
<stgraber> kinda looked dead, people seem to e-mail LKML for it instead which is a bit odd
<infinity> Hrm.  Last upstream release 2014, last upstream commit 2017.
<infinity> So, not dead, but very slow.
<infinity> That's unfortunate.
<infinity> Also, upstream git has zstd support (which is the last commit).
<infinity> That sounds fun.
<stgraber> would be neat if they felt like releaseing every once in a while :)
<stgraber> especially given that they haven't released since a CVE fix...
<infinity> Yeah, 4.4 is long overdue, I'd say. :P
<infinity> And all our local patches should probably go upstream.
<infinity> But I'm very not going to do that.
-queuebot:#ubuntu-release- Unapproved: squashfs-tools (xenial-proposed/main) [1:4.3-3ubuntu2.16.04.2 => 1:4.3-3ubuntu2.16.04.3] (core)
<infinity> But with so much of our infra (livefs, some virt/container images, snaps) relying on squashfs, it'd be nice if we could help revitalize upstream.
<stgraber> both of the new patches are upstream at least
-queuebot:#ubuntu-release- Unapproved: rejected squashfs-tools [source] (xenial-proposed) [1:4.3-3ubuntu2.16.04.3]
<infinity> stgraber: I didn't really care about the two non-functional changes, but thanks. :)
<stgraber> well, figured if I was going to be listing changes due to the resync with bionic :)
<stgraber> I can easily find about half of our patches upstream, maybe more are there and I just can't match them in the git history
<stgraber> kfreebsd appears missing (not super surprising) and I'm not seeing the lzma magic one either
<stgraber> ah and no mention of stickybit
<infinity> Kay, so maybe it's not that dire, and someone just needs to poke upstream to release more than once every 4 years.
<stgraber> the rest appears to all be upstream in one way or another at least
-queuebot:#ubuntu-release- Unapproved: accepted squashfs-tools [source] (xenial-proposed) [1:4.3-3ubuntu2.16.04.3]
<infinity> I'm always slightly terrfied when I run into a project that's still hosted on SourceForge.
<infinity> Although, SF looks much more pleasant than when it went through that awful "let's try to monetize with nasty ads" phase.
<infinity> stgraber: Any plans to do the same thing to trusty, or no carefactor there?
<stgraber> infinity: wasn't planning on it, mostly because the trusty kernel isn't going to get unpriv file caps so caps will just remain busted with LXD on that one...
<infinity> stgraber: Kay.
<stgraber> just looked and it's on 4.2, so would need to check what else changed between that and that 4.3 we have everywhere else now
<infinity> stgraber: Yeah, I wans't suggesting you had to, or even should, as just asking if I should look out for an upload.
<infinity> Generally, I despise the "backport all the things" mentality that makes people want to make trusty and xenial be exact copies of bionic. :P
<infinity> (THough, for utils like this that almost never change, I get it)
<stgraber> yeah, I only really cared about the fscaps fix but the different numbering in patches bugged me so I just decided to check what else was missing and include that too, at which point, making debdiff cross-series be clean by reshuffling things a bit usually makes sense
<stgraber> so trusty -> xenial looks like:
<stgraber>  132 files changed, 28145 insertions(+), 21015 deletions(-)
<stgraber> that doesn't look very pleasant, looks like upstream decided to reshuffle things a bit between 4.2 and 4.3
<infinity> Yeah, pass on that, then.
<infinity> Honestly, I'm happy for enough functionality lacking in old LTSes that it's easier for you guys stuck on the front lines of Mark-facing projects to just say "No" when suggested that you should backport all the things.
<infinity> I'd much rather our users have incentive to upgrade long before an LTS goes EOL.
<stgraber> well, in this case, the LXD snap is available on 14.04 and will include the new unsquashfs after the SRU has gone through, so that takes care of shiny new LXD on old trusty
-queuebot:#ubuntu-release- New binary: budgie-desktop [s390x] (cosmic-proposed/universe) [10.4+git20180806.02.933f78fc03d-0ubuntu1] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: budgie-desktop [amd64] (cosmic-proposed/universe) [10.4+git20180806.02.933f78fc03d-0ubuntu1] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: budgie-desktop [ppc64el] (cosmic-proposed/universe) [10.4+git20180806.02.933f78fc03d-0ubuntu1] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: budgie-desktop [i386] (cosmic-proposed/universe) [10.4+git20180806.02.933f78fc03d-0ubuntu1] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: budgie-desktop [arm64] (cosmic-proposed/universe) [10.4+git20180806.02.933f78fc03d-0ubuntu1] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: budgie-desktop [armhf] (cosmic-proposed/universe) [10.4+git20180806.02.933f78fc03d-0ubuntu1] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- Unapproved: console-setup (bionic-proposed/main) [1.178ubuntu2.4 => 1.178ubuntu2.5] (core)
-queuebot:#ubuntu-release- Unapproved: accepted console-setup [source] (bionic-proposed) [1.178ubuntu2.5]
<wxl> exit
<wxl> oooops
-queuebot:#ubuntu-release- Unapproved: console-setup (bionic-proposed/main) [1.178ubuntu2.5 => 1.178ubuntu2.6] (core)
-queuebot:#ubuntu-release- Unapproved: accepted console-setup [source] (bionic-proposed) [1.178ubuntu2.6]
#ubuntu-release 2018-08-09
-queuebot:#ubuntu-release- Unapproved: rejected ubiquity [source] (xenial-proposed) [2.21.63.8]
-queuebot:#ubuntu-release- New binary: node-code [amd64] (cosmic-proposed/none) [5.2.0-1] (no packageset)
<tjaalton> LocutusOfBorg: looks like forge autopkgtests still fail if cmake outputs warnings
<tjaalton> blocking mesa atm
<LocutusOfBorg> tjaalton, they seem related to new opencl and gcc-8
<LocutusOfBorg> maybe allow stderr is the way to go, feel free to do it
-queuebot:#ubuntu-release- New binary: gutenprint [ppc64el] (cosmic-proposed/main) [5.3.0~pre1-3] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: gutenprint [s390x] (cosmic-proposed/main) [5.3.0~pre1-3] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: gutenprint [armhf] (cosmic-proposed/main) [5.3.0~pre1-3] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: gutenprint [arm64] (cosmic-proposed/main) [5.3.0~pre1-3] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: gutenprint [i386] (cosmic-proposed/main) [5.3.0~pre1-3] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: gutenprint [amd64] (cosmic-proposed/main) [5.3.0~pre1-3] (desktop-core, ubuntu-server)
<LocutusOfBorg> rbasak, https://launchpad.net/ubuntu/+source/php-horde-db/2.4.0-1ubuntu3 I did "fix" probably
<LocutusOfBorg> but I don't know if 42.2 or 42.200000 are really the same value
<LocutusOfBorg> I think no real applications care about the zero after the number, right?
<rbasak> LocutusOfBorg: I wondered if it was a string formatting thing. In which case perhaps it does matter.
<rbasak> (eg. "%2.1f" incorrectly produces a string with too many digits after the decimal point)
<rbasak> I never looked further though.
<LocutusOfBorg>   File "/usr/lib/python2.7/dist-packages/lazr/restfulclient/_browser.py", line 431, in _request
<LocutusOfBorg>     raise error
<LocutusOfBorg> lazr.restfulclient.errors.ClientError: HTTP Error 403: Forbidden
<LocutusOfBorg> nice, pull-lp-source is broken :/
<cjwatson> Known.
<cjwatson> Working on it
<apw> LocutusOfBorg, launchpad is sad, ^ that
<LocutusOfBorg> ta!
<cjwatson> Just compelled to say so in like half a dozen different channels :-/
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (bionic-proposed/main) [1:18.04.22 => 1:18.04.23] (core)
<cjwatson> LP fixed
-queuebot:#ubuntu-release- Unapproved: ubuntu-image (bionic-proposed/main) [1.3+18.04ubuntu2 => 1.4+18.04ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-image (xenial-proposed/universe) [1.3+16.04ubuntu2 => 1.4+16.04ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: mariadb-10.1 [s390x] (cosmic-proposed/universe) [1:10.1.35-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: mariadb-10.1 [ppc64el] (cosmic-proposed/universe) [1:10.1.35-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: mariadb-10.1 [i386] (cosmic-proposed/universe) [1:10.1.35-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: bolt (bionic-proposed/main) [0.3-0ubuntu0.1 => 0.4-0ubuntu0.18.04.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: mariadb-10.1 [amd64] (cosmic-proposed/universe) [1:10.1.35-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (bionic-proposed) [1:18.04.23]
-queuebot:#ubuntu-release- New binary: mariadb-10.1 [arm64] (cosmic-proposed/universe) [1:10.1.35-1ubuntu1] (no packageset)
<acheronuk> is that release-upgrader fix going to get the usual 7 days aging in -proposed, and hence at least 7 days until meta-release-lts updated for upgrades?
-queuebot:#ubuntu-release- New binary: radare2 [s390x] (cosmic-proposed/universe) [2.8.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnuastro [s390x] (cosmic-proposed/universe) [0.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [ppc64el] (cosmic-proposed/universe) [2.8.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: glasstty [amd64] (cosmic-proposed/none) [0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [amd64] (cosmic-proposed/universe) [2.8.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-toidentifier [amd64] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [i386] (cosmic-proposed/universe) [2.8.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnuastro [i386] (cosmic-proposed/universe) [0.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnuastro [amd64] (cosmic-proposed/universe) [0.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [arm64] (cosmic-proposed/universe) [2.8.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mariadb-10.1 [armhf] (cosmic-proposed/universe) [1:10.1.35-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [armhf] (cosmic-proposed/universe) [2.8.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnuastro [arm64] (cosmic-proposed/universe) [0.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnuastro [armhf] (cosmic-proposed/universe) [0.7-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted dpdk [source] (bionic-proposed) [17.11.3-3~ubuntu0.18.04]
-queuebot:#ubuntu-release- Unapproved: accepted freeipmi [source] (bionic-proposed) [1.4.11-1.1ubuntu4.1]
-queuebot:#ubuntu-release- Unapproved: accepted man-db [source] (bionic-proposed) [2.8.3-2ubuntu0.1]
-queuebot:#ubuntu-release- New binary: dpdk [ppc64el] (bionic-proposed/main) [17.11.3-3~ubuntu0.18.04] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: petsc [s390x] (cosmic-proposed/universe) [3.9.3+dfsg1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: qtstyleplugins-src [s390x] (cosmic-proposed/universe) [5.0.0+git23.g335dbec-2ubuntu1] (qt5, ubuntu-budgie, ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.525.6]
-queuebot:#ubuntu-release- New binary: qtstyleplugins-src [ppc64el] (cosmic-proposed/universe) [5.0.0+git23.g335dbec-2ubuntu1] (qt5, ubuntu-budgie, ubuntu-mate)
<tsimonq2> qtstyleplugins-src binary NEW is just shuffling things around a bit. I plan on doing it in Debian immediately following the Qt 5.11 transition (and after getting an ack from Pino) but since there's no new content in the binaries, swift processing would be appreciated. :)
-queuebot:#ubuntu-release- New binary: dpdk [amd64] (bionic-proposed/main) [17.11.3-3~ubuntu0.18.04] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: petsc [ppc64el] (cosmic-proposed/universe) [3.9.3+dfsg1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: qtstyleplugins-src [amd64] (cosmic-proposed/universe) [5.0.0+git23.g335dbec-2ubuntu1] (qt5, ubuntu-budgie, ubuntu-mate)
-queuebot:#ubuntu-release- New binary: qtstyleplugins-src [arm64] (cosmic-proposed/universe) [5.0.0+git23.g335dbec-2ubuntu1] (qt5, ubuntu-budgie, ubuntu-mate)
-queuebot:#ubuntu-release- New binary: qtstyleplugins-src [armhf] (cosmic-proposed/universe) [5.0.0+git23.g335dbec-2ubuntu1] (qt5, ubuntu-budgie, ubuntu-mate)
-queuebot:#ubuntu-release- New binary: qtstyleplugins-src [i386] (cosmic-proposed/universe) [5.0.0+git23.g335dbec-2ubuntu1] (qt5, ubuntu-budgie, ubuntu-mate)
-queuebot:#ubuntu-release- New binary: dpdk [arm64] (bionic-proposed/main) [17.11.3-3~ubuntu0.18.04] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: dpdk [i386] (bionic-proposed/main) [17.11.3-3~ubuntu0.18.04] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: qtstyleplugins-src [ppc64el] (cosmic-proposed/universe) [5.0.0+git23.g335dbec-2ubuntu2] (qt5, ubuntu-budgie, ubuntu-mate)
-queuebot:#ubuntu-release- New binary: qtstyleplugins-src [s390x] (cosmic-proposed/universe) [5.0.0+git23.g335dbec-2ubuntu2] (qt5, ubuntu-budgie, ubuntu-mate)
-queuebot:#ubuntu-release- New binary: petsc [amd64] (cosmic-proposed/universe) [3.9.3+dfsg1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: qtstyleplugins-src [amd64] (cosmic-proposed/universe) [5.0.0+git23.g335dbec-2ubuntu2] (qt5, ubuntu-budgie, ubuntu-mate)
-queuebot:#ubuntu-release- New binary: qtstyleplugins-src [armhf] (cosmic-proposed/universe) [5.0.0+git23.g335dbec-2ubuntu2] (qt5, ubuntu-budgie, ubuntu-mate)
-queuebot:#ubuntu-release- New binary: qtstyleplugins-src [i386] (cosmic-proposed/universe) [5.0.0+git23.g335dbec-2ubuntu2] (qt5, ubuntu-budgie, ubuntu-mate)
-queuebot:#ubuntu-release- New binary: qtstyleplugins-src [arm64] (cosmic-proposed/universe) [5.0.0+git23.g335dbec-2ubuntu2] (qt5, ubuntu-budgie, ubuntu-mate)
-queuebot:#ubuntu-release- New binary: petsc [i386] (cosmic-proposed/universe) [3.9.3+dfsg1-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-phabricator (bionic-proposed/universe) [0.7.0-1 => 0.7.0-1ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: petsc [arm64] (cosmic-proposed/universe) [3.9.3+dfsg1-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (bionic-proposed/main) [1:18.04.23 => 1:18.04.24] (core)
-queuebot:#ubuntu-release- New binary: petsc [armhf] (cosmic-proposed/universe) [3.9.3+dfsg1-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-release-upgrader [source] (bionic-proposed) [1:18.04.24]
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (bionic-proposed/main) [1:18.04.23 => 1:18.04.24] (core)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (bionic-proposed) [1:18.04.24]
-queuebot:#ubuntu-release- Unapproved: accepted protracker [source] (bionic-proposed) [2.3d.r92-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted open-iscsi [source] (bionic-proposed) [2.0.874-5ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted open-iscsi [source] (xenial-proposed) [2.0.873+git0.3b4b4500-14ubuntu3.5]
#ubuntu-release 2018-08-10
<fo0bar> slangasek: could you update the cdimage trigger-mirrors please?  arzachel.canonical.com and neison.canonical.com are replacing goldenapple and zaniah
-queuebot:#ubuntu-release- New binary: julia [arm64] (cosmic-proposed/universe) [0.7.0-1] (no packageset)
<mwhudson> fo0bar: he's not around today and in any case is past EOD, maybe try a less transient means of notification? :)
<fo0bar> mwhudson: what, you mean not everyone works 10-7 US-W? :)  it's not urgent (not in DNS yet) and AFAICT it's part of a secrets repo he updates so there doesn't appear to be an upstream.  I'll just send an email
<mwhudson> fo0bar: our team is not really known for it's predictable hours...
-queuebot:#ubuntu-release- New binary: julia [amd64] (cosmic-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: calamares-settings-ubuntu [i386] (cosmic-proposed/universe) [15] (no packageset)
-queuebot:#ubuntu-release- New binary: calamares-settings-ubuntu [s390x] (cosmic-proposed/universe) [15] (no packageset)
-queuebot:#ubuntu-release- New binary: calamares-settings-ubuntu [ppc64el] (cosmic-proposed/universe) [15] (no packageset)
-queuebot:#ubuntu-release- New binary: calamares-settings-ubuntu [amd64] (cosmic-proposed/universe) [15] (no packageset)
-queuebot:#ubuntu-release- New binary: calamares-settings-ubuntu [armhf] (cosmic-proposed/universe) [15] (no packageset)
-queuebot:#ubuntu-release- New binary: calamares-settings-ubuntu [arm64] (cosmic-proposed/universe) [15] (no packageset)
<slangasek> fo0bar, mwhudson: done ;)
-queuebot:#ubuntu-release- New binary: calamares-settings-ubuntu [i386] (cosmic-proposed/universe) [16] (no packageset)
-queuebot:#ubuntu-release- New binary: calamares-settings-ubuntu [s390x] (cosmic-proposed/universe) [16] (no packageset)
-queuebot:#ubuntu-release- New binary: calamares-settings-ubuntu [ppc64el] (cosmic-proposed/universe) [16] (no packageset)
-queuebot:#ubuntu-release- New binary: calamares-settings-ubuntu [amd64] (cosmic-proposed/universe) [16] (no packageset)
-queuebot:#ubuntu-release- New binary: calamares-settings-ubuntu [armhf] (cosmic-proposed/universe) [16] (no packageset)
-queuebot:#ubuntu-release- New binary: calamares-settings-ubuntu [arm64] (cosmic-proposed/universe) [16] (no packageset)
<fo0bar> slangasek: ta!
<tsimonq2> slangasek: Could I get some Binary NEW poking on calamares-settings-ubuntu and qtstyleplugins-src when you get the chance?
<cjwatson> infinity: FYI, I'm removing artful from ddebs.u.c.  It's a bit early, but germanium is running a little low on space, and all those ddebs should be in the LP librarian if need be.
-queuebot:#ubuntu-release- Unapproved: xorg-server (xenial-proposed/main) [2:1.18.4-0ubuntu0.7 => 2:1.18.4-0ubuntu0.8] (desktop-core, xorg)
-queuebot:#ubuntu-release- Unapproved: xorg-server (xenial-proposed/main) [2:1.18.4-0ubuntu0.7 => 2:1.18.4-0ubuntu0.8] (desktop-core, xorg)
-queuebot:#ubuntu-release- Unapproved: rejected xorg-server [source] (xenial-proposed) [2:1.18.4-0ubuntu0.8]
-queuebot:#ubuntu-release- Unapproved: accepted xorg-server [source] (xenial-proposed) [2:1.18.4-0ubuntu0.8]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (bionic-proposed) [1:3.28.2-0ubuntu0.18.04.2]
-queuebot:#ubuntu-release- Unapproved: fwts (xenial-proposed/universe) [16.03.00-0ubuntu1.1 => 16.03.00-0ubuntu1.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fwts (bionic-proposed/universe) [18.03.00-0ubuntu2 => 18.03.00-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-araddon-gou [amd64] (cosmic-proposed/none) [0.0~git20180509.7db4be5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libzc [s390x] (cosmic-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fonts-gnutypewriter [amd64] (cosmic-proposed/none) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libzc [i386] (cosmic-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libzc [amd64] (cosmic-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libzc [ppc64el] (cosmic-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libzc [arm64] (cosmic-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libzc [armhf] (cosmic-proposed/universe) [0.4.1-1] (no packageset)
<coreycb> hello, can an archive admin please accept python-thriftpy from the New queue? I've added the py2 binary python-thriftpy package back since python-happybase still needs it (needed by panko). this will help unblock these packages for OpenStack.
-queuebot:#ubuntu-release- New: accepted python-thriftpy [i386] (cosmic-proposed) [0.3.9+ds1-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted python-thriftpy [s390x] (cosmic-proposed) [0.3.9+ds1-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted python-thriftpy [ppc64el] (cosmic-proposed) [0.3.9+ds1-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted python-thriftpy [amd64] (cosmic-proposed) [0.3.9+ds1-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted python-thriftpy [armhf] (cosmic-proposed) [0.3.9+ds1-1ubuntu2]
-queuebot:#ubuntu-release- New binary: networking-bagpipe [amd64] (cosmic-proposed/universe) [9.0.0~b3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-thriftpy [arm64] (cosmic-proposed) [0.3.9+ds1-1ubuntu2]
-queuebot:#ubuntu-release- New source: python-blazarclient (cosmic-proposed/primary) [2.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: cinder [amd64] (cosmic-proposed/main) [2:13.0.0~b3-0ubuntu1] (openstack, ubuntu-server)
<apw> coreycb, ^
<coreycb> Thanks apw
<acheronuk> ppc64el failure on timeout https://launchpad.net/ubuntu/+source/ghostscript/9.23~dfsg+1-0ubuntu1
<acheronuk> could someone retry that if it could maybe succeed on a retry?
<acheronuk> LocutusOfBorg: could you? ^^^
<acheronuk> in main, so needs core dev
<acheronuk> at the moment that leaves okular unbuildable in proposed, and I would guess a fair amount of other things as well
<ginggs> acheronuk: retried
<acheronuk> ginggs: thanks. worth a try ;)
<ginggs> acheronuk: if that doesn't work, you could try rebuilding with -O2 in your PPA, or maybe just try that anyway
<acheronuk> ginggs: uploader has asked in #ubuntu-devel in the meantime
<slangasek> ginggs: tkamppeter was just asking for help with this in #ubuntu-devel; maybe coordinate with him?
<slangasek> yah what acheronuk said
-queuebot:#ubuntu-release- Unapproved: rejected maas [source] (xenial-proposed) [2.3.3-6498-ge4db91d-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted maas [source] (xenial-proposed) [2.3.4-6508-g4f77e30-0ubuntu1]
<bdmurray> sil2100: Can you remove maxima from xenial-proposed since it FTBFS on some arches?
<sil2100> bdmurray: sure
<sil2100> bdmurray: done
 * sil2100 is cleaning up -proposed uploads now
<bdmurray> sil2100: thanks
-queuebot:#ubuntu-release- New: accepted fonts-gnutypewriter [amd64] (cosmic-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-araddon-gou [amd64] (cosmic-proposed) [0.0~git20180509.7db4be5-1]
-queuebot:#ubuntu-release- New: accepted glasstty [amd64] (cosmic-proposed) [0-1]
-queuebot:#ubuntu-release- New: accepted gutenprint [amd64] (cosmic-proposed) [5.3.0~pre1-3]
-queuebot:#ubuntu-release- New: accepted gutenprint [arm64] (cosmic-proposed) [5.3.0~pre1-3]
-queuebot:#ubuntu-release- New: accepted gutenprint [i386] (cosmic-proposed) [5.3.0~pre1-3]
-queuebot:#ubuntu-release- New: accepted gutenprint [s390x] (cosmic-proposed) [5.3.0~pre1-3]
-queuebot:#ubuntu-release- New: accepted libzc [arm64] (cosmic-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted libzc [i386] (cosmic-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted libzc [s390x] (cosmic-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted node-toidentifier [amd64] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted petsc [arm64] (cosmic-proposed) [3.9.3+dfsg1-3]
-queuebot:#ubuntu-release- New: accepted petsc [i386] (cosmic-proposed) [3.9.3+dfsg1-3]
-queuebot:#ubuntu-release- New: accepted petsc [s390x] (cosmic-proposed) [3.9.3+dfsg1-3]
-queuebot:#ubuntu-release- New: accepted gutenprint [armhf] (cosmic-proposed) [5.3.0~pre1-3]
-queuebot:#ubuntu-release- New: accepted libzc [amd64] (cosmic-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted libzc [ppc64el] (cosmic-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted petsc [amd64] (cosmic-proposed) [3.9.3+dfsg1-3]
-queuebot:#ubuntu-release- New: accepted petsc [ppc64el] (cosmic-proposed) [3.9.3+dfsg1-3]
-queuebot:#ubuntu-release- New: accepted radare2 [arm64] (cosmic-proposed) [2.8.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted radare2 [i386] (cosmic-proposed) [2.8.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted radare2 [s390x] (cosmic-proposed) [2.8.0+dfsg-1]
-queuebot:#ubuntu-release- New binary: dovecot [ppc64el] (cosmic-proposed/main) [1:2.3.2.1-1ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New source: fwupd-signed (cosmic-proposed/primary) [1.0]
-queuebot:#ubuntu-release- New: accepted gutenprint [ppc64el] (cosmic-proposed) [5.3.0~pre1-3]
-queuebot:#ubuntu-release- New: accepted node-code [amd64] (cosmic-proposed) [5.2.0-1]
-queuebot:#ubuntu-release- New: accepted radare2 [amd64] (cosmic-proposed) [2.8.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted radare2 [ppc64el] (cosmic-proposed) [2.8.0+dfsg-1]
-queuebot:#ubuntu-release- New binary: dovecot [s390x] (cosmic-proposed/main) [1:2.3.2.1-1ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: fwupdate [armhf] (cosmic-proposed/main) [12-3] (core)
-queuebot:#ubuntu-release- New binary: python-os-traits [amd64] (cosmic-proposed/main) [0.9.0-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: sl-modem [i386] (cosmic-proposed/multiverse) [2.9.11~20110321-13] (no packageset)
-queuebot:#ubuntu-release- New: accepted libzc [armhf] (cosmic-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted radare2 [armhf] (cosmic-proposed) [2.8.0+dfsg-1]
-queuebot:#ubuntu-release- New binary: fwupdate [armhf] (cosmic-proposed/main) [12-2] (core)
-queuebot:#ubuntu-release- New binary: sl-modem [amd64] (cosmic-proposed/multiverse) [2.9.11~20110321-13] (no packageset)
-queuebot:#ubuntu-release- New: accepted petsc [armhf] (cosmic-proposed) [3.9.3+dfsg1-3]
-queuebot:#ubuntu-release- New binary: python-ceilometermiddleware [amd64] (cosmic-proposed/universe) [1.3.0-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- New binary: dovecot [i386] (cosmic-proposed/main) [1:2.3.2.1-1ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New: accepted sl-modem [amd64] (cosmic-proposed) [2.9.11~20110321-13]
-queuebot:#ubuntu-release- New source: vaultlocker (cosmic-proposed/primary) [1.0.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted sl-modem [i386] (cosmic-proposed) [2.9.11~20110321-13]
-queuebot:#ubuntu-release- New: accepted fwupdate [armhf] (cosmic-proposed) [12-2]
-queuebot:#ubuntu-release- New: accepted gnuastro [amd64] (cosmic-proposed) [0.7-1]
-queuebot:#ubuntu-release- New: accepted gnuastro [armhf] (cosmic-proposed) [0.7-1]
-queuebot:#ubuntu-release- New: accepted gnuastro [s390x] (cosmic-proposed) [0.7-1]
-queuebot:#ubuntu-release- New: accepted julia [arm64] (cosmic-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted fwupdate [armhf] (cosmic-proposed) [12-3]
-queuebot:#ubuntu-release- New: accepted gnuastro [i386] (cosmic-proposed) [0.7-1]
-queuebot:#ubuntu-release- New: accepted gnuastro [arm64] (cosmic-proposed) [0.7-1]
-queuebot:#ubuntu-release- New: accepted julia [amd64] (cosmic-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New binary: android-platform-external-boringssl [ppc64el] (cosmic-proposed/none) [8.1.0+r23-1] (no packageset)
-queuebot:#ubuntu-release- New binary: android-platform-external-boringssl [amd64] (cosmic-proposed/universe) [8.1.0+r23-1] (no packageset)
-queuebot:#ubuntu-release- New binary: android-platform-external-boringssl [i386] (cosmic-proposed/universe) [8.1.0+r23-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: 2ping (bionic-proposed/universe) [4.1-1 => 4.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: android-platform-external-boringssl [arm64] (cosmic-proposed/universe) [8.1.0+r23-1] (no packageset)
-queuebot:#ubuntu-release- New binary: android-platform-external-boringssl [armhf] (cosmic-proposed/universe) [8.1.0+r23-1] (no packageset)
-queuebot:#ubuntu-release- New binary: slepc [s390x] (cosmic-proposed/universe) [3.9.2+dfsg1-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: slepc [ppc64el] (cosmic-proposed/universe) [3.9.2+dfsg1-1build1] (no packageset)
<infinity> cjwatson: How is that "early"?  It's been EOL for a while.
-queuebot:#ubuntu-release- New binary: slepc [amd64] (cosmic-proposed/universe) [3.9.2+dfsg1-1build1] (no packageset)
<fo0bar> ^ could I get that 2ping bionic-proposed/universe upload approved?  re: LP: #1786397
<ubot5> Launchpad bug 1786397 in 2ping (Ubuntu) "2ping crashes on non-encrypted session" [High,Confirmed] https://launchpad.net/bugs/1786397
<fo0bar> (not sure if that gets looked at in someone's queue eventually; sorry if so.  last time I did an SRU was years ago)
<slangasek> fo0bar: yeah, it's in a queue for eventual processing
<fo0bar> slangasek: ta, no rush.  the SRU docs have a gap between upload and verification (implies it's instant) and I didn't want to jump the gun and set verification-needed before it was actually in -proposed
<fo0bar> (or I just read it wrong.  "After upload, the bug status should be changed to In Progress, once accepted into release-proposed, the status will be automatically changed to Fix Committed.")
<infinity> fo0bar: Yeah, the Fix Committed and v-needed bits are set by us when we accept.
<fo0bar> infinity: cut me some slack, it's my first day!
<fo0bar> :)
<infinity> *raise brow*
<infinity> I call shenanigans.
<fo0bar> infinity: on an unrelated note, thanks for cleaning up cdimage.  however I'm still going to kill the 1TB servers with fire, and replacements are about to go live today
<fo0bar> they have 8TB, which is more than even nusakan.  *should* last awhile, heh
<infinity> fo0bar: Oh, shiny.
<infinity> fo0bar: Can nusakan also get some extra terabyteses?
<infinity> fo0bar: Aren't we, like, the last users of the miserable dying SAN?
<fo0bar> infinity: there's a PO in progress to replace the SAN with a cloudless ceph cluster.  however, it's been in progress for awhile, and I fear to ask what the status is.  but I will when my manager gets back from vacation
<fo0bar> the only reason the cdimage servers are getting replaced in a reasonable timeframe was the temporary SPOF on hutton kicked us into reallocating two machines from another project, which is why they're slightly overspecced
<infinity> fo0bar: I assumed we'd do something similar to nusakan that got done to pepo.
<infinity> fo0bar: Given how we grind bits on that machine, remote storage doesn't really make sense.
<infinity> (IMO)
<infinity> Or, we could split it to a mix of local and remote for working sets versus half-archived stuff.  But that would also take jiggerying some of how we do stuff, path-wise.
<fo0bar> that's a good point.  but FAOD there's still enough at-rest junk on the SAN that I believe the reacement will still go through
<fo0bar> *replacement
<fo0bar> come to think of it, I think I originally built pepo too
<fo0bar> I get all the best projects
-queuebot:#ubuntu-release- New binary: slepc [arm64] (cosmic-proposed/universe) [3.9.2+dfsg1-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: manila-ui [amd64] (cosmic-proposed/universe) [2.16.0-0ubuntu1] (no packageset)
<acheronuk> slangasek: would it be possible/acceptable to get ghostscript out of proposed until we know the build is fixed? if not I can probably work around it, but would be better not to have uninstalable build depends for some things due to that failure
<tsimonq2> infinity, slangasek: Are Xenial dailies still supposed to be a thing after 16.04.5? They're still enabled in /etc/crontab of lp:ubuntu-cdimage and still being built.
<infinity> tsimonq2: They're not supposed to be a thing.  Did someone re-enable them?
<tsimonq2> infinity: Apparently, it seems.
<infinity> So they did.
<infinity> tsimonq2: To be fair, lp:ubuntu-cdimage doesn't relate here.
<infinity> But someone did re-enable them on the live crontab too.
 * infinity twiddles them back off.
<sarnold> why wouldn't we keep generating dailies?
<tsimonq2> infinity: You might as well go through and rm -rf xenial directories in the flavors as well.
<infinity> sarnold: There are no more point releases after .5
<tsimonq2> sarnold: Because Xenial has had its final point release.
<tsimonq2> Right.
<infinity> tsimonq2: At some point, yes.
<tsimonq2> infinity: Well, is there any reason to keep wasting the disk space? :P
<sarnold> I thought we made the dailies to keep sucking in security updates and srus?
<tsimonq2> Â¯\_(ã)_/Â¯
<tsimonq2> sarnold: Only up to .5.
<tsimonq2> Otherwise users get those through normal system updates.
<infinity> sarnold: Maybe you're confusing ISOs and cloud images?
<infinity> sarnold: No one other than testers should ever actually use daily ISOs.
<sarnold> infinity: yes. yes I am. thanks :)
<infinity> sarnold: They have proposed enabled, they're half broken, etc.
<sarnold> wow
<tsimonq2> infinity: lp:ubuntu-cdimage isn't accurate> That hasn't seen an update since Lubuntu Next was dropped. :P
<sarnold> that's definitely not what I expected, hehe
<sarnold> thanks
<tsimonq2> I'm curious, is -proposed just enabled on build time for those, or in the actually-installed system?
<infinity> tsimonq2: It's not so much that it's "not accurate", it's that there's no point in committing temp tweaks to the live crontab and uncommitting them again, with contrab imports and exports in between.
<tsimonq2> infinity: Got it.
<infinity> tsimonq2: Build-time and installed.
<tsimonq2> infinity: Oh, fun.
<slangasek> acheronuk: wasn't tkamppeter working on getting ghostscript fixed?  If that's taking too long, I can remove the current broken package from -proposed, yes
<acheronuk> slangasek: yes, sorry, I wasn't asking for immediate removal
<acheronuk> though I don't think -O2 worked :/ https://launchpad.net/~till-kamppeter/+archive/ubuntu/ppa/+build/15253371
-queuebot:#ubuntu-release- Unapproved: rejected fwupd [amd64] (cosmic-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- Unapproved: rejected fwupd [armhf] (cosmic-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- Unapproved: rejected fwupd [amd64] (cosmic-proposed) [1.1.0-4]
-queuebot:#ubuntu-release- Unapproved: rejected fwupd [armhf] (cosmic-proposed) [1.1.0-4]
-queuebot:#ubuntu-release- Unapproved: rejected fwupd [amd64] (cosmic-proposed) [1.1.0-6]
-queuebot:#ubuntu-release- Unapproved: rejected fwupd [armhf] (cosmic-proposed) [1.1.0-6]
-queuebot:#ubuntu-release- Unapproved: rejected fwupd [arm64] (cosmic-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- Unapproved: rejected fwupd [arm64] (cosmic-proposed) [1.1.0-4]
-queuebot:#ubuntu-release- Unapproved: rejected fwupd [arm64] (cosmic-proposed) [1.1.0-6]
-queuebot:#ubuntu-release- Unapproved: rejected fwupd [i386] (cosmic-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- Unapproved: rejected fwupd [i386] (cosmic-proposed) [1.1.0-6]
-queuebot:#ubuntu-release- Unapproved: rejected fwupd [i386] (cosmic-proposed) [1.1.0-4]
-queuebot:#ubuntu-release- Unapproved: rejected fwupdate [amd64] (cosmic-proposed) [12-2]
-queuebot:#ubuntu-release- Unapproved: rejected fwupdate [i386] (cosmic-proposed) [12-2]
-queuebot:#ubuntu-release- Unapproved: rejected fwupdate [arm64] (cosmic-proposed) [12-2]
<slangasek> acheronuk: and I just did a test build on a ppc64el machine and got no hang
<acheronuk> slangasek: great, but the builders don't seem to be so accommodating. any clue why?
<slangasek> yeah, not great at all ;)
<slangasek> acheronuk: ok, apparently after making sure the chroot is completely up to date with -proposed, I can reproduce *a* hang, though not at the same point seen on the buildds
<slangasek> and not a hang so much as 100% CPU usage by a compiler
-queuebot:#ubuntu-release- New binary: networking-bagpipe [amd64] (cosmic-proposed/universe) [9.0.0~rc1-0ubuntu1] (no packageset)
<cjwatson> infinity: early> Just 'cos it's not on old-releases yet
<slangasek> acheronuk, tkamppeter: building with -O2 works around the problem fine, but passing DEB_CFLAGS_MAINT_APPEND fails to get picked up by the build system (and it's cdbs, so I'm not enthusiastic about digging into it)
-queuebot:#ubuntu-release- New binary: cinder [amd64] (cosmic-proposed/main) [2:13.0.0~rc1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New source: zvmcloudconnector (cosmic-proposed/primary) [1.2.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-system-monitor (bionic-proposed/universe) [35-1 => 35-1ubuntu1~jdstrand1] (no packageset)
-queuebot:#ubuntu-release- New binary: slepc [i386] (cosmic-proposed/universe) [3.9.2+dfsg1-1build1] (no packageset)
<acheronuk> slangasek: ummm. pass on that as well
-queuebot:#ubuntu-release- Unapproved: accepted 2ping [source] (bionic-proposed) [4.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted fwts [source] (bionic-proposed) [18.03.00-0ubuntu3]
<ehashman> slangasek: saw the updates on the node bug, I will attempt to test for you tonight or tomorrow :)
<ehashman> and thanks!
<slangasek> ehashman: no problem, sorry it took so long (would've done it a couple days sooner but was out sick)
<ehashman> it's alright, hope you feel better now
<ehashman> I was less worried about a delay and more worried about the initial wontfix
<ehashman> there is some discussion om the upstream bug... archlinux finally has committed to fixing this in their lts node as well
<ehashman> so just Debian left (I dunno if there's anything I can do to speed up getting node 10 in unstable...)
<slangasek> rbasak's comments still apply wrt the incomplete expression of the current ABI string
<rbasak> I'm concerned that this isn't fixed properly in our development release. It'll almost certainly "regress" sooner or later (ie. a future Ubuntu release will contain a nodejs with a similar ABI incompatibility).
<rbasak> I hope upstream fix this properly, but I suspect they won't.
<ehashman> rbasak: I'm trying to coaxthem into better ABI management practices but..
<rbasak> ehashman: I appreciate your efforts
<ehashman> are there any resoirces I can point them at?
<ehashman> I'm suggesting they don't vendor and export all these external lib symbols
<rbasak> What sort of thing do you have in mind?
<ehashman> they also don't version their own symbols
<ehashman> they just claim they will maintain ABI compat for a major release
<ehashman> the Python approach for SSL involves actual cryptographic engineers maintaining the SSL wrapper lib that is versioned and natively built against a policy
<ehashman> where the policy env is an ancient minimal centos image
<rbasak> The problem starts because they bundle their dependencies
<rbasak> And distributions must unbundle to be able to maintain their own release stability/security promises.
<ehashman> some of them are hard to get around
<ehashman> their libv8 is so heavily patched...
<ehashman> but openssl is sort of silly
<ehashman> I don't think incompat has come up with the other deps
<rbasak> If their downstreams unbundle (as they do for at least some of these), then they can't rely on dependency stability for ABI
<rbasak> Since the downstreams may choose not to ship the version they're depending on
<ehashman> even if they don't unbundle ulstream they can at least stop exporting the symbols for comlatibility
<rbasak> Making it impossible for their downstreams to build for that ABI
-queuebot:#ubuntu-release- Unapproved: accepted evolution-data-server [source] (bionic-proposed) [3.28.5-0ubuntu0.18.04.1]
<ehashman> like for natively compiled Python extensions we don't even assume compatibility with the system Python headers
<rbasak> The best thing to point them to would be Python then I guess?
<ehashman> https://www.python.org/dev/peps/pep-0513/#libpythonx-y-so-1
<ehashman> yeah I am trying to nudge them in that direction
<ehashman> (I'm one of the manylinux maintainers)
<ehashman> one of the node release managers has told me he's been interested in this for a long time, it's a known problem
-queuebot:#ubuntu-release- Unapproved: accepted python-phabricator [source] (bionic-proposed) [0.7.0-1ubuntu0.1]
-queuebot:#ubuntu-release- New binary: designate [amd64] (cosmic-proposed/main) [1:7.0.0~rc1-0ubuntu1] (openstack, ubuntu-server)
<tsimonq2> Oh, nice. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905868
<ubot5> Debian bug 905868 in gcc-8 "gcc-8: miscompiles vec_sl at -O3 with -fwrapv on ppc64el" [Normal,Open]
#ubuntu-release 2018-08-11
-queuebot:#ubuntu-release- New binary: calamares-settings-ubuntu [i386] (cosmic-proposed/universe) [17] (no packageset)
-queuebot:#ubuntu-release- New binary: calamares-settings-ubuntu [s390x] (cosmic-proposed/universe) [17] (no packageset)
-queuebot:#ubuntu-release- New binary: calamares-settings-ubuntu [ppc64el] (cosmic-proposed/universe) [17] (no packageset)
-queuebot:#ubuntu-release- New binary: calamares-settings-ubuntu [amd64] (cosmic-proposed/universe) [17] (no packageset)
-queuebot:#ubuntu-release- New binary: calamares-settings-ubuntu [armhf] (cosmic-proposed/universe) [17] (no packageset)
-queuebot:#ubuntu-release- New binary: calamares-settings-ubuntu [arm64] (cosmic-proposed/universe) [17] (no packageset)
<tsimonq2> slangasek: ^ can I get approval so I get it rolling in the dailies? :)
-queuebot:#ubuntu-release- New: accepted android-platform-external-boringssl [armhf] (cosmic-proposed) [8.1.0+r23-1]
-queuebot:#ubuntu-release- New: accepted android-platform-external-boringssl [amd64] (cosmic-proposed) [8.1.0+r23-1]
-queuebot:#ubuntu-release- New: accepted android-platform-external-boringssl [i386] (cosmic-proposed) [8.1.0+r23-1]
-queuebot:#ubuntu-release- New: accepted android-platform-external-boringssl [arm64] (cosmic-proposed) [8.1.0+r23-1]
-queuebot:#ubuntu-release- New: accepted android-platform-external-boringssl [ppc64el] (cosmic-proposed) [8.1.0+r23-1]
-queuebot:#ubuntu-release- New: accepted hvac [source] (cosmic-proposed) [0.5.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: hvac [amd64] (cosmic-proposed/none) [0.5.0-0ubuntu1] (no packageset)
<LocutusOfBorg> tsimonq2, bad ffmpeg upload is bad :D
 * LocutusOfBorg exports the variable and reuploads :p
<acheronuk> ah, that's why the ppc64el autotest still fails!
<tsimonq2> LocutusOfBorg: baaaaaah.
 * tsimonq2 blames Laney :P
<LocutusOfBorg> yep, I see the export does actually pass the -O2 to the build (on DOM)
<LocutusOfBorg> lets see if we got it right :)
 * tsimonq2 sends giraffes at Laney as a present.
<LocutusOfBorg> we hate giraffes!
<tsimonq2> Exactly. :D
<LocutusOfBorg> but not as much as horses I would say
<LocutusOfBorg> horses are evil
<acheronuk> ????
<acheronuk> oh. ic
 * LocutusOfBorg finds the video
<LocutusOfBorg> https://www.youtube.com/watch?v=ojgrEGmDSCg
<LocutusOfBorg> this one!
<tsimonq2> (I'm blaming Laney because I blindly copied what he did in #ubuntu-devel. :P)
<tsimonq2> LocutusOfBorg: hahaha
<LocutusOfBorg> tsimonq2, I see from build log that it might be not enough, because it passes -O2, but there is another -O3 passed by dpkg itself
<LocutusOfBorg> it might win the latter, so -O3
<tsimonq2> LocutusOfBorg: Please follow up on the Debian bug then, if that's not the case.
<acheronuk> LocutusOfBorg: seems a fair amount of logic in source configure to set different optimisations
<acheronuk> depending on the env
<acheronuk> and --optflags=OPTFLAGS override optimization-related compiler flags
<tsimonq2> Man, where is this all documented?
<tsimonq2> This is slightly confusing to me; even as a MOTU.
<tsimonq2> LocutusOfBorg: Bad LocutusOfBorg is bad and doesn't link docs. :D
<acheronuk> that is in configure in the source
<tsimonq2> Anyway, I should try to ð´ o/
<tsimonq2> acheronuk: Right; confusing. ;)
<acheronuk> it is if you depend on the BS and never run ./configure --help yourself!
<tsimonq2> hahahaha
<LocutusOfBorg> bad tsimonq2 exporting -O2 everywhere! :)
<tsimonq2> ð
<LocutusOfBorg> acheronuk, I was looking at "--extra-cxxflags=ECFLAGS" instead
<acheronuk> LocutusOfBorg: I only skimmed it, so could be
<LocutusOfBorg> I'm trying to get the order of all that stuff, in the meanwhile I uploaded a build on my ppa
<LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+sourcepub/9325527/+listing-archive-extra
<acheronuk> I still see -O3 after -O2 in the logs there
<LocutusOfBorg> acheronuk, https://trac.ffmpeg.org/ticket/2816
<LocutusOfBorg> you are my best bet
<LocutusOfBorg> acheronuk, that build was to see if only ppc64el was using the code
<LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa/+packages
<LocutusOfBorg> this one uses your approach
<LocutusOfBorg> I grepped math-errno and it is indeed passed by the configure script, not something that comes from gcc or dpkg
<LocutusOfBorg> and the -O3 we want to override is added in the same chunk of configure code
<acheronuk> makes sense
<acheronuk> ambiguous configure options. sigh
<acheronuk> google shows me a fair few examples where people have -O2 and other options passed via --optflags. whether it effective is another matter
<LocutusOfBorg> yep
<acheronuk> optflags gives me 'CFLAGS= blah blah blah -O2' in ffbuild/config.mak after local configure, vs -O3 without, so seems to be effective there
<LocutusOfBorg> doesnt work in ppa
<LocutusOfBorg> https://launchpadlibrarian.net/382847674/buildlog_ubuntu-cosmic-ppc64el.ffmpeg_7%3A4.0.2-1ubuntu3_BUILDING.txt.gz
<acheronuk> sigh
<LocutusOfBorg> does it look ok to you=
<LocutusOfBorg> ?
<acheronuk> it appears not ok
<LocutusOfBorg> but the configure line?
<acheronuk> looks fine compared to what worked locally here
<LocutusOfBorg> lol acheronuk it wasn't
<LocutusOfBorg> ahahaha got it
<LocutusOfBorg>   CONFIG += --optflags='-O2'
<LocutusOfBorg>   CONFIG += "--optflags='-O2'"
<LocutusOfBorg> this was the difference
<LocutusOfBorg> and now it works
<LocutusOfBorg> bad configure is bad
<LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa/+build/15254125
<acheronuk> lol. not sure how I missed the " "
<acheronuk> looking to hard at the arg, and not what was around it I guess!
<acheronuk> LocutusOfBorg: ooh. you uploaded. fingers crossed then
<acheronuk> on the tests
<acheronuk> it bugs me that on each gcc invocation you still see -O3, but followed by -O2 :/
<acheronuk> oh, but that is a just a reversal of what happened without optflags, so just how this one rocks I guess
<LocutusOfBorg> arm64 what about failing to build?
<acheronuk> oh ffs
<acheronuk> LocutusOfBorg: retried and succeeded?
<LocutusOfBorg> ssssshhhh we didn't see it failing, ever! :)
<ginggs> LocutusOfBorg: are you going to try setting -O2 for ghostscript?
<acheronuk> LocutusOfBorg: autotest still fails: https://autopkgtest.ubuntu.com/packages/ffmpeg/cosmic/ppc64el
<ginggs> i tried in my PPA twice https://launchpad.net/~ginggs/+archive/ubuntu/testing/+sourcepub/9320256/+listing-archive-extra
<ginggs> what I didn't try was export DEB_CFLAGS_MAINT_STRIP=-O3 / export DEB_CFLAGS_MAINT_APPEND=-O2 together with CONFIG += --optflags=-O2
<ginggs> i.e. maybe we need to override the -O3 that ubuntu put in, as well as what configure puts in
<LocutusOfBorg> ginggs, I'm leaving shortly
<LocutusOfBorg> lets try a new ffmpeg spin then
<LocutusOfBorg> ginggs, sorry I didn't get your sentence above, did that approach work or not?
<ginggs> i tried DEB_CFLAGS_MAINT_STRIP=-O3 / export DEB_CFLAGS_MAINT_APPEND=-O2 in ~ppa1
<ginggs> then CONFIG += --optflags=-O2 in ~ppa2
<ginggs> i haven't tried both together
<ginggs> i can try that in my PPA now, at least it might make it easier to spot in the log if -O3 creeps in from elsewhere
<ginggs> building now https://launchpad.net/~ginggs/+archive/ubuntu/testing/+sourcepub/9325607/+listing-archive-extra
<LocutusOfBorg> I did fix it
<LocutusOfBorg> objdump shows good code with -O3 and -fno-wrapv on ppc64el pbuilder chroot
<LocutusOfBorg> I have to leave, uploaded
<LocutusOfBorg> fingers crossed!
<ginggs> LocutusOfBorg: it worked! http://autopkgtest.ubuntu.com/packages/f/ffmpeg/cosmic/ppc64el
<ginggs> tkamppeter: ghostscript uploaded. you almost had it, the DEB_CFLAGS_MAINT bit had to come before include /usr/share/cdbs/1/rules/debhelper.mk
<acheronuk> aaaah
<acheronuk> ginggs: thank you
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-system-monitor (bionic-proposed/universe) [35-1 => 35-1ubuntu0.18.04.1] (no packageset)
<Laney> tsimonq2: I said export in there.
<Laney> and it would have been good to get it all passing in a PPA instead of using the real archive to iterate
<Laney> anyway, hope it fixes it, thx for working on that
<ginggs> running the autopkgtests in a PPA is quicker too...
<ginggs> if you can get the URLs right https://wiki.ubuntu.com/ProposedMigration#Testing_against_a_PPA
<Laney> ginggs: what was wrong with DEB_CFLAGS_MAINT_APPEND in ghostscript btw? I just uploaded with that and it built on ppc64el OK https://launchpad.net/~laney/+archive/ubuntu/ppa/+build/15254447 https://paste.ubuntu.com/p/M6nrXF5ybB/
<ginggs> [13:58:22] <ginggs> tkamppeter: ghostscript uploaded. you almost had it, the DEB_CFLAGS_MAINT bit had to come before include /usr/share/cdbs/1/rules/debhelper.mk
<ginggs> Laney: ^
<ginggs> cdbs... shudder
<Laney> ginggs: right, but I'm talking about using STRIP/PREPEND which is a bit unusual
<ginggs> Laney: DEB_CFLAGS_MAINT_APPEND probably would have worked, i prefer STRIP/PREPEND as it makes the logs easier to read
<slangasek> ddstreet: it seems your nodejs SRU FTBFS on all archs, as noted by ehashman on the bug.  can you follow through on this?  Specifically, parallel/test-tls-server-verify test fails
<tsimonq2> Laney: :P
#ubuntu-release 2018-08-12
<tsimonq2> Oh, fun, I hate stupid oversights.
<tsimonq2> Bug 1786602.
<ubot5> bug 1786602 in lubuntu-default-settings (Ubuntu) "Lubuntu 18.04 "Lubuntu Qt session" crashes the system" [Undecided,New] https://launchpad.net/bugs/1786602
<tsimonq2> Apparently before the release, I forgot to get the Lubuntu Next xsession out of the main install.
<tsimonq2> Siiiiigh.
-queuebot:#ubuntu-release- Unapproved: lubuntu-default-settings (bionic-proposed/universe) [0.54 => 0.54.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rkhunter (bionic-proposed/universe) [1.4.6-1 => 1.4.6-2~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: evolution-data-server [s390x] (cosmic-proposed/main) [3.29.90-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: evolution-data-server [ppc64el] (cosmic-proposed/main) [3.29.90-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: evolution-data-server [amd64] (cosmic-proposed/main) [3.29.90-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: evolution-data-server [i386] (cosmic-proposed/main) [3.29.90-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: evolution-data-server [arm64] (cosmic-proposed/main) [3.29.90-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: evolution-data-server [armhf] (cosmic-proposed/main) [3.29.90-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted calamares-settings-ubuntu [amd64] (cosmic-proposed) [17]
-queuebot:#ubuntu-release- New: accepted calamares-settings-ubuntu [armhf] (cosmic-proposed) [17]
-queuebot:#ubuntu-release- New: accepted calamares-settings-ubuntu [ppc64el] (cosmic-proposed) [17]
-queuebot:#ubuntu-release- New: accepted evolution-data-server [amd64] (cosmic-proposed) [3.29.90-1]
-queuebot:#ubuntu-release- New: accepted evolution-data-server [armhf] (cosmic-proposed) [3.29.90-1]
-queuebot:#ubuntu-release- New: accepted evolution-data-server [ppc64el] (cosmic-proposed) [3.29.90-1]
-queuebot:#ubuntu-release- New: accepted calamares-settings-ubuntu [arm64] (cosmic-proposed) [17]
-queuebot:#ubuntu-release- New: accepted calamares-settings-ubuntu [s390x] (cosmic-proposed) [17]
-queuebot:#ubuntu-release- New: accepted evolution-data-server [i386] (cosmic-proposed) [3.29.90-1]
-queuebot:#ubuntu-release- New: accepted calamares-settings-ubuntu [i386] (cosmic-proposed) [17]
-queuebot:#ubuntu-release- New: accepted evolution-data-server [s390x] (cosmic-proposed) [3.29.90-1]
-queuebot:#ubuntu-release- New: accepted evolution-data-server [arm64] (cosmic-proposed) [3.29.90-1]
-queuebot:#ubuntu-release- New: accepted calamares-settings-ubuntu [amd64] (cosmic-proposed) [15]
-queuebot:#ubuntu-release- New: accepted calamares-settings-ubuntu [armhf] (cosmic-proposed) [15]
-queuebot:#ubuntu-release- New: accepted calamares-settings-ubuntu [ppc64el] (cosmic-proposed) [15]
-queuebot:#ubuntu-release- New: accepted calamares-settings-ubuntu [amd64] (cosmic-proposed) [16]
-queuebot:#ubuntu-release- New: accepted calamares-settings-ubuntu [armhf] (cosmic-proposed) [16]
-queuebot:#ubuntu-release- New: accepted calamares-settings-ubuntu [ppc64el] (cosmic-proposed) [16]
-queuebot:#ubuntu-release- New: accepted calamares-settings-ubuntu [arm64] (cosmic-proposed) [15]
-queuebot:#ubuntu-release- New: accepted calamares-settings-ubuntu [s390x] (cosmic-proposed) [15]
-queuebot:#ubuntu-release- New: accepted calamares-settings-ubuntu [i386] (cosmic-proposed) [16]
-queuebot:#ubuntu-release- New: accepted calamares-settings-ubuntu [i386] (cosmic-proposed) [15]
-queuebot:#ubuntu-release- New: accepted calamares-settings-ubuntu [s390x] (cosmic-proposed) [16]
-queuebot:#ubuntu-release- New: accepted calamares-settings-ubuntu [arm64] (cosmic-proposed) [16]
-queuebot:#ubuntu-release- New: accepted mariadb-10.1 [amd64] (cosmic-proposed) [1:10.1.35-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted mariadb-10.1 [armhf] (cosmic-proposed) [1:10.1.35-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted mariadb-10.1 [ppc64el] (cosmic-proposed) [1:10.1.35-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted mariadb-10.1 [arm64] (cosmic-proposed) [1:10.1.35-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted mariadb-10.1 [s390x] (cosmic-proposed) [1:10.1.35-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted mariadb-10.1 [i386] (cosmic-proposed) [1:10.1.35-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted qtstyleplugins-src [amd64] (cosmic-proposed) [5.0.0+git23.g335dbec-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted qtstyleplugins-src [armhf] (cosmic-proposed) [5.0.0+git23.g335dbec-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted qtstyleplugins-src [ppc64el] (cosmic-proposed) [5.0.0+git23.g335dbec-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted qtstyleplugins-src [amd64] (cosmic-proposed) [5.0.0+git23.g335dbec-2ubuntu2]
-queuebot:#ubuntu-release- New: accepted qtstyleplugins-src [armhf] (cosmic-proposed) [5.0.0+git23.g335dbec-2ubuntu2]
-queuebot:#ubuntu-release- New: accepted qtstyleplugins-src [ppc64el] (cosmic-proposed) [5.0.0+git23.g335dbec-2ubuntu2]
-queuebot:#ubuntu-release- New: accepted qtstyleplugins-src [arm64] (cosmic-proposed) [5.0.0+git23.g335dbec-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted qtstyleplugins-src [s390x] (cosmic-proposed) [5.0.0+git23.g335dbec-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted qtstyleplugins-src [i386] (cosmic-proposed) [5.0.0+git23.g335dbec-2ubuntu2]
-queuebot:#ubuntu-release- New: accepted qtstyleplugins-src [i386] (cosmic-proposed) [5.0.0+git23.g335dbec-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted qtstyleplugins-src [s390x] (cosmic-proposed) [5.0.0+git23.g335dbec-2ubuntu2]
-queuebot:#ubuntu-release- New: accepted qtstyleplugins-src [arm64] (cosmic-proposed) [5.0.0+git23.g335dbec-2ubuntu2]
-queuebot:#ubuntu-release- New: accepted budgie-desktop [amd64] (cosmic-proposed) [10.4+git20180806.02.933f78fc03d-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted budgie-desktop [armhf] (cosmic-proposed) [10.4+git20180806.02.933f78fc03d-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted budgie-desktop [ppc64el] (cosmic-proposed) [10.4+git20180806.02.933f78fc03d-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted dovecot [amd64] (cosmic-proposed) [1:2.3.2.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted dovecot [armhf] (cosmic-proposed) [1:2.3.2.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted dovecot [ppc64el] (cosmic-proposed) [1:2.3.2.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted budgie-desktop [arm64] (cosmic-proposed) [10.4+git20180806.02.933f78fc03d-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted budgie-desktop [s390x] (cosmic-proposed) [10.4+git20180806.02.933f78fc03d-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted dovecot [i386] (cosmic-proposed) [1:2.3.2.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted budgie-desktop [i386] (cosmic-proposed) [10.4+git20180806.02.933f78fc03d-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted dovecot [s390x] (cosmic-proposed) [1:2.3.2.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted dovecot [arm64] (cosmic-proposed) [1:2.3.2.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted python-ceilometermiddleware [amd64] (cosmic-proposed) [1.3.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted python-os-traits [amd64] (cosmic-proposed) [0.9.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted cinder [amd64] (cosmic-proposed) [2:13.0.0~b3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted designate [amd64] (cosmic-proposed) [1:7.0.0~b3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted hvac [amd64] (cosmic-proposed) [0.5.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted cinder [amd64] (cosmic-proposed) [2:13.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted designate [amd64] (cosmic-proposed) [1:7.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted networking-bagpipe [amd64] (cosmic-proposed) [9.0.0~b3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted networking-bagpipe [amd64] (cosmic-proposed) [9.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted manila-ui [amd64] (cosmic-proposed) [2.16.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted slepc [amd64] (cosmic-proposed) [3.9.2+dfsg1-1build1]
-queuebot:#ubuntu-release- New: accepted slepc [i386] (cosmic-proposed) [3.9.2+dfsg1-1build1]
-queuebot:#ubuntu-release- New: accepted slepc [s390x] (cosmic-proposed) [3.9.2+dfsg1-1build1]
-queuebot:#ubuntu-release- New: accepted python-blazarclient [source] (cosmic-proposed) [2.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted slepc [ppc64el] (cosmic-proposed) [3.9.2+dfsg1-1build1]
-queuebot:#ubuntu-release- New: accepted slepc [arm64] (cosmic-proposed) [3.9.2+dfsg1-1build1]
-queuebot:#ubuntu-release- New binary: python-blazarclient [amd64] (cosmic-proposed/none) [2.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-blazarclient [amd64] (cosmic-proposed) [2.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: heat [amd64] (cosmic-proposed/main) [1:11.0.0~rc1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New binary: minetest-mod-skyblock [amd64] (cosmic-proposed/universe) [0.2.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-byte-tools [i386] (cosmic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-phf-shared [s390x] (cosmic-proposed/universe) [0.7.22-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syscallz [i386] (cosmic-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-priority [amd64] (cosmic-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syscallz [amd64] (cosmic-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-generic-array [amd64] (cosmic-proposed/universe) [0.11.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: txws [amd64] (cosmic-proposed/universe) [0.9.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: chafa [ppc64el] (cosmic-proposed/universe) [0.9.0+git20180731.5ddfe4c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hivelytracker [i386] (cosmic-proposed/universe) [0+git20180223-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qlogo [s390x] (cosmic-proposed/universe) [0.92-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-byte-tools [arm64] (cosmic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-byte-tools [ppc64el] (cosmic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-dhcp4r [amd64] (cosmic-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-generic-array [i386] (cosmic-proposed/universe) [0.11.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-generic-array [s390x] (cosmic-proposed/universe) [0.11.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-phf-shared [arm64] (cosmic-proposed/universe) [0.7.22-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-phf-shared [i386] (cosmic-proposed/universe) [0.7.22-1] (no packageset)
-queuebot:#ubuntu-release- New binary: chafa [s390x] (cosmic-proposed/universe) [0.9.0+git20180731.5ddfe4c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-byte-tools [amd64] (cosmic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-byte-tools [s390x] (cosmic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-generic-array [ppc64el] (cosmic-proposed/universe) [0.11.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-phf-shared [armhf] (cosmic-proposed/universe) [0.7.22-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pktparse [amd64] (cosmic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pktparse [armhf] (cosmic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pktparse [ppc64el] (cosmic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syscallz [ppc64el] (cosmic-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-url-serde [amd64] (cosmic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qlogo [amd64] (cosmic-proposed/universe) [0.92-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-dhcp4r [i386] (cosmic-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-phf-shared [ppc64el] (cosmic-proposed/universe) [0.7.22-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pktparse [i386] (cosmic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syscallz [s390x] (cosmic-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-url-serde [s390x] (cosmic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-byte-tools [armhf] (cosmic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pktparse [arm64] (cosmic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-url-serde [i386] (cosmic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-phf-shared [amd64] (cosmic-proposed/universe) [0.7.22-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pktparse [s390x] (cosmic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: chafa [amd64] (cosmic-proposed/universe) [0.9.0+git20180731.5ddfe4c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: chafa [armhf] (cosmic-proposed/universe) [0.9.0+git20180731.5ddfe4c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmbassador-java [amd64] (cosmic-proposed/universe) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qlogo [armhf] (cosmic-proposed/universe) [0.92-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qlogo [ppc64el] (cosmic-proposed/universe) [0.92-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-generic-array [arm64] (cosmic-proposed/universe) [0.11.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syscallz [arm64] (cosmic-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-url-serde [ppc64el] (cosmic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: chafa [arm64] (cosmic-proposed/universe) [0.9.0+git20180731.5ddfe4c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qlogo [arm64] (cosmic-proposed/universe) [0.92-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-dhcp4r [armhf] (cosmic-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syscallz [armhf] (cosmic-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hivelytracker [amd64] (cosmic-proposed/universe) [0+git20180223-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-generic-array [armhf] (cosmic-proposed/universe) [0.11.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qlogo [i386] (cosmic-proposed/universe) [0.92-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-url-serde [arm64] (cosmic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-url-serde [armhf] (cosmic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: breezy [i386] (cosmic-proposed/universe) [3.0.0~bzr7065-1] (no packageset)
-queuebot:#ubuntu-release- New binary: breezy [amd64] (cosmic-proposed/universe) [3.0.0~bzr7065-1] (no packageset)
-queuebot:#ubuntu-release- New binary: breezy [armhf] (cosmic-proposed/universe) [3.0.0~bzr7065-1] (no packageset)
-queuebot:#ubuntu-release- New binary: breezy [arm64] (cosmic-proposed/universe) [3.0.0~bzr7065-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libmbassador-java [amd64] (cosmic-proposed) [1.3.1-1]
-queuebot:#ubuntu-release- New: accepted minetest-mod-skyblock [amd64] (cosmic-proposed) [0.2.4-1]
-queuebot:#ubuntu-release- New: accepted qlogo [amd64] (cosmic-proposed) [0.92-1]
-queuebot:#ubuntu-release- New: accepted qlogo [armhf] (cosmic-proposed) [0.92-1]
-queuebot:#ubuntu-release- New: accepted qlogo [ppc64el] (cosmic-proposed) [0.92-1]
-queuebot:#ubuntu-release- New: accepted rust-byte-tools [amd64] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-byte-tools [armhf] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-byte-tools [ppc64el] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-generic-array [arm64] (cosmic-proposed) [0.11.1-1]
-queuebot:#ubuntu-release- New: accepted python-priority [amd64] (cosmic-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted qlogo [i386] (cosmic-proposed) [0.92-1]
-queuebot:#ubuntu-release- New: accepted rust-byte-tools [arm64] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-byte-tools [s390x] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted qlogo [arm64] (cosmic-proposed) [0.92-1]
-queuebot:#ubuntu-release- New: accepted rust-byte-tools [i386] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted qlogo [s390x] (cosmic-proposed) [0.92-1]
-queuebot:#ubuntu-release- New: accepted rust-generic-array [armhf] (cosmic-proposed) [0.11.1-1]
-queuebot:#ubuntu-release- New: accepted rust-generic-array [amd64] (cosmic-proposed) [0.11.1-1]
-queuebot:#ubuntu-release- New: accepted rust-generic-array [ppc64el] (cosmic-proposed) [0.11.1-1]
-queuebot:#ubuntu-release- New: accepted rust-phf-shared [amd64] (cosmic-proposed) [0.7.22-1]
-queuebot:#ubuntu-release- New: accepted rust-phf-shared [armhf] (cosmic-proposed) [0.7.22-1]
-queuebot:#ubuntu-release- New: accepted rust-phf-shared [ppc64el] (cosmic-proposed) [0.7.22-1]
-queuebot:#ubuntu-release- New: accepted rust-pktparse [amd64] (cosmic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted rust-pktparse [armhf] (cosmic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted rust-pktparse [ppc64el] (cosmic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted rust-syscallz [amd64] (cosmic-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-syscallz [armhf] (cosmic-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-generic-array [i386] (cosmic-proposed) [0.11.1-1]
-queuebot:#ubuntu-release- New: accepted rust-phf-shared [arm64] (cosmic-proposed) [0.7.22-1]
-queuebot:#ubuntu-release- New: accepted rust-phf-shared [s390x] (cosmic-proposed) [0.7.22-1]
-queuebot:#ubuntu-release- New: accepted rust-pktparse [i386] (cosmic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted rust-syscallz [arm64] (cosmic-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-syscallz [ppc64el] (cosmic-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-url-serde [arm64] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-url-serde [ppc64el] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-generic-array [s390x] (cosmic-proposed) [0.11.1-1]
-queuebot:#ubuntu-release- New: accepted rust-pktparse [arm64] (cosmic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted rust-syscallz [i386] (cosmic-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-url-serde [armhf] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-phf-shared [i386] (cosmic-proposed) [0.7.22-1]
-queuebot:#ubuntu-release- New: accepted rust-syscallz [s390x] (cosmic-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-pktparse [s390x] (cosmic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted rust-url-serde [amd64] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-url-serde [s390x] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-url-serde [i386] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted txws [amd64] (cosmic-proposed) [0.9.1-2]
<cpaelzer> hi, surely not the best time in a week to ask - but since I get "stuck in proposed messages" now :-)
<cpaelzer> arr, forget the above
<cpaelzer> I wanted to ask about dovecot in new queue, but someone accepted today over the day
<cpaelzer> thanks
<cpaelzer> a bit unfait thou that then out of a sudden the time to nag me by the bot is instant expired :-)
<apw> cpaelzer, i have the feeling that migrating can trigger one of those warnings just before
<mwhudson> i guess someone will eventually have to look at the php-imagick autopkgtests
-queuebot:#ubuntu-release- New binary: chafa [amd64] (cosmic-proposed/universe) [0.9.0+git20180731.5ddfe4c-2] (no packageset)
-queuebot:#ubuntu-release- New binary: chafa [s390x] (cosmic-proposed/universe) [0.9.0+git20180731.5ddfe4c-2] (no packageset)
-queuebot:#ubuntu-release- New binary: chafa [i386] (cosmic-proposed/universe) [0.9.0+git20180731.5ddfe4c-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hivelytracker [amd64] (cosmic-proposed/universe) [0+git20180223-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hivelytracker [ppc64el] (cosmic-proposed/universe) [0+git20180223-2] (no packageset)
-queuebot:#ubuntu-release- New binary: chafa [ppc64el] (cosmic-proposed/universe) [0.9.0+git20180731.5ddfe4c-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hivelytracker [s390x] (cosmic-proposed/universe) [0+git20180223-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hivelytracker [i386] (cosmic-proposed/universe) [0+git20180223-2] (no packageset)
-queuebot:#ubuntu-release- New binary: chafa [arm64] (cosmic-proposed/universe) [0.9.0+git20180731.5ddfe4c-2] (no packageset)
-queuebot:#ubuntu-release- New binary: dolfin [i386] (cosmic-proposed/universe) [2018.1.0.post1-7] (no packageset)
-queuebot:#ubuntu-release- New binary: chafa [armhf] (cosmic-proposed/universe) [0.9.0+git20180731.5ddfe4c-2] (no packageset)
-queuebot:#ubuntu-release- New binary: yapf [amd64] (cosmic-proposed/universe) [0.22.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hivelytracker [arm64] (cosmic-proposed/universe) [0+git20180223-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hivelytracker [armhf] (cosmic-proposed/universe) [0+git20180223-2] (no packageset)
-queuebot:#ubuntu-release- New binary: dolfin [ppc64el] (cosmic-proposed/universe) [2018.1.0.post1-7] (no packageset)
-queuebot:#ubuntu-release- New binary: dolfin [s390x] (cosmic-proposed/universe) [2018.1.0.post1-7] (no packageset)
-queuebot:#ubuntu-release- New binary: dolfin [amd64] (cosmic-proposed/universe) [2018.1.0.post1-7] (no packageset)
-queuebot:#ubuntu-release- New binary: dolfin [arm64] (cosmic-proposed/universe) [2018.1.0.post1-7] (no packageset)
#ubuntu-release 2019-08-05
-queuebot:#ubuntu-release- New binary: biobambam2 [armhf] (eoan-proposed/universe) [2.0.95-1] (no packageset)
-queuebot:#ubuntu-release- New binary: biobambam2 [arm64] (eoan-proposed/universe) [2.0.95-1] (no packageset)
-queuebot:#ubuntu-release- New binary: http-parser [amd64] (eoan-proposed/main) [2.9.2-2] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: http-parser [i386] (eoan-proposed/main) [2.9.2-2] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: http-parser [s390x] (eoan-proposed/main) [2.9.2-2] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: http-parser [ppc64el] (eoan-proposed/main) [2.9.2-2] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: http-parser [arm64] (eoan-proposed/main) [2.9.2-2] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: http-parser [armhf] (eoan-proposed/main) [2.9.2-2] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: ocaml-dune [i386] (eoan-proposed/universe) [1.6.2-4build1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-dune [s390x] (eoan-proposed/universe) [1.6.2-4build1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-dune [amd64] (eoan-proposed/universe) [1.6.2-4build1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-dune [ppc64el] (eoan-proposed/universe) [1.6.2-4build1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-dune [arm64] (eoan-proposed/universe) [1.6.2-4build1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-dune [armhf] (eoan-proposed/universe) [1.6.2-4build1] (no packageset)
-queuebot:#ubuntu-release- New binary: dolfin [amd64] (eoan-proposed/universe) [2019.1.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: dolfin [ppc64el] (eoan-proposed/universe) [2019.1.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: dolfin [s390x] (eoan-proposed/universe) [2019.1.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: dolfin [i386] (eoan-proposed/universe) [2019.1.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: dolfin [armhf] (eoan-proposed/universe) [2019.1.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: dolfin [arm64] (eoan-proposed/universe) [2019.1.0-3] (no packageset)
<sil2100> infinity: I see the new gstreamer stack ready and verified in bionic-proposed, you think it's safe to still get that in for .3? Or would you prefer to wait with it after the point-release?
-queuebot:#ubuntu-release- New source: rtl8821ce (eoan-proposed/primary) [5.2.5.2.1.30816.20190425-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected dpdk [source] (disco-proposed) [18.11.2-1ubuntu0.19.04.1]
-queuebot:#ubuntu-release- New: accepted dolfin [amd64] (eoan-proposed) [2019.1.0-3]
-queuebot:#ubuntu-release- New: accepted dolfin [armhf] (eoan-proposed) [2019.1.0-3]
-queuebot:#ubuntu-release- New: accepted dolfin [ppc64el] (eoan-proposed) [2019.1.0-3]
-queuebot:#ubuntu-release- New: accepted dolfin [arm64] (eoan-proposed) [2019.1.0-3]
-queuebot:#ubuntu-release- New: accepted dolfin [s390x] (eoan-proposed) [2019.1.0-3]
-queuebot:#ubuntu-release- New: accepted dolfin [i386] (eoan-proposed) [2019.1.0-3]
-queuebot:#ubuntu-release- Unapproved: pulseaudio (bionic-proposed/main) [1:11.1-1ubuntu7.3 => 1:11.1-1ubuntu7.4] (desktop-core, ubuntu-server)
<cpaelzer> sil2100: hiho on DPDK is it the former Disco changelog that you miss as merge changelog ?
<cpaelzer> this was lost due to the joint Packaging in Debian that we do, but I can insert that easily if that is all that was missing
<cpaelzer> hence I'm asking (and checking) if there is more missing
<cpaelzer> Oh I think I see
-queuebot:#ubuntu-release- New: accepted http-parser [arm64] (eoan-proposed) [2.9.2-2]
-queuebot:#ubuntu-release- New: accepted http-parser [i386] (eoan-proposed) [2.9.2-2]
-queuebot:#ubuntu-release- New: accepted http-parser [armhf] (eoan-proposed) [2.9.2-2]
<cpaelzer> the bug ref was on the old stable update
<cpaelzer> grml
<cpaelzer> I have a new one already with all the test data
-queuebot:#ubuntu-release- New: accepted http-parser [amd64] (eoan-proposed) [2.9.2-2]
-queuebot:#ubuntu-release- New: accepted http-parser [s390x] (eoan-proposed) [2.9.2-2]
-queuebot:#ubuntu-release- New: accepted ocaml-dune [arm64] (eoan-proposed) [1.6.2-4]
-queuebot:#ubuntu-release- New: accepted ocaml-dune [i386] (eoan-proposed) [1.6.2-4]
-queuebot:#ubuntu-release- New: accepted ocaml-dune [s390x] (eoan-proposed) [1.6.2-4]
-queuebot:#ubuntu-release- New: accepted http-parser [ppc64el] (eoan-proposed) [2.9.2-2]
-queuebot:#ubuntu-release- New: accepted ocaml-dune [armhf] (eoan-proposed) [1.6.2-4]
-queuebot:#ubuntu-release- New: accepted ocaml-dune [amd64] (eoan-proposed) [1.6.2-4]
-queuebot:#ubuntu-release- New: accepted ocaml-dune [ppc64el] (eoan-proposed) [1.6.2-4]
<cpaelzer> Bionic upload references 1836365 + 1827102 which is correct, Disco yeah disco has the bad ref
<cpaelzer> fixing
<sil2100> cpaelzer: thanks!
<cpaelzer> sil2100: about "proper changelog linked in"
<tseliot> hi, can an admin reject backport-iwlwifi-dkms from eoan (NEW), please? I need to fix the copyright file
<cpaelzer> sil2100: I set -v to the last 18.11 matching upload
<cpaelzer> and in between there are the changelogs linked
<cpaelzer> sil2100: do you want them to show up "again" in the topmost changelog entry?
 * cpaelzer checks if the upload had -v set properly as expected
<cpaelzer> sil2100: the now regenerated upload surely is made with the proper -v to have the changelogs linked
<cpaelzer> let me check the other one in bionic-unapproved
-queuebot:#ubuntu-release- New: accepted r-cran-mets [amd64] (eoan-proposed) [1.2.5-1]
-queuebot:#ubuntu-release- New: accepted r-cran-mets [armhf] (eoan-proposed) [1.2.5-1]
-queuebot:#ubuntu-release- New: accepted r-cran-mets [ppc64el] (eoan-proposed) [1.2.5-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ordinal [amd64] (eoan-proposed) [2019.4-25-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ordinal [armhf] (eoan-proposed) [2019.4-25-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ordinal [ppc64el] (eoan-proposed) [2019.4-25-1]
-queuebot:#ubuntu-release- New: accepted r-cran-mets [arm64] (eoan-proposed) [1.2.5-1]
-queuebot:#ubuntu-release- New: accepted r-cran-mets [s390x] (eoan-proposed) [1.2.5-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ordinal [i386] (eoan-proposed) [2019.4-25-1]
-queuebot:#ubuntu-release- New: accepted r-cran-mets [i386] (eoan-proposed) [1.2.5-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ordinal [s390x] (eoan-proposed) [2019.4-25-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ordinal [arm64] (eoan-proposed) [2019.4-25-1]
-queuebot:#ubuntu-release- Unapproved: dpdk (disco-proposed/main) [18.11-6 => 18.11.2-1ubuntu0.19.04.1] (ubuntu-server)
<cpaelzer> sil2100: the one in Bionic is a direct update (no -v used there), but also there I linked the external changelog
<cpaelzer> so it should be ok (bionic as it was, and disco as I now re-uploaded it)
-queuebot:#ubuntu-release- New: accepted r-cran-pcict [amd64] (eoan-proposed) [0.5-4.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-pcict [armhf] (eoan-proposed) [0.5-4.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-pcict [ppc64el] (eoan-proposed) [0.5-4.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-pcict [arm64] (eoan-proposed) [0.5-4.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-pcict [s390x] (eoan-proposed) [0.5-4.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-pcict [i386] (eoan-proposed) [0.5-4.1-1]
<cpaelzer> sil2100: let me know if you still need something changed
-queuebot:#ubuntu-release- New: accepted taurus [amd64] (eoan-proposed) [4.5.0+dfsg-2]
<sil2100> cpaelzer: thanks! Will look in a moment ;)
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (disco-proposed) [3:15.1.0-0ubuntu1.1]
<tseliot> sil2100: hey, can you also reject backport-iwlwifi-dkms 7906-0ubuntu1 (New) from eoan later, please?
<sil2100> tseliot: sure
-queuebot:#ubuntu-release- Unapproved: accepted dpdk [source] (disco-proposed) [18.11.2-1ubuntu0.19.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted dpdk [source] (bionic-proposed) [17.11.6-0~ubuntu18.04.1]
-queuebot:#ubuntu-release- New: rejected backport-iwlwifi-dkms [source] (eoan-proposed) [7906-0ubuntu1]
<cpaelzer> Thanks sil2100
<cpaelzer> seems the uploade for dpdk were ok now
<tseliot> sil2100: thanks!
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1053.58] (kernel)
-queuebot:#ubuntu-release- New binary: r-cran-jomo [s390x] (eoan-proposed/universe) [2.6-8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-jomo [amd64] (eoan-proposed/universe) [2.6-8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-jomo [i386] (eoan-proposed/universe) [2.6-8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-jomo [arm64] (eoan-proposed/universe) [2.6-8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-jomo [armhf] (eoan-proposed/universe) [2.6-8-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1053.58]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp-edge [amd64] (bionic-proposed/main) [5.0.0-1012.12~18.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp-edge [amd64] (bionic-proposed) [5.0.0-1012.12~18.04.1]
-queuebot:#ubuntu-release- New source: backport-iwlwifi-dkms (eoan-proposed/primary) [7906-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: base-files (bionic-proposed/main) [10.1ubuntu2.5 => 10.1ubuntu2.6] (core)
<infinity> sil2100: ^-- New base-files for the point release.
<sil2100> infinity: looking o/
<sil2100> (...once the debdiff appears)
<sil2100> ah screw it, I diff it myself
<cjwatson> It's generated now
<cjwatson> (I didn't do anything, just looked at logs)
<sil2100> cjwatson: yeah, it's just me being impatient, as always...
-queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (bionic-proposed) [10.1ubuntu2.6]
-queuebot:#ubuntu-release- New binary: libvpx [s390x] (eoan-proposed/main) [1.8.1-2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: libvpx [i386] (eoan-proposed/main) [1.8.1-2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: r-cran-jomo [s390x] (eoan-proposed/universe) [2.6-9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libvpx [amd64] (eoan-proposed/main) [1.8.1-2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: r-cran-jomo [i386] (eoan-proposed/universe) [2.6-9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libvpx [ppc64el] (eoan-proposed/main) [1.8.1-2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: r-cran-jomo [amd64] (eoan-proposed/universe) [2.6-9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnuastro [amd64] (eoan-proposed/universe) [0.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnuastro [i386] (eoan-proposed/universe) [0.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnuastro [s390x] (eoan-proposed/universe) [0.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-jomo [armhf] (eoan-proposed/universe) [2.6-9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-jomo [arm64] (eoan-proposed/universe) [2.6-9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libvpx [arm64] (eoan-proposed/main) [1.8.1-2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: libvpx [armhf] (eoan-proposed/main) [1.8.1-2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: gnuastro [arm64] (eoan-proposed/universe) [0.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnuastro [armhf] (eoan-proposed/universe) [0.10-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted partman-base [source] (disco-proposed) [206ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted partman-base [source] (bionic-proposed) [192ubuntu1.1]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [5.0.0-1013.13~18.04.2] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [5.0.0-1013.13~18.04.2]
-queuebot:#ubuntu-release- New binary: r-cran-jomo [ppc64el] (eoan-proposed/universe) [2.6-9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnuastro [ppc64el] (eoan-proposed/universe) [0.10-1] (no packageset)
<rbalint> LocutusOfBorg, sil2100: iptables is blocked in migration by libnftnl11 being in mail, while it was MIR-ed in the past: LP: #1545854
<ubot5> Launchpad bug 1545854 in mxml (Ubuntu) "[MIR] build dependency of iptables" [Undecided,Fix released] https://launchpad.net/bugs/1545854
<rbalint> (it will hold back my next systemd upload, too)
<rbalint> sil2100, could you please move libnftnl11 back to main?
<sil2100> rbalint: hm, so I don't know all the details regarding MIR AA handling, but it looks to me that it was in main around 2016 and a few months later again demoted to universe
<sil2100> rbalint: I don't know the reasons why it was demoted and I wouldn't want to act on it without consulting it with the MIR team first, especially that the last MIR analysis was done 3 years ago
<rbalint> sil2100, can we look up the demotion log somewhere?
<sil2100> (also, don't know the procedures of re-promoting a demoted package)
<sil2100> rbalint: I saw the demotion, but there was no message for it, I don't think there are any
<sil2100> rbalint: what I'd recommend is filling out another MIR with the rationale, pointing to the old MIR and poking e.g. cyphermox about it
<sil2100> Since I doubt a full review will be required
<sil2100> As said, I don't know the procedures, on the MIR page the only thing 'close' to our situation I found is: "If a new source package contains only code which is already in main (e.g., the result of a source package split or rename, or source packages with a version in the name), it may not need a full review. Submitting a bug with an explanation is sufficient."
<sil2100> Since this is similar, as the package already was in main, maybe we can just submit a bug with the explaination and then look for MIR team inut
<sil2100> *input
<rbalint> sil2100, ok, opening the bug
<rbalint> sil2100, cyphermox: LP: #1838989 i'm also pinging security team since iptables is their package
<ubot5> Launchpad bug 1838989 in libnftnl (Ubuntu) " [MIR] libnftnl: dependency of iptables " [Undecided,New] https://launchpad.net/bugs/1838989
<sil2100> rbalint: thanks!
<LocutusOfBorg> sil2100, I know why
<LocutusOfBorg> basically, there was an iptables package that was using nftnl
<LocutusOfBorg> that got moved to universe
<LocutusOfBorg> so, the package went in main/universe for some times
<LocutusOfBorg> "iptables-nftables-compat"
<LocutusOfBorg> this one ^^ with the archive reorg, packages in main could have subpackages in universe, and this was one of them, so the nftnl was not "required in main" anymore
<LocutusOfBorg> now that package is merged back to the main iptables
<LocutusOfBorg> so we need it again
-queuebot:#ubuntu-release- New: accepted gnuastro [amd64] (eoan-proposed) [0.10-1]
-queuebot:#ubuntu-release- New: accepted gnuastro [armhf] (eoan-proposed) [0.10-1]
-queuebot:#ubuntu-release- New: accepted gnuastro [ppc64el] (eoan-proposed) [0.10-1]
-queuebot:#ubuntu-release- New: accepted gnuastro [arm64] (eoan-proposed) [0.10-1]
-queuebot:#ubuntu-release- New: accepted gnuastro [s390x] (eoan-proposed) [0.10-1]
-queuebot:#ubuntu-release- New: accepted gnuastro [i386] (eoan-proposed) [0.10-1]
-queuebot:#ubuntu-release- New: accepted libvpx [amd64] (eoan-proposed) [1.8.1-2]
-queuebot:#ubuntu-release- New: accepted libvpx [armhf] (eoan-proposed) [1.8.1-2]
-queuebot:#ubuntu-release- New: accepted libvpx [ppc64el] (eoan-proposed) [1.8.1-2]
-queuebot:#ubuntu-release- New: accepted r-cran-jomo [amd64] (eoan-proposed) [2.6-9-1]
-queuebot:#ubuntu-release- New: accepted r-cran-jomo [armhf] (eoan-proposed) [2.6-9-1]
-queuebot:#ubuntu-release- New: accepted r-cran-jomo [ppc64el] (eoan-proposed) [2.6-9-1]
-queuebot:#ubuntu-release- New: accepted libvpx [arm64] (eoan-proposed) [1.8.1-2]
-queuebot:#ubuntu-release- New: accepted libvpx [s390x] (eoan-proposed) [1.8.1-2]
-queuebot:#ubuntu-release- New: accepted r-cran-jomo [i386] (eoan-proposed) [2.6-9-1]
-queuebot:#ubuntu-release- New: accepted libvpx [i386] (eoan-proposed) [1.8.1-2]
-queuebot:#ubuntu-release- New: accepted r-cran-jomo [s390x] (eoan-proposed) [2.6-9-1]
-queuebot:#ubuntu-release- New: accepted r-cran-jomo [arm64] (eoan-proposed) [2.6-9-1]
-queuebot:#ubuntu-release- New: accepted r-cran-jomo [amd64] (eoan-proposed) [2.6-8-1]
-queuebot:#ubuntu-release- New: accepted r-cran-jomo [armhf] (eoan-proposed) [2.6-8-1]
-queuebot:#ubuntu-release- New: accepted r-cran-jomo [s390x] (eoan-proposed) [2.6-8-1]
-queuebot:#ubuntu-release- New: accepted r-cran-jomo [arm64] (eoan-proposed) [2.6-8-1]
-queuebot:#ubuntu-release- New: accepted r-cran-jomo [i386] (eoan-proposed) [2.6-8-1]
-queuebot:#ubuntu-release- New binary: r-cran-mitml [amd64] (eoan-proposed/universe) [0.3-7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mshr [i386] (eoan-proposed/universe) [2019.1.0+dfsg1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syn [amd64] (eoan-proposed/universe) [0.15.42-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syn [s390x] (eoan-proposed/universe) [0.15.42-1] (no packageset)
-queuebot:#ubuntu-release- New binary: asymptote [s390x] (eoan-proposed/universe) [2.49-3] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syn [arm64] (eoan-proposed/universe) [0.15.42-1] (no packageset)
-queuebot:#ubuntu-release- New binary: atropos [amd64] (eoan-proposed/none) [1.1.21+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syn [armhf] (eoan-proposed/universe) [0.15.42-1] (no packageset)
-queuebot:#ubuntu-release- New binary: indicator-sensors [i386] (eoan-proposed/universe) [0.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-fst [amd64] (eoan-proposed/universe) [0.3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-dagre-d3-renderer [amd64] (eoan-proposed/universe) [0.5.8+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syn [i386] (eoan-proposed/universe) [0.15.42-1] (no packageset)
-queuebot:#ubuntu-release- New binary: indicator-sensors [amd64] (eoan-proposed/universe) [0.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kallisto [amd64] (eoan-proposed/universe) [0.45.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ucd-parse [amd64] (eoan-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tcmu [amd64] (eoan-proposed/universe) [1.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: indicator-sensors [s390x] (eoan-proposed/universe) [0.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ucd-parse [i386] (eoan-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-fst [i386] (eoan-proposed/universe) [0.3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kallisto [i386] (eoan-proposed/universe) [0.45.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-fst [s390x] (eoan-proposed/universe) [0.3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: labelme [s390x] (eoan-proposed/universe) [3.16.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-fst [armhf] (eoan-proposed/universe) [0.3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tcmu [i386] (eoan-proposed/universe) [1.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: asymptote [amd64] (eoan-proposed/universe) [2.49-3] (no packageset)
-queuebot:#ubuntu-release- New binary: kallisto [s390x] (eoan-proposed/universe) [0.45.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: labelme [armhf] (eoan-proposed/universe) [3.16.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-fst [arm64] (eoan-proposed/universe) [0.3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ucd-parse [s390x] (eoan-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: shapeit4 [s390x] (eoan-proposed/universe) [0.0.0+git20181214+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: asymptote [i386] (eoan-proposed/universe) [2.49-3] (no packageset)
-queuebot:#ubuntu-release- New binary: labelme [i386] (eoan-proposed/universe) [3.16.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: shapeit4 [i386] (eoan-proposed/universe) [0.0.0+git20181214+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: labelme [amd64] (eoan-proposed/universe) [3.16.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syn [ppc64el] (eoan-proposed/universe) [0.15.42-1] (no packageset)
-queuebot:#ubuntu-release- New binary: indicator-sensors [arm64] (eoan-proposed/universe) [0.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kallisto [arm64] (eoan-proposed/universe) [0.45.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: labelme [arm64] (eoan-proposed/universe) [3.16.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ucd-parse [armhf] (eoan-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tcmu [s390x] (eoan-proposed/universe) [1.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: indicator-sensors [armhf] (eoan-proposed/universe) [0.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ucd-parse [arm64] (eoan-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kallisto [armhf] (eoan-proposed/universe) [0.45.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: shapeit4 [armhf] (eoan-proposed/universe) [0.0.0+git20181214+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: asymptote [ppc64el] (eoan-proposed/universe) [2.49-3] (no packageset)
-queuebot:#ubuntu-release- New binary: shapeit4 [arm64] (eoan-proposed/universe) [0.0.0+git20181214+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tcmu [arm64] (eoan-proposed/universe) [1.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: atropos [arm64] (eoan-proposed/universe) [1.1.21+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tcmu [armhf] (eoan-proposed/universe) [1.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: skesa [i386] (eoan-proposed/universe) [2.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gmsh [s390x] (eoan-proposed/universe) [4.4.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: shapeit4 [amd64] (eoan-proposed/universe) [0.0.0+git20181214+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gmsh [amd64] (eoan-proposed/universe) [4.4.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: atropos [ppc64el] (eoan-proposed/universe) [1.1.21+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gmsh [ppc64el] (eoan-proposed/universe) [4.4.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kallisto [ppc64el] (eoan-proposed/universe) [0.45.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gmsh [i386] (eoan-proposed/universe) [4.4.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: indicator-sensors [ppc64el] (eoan-proposed/universe) [0.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: labelme [ppc64el] (eoan-proposed/universe) [3.16.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-fst [ppc64el] (eoan-proposed/universe) [0.3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ucd-parse [ppc64el] (eoan-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: shapeit4 [ppc64el] (eoan-proposed/universe) [0.0.0+git20181214+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mshr [amd64] (eoan-proposed/universe) [2019.1.0+dfsg1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: mshr [armhf] (eoan-proposed/universe) [2019.1.0+dfsg1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: skesa [amd64] (eoan-proposed/universe) [2.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: asymptote [arm64] (eoan-proposed/universe) [2.49-3] (no packageset)
-queuebot:#ubuntu-release- New binary: asymptote [armhf] (eoan-proposed/universe) [2.49-3] (no packageset)
-queuebot:#ubuntu-release- New binary: gmsh [arm64] (eoan-proposed/universe) [4.4.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gmsh [armhf] (eoan-proposed/universe) [4.4.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Bionic 18.04.3] (20101020ubuntu543.10) has been added
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Bionic 18.04.3] (20101020ubuntu543.10) has been added
-queuebot:#ubuntu-release- Builds: Netboot armhf [Bionic 18.04.3] (20101020ubuntu543.10) has been added
-queuebot:#ubuntu-release- Builds: Netboot i386 [Bionic 18.04.3] (20101020ubuntu543.10) has been added
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Bionic 18.04.3] (20101020ubuntu543.10) has been added
-queuebot:#ubuntu-release- Builds: Netboot s390x [Bionic 18.04.3] (20101020ubuntu543.10) has been added
-queuebot:#ubuntu-release- New: accepted asymptote [amd64] (eoan-proposed) [2.49-3]
-queuebot:#ubuntu-release- New: accepted asymptote [armhf] (eoan-proposed) [2.49-3]
-queuebot:#ubuntu-release- New: accepted asymptote [ppc64el] (eoan-proposed) [2.49-3]
-queuebot:#ubuntu-release- New: accepted gmsh [amd64] (eoan-proposed) [4.4.1+ds1-1]
-queuebot:#ubuntu-release- New: accepted gmsh [armhf] (eoan-proposed) [4.4.1+ds1-1]
-queuebot:#ubuntu-release- New: accepted gmsh [ppc64el] (eoan-proposed) [4.4.1+ds1-1]
-queuebot:#ubuntu-release- New: accepted indicator-sensors [amd64] (eoan-proposed) [0.9-1]
-queuebot:#ubuntu-release- New: accepted indicator-sensors [armhf] (eoan-proposed) [0.9-1]
-queuebot:#ubuntu-release- New: accepted indicator-sensors [ppc64el] (eoan-proposed) [0.9-1]
-queuebot:#ubuntu-release- New: accepted kallisto [amd64] (eoan-proposed) [0.45.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted asymptote [arm64] (eoan-proposed) [2.49-3]
-queuebot:#ubuntu-release- New: accepted asymptote [s390x] (eoan-proposed) [2.49-3]
-queuebot:#ubuntu-release- New: accepted gmsh [i386] (eoan-proposed) [4.4.1+ds1-1]
-queuebot:#ubuntu-release- New: accepted indicator-sensors [arm64] (eoan-proposed) [0.9-1]
-queuebot:#ubuntu-release- New: accepted indicator-sensors [s390x] (eoan-proposed) [0.9-1]
-queuebot:#ubuntu-release- New: accepted kallisto [armhf] (eoan-proposed) [0.45.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted kallisto [ppc64el] (eoan-proposed) [0.45.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted labelme [amd64] (eoan-proposed) [3.16.1-1]
-queuebot:#ubuntu-release- New: accepted labelme [armhf] (eoan-proposed) [3.16.1-1]
-queuebot:#ubuntu-release- New: accepted labelme [ppc64el] (eoan-proposed) [3.16.1-1]
-queuebot:#ubuntu-release- New: accepted asymptote [i386] (eoan-proposed) [2.49-3]
-queuebot:#ubuntu-release- New: accepted gmsh [s390x] (eoan-proposed) [4.4.1+ds1-1]
-queuebot:#ubuntu-release- New: accepted kallisto [arm64] (eoan-proposed) [0.45.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted kallisto [s390x] (eoan-proposed) [0.45.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted labelme [i386] (eoan-proposed) [3.16.1-1]
-queuebot:#ubuntu-release- New binary: biobambam2 [amd64] (eoan-proposed/universe) [2.0.95-1] (no packageset)
-queuebot:#ubuntu-release- New binary: biobambam2 [armhf] (eoan-proposed/universe) [2.0.95-1] (no packageset)
-queuebot:#ubuntu-release- New binary: biobambam2 [ppc64el] (eoan-proposed/universe) [2.0.95-1] (no packageset)
-queuebot:#ubuntu-release- New source: ibus-avro (eoan-proposed/primary) [1.1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: ocaml-dune [s390x] (eoan-proposed/universe) [1.6.2-4build1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gmsh [arm64] (eoan-proposed) [4.4.1+ds1-1]
-queuebot:#ubuntu-release- New: accepted kallisto [i386] (eoan-proposed) [0.45.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted labelme [s390x] (eoan-proposed) [3.16.1-1]
-queuebot:#ubuntu-release- New binary: biobambam2 [i386] (eoan-proposed/universe) [2.0.95-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-dune [i386] (eoan-proposed/universe) [1.6.2-4build1] (no packageset)
-queuebot:#ubuntu-release- New: accepted indicator-sensors [i386] (eoan-proposed) [0.9-1]
-queuebot:#ubuntu-release- New binary: biobambam2 [arm64] (eoan-proposed/universe) [2.0.95-1] (no packageset)
-queuebot:#ubuntu-release- New source: xfce4-panel-profiles (eoan-proposed/primary) [1.0.9-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted r-cran-mitml [amd64] (eoan-proposed) [0.3-7-1]
-queuebot:#ubuntu-release- New: accepted rust-fst [arm64] (eoan-proposed) [0.3.5-1]
-queuebot:#ubuntu-release- New: accepted rust-fst [i386] (eoan-proposed) [0.3.5-1]
-queuebot:#ubuntu-release- New: accepted rust-fst [s390x] (eoan-proposed) [0.3.5-1]
-queuebot:#ubuntu-release- New: accepted rust-syn [arm64] (eoan-proposed) [0.15.42-1]
-queuebot:#ubuntu-release- New: accepted rust-syn [i386] (eoan-proposed) [0.15.42-1]
-queuebot:#ubuntu-release- New: accepted rust-syn [s390x] (eoan-proposed) [0.15.42-1]
-queuebot:#ubuntu-release- New: accepted labelme [arm64] (eoan-proposed) [3.16.1-1]
-queuebot:#ubuntu-release- New: accepted node-dagre-d3-renderer [amd64] (eoan-proposed) [0.5.8+dfsg-2]
-queuebot:#ubuntu-release- New: accepted rust-fst [armhf] (eoan-proposed) [0.3.5-1]
-queuebot:#ubuntu-release- New: accepted rust-syn [amd64] (eoan-proposed) [0.15.42-1]
-queuebot:#ubuntu-release- New: accepted rust-syn [ppc64el] (eoan-proposed) [0.15.42-1]
-queuebot:#ubuntu-release- New: accepted rust-ucd-parse [arm64] (eoan-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted rust-ucd-parse [i386] (eoan-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted rust-ucd-parse [s390x] (eoan-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted shapeit4 [arm64] (eoan-proposed) [0.0.0+git20181214+dfsg-1]
-queuebot:#ubuntu-release- New: accepted shapeit4 [i386] (eoan-proposed) [0.0.0+git20181214+dfsg-1]
-queuebot:#ubuntu-release- New binary: haskell-microspec [amd64] (eoan-proposed/universe) [0.2.1.3-1build1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-fst [ppc64el] (eoan-proposed) [0.3.5-1]
-queuebot:#ubuntu-release- New: accepted rust-ucd-parse [amd64] (eoan-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted rust-ucd-parse [ppc64el] (eoan-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted shapeit4 [armhf] (eoan-proposed) [0.0.0+git20181214+dfsg-1]
-queuebot:#ubuntu-release- New: accepted shapeit4 [s390x] (eoan-proposed) [0.0.0+git20181214+dfsg-1]
-queuebot:#ubuntu-release- New: accepted rust-fst [amd64] (eoan-proposed) [0.3.5-1]
-queuebot:#ubuntu-release- New: accepted rust-ucd-parse [armhf] (eoan-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted shapeit4 [ppc64el] (eoan-proposed) [0.0.0+git20181214+dfsg-1]
-queuebot:#ubuntu-release- New: accepted rust-syn [armhf] (eoan-proposed) [0.15.42-1]
-queuebot:#ubuntu-release- New: accepted shapeit4 [amd64] (eoan-proposed) [0.0.0+git20181214+dfsg-1]
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Bionic 18.04.3] has been updated (20190805)
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Bionic 18.04.3] has been updated (20190805)
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Bionic 18.04.3] has been updated (20190805)
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Bionic 18.04.3] has been updated (20190805)
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Bionic 18.04.3] has been updated (20190805)
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Bionic 18.04.3] has been updated (20190805)
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Bionic 18.04.3] has been updated (20190805)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Bionic 18.04.3] has been updated (20190805)
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Bionic 18.04.3] has been updated (20190805)
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Bionic 18.04.3] has been updated (20190805)
-queuebot:#ubuntu-release- New binary: r-cran-mice [s390x] (eoan-proposed/universe) [3.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-mice [amd64] (eoan-proposed/universe) [3.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-mice [ppc64el] (eoan-proposed/universe) [3.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-mice [i386] (eoan-proposed/universe) [3.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-mice [arm64] (eoan-proposed/universe) [3.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-mice [armhf] (eoan-proposed/universe) [3.6.0-1] (no packageset)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Bionic 18.04.3] has been updated (20190805)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi3 [Bionic 18.04.3] has been updated (20190805)
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Bionic 18.04.3] has been updated (20190805)
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi3 [Bionic 18.04.3] has been updated (20190805)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Bionic 18.04.3] has been updated (20190805)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Bionic 18.04.3] has been updated (20190805)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Bionic 18.04.3] has been updated (20190805)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Bionic 18.04.3] has been updated (20190805)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Bionic 18.04.3] has been updated (20190805)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Bionic 18.04.3] has been updated (20190805)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Bionic 18.04.3] has been updated (20190805)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Bionic 18.04.3] has been updated (20190805)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Bionic 18.04.3] has been updated (20190805)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Bionic 18.04.3] has been updated (20190805)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Bionic 18.04.3] has been updated (20190805)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Bionic 18.04.3] has been updated (20190805)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Bionic 18.04.3] has been updated (20190805)
<Ukikie> With regards to xfce4-panel-profiles sitting in NEW, it's not as much a "new" package as one that's been renamed and moved from Launchpad to Xfce upstream.
<Ukikie> It replaces xfpanel-switch.
#ubuntu-release 2019-08-06
-queuebot:#ubuntu-release- New binary: llvm-toolchain-8 [s390x] (eoan-proposed/main) [1:8.0.1-1] (core)
-queuebot:#ubuntu-release- New: accepted atropos [ppc64el] (eoan-proposed) [1.1.21+dfsg-1]
-queuebot:#ubuntu-release- New: accepted mshr [amd64] (eoan-proposed) [2019.1.0+dfsg1-3]
-queuebot:#ubuntu-release- New: accepted r-cran-mice [amd64] (eoan-proposed) [3.6.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-mice [armhf] (eoan-proposed) [3.6.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-mice [ppc64el] (eoan-proposed) [3.6.0-1]
-queuebot:#ubuntu-release- New: accepted skesa [amd64] (eoan-proposed) [2.3.0-1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-8 [s390x] (eoan-proposed) [1:8.0.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-mice [arm64] (eoan-proposed) [3.6.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-mice [s390x] (eoan-proposed) [3.6.0-1]
-queuebot:#ubuntu-release- New: accepted mshr [armhf] (eoan-proposed) [2019.1.0+dfsg1-3]
-queuebot:#ubuntu-release- New: accepted r-cran-mice [i386] (eoan-proposed) [3.6.0-1]
-queuebot:#ubuntu-release- New: accepted atropos [amd64] (eoan-proposed) [1.1.21+dfsg-1]
-queuebot:#ubuntu-release- New: accepted mshr [i386] (eoan-proposed) [2019.1.0+dfsg1-3]
-queuebot:#ubuntu-release- New: accepted tcmu [amd64] (eoan-proposed) [1.4.0-1]
-queuebot:#ubuntu-release- New: accepted tcmu [armhf] (eoan-proposed) [1.4.0-1]
-queuebot:#ubuntu-release- New: accepted tcmu [s390x] (eoan-proposed) [1.4.0-1]
-queuebot:#ubuntu-release- New: accepted atropos [arm64] (eoan-proposed) [1.1.21+dfsg-1]
-queuebot:#ubuntu-release- New: accepted tcmu [arm64] (eoan-proposed) [1.4.0-1]
-queuebot:#ubuntu-release- New: accepted skesa [i386] (eoan-proposed) [2.3.0-1]
-queuebot:#ubuntu-release- New: accepted tcmu [i386] (eoan-proposed) [1.4.0-1]
-queuebot:#ubuntu-release- New: accepted biobambam2 [amd64] (eoan-proposed) [2.0.95-1]
-queuebot:#ubuntu-release- New: accepted biobambam2 [armhf] (eoan-proposed) [2.0.95-1]
-queuebot:#ubuntu-release- New: accepted biobambam2 [ppc64el] (eoan-proposed) [2.0.95-1]
-queuebot:#ubuntu-release- New: accepted biobambam2 [arm64] (eoan-proposed) [2.0.95-1]
-queuebot:#ubuntu-release- New: accepted biobambam2 [i386] (eoan-proposed) [2.0.95-1]
-queuebot:#ubuntu-release- New binary: llvm-toolchain-8 [amd64] (eoan-proposed/main) [1:8.0.1-1] (core)
-queuebot:#ubuntu-release- New binary: llvm-toolchain-8 [ppc64el] (eoan-proposed/main) [1:8.0.1-1] (core)
-queuebot:#ubuntu-release- New binary: llvm-toolchain-8 [i386] (eoan-proposed/main) [1:8.0.1-1] (core)
-queuebot:#ubuntu-release- Unapproved: qemu (bionic-proposed/main) [1:2.11+dfsg-1ubuntu7.16 => 1:2.11+dfsg-1ubuntu7.17] (ubuntu-server, virt)
<cpaelzer> rbasak: (or other SRU people) there was a minor fixup needed for the bug 1828495 SRU which is now provided
<ubot5> bug 1828495 in linux (Ubuntu Eoan) "[KVM][CLX] CPUID_7_0_EDX_ARCH_CAPABILITIES is not enabled in VM." [Wishlist,In progress] https://launchpad.net/bugs/1828495
<cpaelzer> if one could check and accept that over what is in -proposed now that would be great
<cpaelzer> the new upload is qemu 1:2.11+dfsg-1ubuntu7.17
-queuebot:#ubuntu-release- New binary: llvm-toolchain-8 [armhf] (eoan-proposed/main) [1:8.0.1-1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (bionic-proposed) [1:2.11+dfsg-1ubuntu7.17]
<rbasak> cpaelzer: done ^
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-8 [amd64] (eoan-proposed) [1:8.0.1-1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-8 [armhf] (eoan-proposed) [1:8.0.1-1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-8 [i386] (eoan-proposed) [1:8.0.1-1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-8 [ppc64el] (eoan-proposed) [1:8.0.1-1]
-queuebot:#ubuntu-release- New binary: double-conversion [amd64] (eoan-proposed/universe) [3.1.5-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: double-conversion [i386] (eoan-proposed/universe) [3.1.5-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: double-conversion [ppc64el] (eoan-proposed/universe) [3.1.5-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: double-conversion [s390x] (eoan-proposed/universe) [3.1.5-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: double-conversion [arm64] (eoan-proposed/universe) [3.1.5-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: double-conversion [armhf] (eoan-proposed/universe) [3.1.5-2] (kubuntu)
-queuebot:#ubuntu-release- New: accepted zsys [source] (eoan-proposed) [0.1]
-queuebot:#ubuntu-release- New binary: zsys [s390x] (eoan-proposed/none) [0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: zsys [amd64] (eoan-proposed/none) [0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: zsys [i386] (eoan-proposed/none) [0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: zsys [ppc64el] (eoan-proposed/none) [0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: zsys [arm64] (eoan-proposed/none) [0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: zsys [armhf] (eoan-proposed/universe) [0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: nut [s390x] (eoan-proposed/main) [2.7.4-9ubuntu1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: nut [i386] (eoan-proposed/main) [2.7.4-9ubuntu1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: nut [amd64] (eoan-proposed/main) [2.7.4-9ubuntu1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: nut [ppc64el] (eoan-proposed/main) [2.7.4-9ubuntu1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: nut [arm64] (eoan-proposed/main) [2.7.4-9ubuntu1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: nut [armhf] (eoan-proposed/main) [2.7.4-9ubuntu1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted zsys [amd64] (eoan-proposed) [0.1]
-queuebot:#ubuntu-release- New: accepted zsys [armhf] (eoan-proposed) [0.1]
-queuebot:#ubuntu-release- New: accepted zsys [ppc64el] (eoan-proposed) [0.1]
-queuebot:#ubuntu-release- New: accepted zsys [arm64] (eoan-proposed) [0.1]
-queuebot:#ubuntu-release- New: accepted zsys [s390x] (eoan-proposed) [0.1]
-queuebot:#ubuntu-release- New: accepted zsys [i386] (eoan-proposed) [0.1]
<coreycb> bdmurray: hi, would you be able to take a look at releasing nova to bionic-updates? we have security fixes coming out today so we'll either need to get that released or rebase what's in proposed if it's not ready.
<bdmurray> coreycb: does in the next hour work for you?
<coreycb> bdmurray: yes, thank you
-queuebot:#ubuntu-release- New binary: pristine-lfs [armhf] (eoan-proposed/none) [20190626.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pristine-lfs [amd64] (eoan-proposed/none) [20190626.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pristine-lfs [i386] (eoan-proposed/none) [20190626.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pristine-lfs [arm64] (eoan-proposed/none) [20190626.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pristine-lfs [s390x] (eoan-proposed/none) [20190626.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bstr [armhf] (eoan-proposed/none) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bstr [arm64] (eoan-proposed/none) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bstr [i386] (eoan-proposed/none) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bstr [amd64] (eoan-proposed/none) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bstr [s390x] (eoan-proposed/none) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted pristine-lfs [amd64] (eoan-proposed) [20190626.0-1]
-queuebot:#ubuntu-release- New: accepted pristine-lfs [i386] (eoan-proposed) [20190626.0-1]
-queuebot:#ubuntu-release- New: accepted rust-bstr [amd64] (eoan-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted rust-bstr [armhf] (eoan-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted rust-bstr [s390x] (eoan-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted pristine-lfs [arm64] (eoan-proposed) [20190626.0-1]
-queuebot:#ubuntu-release- New: accepted rust-bstr [arm64] (eoan-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted pristine-lfs [s390x] (eoan-proposed) [20190626.0-1]
-queuebot:#ubuntu-release- New: accepted rust-bstr [i386] (eoan-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted double-conversion [amd64] (eoan-proposed) [3.1.5-2]
-queuebot:#ubuntu-release- New: accepted double-conversion [armhf] (eoan-proposed) [3.1.5-2]
-queuebot:#ubuntu-release- New: accepted double-conversion [ppc64el] (eoan-proposed) [3.1.5-2]
-queuebot:#ubuntu-release- New: accepted pristine-lfs [armhf] (eoan-proposed) [20190626.0-1]
-queuebot:#ubuntu-release- New: accepted double-conversion [arm64] (eoan-proposed) [3.1.5-2]
-queuebot:#ubuntu-release- New: accepted double-conversion [s390x] (eoan-proposed) [3.1.5-2]
-queuebot:#ubuntu-release- New: accepted double-conversion [i386] (eoan-proposed) [3.1.5-2]
<bdmurray> coreycb: bug 1830341 isn't verified for nova yet afaict.
<ubot5> bug 1830341 in nova (Ubuntu Bionic) "[SRU] queens stable releases" [High,Fix committed] https://launchpad.net/bugs/1830341
<coreycb> bdmurray: let me update that, i just ran regression tests
<coreycb> bdmurray: we still need to do manual verification testing of horizon for that 1830341 but the rest of the packages are tested and ready to release
<coreycb> bdmurray: dosaboy is testing nova 2:19.0.1-0ubuntu2 in disco-proposed over the next few hours so i think we'll try to release that with the security update too
<bdmurray> coreycb: okay
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [5.0.0-1014.14~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-57.63] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp-edge [amd64] (bionic-proposed/main) [5.0.0-1013.13~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1018.20] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-gke-4.15 [amd64] (bionic-proposed/main) [4.15.0-1039.41] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-57.63] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (bionic-proposed/main) [5.0.0-25.26~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (disco-proposed/main) [5.0.0-25.26] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (bionic-proposed/main) [4.15.0-1020.22] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gke-5.0 [amd64] (bionic-proposed/universe) [5.0.0-1013.13~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (disco-proposed/main) [5.0.0-1014.14] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (disco-proposed/main) [5.0.0-25.26] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-57.63~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (bionic-proposed/main) [5.0.0-25.26~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1054.59] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (disco-proposed/main) [5.0.0-1013.13] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [5.0.0-1014.14~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-57.63]
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1049.56] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-57.63~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-159.187] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-57.63]
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (disco-proposed/main) [5.0.0-25.26] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [arm64] (bionic-proposed/main) [5.0.0-25.26~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (xenial-proposed/main) [4.15.0-1020.22~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp-edge [amd64] (bionic-proposed) [5.0.0-1013.13~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.0 [amd64] (bionic-proposed) [5.0.0-1013.13~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [arm64] (bionic-proposed) [5.0.0-25.26~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1018.20]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1020.22]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (disco-proposed) [5.0.0-25.26]
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-4.15 [amd64] (bionic-proposed) [4.15.0-1039.41]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (bionic-proposed) [5.0.0-25.26~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (disco-proposed) [5.0.0-25.26]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (bionic-proposed) [5.0.0-25.26~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (disco-proposed) [5.0.0-25.26]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1049.56]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (disco-proposed) [5.0.0-1014.14]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1054.59]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (disco-proposed) [5.0.0-1013.13]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-159.187]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-57.63~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (xenial-proposed) [4.15.0-1020.22~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-57.63~16.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1039.41~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1039.41~16.04.1]
<enyc> LocutusOfBorg: fwiw, on further investigation  r.e. virtualbox-ext-pack  upgrade, I'm getting impression a local network issue / http-redirect  etc.  caused the ext-pack download checksum to fail  ...
<enyc> LocutusOfBorg: does raise the question if the ext-pack shouldnormalyl be loaded over  https  so ssl-verified connection etc...
<Ukikie> The SHA1 sum in the postinst is more trustworthy than relying on CAs.
-queuebot:#ubuntu-release- Unapproved: grub2 (eoan-proposed/main) [2.04-1ubuntu4 => 2.04-1ubuntu4] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (eoan-proposed/main) [2.04-1ubuntu4 => 2.04-1ubuntu4] (core)
<RAOF> Hm. Is there any reason not to release bug# 1444656 to Trusty? It seems like it should be a valid candidate, but it's been sitting there for ages (I've only just noticed it)
#ubuntu-release 2019-08-07
<vorlon> RAOF: mainly that trusty is out of standard support and it's unclear what it should mean to release an SRU at this point, particularly as this one was for a security update
<vorlon> oops, clicked the wrong version, is not a security update but uploaded by a security person
<RAOF> Heh, yeah. Didn't seem to be a security update, but a failure-to-connect bug.
<RAOF> The âare we releasing SRUs to no-longer-supported-Trustyâ question still applies.
<RAOF> Raising the related point: why is Trusty still in the report?
<vorlon> because we haven't decided yet what to do with those three SRUs ;)
<vorlon> well also, there's an ubuntu-advantage-tools SRU still coming
<vorlon> so yeah
<RAOF> Fair
<bluesabre> Can xfce4-panel-profiles be released into eoan? It replaces xfpanel-switch as the upstream moved to the Xfce project. :)
-queuebot:#ubuntu-release- New: rejected petsc [amd64] (eoan-proposed) [3.11.3+dfsg1-1~build1]
-queuebot:#ubuntu-release- New: rejected petsc [armhf] (eoan-proposed) [3.11.3+dfsg1-1~build1]
-queuebot:#ubuntu-release- New: rejected petsc [ppc64el] (eoan-proposed) [3.11.3+dfsg1-1~build1]
-queuebot:#ubuntu-release- New: rejected petsc [arm64] (eoan-proposed) [3.11.3+dfsg1-1~build1]
-queuebot:#ubuntu-release- New: rejected petsc [s390x] (eoan-proposed) [3.11.3+dfsg1-1~build1]
-queuebot:#ubuntu-release- New: rejected petsc [i386] (eoan-proposed) [3.11.3+dfsg1-1~build1]
-queuebot:#ubuntu-release- New: accepted haskell-raw-strings-qq [amd64] (eoan-proposed) [1.1-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-microspec [amd64] (eoan-proposed) [0.2.1.3-1build1]
-queuebot:#ubuntu-release- New: accepted xfce4-panel-profiles [source] (eoan-proposed) [1.0.9-0ubuntu1]
-queuebot:#ubuntu-release- New binary: xfce4-panel-profiles [amd64] (eoan-proposed/none) [1.0.9-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ocaml-dune [amd64] (eoan-proposed) [1.6.2-4build1]
-queuebot:#ubuntu-release- New: accepted ocaml-dune [armhf] (eoan-proposed) [1.6.2-4build1]
-queuebot:#ubuntu-release- New: accepted ocaml-dune [ppc64el] (eoan-proposed) [1.6.2-4build1]
-queuebot:#ubuntu-release- New: accepted ocaml-dune [arm64] (eoan-proposed) [1.6.2-4build1]
-queuebot:#ubuntu-release- New: accepted ocaml-dune [s390x] (eoan-proposed) [1.6.2-4build1]
-queuebot:#ubuntu-release- New: accepted ocaml-dune [i386] (eoan-proposed) [1.6.2-4build1]
-queuebot:#ubuntu-release- New: accepted xfce4-panel-profiles [amd64] (eoan-proposed) [1.0.9-0ubuntu1]
<bluesabre> thanks!
-queuebot:#ubuntu-release- New binary: golang-github-gin-contrib-cors [amd64] (eoan-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-yourbasic-graph [amd64] (eoan-proposed/universe) [1.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-gin-contrib-static [amd64] (eoan-proposed/universe) [0.0~git20190511.c1cdf9c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: moonshot-trust-router [s390x] (eoan-proposed/universe) [3.5.0+1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcds [amd64] (eoan-proposed/universe) [2.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: moonshot-trust-router [i386] (eoan-proposed/universe) [3.5.0+1] (no packageset)
-queuebot:#ubuntu-release- New binary: moonshot-trust-router [amd64] (eoan-proposed/universe) [3.5.0+1] (no packageset)
-queuebot:#ubuntu-release- New binary: moonshot-trust-router [ppc64el] (eoan-proposed/universe) [3.5.0+1] (no packageset)
-queuebot:#ubuntu-release- New binary: moonshot-trust-router [armhf] (eoan-proposed/universe) [3.5.0+1] (no packageset)
-queuebot:#ubuntu-release- New binary: moonshot-trust-router [arm64] (eoan-proposed/universe) [3.5.0+1] (no packageset)
<LocutusOfBorg> hello, can you please promote golang-1.12 and demote golang-1.11?
<LocutusOfBorg> I don't remember how to know what to rebuild, because reverse-deps fails to spot them
-queuebot:#ubuntu-release- New: accepted golang-github-gin-contrib-cors [amd64] (eoan-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-yourbasic-graph [amd64] (eoan-proposed) [1.0.5-1]
-queuebot:#ubuntu-release- New: accepted moonshot-trust-router [amd64] (eoan-proposed) [3.5.0+1]
-queuebot:#ubuntu-release- New: accepted moonshot-trust-router [armhf] (eoan-proposed) [3.5.0+1]
-queuebot:#ubuntu-release- New: accepted moonshot-trust-router [ppc64el] (eoan-proposed) [3.5.0+1]
-queuebot:#ubuntu-release- New: accepted golang-github-gin-contrib-static [amd64] (eoan-proposed) [0.0~git20190511.c1cdf9c-1]
-queuebot:#ubuntu-release- New: accepted moonshot-trust-router [arm64] (eoan-proposed) [3.5.0+1]
-queuebot:#ubuntu-release- New: accepted moonshot-trust-router [s390x] (eoan-proposed) [3.5.0+1]
-queuebot:#ubuntu-release- New: accepted libcds [amd64] (eoan-proposed) [2.3.3-1]
-queuebot:#ubuntu-release- New: accepted moonshot-trust-router [i386] (eoan-proposed) [3.5.0+1]
<sil2100> tjaalton: hey, I see multiple people reporting LP: #1838698 for .3 - do you know anything about it? Could you take a look?
<ubot5> Launchpad bug 1838698 in xserver-xorg-video-intel-hwe-18.04 (Ubuntu) "Cannot boot ISO unless using nomodeset" [Undecided,New] https://launchpad.net/bugs/1838698
<tjaalton> sil2100: if nomodeset doesn't work then it's something worse
<tjaalton> where are the other bugs?
-queuebot:#ubuntu-release- Unapproved: cinder (disco-proposed/main) [2:14.0.1-0ubuntu1 => 2:14.0.1-0ubuntu2] (openstack, ubuntu-server)
<infinity> tjaalton: It's people dogpiling on the same bug in the ISO tracker.
<infinity> tjaalton: And I see no indication that nomodeset doesn't work.  Just that it didn't used to be necessary.
<tjaalton> infinity: booting after installation resulted in the corrupted screen
<tjaalton> with nomodeset
<infinity> tjaalton: Oh, huh, I missed comment 4.  Or misread it.  Fun.
<tjaalton> and I was able to boot a 32bit 5.0.0-23 on a thinkpad t470s just fine yesterday
<tjaalton> the cpu in this case is a celeron (braswell) though
<infinity> Well, it's also weird that he could boot the ISO with nomodeset, complete the install, but on reboot it wouldn't work?
<infinity> Should be the same kernel and X.
<infinity> So, WTF.
<tjaalton> yes
<tjaalton> fossfreedom: remove nomodeset from cmdline, it got added by the installer
<tjaalton> to the installed system
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (eoan-proposed) [2.04-1ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (eoan-proposed) [2.04-1ubuntu4]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-58.64] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-58.64] (core, kernel)
<fossfreedom> tjaalton: thought I did ... but repeating the full disk install again anyway.  cheers
<tjaalton> fossfreedom: you don't need to reinstall
<fossfreedom> I've wiped it in the mean-time - was testing 19.10 stuff on this thing
<tjaalton> ok
<coreycb> rbasak: hi, if you have a chance nova should be ready to release to disco-updates
<rbasak> coreycb: what's the status in Eoan please? Not Fix Released yet?
<coreycb> rbasak: sorry swapped to a mtg. will check shortly.
<patriciadomin> hello. do we have the netboot image for testing 18.04.3?
<patriciadomin> the link here is broken for - netboot/arm64 : http://iso.qa.ubuntu.com/qatracker/milestones/405/builds/197384/downloads
<infinity> patriciadomin: Change "bionic" to "bionic-updates" in that URL.
<infinity> I'd fix the tracker, but I'm heading to bed.
<sil2100> infinity: I'll fix it
<sil2100> infinity: go rest!
<sil2100> ;)
<patriciadomin> infinity: thanks good night, but there's no bionic in the URL
<infinity> patriciadomin: In the URL on the page you linked.
<infinity> ...dists/bionic/main...
<sil2100> patriciadomin: http://ports.ubuntu.com/ubuntu-ports/dists/bionic-updates/main/installer-arm64/20101020ubuntu543.10/images/netboot/mini.iso
<patriciadomin> hah! many thanks infinity sil2100 o/
<fossfreedom> tjaalton: unfortunately all the logs written are zero bytes in length. So nothing meaningful to show :/
<sil2100> I'll check if the others don't need fixing as well
<sil2100> patriciadomin: should be fixed if anything: http://iso.qa.ubuntu.com/qatracker/milestones/405/builds/197384/downloads
 * sil2100 fixes all other netboot urls
<patriciadomin> sil2100: thanks
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Bionic 18.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Bionic 18.04.3] has been marked as ready
<tjaalton> fossfreedom: boot with drm.debug=14 and check kern.log? surely it has something on it from that boot?
<tjaalton> unless it hangs before it has a chance of writing things on the disk
<tjaalton> fossfreedom: one thing you could try is blacklist i915.ko, update-initramfs -k all -u, reboot
<tjaalton> then ssh in, stop lightdm/gdm, modprobe i915
<tjaalton> see what happens
<coreycb> rbasak: sorry for the delay. that fix is fix committed for eoan.
<coreycb> rbasak: i recognize we have eoan-proposed migration issues with openstack packages. was focusing on that but got switched to other things this week.
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Bionic 18.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Bionic 18.04.3] has been marked as ready
<sil2100> Oh, hm, we don't have jibel around this week
<sil2100> willcooke: hey! Since jibel is out, do you think we could have someone else from the desktop team doing some iso-testing? Do we have any additional QA people with hardware and some cycles?
<willcooke> sil2100, I can do that in a bit, thanks for the ping
<sil2100> willcooke: huge thanks! Since I will be picking up some other isos, but I basically can only test on kvm right now
<sil2100> infinity: ^
<sil2100> At least some additional sanity testing on real hardware would be enough - I see one tester already ran some successful tests
<rbasak> coreycb: sorry for the delay, I was otp!
<juliank> PSA: DO NOT run autopkgtests with all-proposed on i386 - they will fail
<rbasak> coreycb: has there been any verification that nova still generally works - eg. regular QA tests run?
<rbasak> The bug doesn't mention that, only checking the specific failure case being fixed.
<coreycb> rbasak: yes there has, i ran regression 2 days ago. let me post results to the bug
<coreycb> rbasak: ok i've added those details
<rbasak> Thanks! Looking.
<rbasak> coreycb: OK, released, thanks. I am assuming that the version you tested in that test was definitely 2:19.0.1-0ubuntu2 :)
<coreycb> rbasak: of course it was :)  thank you!
<juliank> ahasenack, LocutusOfBor, vorlon I deleted your autopkgtest reruns for i386 eoan with all-proposed from the queue
<juliank> LocutusOfBorg: ^
<juliank> There currently is a problem with systemd-resolved not starting with all-proposed, and the autopkgtests running in endless failure loops
<juliank> This seems to be a problem with the new gnutls28 requiring write and executable permissions
<juliank> /lib/systemd/systemd-resolved: error while loading shared libraries: /lib/i386-linux-gnu/libgnutls.so.30: cannot make segment writable for relocation:
<juliank> which it can't because systemd-resolved runs with MemoryDenyWriteExecute=yes
 * juliank apologizes for the inconvenience
<juliank> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1839354
<ubot5> Ubuntu bug 1839354 in systemd (Ubuntu) "gnutls28 requires write and executable bits" [Undecided,New]
<juliank> Full list of deleted tests: https://paste.ubuntu.com/p/N7kr6X6P9Q/
<juliank> oh I should delete the gnutls28 triggered ones
<juliank> vorlon: There is a tmux that runs a watch that removes any more tests triggered by gnutls28 on i386, need to stop that at some point
<juliank> it runs on the cloud worker
<juliank> hopefully the queue size gets down now
<juliank> for some weird reason they were all triggered with  3.6.9-2, despite  3.6.9-3 being in proposed
-queuebot:#ubuntu-release- Unapproved: samba (disco-proposed/main) [2:4.10.0+dfsg-0ubuntu2.2 => 2:4.10.0+dfsg-0ubuntu2.3] (core)
#ubuntu-release 2019-08-08
<vorlon> fixed gnutls28 is in -proposed.  command that was periodically deleting new gnutls28-triggered tests, stopped.  previously cancelled --all-proposed tests retriggered, approximately
-queuebot:#ubuntu-release- New binary: libgclib [amd64] (eoan-proposed/universe) [0.11.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libgclib [s390x] (eoan-proposed/universe) [0.11.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libgclib [ppc64el] (eoan-proposed/universe) [0.11.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libgclib [arm64] (eoan-proposed/universe) [0.11.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-58.64]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-58.64]
-queuebot:#ubuntu-release- Unapproved: accepted ibus [source] (bionic-proposed) [1.5.17-3ubuntu5]
<willcooke> sil2100, morning!  ISO testing done, except for.. CJK & VMware.  Do you have a VMware setup anywhere?
<willcooke> sil2100, handsome_feng will find someone to do the CJK test.  woot!
<sil2100> willcooke: oh my, thanks a lot, you're a life saver! Sadly I never did any VMware testing before - let's poke infinity to see if we should block on getting that tested
<willcooke> sil2100, np at all, happy to help.  I've asked desktoppers to do some more tests this morning too
-queuebot:#ubuntu-release- New: rejected ibus-avro [source] (eoan-proposed) [1.1-0ubuntu1]
<rbalint> sil2100, could you please move libnftnl to main? LP: #1838989
<ubot5> Launchpad bug 1838989 in libnftnl (Ubuntu) " [MIR] libnftnl: dependency of iptables " [Undecided,Fix committed] https://launchpad.net/bugs/1838989
<sil2100> rbalint: ACK! Ok, good to know we can just re-promote without any new bugs in the future
<sil2100> rbalint: done
<fossfreedom> dunno if its helpful but managed to get a trace for LP: #1838698 - attached it there.
<ubot5> Launchpad bug 1838698 in linux-hwe (Ubuntu) "Cannot boot ISO unless using nomodeset" [Undecided,New] https://launchpad.net/bugs/1838698
<LocutusOfBorg> please decruft NBS-proposed cleanup old binaries left on armhf: libpetsc-complex3.10, libpetsc-complex3.10-dbg, libpetsc-complex3.10-dev, libpetsc-real3.10, libpetsc-real3.10-dbg, libpetsc-real3.10-dev, libpetsc3.10-dev-common, libpetsc3.10-dev-examples, petsc3.10-doc (from 3.10.5+dfsg1-1build1)
<LocutusOfBorg> this should unblock petsc and I can see what is missing
<tjaalton> fossfreedom: have you tried newer kernels?
<tjaalton> mainline 5.1 etc
<infinity> LocutusOfBorg: Done.
<LocutusOfBorg> lovely thanks
<fossfreedom> tjaalton: tried the 5.3rc3 32bit kernel - same crash when modprobe i915
-queuebot:#ubuntu-release- New source: ibus-avro (eoan-proposed/primary) [1.1-0ubuntu1]
<tjaalton> fossfreedom: ugh, this probably isn't fixed in drm-intel-next either then, so should be filed upstream
<tjaalton> fossfreedom: but you probably should test that in case, drm-tip/current
-queuebot:#ubuntu-release- New: accepted ibus-avro [source] (eoan-proposed) [1.1-0ubuntu1]
<tjaalton> +just
<tjaalton> infinity: xrdp-hwe-18.04 is probably still in NEW?
-queuebot:#ubuntu-release- New binary: ibus-avro [amd64] (eoan-proposed/none) [1.1-0ubuntu1] (no packageset)
<infinity> tjaalton: Might be.  I vaguely rememeber giving you a non-commitment to reviewing that and asking you to find someone else.
<tjaalton> could be
<tjaalton> vorlon, apw, sil2100.. who else?
<rbalint> sil2100, could you please merge this https://code.launchpad.net/~rbalint/britney/autopkgtest-eoan-hints/+merge/371079 to unblock file?
<tjaalton> fossfreedom: I'll build you a kernel with a debug commit
<LocutusOfBorg> infinity, same for old binaries left on amd64: python-dolfin (from 2019.1.0-3) please?
<LocutusOfBorg> I probably fixed mshr, so we should be mostly good
-queuebot:#ubuntu-release- Unapproved: resource-agents (bionic-proposed/main) [1:4.1.0~rc1-1ubuntu1.1 => 1:4.1.0~rc1-1ubuntu1.2] (ubuntu-server)
<slashd> sil2100 ^ package I was talking about ^
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Bionic 18.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Bionic 18.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Bionic 18.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Bionic 18.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Bionic 18.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Bionic 18.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Bionic 18.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Bionic 18.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Bionic 18.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Bionic 18.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Bionic 18.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Bionic 18.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Bionic 18.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Bionic 18.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Bionic 18.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi3 [Bionic 18.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Bionic 18.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Bionic 18.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi3 [Bionic 18.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Bionic 18.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Bionic 18.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Bionic 18.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Bionic 18.04.3] has been marked as ready
* infinity changed the topic of #ubuntu-release to: Released: Bionic 18.04.3, Disco 19.04 | Archive: Open | Eoan Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melius malum quod cognoscis
-queuebot:#ubuntu-release- Builds: 33 entries have been added, updated or disabled
<ginggs> infinity LocutusOfBorg: I think you might get blocked on deal.ii FTBFS on arm64 (it builds in debian with gcc 8)
<LocutusOfBorg> ginggs, AFAIR you asked to remove it on arm64?
-queuebot:#ubuntu-release- New sync: qtwebkit (eoan-proposed/primary) [2.3.4.dfsg-10]
<tjaalton> fossfreedom: also, test with 'nopti' on the cmdline
<LocutusOfBorg> infinity, ^^ please let this one in, and remove qtwebkit-source (broken, useless FTBFS, stupid duplicate of this one)
<LocutusOfBorg> one day I'll understand why Ubuntu folks like that much to duplicate stuff
<infinity> LocutusOfBorg: I'm falling into bed.  Nick highlight someone else for a while. :P
<LocutusOfBorg> I wish you a good sleep(36000) :)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [4.15.0-1040.42] (kernel)
<infinity> LocutusOfBorg: As for "uselessly duplicating stuff", pretty sure a lot of that was packaged in Ubuntu first, then renamed when Debian did it.
<LocutusOfBorg> infinity, changelog says otherwise, anyhow, I tested the libraries and they build/install/replace the ubuntu stuff correctly
<LocutusOfBorg> so we should fix reverse-deps
<LocutusOfBorg> I'm not sure if I want to tell this to you... I hope you won't have nightmares
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/semantik/0.9.5-0ubuntu4/+build/17382967
<LocutusOfBorg>  /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libQtWebKit.so: error adding symbols: bad value
<LocutusOfBorg> collect2: error: ld returned 1 exit status
<LocutusOfBorg> this is the reason for my sync
-queuebot:#ubuntu-release- New binary: linux-signed-gke-4.15 [amd64] (bionic-proposed/main) [4.15.0-1040.42] (no packageset)
<LocutusOfBorg> somewhat gcc-9 broke something
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (bionic-proposed/main) [4.15.0-1021.23] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1050.57] (kernel)
<ginggs> LocutusOfBorg: i did not
<LocutusOfBorg> ginggs, upload a version that uses gcc-8 on arm64?
<ginggs> LocutusOfBorg: that package takes about 8 hours to build, removal probably better
-queuebot:#ubuntu-release- Unapproved: accepted resource-agents [source] (bionic-proposed) [1:4.1.0~rc1-1ubuntu1.2]
<tjaalton> fossfreedom: test https://aaltoset.kapsi.fi/32bit-debug
<vorlon> did the ubuntu-mate images go out oversized with the point release?
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [4.15.0-1040.42]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1050.57]
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-4.15 [amd64] (bionic-proposed) [4.15.0-1040.42]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1021.23]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1040.42~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1040.42~16.04.1]
-queuebot:#ubuntu-release- New source: linux-firmware-dragonboard410 (eoan-proposed/primary) [88-0ubuntu1]
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (xenial-proposed/main) [4.15.0-1021.23~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (xenial-proposed) [4.15.0-1021.23~16.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-58.64~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-58.64~16.04.1]
-queuebot:#ubuntu-release- Unapproved: thermald (bionic-proposed/main) [1.7.0-5ubuntu2 => 1.7.0-5ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: btrfs-tools (xenial-proposed/main) [4.4-1ubuntu1 => 4.4-1ubuntu1.1] (core)
<LocutusOfBorg> anybody wants to NBS cleanup proposed?
<LocutusOfBorg> old binaries left on i386: libmshr2018.1 (from 2018.1.0+dfsg1-7build5)
<LocutusOfBorg> vorlon, ^^ please?
-queuebot:#ubuntu-release- New binary: libcdio-paranoia [amd64] (eoan-proposed/main) [10.2+2.0.0-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: ros-python-qt-binding [amd64] (eoan-proposed/universe) [0.3.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libcdio-paranoia [i386] (eoan-proposed/main) [10.2+2.0.0-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libcdio-paranoia [s390x] (eoan-proposed/main) [10.2+2.0.0-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libcdio-paranoia [armhf] (eoan-proposed/main) [10.2+2.0.0-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: rust-diesel [amd64] (eoan-proposed/universe) [1.4.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libcdio-paranoia [ppc64el] (eoan-proposed/main) [10.2+2.0.0-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: parlatype [i386] (eoan-proposed/universe) [1.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: parlatype [amd64] (eoan-proposed/universe) [1.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pbbam [amd64] (eoan-proposed/universe) [0.23.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcdio-paranoia [arm64] (eoan-proposed/main) [10.2+2.0.0-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: parlatype [ppc64el] (eoan-proposed/universe) [1.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: claws-mail [i386] (eoan-proposed/universe) [3.17.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: parlatype [arm64] (eoan-proposed/universe) [1.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pbbam [ppc64el] (eoan-proposed/universe) [0.23.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-diesel [arm64] (eoan-proposed/universe) [1.4.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: parlatype [armhf] (eoan-proposed/universe) [1.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: claws-mail [s390x] (eoan-proposed/universe) [3.17.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-diesel [s390x] (eoan-proposed/universe) [1.4.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: claws-mail [amd64] (eoan-proposed/universe) [3.17.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-diesel [ppc64el] (eoan-proposed/universe) [1.4.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cbindgen [amd64] (eoan-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-diesel [i386] (eoan-proposed/universe) [1.4.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-diesel [armhf] (eoan-proposed/universe) [1.4.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cbindgen [s390x] (eoan-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: claws-mail [ppc64el] (eoan-proposed/universe) [3.17.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cbindgen [i386] (eoan-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nx-libs [amd64] (eoan-proposed/universe) [2:3.5.99.21-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cbindgen [ppc64el] (eoan-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: claws-mail [arm64] (eoan-proposed/universe) [3.17.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: claws-mail [armhf] (eoan-proposed/universe) [3.17.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cbindgen [armhf] (eoan-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pbbam [arm64] (eoan-proposed/universe) [0.23.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cbindgen [arm64] (eoan-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted claws-mail [armhf] (eoan-proposed) [3.17.4-1]
-queuebot:#ubuntu-release- New: accepted rust-cbindgen [arm64] (eoan-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted pbbam [arm64] (eoan-proposed) [0.23.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted rust-cbindgen [armhf] (eoan-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted claws-mail [arm64] (eoan-proposed) [3.17.4-1]
-queuebot:#ubuntu-release- New: accepted nx-libs [amd64] (eoan-proposed) [2:3.5.99.21-2]
-queuebot:#ubuntu-release- New: accepted rust-cbindgen [ppc64el] (eoan-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted rust-diesel [armhf] (eoan-proposed) [1.4.2-2]
-queuebot:#ubuntu-release- New: accepted rust-diesel [ppc64el] (eoan-proposed) [1.4.2-2]
-queuebot:#ubuntu-release- New: accepted claws-mail [ppc64el] (eoan-proposed) [3.17.4-1]
-queuebot:#ubuntu-release- New: accepted rust-cbindgen [s390x] (eoan-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted rust-cbindgen [i386] (eoan-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted rust-diesel [i386] (eoan-proposed) [1.4.2-2]
-queuebot:#ubuntu-release- New: accepted claws-mail [amd64] (eoan-proposed) [3.17.4-1]
-queuebot:#ubuntu-release- New: accepted parlatype [arm64] (eoan-proposed) [1.6.1-1]
-queuebot:#ubuntu-release- New: accepted pbbam [ppc64el] (eoan-proposed) [0.23.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted rust-diesel [arm64] (eoan-proposed) [1.4.2-2]
-queuebot:#ubuntu-release- New: accepted claws-mail [s390x] (eoan-proposed) [3.17.4-1]
-queuebot:#ubuntu-release- New: accepted rust-cbindgen [amd64] (eoan-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted parlatype [armhf] (eoan-proposed) [1.6.1-1]
-queuebot:#ubuntu-release- New: accepted rust-diesel [s390x] (eoan-proposed) [1.4.2-2]
-queuebot:#ubuntu-release- New: accepted claws-mail [i386] (eoan-proposed) [3.17.4-1]
-queuebot:#ubuntu-release- New: accepted libcdio-paranoia [armhf] (eoan-proposed) [10.2+2.0.0-1]
-queuebot:#ubuntu-release- New: accepted parlatype [amd64] (eoan-proposed) [1.6.1-1]
-queuebot:#ubuntu-release- New: accepted parlatype [ppc64el] (eoan-proposed) [1.6.1-1]
-queuebot:#ubuntu-release- New: accepted rust-diesel [amd64] (eoan-proposed) [1.4.2-2]
-queuebot:#ubuntu-release- New: accepted libcdio-paranoia [arm64] (eoan-proposed) [10.2+2.0.0-1]
-queuebot:#ubuntu-release- New: accepted parlatype [i386] (eoan-proposed) [1.6.1-1]
-queuebot:#ubuntu-release- New: accepted libcdio-paranoia [ppc64el] (eoan-proposed) [10.2+2.0.0-1]
-queuebot:#ubuntu-release- New: accepted pbbam [amd64] (eoan-proposed) [0.23.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted libcdio-paranoia [amd64] (eoan-proposed) [10.2+2.0.0-1]
-queuebot:#ubuntu-release- New: accepted libcdio-paranoia [s390x] (eoan-proposed) [10.2+2.0.0-1]
-queuebot:#ubuntu-release- New: accepted libgclib [ppc64el] (eoan-proposed) [0.11.2-1]
-queuebot:#ubuntu-release- New: accepted ros-python-qt-binding [amd64] (eoan-proposed) [0.3.5-2]
-queuebot:#ubuntu-release- New: accepted libcdio-paranoia [i386] (eoan-proposed) [10.2+2.0.0-1]
-queuebot:#ubuntu-release- New: accepted libgclib [s390x] (eoan-proposed) [0.11.2-1]
-queuebot:#ubuntu-release- New: accepted libgclib [arm64] (eoan-proposed) [0.11.2-1]
-queuebot:#ubuntu-release- New: accepted libgclib [amd64] (eoan-proposed) [0.11.2-1]
<vorlon> LocutusOfBorg: libmshr2018.1 done
-queuebot:#ubuntu-release- New binary: gffread [ppc64el] (eoan-proposed/universe) [0.11.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gffread [s390x] (eoan-proposed/universe) [0.11.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gffread [amd64] (eoan-proposed/universe) [0.11.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gffread [arm64] (eoan-proposed/universe) [0.11.4-1] (no packageset)
<seb128> https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes should probably be updated, it currently has sections like 'Get Ubuntu 18.04.2 LTS" and still point to .2 images
<vorlon> infinity: ^^
<tjaalton> vorlon: if you have time to review xrdp-hwe-18.04 from bionic new, that'd be swell
<tjaalton> it's needed to be able to use xrdp with the hwe stack xserver
-queuebot:#ubuntu-release- New: accepted xrdp-hwe-18.04 [source] (bionic-proposed) [0.9.5-2~18.04.1]
-queuebot:#ubuntu-release- New binary: xrdp-hwe-18.04 [amd64] (bionic-proposed/none) [0.9.5-2~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: xrdp-hwe-18.04 [s390x] (bionic-proposed/none) [0.9.5-2~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: xrdp-hwe-18.04 [i386] (bionic-proposed/none) [0.9.5-2~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: xrdp-hwe-18.04 [ppc64el] (bionic-proposed/none) [0.9.5-2~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: xrdp-hwe-18.04 [armhf] (bionic-proposed/none) [0.9.5-2~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: xrdp-hwe-18.04 [arm64] (bionic-proposed/none) [0.9.5-2~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: budgie-wallpapers [amd64] (eoan-proposed/universe) [19.10] (personal-fossfreedom, ubuntu-budgie)
#ubuntu-release 2019-08-09
<infinity> vorlon: The correct response to seb would have been "it's a wiki".
-queuebot:#ubuntu-release- Unapproved: partman-base (disco-proposed/main) [206ubuntu1.1 => 206ubuntu1.2] (core)
-queuebot:#ubuntu-release- Unapproved: partman-base (bionic-proposed/main) [192ubuntu1.1 => 192ubuntu1.2] (core)
<tjaalton> vorlon: thanks!
-queuebot:#ubuntu-release- New binary: golang-github-anacrolix-tagflag [amd64] (eoan-proposed/universe) [0.0.0-20180109-2146c8d-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-fernet-fernet-go [amd64] (eoan-proposed/universe) [0.0~git20180830.9eac43b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-fernet-fernet-go [i386] (eoan-proposed/universe) [0.0~git20180830.9eac43b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gopkg-src-d-go-git.v4 [amd64] (eoan-proposed/universe) [4.11.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-shurcool-httpgzip [amd64] (eoan-proposed/universe) [0.0~git20190516.1c7afaa-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-fernet-fernet-go [ppc64el] (eoan-proposed/universe) [0.0~git20180830.9eac43b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-fernet-fernet-go [s390x] (eoan-proposed/universe) [0.0~git20180830.9eac43b-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-github-fernet-fernet-go [ppc64el] (eoan-proposed) [0.0~git20180830.9eac43b-1]
-queuebot:#ubuntu-release- New: accepted golang-github-fernet-fernet-go [s390x] (eoan-proposed) [0.0~git20180830.9eac43b-1]
-queuebot:#ubuntu-release- New: accepted golang-github-fernet-fernet-go [amd64] (eoan-proposed) [0.0~git20180830.9eac43b-1]
-queuebot:#ubuntu-release- New: accepted golang-github-shurcool-httpgzip [amd64] (eoan-proposed) [0.0~git20190516.1c7afaa-1]
-queuebot:#ubuntu-release- New: accepted golang-github-fernet-fernet-go [i386] (eoan-proposed) [0.0~git20180830.9eac43b-1]
-queuebot:#ubuntu-release- New: accepted golang-gopkg-src-d-go-git.v4 [amd64] (eoan-proposed) [4.11.0-1]
-queuebot:#ubuntu-release- New: accepted gffread [amd64] (eoan-proposed) [0.11.4-1]
-queuebot:#ubuntu-release- New: accepted gffread [s390x] (eoan-proposed) [0.11.4-1]
-queuebot:#ubuntu-release- New: accepted gffread [arm64] (eoan-proposed) [0.11.4-1]
-queuebot:#ubuntu-release- New: accepted golang-github-anacrolix-tagflag [amd64] (eoan-proposed) [0.0.0-20180109-2146c8d-1]
-queuebot:#ubuntu-release- New: accepted gffread [ppc64el] (eoan-proposed) [0.11.4-1]
-queuebot:#ubuntu-release- New binary: golang-github-mattn-go-gtk [amd64] (eoan-proposed/universe) [0.1+git20190405.4deadb4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-mattn-go-gtk [s390x] (eoan-proposed/universe) [0.1+git20190405.4deadb4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-mattn-go-gtk [i386] (eoan-proposed/universe) [0.1+git20190405.4deadb4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-mattn-go-gtk [ppc64el] (eoan-proposed/universe) [0.1+git20190405.4deadb4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-mattn-go-gtk [armhf] (eoan-proposed/universe) [0.1+git20190405.4deadb4-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-github-mattn-go-gtk [armhf] (eoan-proposed) [0.1+git20190405.4deadb4-1]
-queuebot:#ubuntu-release- New: accepted golang-github-mattn-go-gtk [ppc64el] (eoan-proposed) [0.1+git20190405.4deadb4-1]
-queuebot:#ubuntu-release- New: accepted golang-github-mattn-go-gtk [i386] (eoan-proposed) [0.1+git20190405.4deadb4-1]
-queuebot:#ubuntu-release- New: accepted golang-github-mattn-go-gtk [amd64] (eoan-proposed) [0.1+git20190405.4deadb4-1]
-queuebot:#ubuntu-release- New binary: golang-github-mattn-go-gtk [arm64] (eoan-proposed/universe) [0.1+git20190405.4deadb4-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-github-mattn-go-gtk [s390x] (eoan-proposed) [0.1+git20190405.4deadb4-1]
-queuebot:#ubuntu-release- New: accepted golang-github-mattn-go-gtk [arm64] (eoan-proposed) [0.1+git20190405.4deadb4-1]
<vorlon> autopkgtest queues were a bit stuck; I'm not sure why, but restarting rabbitmq seems to have un-stuck it now
<vorlon> tjaalton: n/p
<vorlon> infinity: should the release notes not be an item on https://wiki.ubuntu.com/PointReleaseProcess ?
-queuebot:#ubuntu-release- New binary: node-cosmiconfig [amd64] (eoan-proposed/universe) [5.2.1-1] (no packageset)
<infinity> vorlon: Are they not?  Several people had fiddled with notes already, and I assume we all assumed someone else had done the URLs. :P
<infinity> vorlon: (but if they're not, maybe calling out the download links as needing editing on "day of" would be a solid bullet point, yes)
-queuebot:#ubuntu-release- New: accepted node-cosmiconfig [amd64] (eoan-proposed) [5.2.1-1]
-queuebot:#ubuntu-release- Unapproved: bind9 (bionic-proposed/main) [1:9.11.3+dfsg-1ubuntu1.8 => 1:9.11.3+dfsg-1ubuntu1.9] (core)
-queuebot:#ubuntu-release- Unapproved: bind9 (xenial-proposed/main) [1:9.10.3.dfsg.P4-8ubuntu1.14 => 1:9.10.3.dfsg.P4-8ubuntu1.15] (core)
-queuebot:#ubuntu-release- New: accepted ibus-avro [amd64] (eoan-proposed) [1.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: apt (disco-updates/main) [1.8.1 => 1.8.3] (core)
-queuebot:#ubuntu-release- New binary: rust-quick-xml [amd64] (eoan-proposed/universe) [0.14.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-quick-xml [i386] (eoan-proposed/universe) [0.14.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-quick-xml [armhf] (eoan-proposed/universe) [0.14.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-quick-xml [arm64] (eoan-proposed/universe) [0.14.0-2ubuntu1] (no packageset)
<Locutusofborg> please accept the sync I did on eoan new queue...
<Locutusofborg> "qtwebkit"
-queuebot:#ubuntu-release- Unapproved: zfs-linux (xenial-proposed/main) [0.6.5.6-0ubuntu27 => 0.6.5.6-0ubuntu28] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-quick-xml [ppc64el] (eoan-proposed/universe) [0.14.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-quick-xml [s390x] (eoan-proposed/universe) [0.14.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ucd-generate [amd64] (eoan-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ucd-generate [ppc64el] (eoan-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ucd-generate [s390x] (eoan-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ucd-generate [arm64] (eoan-proposed/universe) [0.2.1-1] (no packageset)
<juliank> who's triggering debian-xcontrol builds?
<juliank> why is that even still in proposed?
-queuebot:#ubuntu-release- New sync: magnus (eoan-proposed/primary) [1.0.2-2]
-queuebot:#ubuntu-release- New source: magnus (eoan-proposed/primary) [1.0.2-2]
<juliank> ^ the source should go away
<ogra> infinity, we're sitting here at the toronto sprint, trying to cross-build a classic armhf image with ubuntu-image and run into the old /lib/ld-linux-* not fund issue with live-build ... i figured you'd probably remember from the top of your head how to get around it (i forgot)
-queuebot:#ubuntu-release- New: rejected magnus [source] (eoan-proposed) [1.0.2-2]
-queuebot:#ubuntu-release- Unapproved: nautilus (disco-proposed/main) [1:3.32.1-0ubuntu0.19.04.0 => 1:3.32.3-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: procps (disco-proposed/main) [2:3.3.15-2ubuntu2 => 2:3.3.15-2ubuntu2.1] (core)
-queuebot:#ubuntu-release- Unapproved: procps (bionic-proposed/main) [2:3.3.12-3ubuntu1.1 => 2:3.3.12-3ubuntu1.2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted procps [source] (disco-proposed) [2:3.3.15-2ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted procps [source] (bionic-proposed) [2:3.3.12-3ubuntu1.2]
-queuebot:#ubuntu-release- New binary: bifcl [amd64] (eoan-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libnfsidmap-regex [i386] (eoan-proposed/none) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bifcl [i386] (eoan-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libnfsidmap-regex [amd64] (eoan-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-yubico [amd64] (eoan-proposed/universe) [1.3.2-2.1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-aho-corasick [i386] (eoan-proposed/universe) [0.7.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mpi4py-fft [amd64] (eoan-proposed/universe) [2.0.0.doc0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-console [amd64] (eoan-proposed/universe) [0.7.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-aho-corasick [amd64] (eoan-proposed/universe) [0.7.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mpi4py-fft [i386] (eoan-proposed/universe) [2.0.0.doc0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-euclid-0.19 [amd64] (eoan-proposed/universe) [0.19.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-float-ord [amd64] (eoan-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-console [i386] (eoan-proposed/universe) [0.7.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-float-ord [i386] (eoan-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-euclid-0.19 [i386] (eoan-proposed/universe) [0.19.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ccls [amd64] (eoan-proposed/universe) [0.20190314-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pbr [amd64] (eoan-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-chacha-0.1 [amd64] (eoan-proposed/universe) [0.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-core-0.4 [amd64] (eoan-proposed/universe) [0.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ring [amd64] (eoan-proposed/universe) [0.14.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ccls [i386] (eoan-proposed/universe) [0.20190314-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-chacha-0.1 [i386] (eoan-proposed/universe) [0.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pbr [i386] (eoan-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-core-0.4 [i386] (eoan-proposed/universe) [0.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-video [amd64] (eoan-proposed/universe) [1.2.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pulseeffects [i386] (eoan-proposed/universe) [4.5.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-video [i386] (eoan-proposed/universe) [1.2.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ring [i386] (eoan-proposed/universe) [0.14.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: calc [amd64] (eoan-proposed/universe) [2.12.7.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-aho-corasick [ppc64el] (eoan-proposed/universe) [0.7.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bifcl [s390x] (eoan-proposed/universe) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libnfsidmap-regex [s390x] (eoan-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-console [s390x] (eoan-proposed/universe) [0.7.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: calc [i386] (eoan-proposed/universe) [2.12.7.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-float-ord [s390x] (eoan-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-aho-corasick [s390x] (eoan-proposed/universe) [0.7.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bifcl [arm64] (eoan-proposed/universe) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bifcl [ppc64el] (eoan-proposed/universe) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-aho-corasick [arm64] (eoan-proposed/universe) [0.7.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-euclid-0.19 [s390x] (eoan-proposed/universe) [0.19.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bifcl [armhf] (eoan-proposed/universe) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-aho-corasick [armhf] (eoan-proposed/universe) [0.7.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mpi4py-fft [s390x] (eoan-proposed/universe) [2.0.0.doc0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pbr [s390x] (eoan-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ccls [s390x] (eoan-proposed/universe) [0.20190314-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pulseeffects [amd64] (eoan-proposed/universe) [4.5.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libnfsidmap-regex [ppc64el] (eoan-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-chacha-0.1 [s390x] (eoan-proposed/universe) [0.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libnfsidmap-regex [arm64] (eoan-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pulseeffects [s390x] (eoan-proposed/universe) [4.5.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mpi4py-fft [ppc64el] (eoan-proposed/universe) [2.0.0.doc0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-core-0.4 [s390x] (eoan-proposed/universe) [0.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: calc [s390x] (eoan-proposed/universe) [2.12.7.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-video [s390x] (eoan-proposed/universe) [1.2.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-console [ppc64el] (eoan-proposed/universe) [0.7.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-euclid-0.19 [armhf] (eoan-proposed/universe) [0.19.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-float-ord [arm64] (eoan-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-float-ord [ppc64el] (eoan-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-chacha-0.1 [armhf] (eoan-proposed/universe) [0.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mpi4py-fft [armhf] (eoan-proposed/universe) [2.0.0.doc0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-euclid-0.19 [arm64] (eoan-proposed/universe) [0.19.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-float-ord [armhf] (eoan-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-chacha-0.1 [ppc64el] (eoan-proposed/universe) [0.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-console [armhf] (eoan-proposed/universe) [0.7.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-chacha-0.1 [arm64] (eoan-proposed/universe) [0.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-euclid-0.19 [ppc64el] (eoan-proposed/universe) [0.19.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ccls [ppc64el] (eoan-proposed/universe) [0.20190314-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pbr [arm64] (eoan-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pbr [ppc64el] (eoan-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-console [arm64] (eoan-proposed/universe) [0.7.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ring [arm64] (eoan-proposed/universe) [0.14.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pbr [armhf] (eoan-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ccls [armhf] (eoan-proposed/universe) [0.20190314-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pulseeffects [ppc64el] (eoan-proposed/universe) [4.5.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-core-0.4 [armhf] (eoan-proposed/universe) [0.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-video [armhf] (eoan-proposed/universe) [1.2.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ring [armhf] (eoan-proposed/universe) [0.14.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-core-0.4 [arm64] (eoan-proposed/universe) [0.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ccls [arm64] (eoan-proposed/universe) [0.20190314-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-core-0.4 [ppc64el] (eoan-proposed/universe) [0.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: calc [arm64] (eoan-proposed/universe) [2.12.7.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-video [arm64] (eoan-proposed/universe) [1.2.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: calc [armhf] (eoan-proposed/universe) [2.12.7.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: calc [ppc64el] (eoan-proposed/universe) [2.12.7.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: mpi4py-fft [arm64] (eoan-proposed/universe) [2.0.0.doc0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pulseeffects [armhf] (eoan-proposed/universe) [4.5.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pulseeffects [arm64] (eoan-proposed/universe) [4.5.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1055.60] (kernel)
<infinity> ogra: I don't think I've ever been silly enough to cross-build with live-build.
<tjaalton> fossfreedom: did you try the debug kernel I built?
<fossfreedom> Thx tjaalton ... I have been out and about with the family today.  Will spend sometime this weekend. Cheers.
<tjaalton> fossfreedom: yeah, no worries
-queuebot:#ubuntu-release- New binary: rust-content-inspector [amd64] (eoan-proposed/universe) [0.2.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-content-inspector [s390x] (eoan-proposed/universe) [0.2.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-line-wrap [i386] (eoan-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-content-inspector [i386] (eoan-proposed/universe) [0.2.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-line-wrap [s390x] (eoan-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-line-wrap [amd64] (eoan-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-content-inspector [ppc64el] (eoan-proposed/universe) [0.2.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-line-wrap [ppc64el] (eoan-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-content-inspector [arm64] (eoan-proposed/universe) [0.2.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-line-wrap [arm64] (eoan-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-content-inspector [armhf] (eoan-proposed/universe) [0.2.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-line-wrap [armhf] (eoan-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-line-wrap [armhf] (eoan-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted calc [ppc64el] (eoan-proposed) [2.12.7.2-3]
-queuebot:#ubuntu-release- New: accepted pulseeffects [arm64] (eoan-proposed) [4.5.6-2]
-queuebot:#ubuntu-release- New: accepted rust-content-inspector [amd64] (eoan-proposed) [0.2.4-1]
-queuebot:#ubuntu-release- New: accepted rust-content-inspector [armhf] (eoan-proposed) [0.2.4-1]
-queuebot:#ubuntu-release- New: accepted rust-content-inspector [ppc64el] (eoan-proposed) [0.2.4-1]
-queuebot:#ubuntu-release- New: accepted rust-line-wrap [amd64] (eoan-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-line-wrap [i386] (eoan-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-line-wrap [s390x] (eoan-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New binary: rust-pbr [i386] (eoan-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-chacha-0.1 [i386] (eoan-proposed/universe) [0.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted mpi4py-fft [arm64] (eoan-proposed) [2.0.0.doc0-1]
-queuebot:#ubuntu-release- New: accepted rust-content-inspector [arm64] (eoan-proposed) [0.2.4-1]
-queuebot:#ubuntu-release- New: accepted rust-content-inspector [s390x] (eoan-proposed) [0.2.4-1]
-queuebot:#ubuntu-release- New: accepted rust-line-wrap [ppc64el] (eoan-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New binary: rust-rand-chacha-0.1 [amd64] (eoan-proposed/universe) [0.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-core-0.4 [i386] (eoan-proposed/universe) [0.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted pulseeffects [armhf] (eoan-proposed) [4.5.6-2]
-queuebot:#ubuntu-release- New: accepted rust-line-wrap [arm64] (eoan-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New binary: rust-rand-core-0.4 [amd64] (eoan-proposed/universe) [0.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-content-inspector [i386] (eoan-proposed) [0.2.4-1]
-queuebot:#ubuntu-release- New binary: ccls [amd64] (eoan-proposed/universe) [0.20190314-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted calc [arm64] (eoan-proposed) [2.12.7.2-3]
-queuebot:#ubuntu-release- New: accepted ccls [arm64] (eoan-proposed) [0.20190314-1]
-queuebot:#ubuntu-release- New: accepted ccls [ppc64el] (eoan-proposed) [0.20190314-1]
-queuebot:#ubuntu-release- New: accepted octave-video [armhf] (eoan-proposed) [1.2.4-1]
-queuebot:#ubuntu-release- New: accepted rust-console [arm64] (eoan-proposed) [0.7.7-1]
-queuebot:#ubuntu-release- New: accepted rust-pbr [armhf] (eoan-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-chacha-0.1 [arm64] (eoan-proposed) [0.1.1-2]
-queuebot:#ubuntu-release- New: accepted rust-rand-core-0.4 [armhf] (eoan-proposed) [0.4.0-2]
-queuebot:#ubuntu-release- New: accepted rust-ring [arm64] (eoan-proposed) [0.14.6-1]
-queuebot:#ubuntu-release- New binary: bifcl [i386] (eoan-proposed/universe) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted calc [armhf] (eoan-proposed) [2.12.7.2-3]
-queuebot:#ubuntu-release- New: accepted octave-video [arm64] (eoan-proposed) [1.2.4-1]
-queuebot:#ubuntu-release- New: accepted rust-pbr [arm64] (eoan-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-core-0.4 [arm64] (eoan-proposed) [0.4.0-2]
-queuebot:#ubuntu-release- New: accepted rust-ring [armhf] (eoan-proposed) [0.14.6-1]
-queuebot:#ubuntu-release- New binary: libnfsidmap-regex [i386] (eoan-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-yubico [amd64] (eoan-proposed/universe) [1.3.2-2.1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-aho-corasick [i386] (eoan-proposed/universe) [0.7.6-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ccls [armhf] (eoan-proposed) [0.20190314-1]
-queuebot:#ubuntu-release- New: accepted rust-pbr [ppc64el] (eoan-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New binary: libnfsidmap-regex [amd64] (eoan-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-aho-corasick [amd64] (eoan-proposed/universe) [0.7.6-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted pulseeffects [ppc64el] (eoan-proposed) [4.5.6-2]
-queuebot:#ubuntu-release- New binary: mpi4py-fft [amd64] (eoan-proposed/universe) [2.0.0.doc0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-rand-core-0.4 [ppc64el] (eoan-proposed) [0.4.0-2]
-queuebot:#ubuntu-release- New: accepted calc [s390x] (eoan-proposed) [2.12.7.2-3]
-queuebot:#ubuntu-release- New: accepted mpi4py-fft [armhf] (eoan-proposed) [2.0.0.doc0-1]
-queuebot:#ubuntu-release- New: accepted octave-video [s390x] (eoan-proposed) [1.2.4-1]
-queuebot:#ubuntu-release- New: accepted rust-console [ppc64el] (eoan-proposed) [0.7.7-1]
-queuebot:#ubuntu-release- New: accepted rust-euclid-0.19 [armhf] (eoan-proposed) [0.19.9-1]
-queuebot:#ubuntu-release- New: accepted rust-float-ord [arm64] (eoan-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-float-ord [ppc64el] (eoan-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-chacha-0.1 [ppc64el] (eoan-proposed) [0.1.1-2]
-queuebot:#ubuntu-release- New binary: budgie-wallpapers [amd64] (eoan-proposed/universe) [19.10] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: nut [arm64] (eoan-proposed/main) [2.7.4-9ubuntu1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted libnfsidmap-regex [arm64] (eoan-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-console [armhf] (eoan-proposed) [0.7.7-1]
-queuebot:#ubuntu-release- New: accepted rust-euclid-0.19 [ppc64el] (eoan-proposed) [0.19.9-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-chacha-0.1 [armhf] (eoan-proposed) [0.1.1-2]
-queuebot:#ubuntu-release- New source: linux-firmware-dragonboard410 (eoan-proposed/primary) [88-0ubuntu1]
-queuebot:#ubuntu-release- New sync: qtwebkit (eoan-proposed/primary) [2.3.4.dfsg-10]
-queuebot:#ubuntu-release- New: accepted mpi4py-fft [ppc64el] (eoan-proposed) [2.0.0.doc0-1]
-queuebot:#ubuntu-release- New: accepted rust-float-ord [armhf] (eoan-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New binary: nut [armhf] (eoan-proposed/main) [2.7.4-9ubuntu1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted rust-euclid-0.19 [arm64] (eoan-proposed) [0.19.9-1]
-queuebot:#ubuntu-release- New binary: rust-quick-xml [amd64] (eoan-proposed/universe) [0.14.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-rand-core-0.4 [s390x] (eoan-proposed) [0.4.0-2]
-queuebot:#ubuntu-release- New: accepted bifcl [arm64] (eoan-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted bifcl [ppc64el] (eoan-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted libnfsidmap-regex [ppc64el] (eoan-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted pulseeffects [amd64] (eoan-proposed) [4.5.6-2]
-queuebot:#ubuntu-release- New: accepted rust-aho-corasick [arm64] (eoan-proposed) [0.7.6-1]
-queuebot:#ubuntu-release- New: accepted rust-aho-corasick [s390x] (eoan-proposed) [0.7.6-1]
-queuebot:#ubuntu-release- New: accepted rust-float-ord [s390x] (eoan-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-chacha-0.1 [s390x] (eoan-proposed) [0.1.1-2]
-queuebot:#ubuntu-release- New: accepted bifcl [armhf] (eoan-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted mpi4py-fft [s390x] (eoan-proposed) [2.0.0.doc0-1]
-queuebot:#ubuntu-release- New: accepted rust-aho-corasick [armhf] (eoan-proposed) [0.7.6-1]
-queuebot:#ubuntu-release- New: accepted rust-pbr [s390x] (eoan-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted ccls [s390x] (eoan-proposed) [0.20190314-1]
-queuebot:#ubuntu-release- New: accepted rust-euclid-0.19 [s390x] (eoan-proposed) [0.19.9-1]
-queuebot:#ubuntu-release- New: accepted pulseeffects [s390x] (eoan-proposed) [4.5.6-2]
-queuebot:#ubuntu-release- New: accepted bifcl [s390x] (eoan-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted calc [i386] (eoan-proposed) [2.12.7.2-3]
-queuebot:#ubuntu-release- New: accepted octave-video [amd64] (eoan-proposed) [1.2.4-1]
-queuebot:#ubuntu-release- New: accepted pulseeffects [i386] (eoan-proposed) [4.5.6-2]
-queuebot:#ubuntu-release- New: accepted rust-console [s390x] (eoan-proposed) [0.7.7-1]
-queuebot:#ubuntu-release- New: accepted calc [amd64] (eoan-proposed) [2.12.7.2-3]
-queuebot:#ubuntu-release- New: accepted octave-video [i386] (eoan-proposed) [1.2.4-1]
-queuebot:#ubuntu-release- New: accepted rust-ring [i386] (eoan-proposed) [0.14.6-1]
-queuebot:#ubuntu-release- New: accepted libnfsidmap-regex [s390x] (eoan-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-aho-corasick [ppc64el] (eoan-proposed) [0.7.6-1]
#ubuntu-release 2019-08-10
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1055.60]
-queuebot:#ubuntu-release- New binary: golang-github-cnf-structhash [amd64] (eoan-proposed/universe) [0.0~git20180104.62a607e-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-jarcoal-httpmock [amd64] (eoan-proposed/universe) [1.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-onig-sys [amd64] (eoan-proposed/universe) [69.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-deanthompson-ginpprof [amd64] (eoan-proposed/universe) [0.0~git20190408.3be6366-1] (no packageset)
-queuebot:#ubuntu-release- New binary: redmine-plugin-local-avatars [amd64] (eoan-proposed/universe) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-plist [amd64] (eoan-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-gin-contrib-gzip [amd64] (eoan-proposed/universe) [0.0.1+git20190510.aef065f-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-shell-words [amd64] (eoan-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-plist [i386] (eoan-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-shell-words [i386] (eoan-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-onig-sys [i386] (eoan-proposed/universe) [69.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-onig-sys [s390x] (eoan-proposed/universe) [69.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-shell-words [s390x] (eoan-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-plist [s390x] (eoan-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-onig-sys [ppc64el] (eoan-proposed/universe) [69.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-shell-words [ppc64el] (eoan-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-plist [ppc64el] (eoan-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-onig-sys [arm64] (eoan-proposed/universe) [69.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-shell-words [arm64] (eoan-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-onig-sys [armhf] (eoan-proposed/universe) [69.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-shell-words [armhf] (eoan-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-plist [arm64] (eoan-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-plist [armhf] (eoan-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-onig-sys [arm64] (eoan-proposed) [69.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-plist [arm64] (eoan-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted rust-plist [ppc64el] (eoan-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted rust-shell-words [armhf] (eoan-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-onig-sys [armhf] (eoan-proposed) [69.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-shell-words [arm64] (eoan-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-plist [armhf] (eoan-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted rust-shell-words [ppc64el] (eoan-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-gin-contrib-gzip [amd64] (eoan-proposed) [0.0.1+git20190510.aef065f-1]
-queuebot:#ubuntu-release- New: accepted rust-onig-sys [i386] (eoan-proposed) [69.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-onig-sys [s390x] (eoan-proposed) [69.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-plist [i386] (eoan-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted rust-shell-words [amd64] (eoan-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-shell-words [s390x] (eoan-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-onig-sys [amd64] (eoan-proposed) [69.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-plist [amd64] (eoan-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted rust-shell-words [i386] (eoan-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-onig-sys [ppc64el] (eoan-proposed) [69.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-plist [s390x] (eoan-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted ccls [amd64] (eoan-proposed) [0.20190314-1]
-queuebot:#ubuntu-release- New: accepted golang-github-deanthompson-ginpprof [amd64] (eoan-proposed) [0.0~git20190408.3be6366-1]
-queuebot:#ubuntu-release- New: accepted redmine-plugin-local-avatars [amd64] (eoan-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-chacha-0.1 [amd64] (eoan-proposed) [0.1.1-2]
-queuebot:#ubuntu-release- New: accepted rust-rand-core-0.4 [amd64] (eoan-proposed) [0.4.0-2]
-queuebot:#ubuntu-release- New: accepted rust-ring [amd64] (eoan-proposed) [0.14.6-1]
-queuebot:#ubuntu-release- New: accepted golang-github-cnf-structhash [amd64] (eoan-proposed) [0.0~git20180104.62a607e-1]
-queuebot:#ubuntu-release- New: accepted rust-pbr [i386] (eoan-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-core-0.4 [i386] (eoan-proposed) [0.4.0-2]
-queuebot:#ubuntu-release- New: accepted golang-github-jarcoal-httpmock [amd64] (eoan-proposed) [1.0.4-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-chacha-0.1 [i386] (eoan-proposed) [0.1.1-2]
-queuebot:#ubuntu-release- New: accepted ccls [i386] (eoan-proposed) [0.20190314-1]
-queuebot:#ubuntu-release- New: accepted mpi4py-fft [i386] (eoan-proposed) [2.0.0.doc0-1]
-queuebot:#ubuntu-release- New: accepted rust-console [amd64] (eoan-proposed) [0.7.7-1]
-queuebot:#ubuntu-release- New: accepted rust-euclid-0.19 [amd64] (eoan-proposed) [0.19.9-1]
-queuebot:#ubuntu-release- New: accepted rust-float-ord [amd64] (eoan-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-pbr [amd64] (eoan-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted libnfsidmap-regex [amd64] (eoan-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-console [i386] (eoan-proposed) [0.7.7-1]
-queuebot:#ubuntu-release- New: accepted rust-float-ord [i386] (eoan-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-aho-corasick [amd64] (eoan-proposed) [0.7.6-1]
-queuebot:#ubuntu-release- New: accepted rust-euclid-0.19 [i386] (eoan-proposed) [0.19.9-1]
-queuebot:#ubuntu-release- New: accepted bifcl [amd64] (eoan-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted libnfsidmap-regex [i386] (eoan-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted python-yubico [amd64] (eoan-proposed) [1.3.2-2.1]
-queuebot:#ubuntu-release- New: accepted rust-ucd-generate [amd64] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-ucd-generate [ppc64el] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted bifcl [i386] (eoan-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-aho-corasick [i386] (eoan-proposed) [0.7.6-1]
-queuebot:#ubuntu-release- New: accepted rust-ucd-generate [s390x] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted mpi4py-fft [amd64] (eoan-proposed) [2.0.0.doc0-1]
-queuebot:#ubuntu-release- New: accepted rust-ucd-generate [arm64] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New binary: redmine-plugin-pretend [amd64] (eoan-proposed/universe) [0.0.2+git20130821-5] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pyramid-chameleon [amd64] (eoan-proposed/universe) [0.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: gevent-websocket [amd64] (eoan-proposed/universe) [0.10.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: kivy [amd64] (eoan-proposed/universe) [1.10.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kivy [s390x] (eoan-proposed/universe) [1.10.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kivy [ppc64el] (eoan-proposed/universe) [1.10.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kivy [i386] (eoan-proposed/universe) [1.10.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kivy [armhf] (eoan-proposed/universe) [1.10.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kivy [arm64] (eoan-proposed/universe) [1.10.1-1] (no packageset)
#ubuntu-release 2019-08-11
<ginggs> would an archive admin please remove r-bioc-metagenomeseq ?  LP: #1839706
<ubot5> Launchpad bug 1839706 in r-bioc-metagenomeseq (Ubuntu) "RM: r-bioc-metagenomeseq/1.24.1-1" [Undecided,New] https://launchpad.net/bugs/1839706
-queuebot:#ubuntu-release- New binary: ocaml-integers [amd64] (eoan-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-integers [i386] (eoan-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-cairo2 [amd64] (eoan-proposed/universe) [0.6.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-sexplib0 [amd64] (eoan-proposed/universe) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-cairo2 [i386] (eoan-proposed/universe) [0.6.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-ffmpeg [i386] (eoan-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-sexplib0 [i386] (eoan-proposed/universe) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-ffmpeg [amd64] (eoan-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: safeclib [amd64] (eoan-proposed/universe) [3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-sexplib0 [armhf] (eoan-proposed/universe) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-integers [armhf] (eoan-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-sexplib0 [arm64] (eoan-proposed/universe) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-cairo2 [armhf] (eoan-proposed/universe) [0.6.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-ffmpeg [armhf] (eoan-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: safeclib [i386] (eoan-proposed/universe) [3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-ffmpeg [arm64] (eoan-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-integers [arm64] (eoan-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-cairo2 [arm64] (eoan-proposed/universe) [0.6.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: safeclib [armhf] (eoan-proposed/universe) [3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-cairo2 [s390x] (eoan-proposed/universe) [0.6.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-integers [s390x] (eoan-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-ffmpeg [s390x] (eoan-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-sexplib0 [s390x] (eoan-proposed/universe) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-cairo2 [ppc64el] (eoan-proposed/universe) [0.6.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-integers [ppc64el] (eoan-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-ffmpeg [ppc64el] (eoan-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-sexplib0 [ppc64el] (eoan-proposed/universe) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: safeclib [ppc64el] (eoan-proposed/universe) [3.5-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gevent-websocket [amd64] (eoan-proposed) [0.10.1-2]
-queuebot:#ubuntu-release- New: accepted kivy [amd64] (eoan-proposed) [1.10.1-1]
-queuebot:#ubuntu-release- New: accepted kivy [armhf] (eoan-proposed) [1.10.1-1]
-queuebot:#ubuntu-release- New: accepted kivy [ppc64el] (eoan-proposed) [1.10.1-1]
-queuebot:#ubuntu-release- New: accepted ocaml-cairo2 [amd64] (eoan-proposed) [0.6.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ocaml-cairo2 [armhf] (eoan-proposed) [0.6.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ocaml-cairo2 [ppc64el] (eoan-proposed) [0.6.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ocaml-ffmpeg [amd64] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted ocaml-ffmpeg [armhf] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted ocaml-ffmpeg [ppc64el] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted ocaml-integers [amd64] (eoan-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted kivy [arm64] (eoan-proposed) [1.10.1-1]
-queuebot:#ubuntu-release- New: accepted kivy [s390x] (eoan-proposed) [1.10.1-1]
-queuebot:#ubuntu-release- New: accepted ocaml-cairo2 [i386] (eoan-proposed) [0.6.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ocaml-ffmpeg [arm64] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted ocaml-ffmpeg [s390x] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted ocaml-integers [armhf] (eoan-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted ocaml-integers [ppc64el] (eoan-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted ocaml-sexplib0 [amd64] (eoan-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted ocaml-sexplib0 [armhf] (eoan-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted ocaml-sexplib0 [ppc64el] (eoan-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted kivy [i386] (eoan-proposed) [1.10.1-1]
-queuebot:#ubuntu-release- New: accepted ocaml-cairo2 [s390x] (eoan-proposed) [0.6.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ocaml-integers [arm64] (eoan-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted ocaml-integers [s390x] (eoan-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted ocaml-sexplib0 [i386] (eoan-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted python-pyramid-chameleon [amd64] (eoan-proposed) [0.3-3]
-queuebot:#ubuntu-release- New: accepted ocaml-cairo2 [arm64] (eoan-proposed) [0.6.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ocaml-integers [i386] (eoan-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted ocaml-sexplib0 [s390x] (eoan-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted ocaml-ffmpeg [i386] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted ocaml-sexplib0 [arm64] (eoan-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted redmine-plugin-pretend [amd64] (eoan-proposed) [0.0.2+git20130821-5]
#ubuntu-release 2020-08-03
-queuebot:#ubuntu-release- New binary: rails [amd64] (groovy-proposed/universe) [2:6.0.3.2+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: rails [amd64] (groovy-proposed/universe) [2:6.0.3.2+dfsg-4] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-blogliterately [amd64] (groovy-proposed/universe) [0.8.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-blogliterately [ppc64el] (groovy-proposed/universe) [0.8.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-blogliterately [arm64] (groovy-proposed/universe) [0.8.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-blogliterately [armhf] (groovy-proposed/universe) [0.8.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-blogliterately [s390x] (groovy-proposed/universe) [0.8.7-1] (no packageset)
<apw> enyc, likely #ubuntu-x
<sil2100> jibel: hey! On the isotracker I see reports for Ubuntu Desktop .1 regarding the font viewer crashing on the live session
<sil2100> Did you see anything like that?
<jibel> sil2100, I'm currently looking at the issue
<jibel> it's old crashes though
<jibel> without much info
<jibel> indeed it crashes
<jibel> in live session only
<sil2100> Ok, if we had that before then I'm not as worried
<sil2100> Can't think of a strong usecase for checking fonts on the live session
<jibel> I get bug https://bugs.launchpad.net/ubuntu/+source/gnome-font-viewer/+bug/1861961
<ubot5> Ubuntu bug 1861961 in gnome-font-viewer (Ubuntu) "gnome-font-viewer crashed with SIGTRAP in _XEventsQueued() from XPending() from gdk_event_source_check() from g_main_context_check() from g_main_context_iterate() from g_main_context_iteration()" [Undecided,Confirmed]
<RikMills> could someone kill the frameworkintegration ppa autotests currently running? I can now see where they are hanging, which was the point
<jibel> sil2100, and not a regression since the release
-queuebot:#ubuntu-release- New binary: haskell-blogliterately [riscv64] (groovy-proposed/universe) [0.8.7-1] (no packageset)
<sil2100> xnox: argh, d-i on s390x for bionic FTBFS
<enyc> apw: thakyou for pointer,  put note thete too
<enyc> apw: its ' bit of a pain  when unclear what issue(s) may be  or even what packages to report
<enyc> apw: i guess i could test 19.10 live iso
<enyc> but still, if not xorg, not xorg video drivers, not radeon-firmware, not kernel ............
<enyc> gtk/associated?  etc
<apw> enyc, yep these are tricky to diagnose
<enyc> apw: I was hoping somebody would joump on or at least give me a $clue
<enyc> apw: i've ended up pci-extending and physically moving cards and making space to put in an actual video-card and  bypass problem that way....................
<apw> enyc, the right place for screen corruption is ubuntu-x, they will be able to split kernel/mesa/X
<enyc> apw: but STILL i'd be happy to help testing  changes that might make ati RS480  work
<enyc> ok!
<sil2100> xnox: ok, I see you have noticed and pushed the fix for it, duh
 * sil2100 could have checked the queue before digging into this
 * sil2100 throws away his change and accepts xnox's
<sil2100> xnox: thanks! ;)
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (bionic-proposed) [20101020ubuntu543.17]
<mwhudson> what is britney complaining about wrt the udebs here? https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#multipath-tools
<mwhudson> afaict the udebs it's talking about exist
<Laney> those messages suck
<Laney> but, component-mismatches?
<mwhudson> i don't think so?
<mwhudson> but maybe
<mwhudson> oh yes
<mwhudson> https://launchpad.net/ubuntu/groovy/amd64/liburcu6-udeb/0.12.1-1 is in universe
<mwhudson> how did that happen
<mwhudson> and why did it not happen to the multipath-tools udebs?
<Laney> why doesn't rmadison work on multpath-udeb
<Laney> such knowledge being expressed here
<mwhudson> https://launchpad.net/ubuntu/groovy/amd64/multipath-udeb/0.8.4-1ubuntu1 <- sez "main"
<Laney> nod
<Laney> doko: ^- what made you demote liburcu6-udeb? component-mismatches or?
<mwhudson> http://archive.ubuntu.com/ubuntu/dists/groovy-proposed/main/debian-installer/binary-amd64/Packages.gz is pretty small now but not quite empty
<mwhudson> er s/-proposed//
<mwhudson> Laney: how can you tell it was doko? :)
<Laney> mwhudson: if you back up one component from the URL you gave, the smoking gun is there
<mwhudson> Laney: ah!
<Laney> that's one of the nice little hidden corners of LP it's good to know about sometimes
<doko> Laney: yes, compomnent mismatches in both proposed and release
<mwhudson> yeah i think i may have seen that page and then failed to find it again
<doko> so why did these appear in component mismatches?
<doko> I still have the list of demoted packages... so I could revert those
<mwhudson> yeah that's a bit strange
<Laney> I guess if you do that, and it comes back on c-m we can debug the report
<mwhudson> i don't know what the long term plan is, we don't care about udebs at all for groovy afaik
<mwhudson> but what Laney suggests makes sense
<Laney> maybe all d-i stuff should be in universe, I dunno
<Laney> whatever it is should be done in a considered way rather than in response here imo
<mwhudson> yep
<mwhudson> now does anyone want to talk about udisks2's autopkgtests or should i just bounce on retry until it works
<Laney> file an rls-gg-incoming bug about that, I think desktop should schedule some work on thoes
 * mwhudson goes for the latter
<mwhudson> ok
<mwhudson> ah there was https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/1888062 already, i tagged it
<ubot5> Ubuntu bug 1888062 in udisks2 (Ubuntu) "autopkgtest became very flaky in Groovy" [High,Confirmed]
<Laney> ð¶
<mwhudson> looks like there is an upstream patch and everything, i guess i could try applying it
<mwhudson> doko: so will you revert your demotions?
<mwhudson> migrating s390-tools/2.12.0-0ubuntu6/s390x to testing makes ubuntu-server/1.452/s390x uninstallable
 * mwhudson squints
<seb128> mwhudson, there is no much point tagging that bug
<mwhudson> seb128: yeah i guess not
<seb128> it's already handled with a fix commited upstream
<mwhudson> seb128: i'm testing the upstream patch now
<seb128> thx
<Laney> disagree, that tagging was like 2 weeks ago, it would have made us look at it tomorrow in the meeting
<Laney> s/tagging/comment/
<doko> mwhudson: promoted again
<smb> Doing some Bionic->Focal upgrades I found https://bugs.launchpad.net/ubuntu/+source/timidity/+bug/1793640 is still relevant. Workaround seems to purge timidity-daemon. That might be something to mention in release notes.
<ubot5> Ubuntu bug 1793640 in timidity (Ubuntu) "Pulseaudio fails to detect sound card, while timidity is installed" [High,Triaged]
<mwhudson> doko: thanks
<seb128> Laney, well it's tagged so we are going to look at it :-) But I've a feeling that it will end up in us agreeing to nominate and me taking assignment since I handle udisk and I upstreamed the report that did lead to the commit that needs backporting, which is basically a no change from where we are today (I was just waiting for an upstream release to get it uploaded)
<Laney> seb128: okey dokey, just take the assignment now :p
<seb128> Laney, done, I should have done that when I triaged it :-)
 * Laney eyes proposed-migration/xenial
<Laney> why crasheth you
<mwhudson> seb128: oh, i just uploaded the patch...
<seb128> mwhudson, ah, even better
<seb128> thanks!
<mwhudson> seb128: np, +1 maint ftw
<seb128> :-)
 * mwhudson stops for now, let's see what britney thinks of the re-componented udebs in the morning
<doko> still puzzled why gcc-9 tries to promote ...
<xnox> mwhudson:  s390-tools-signed needs an upload
<mwhudson> xnox: ah
<mwhudson> xnox: does that require special skills?
<rbalint_> vorlon, do you have a log about how retry-autopkgtest-regressions failing with snap-triggered tests?
<xnox> mwhudson:  just carefully running debian/rules clean, and ensuring version numbers match.
<mwhudson> xnox: as i'm sure you know that was an attempt to trick you into doing it :)
<mwhudson> i will go to bed and see if i need to do it in the morning :-)
<xnox> ahahhahahahhahahhahaa
<sil2100> Laney: hey! Could you again re-run the snapshotting command for focal as you did last week on snakefruit? ;)
<sil2100> Laney: since I remembered now that we just re-spun the images, so the snapshot needs to be re-run
<sil2100> Laney: you can just re-run it as is, no need to delete anything
<Laney> sil2100: ok!
<Laney> lies
<sil2100> Laney: huge thanks! :)
<Laney> I do need to delete it
<sil2100> You do?
<sil2100> Ouchy
<Laney> OSError File exists
<Laney> feel free to fix the tool to avoid that ;-)
<sil2100> Oh well, I guess I wouldn't know since I have no access there!
<sil2100> ;)
<rbalint_> sil2100, if there will be a new respin u-u is ready for release
<rbalint_> sil2100, i have a not too special lxc container where u-u is running for 45 minutes due to not upgradable packages and fixing LP: #1877769 helps with that
<ubot5> Launchpad bug 1877769 in unattended-upgrades (Ubuntu Focal) "[SRU] Rewinding cache triggers obsolete adjustments consuming a lot of CPU" [Undecided,Fix committed] https://launchpad.net/bugs/1877769
-queuebot:#ubuntu-release- New binary: fvwm-crystal [amd64] (groovy-proposed/universe) [3.4.1+dfsg-2] (no packageset)
<sil2100> rbalint_: I hope no respin will be required
<sil2100> vorlon: hey! Regarding shim-signed for bionic - I guess I'd be okay with accepting the new one if we'd be able to verify it in the nearest days
<sil2100> vorlon: I see that the new upload includes a fix on top of the existing changes, so for clarity I'd like it to include all the bugs so far in .changes
<sil2100> Let me re-push
-queuebot:#ubuntu-release- Unapproved: shim-signed (bionic-proposed/main) [1.37~18.04.5 => 1.37~18.04.6] (core)
-queuebot:#ubuntu-release- Unapproved: rejected shim-signed [source] (bionic-proposed) [1.37~18.04.6]
-queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (bionic-proposed) [1.37~18.04.6]
<RikMills> Laney: FYI, for pkg-kde-tools & lintian, looks like it just needs the fixed lintian now in proposed to avoid the hangs
<ricotz> sil2100, hello, would you have time to process libreoffice 1:6.4.5-0ubuntu0.20.04.1 waiting in the focal/queue?
<Laney> RikMills: cool
<RikMills> Laney: PS. Nearly all the KDE build-needed tests should now be gone/going away, anyway \o/
<Laney> yesssssss
<RikMills> sorry that took so long....
<smb> apw, could you put your generous AA hat on and let me know whether bug 1843742 looks to be reasonably set up?
<ubot5> bug 1843742 in irda-utils (Ubuntu) "irda-utils ftbfs in eoan" [High,Confirmed] https://launchpad.net/bugs/1843742
<vorlon> rbalint_: backtrace: https://paste.ubuntu.com/p/Kcdj9j7vBm/
<vorlon> sil2100: shim-signed should be a pretty quick verification.  .changes, yes - do you need me to do anything there or can you reupload it with the correct -v?
<Laney> rbalint_: vorlon: I think I fixed that one earlier, sorry for stealing the work (didn't notice the previous ping)
<vorlon> Laney: ah cheer
<vorlon> s
<ahasenack> hello ubuntu-archive, could someone please take a look at this? https://code.launchpad.net/~ahasenack/ubuntu-seeds/+git/ubuntu-seeds/+merge/388428 It's to promote realmd and adcli to main in focal, after it was approved in groovy. The versions are identical in focal and groovy, and security gave a +1 already
<vorlon> ahasenack: seed changes don't require ubuntu-archive signoff
<vorlon> so don't block on us :)
<ahasenack> correct, but I wouldn't want to change a focal seed befora an AA agrees to promote the package there
<vorlon> ahasenack: ah right, wasn't obvious from the url, sorry
<ahasenack> and isn't there also an imminent .1 release for focal? I also wouldn't want to break that
<vorlon> ahasenack: it's only a supported seed so no point release impact.  +1 for the change, go for it and I can promote
<ahasenack> thank you!
<vorlon> sil2100: ah, you already did that hours ago, cheers ;)
<rbalint_> Laney, thanks! vorlon  thanks, i have not seen this failure yet
<sil2100> ricotz: let me take a look after the meetings!
<sil2100> jibel: hey! So I see you have looked at LP: #1890137, did you check if this affects only Kubuntu or other flavors?
<ubot5> Launchpad bug 1890137 in ubiquity (Ubuntu) "ubiquity crashes when "release notes" selected" [Medium,Confirmed] https://launchpad.net/bugs/1890137
<ricotz> sil2100, ty
<seb128> sil2100, hey, chromium-browser/focal sounds like another SRU worth accepting now if possible (and trivial only changelog update), it's to make sure focal_version > bionic_security, otherwise .1 upgraders might not get the snap
<sil2100> seb128: thanks for the info, on it as well o/
<seb128> thanks!
<sil2100> bdmurray: hey! Did you test that better fix for the meta package removal in u-r-u? Is it ready for releasing?
<sil2100> s/releasing/reviewing
<ahasenack> vorlon: merged
<bdmurray> sil2100: I did test it and uploaded it to groovy, haven't done it for Focal yet.
<sil2100> bdmurray: if you could prep a focal upload that would be sweet, since I guess it'd be nice to fast-track it before we enable upgrades
<bdmurray> sil2100: I was also working on this on Friday and thought it'd be good to bundle with the linux meta package removal fix
<bdmurray> https://code.launchpad.net/~brian-murray/ubuntu-release-upgrader/+git/ubuntu-release-upgrader/+merge/388513
<jibel> sil2100, it doesn't happen on Ubuntu
<sil2100> Let me take a look then
<jibel> sil2100, I'm downloading kubuntu
<bdmurray> sil2100: I haven't found many duplicates of the python-dbg issue so it may be able to wait
<jibel> sil2100, so on kubuntu, the link does nothing because xdg-open uses kde-open which doesn't exist but the installer doesn't crash
<sil2100> jibel: that's good news then
<jibel> i'll file a bug for the wrong association
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (focal-proposed/main) [1:20.04.23 => 1:20.04.24] (core)
<bdmurray> ^sil2100
<bdmurray> I'm writing the test case now
<jibel> sil2100, bug 1890173 it's specific to kubuntu
<ubot5> bug 1890173 in ubiquity (Ubuntu) "[kubuntu] "Release notes" link doesn't open" [Undecided,New] https://launchpad.net/bugs/1890173
<sil2100> bdmurray: \o/
<vorlon> ahasenack: and packages promoted in -updates
-queuebot:#ubuntu-release- New binary: aseba-plugin-blockly [amd64] (groovy-proposed/multiverse) [20180211+git-3] (no packageset)
<ahasenack> vorlon: thank you
-queuebot:#ubuntu-release- New binary: galax [s390x] (groovy-proposed/universe) [1.1-16] (no packageset)
<Laney> hopefully fixed p-m/xenial without breaking anything else ...
<Laney> quite a delicate area of the code though
-queuebot:#ubuntu-release- New binary: galax [ppc64el] (groovy-proposed/universe) [1.1-16] (no packageset)
<vorlon> why does c-m want to promote gcc-9?  nothing in https://people.canonical.com/~ubuntu-archive/component-mismatches.svg or https://people.canonical.com/~ubuntu-archive/component-mismatches.html explains
-queuebot:#ubuntu-release- New binary: galax [amd64] (groovy-proposed/universe) [1.1-16] (no packageset)
-queuebot:#ubuntu-release- New binary: galax [armhf] (groovy-proposed/universe) [1.1-16] (no packageset)
-queuebot:#ubuntu-release- New binary: galax [arm64] (groovy-proposed/universe) [1.1-16] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (focal-proposed) [1:6.4.5-0ubuntu0.20.04.1]
<sil2100> ricotz: hmmm, I wanted to accept libreoffice, but I got this error: "libreoffice_6.4.5.orig-tarballs.tar.xz is already published in archive for focal with a different SHA1 hash (dd676f6a65ab6910b90a944be59e17cb1b34b127 != 79767488a539577fb3a5db828c9245a0fbd0491c)"
<sil2100> ricotz: how did that happen? I would expect it to get rejected on queue upload
<sil2100> vorlon: ^ do you know?
<sil2100> It's weird since now libreoffice is gone from the queue, but I wonder if it actually got accepted
<ricotz> sil2100, hmm, no idea :(, I didn't create these packages. hellsworth did
<ricotz> sil2100, I can prepare fixed ones though
-queuebot:#ubuntu-release- Unapproved: accepted chromium-browser [source] (focal-proposed) [84.0.4147.89-0ubuntu0.20.04.1]
<sil2100> ricotz: I think it might be good to start preparing new ones (and making sure that the same orig  tarballs are used as available in the archive)
<sil2100> Ah, could it be that this was uploaded first to the queue and only afterwards to groovy?
<sil2100> Anyway, I see it as accepted, but it doesn't appear anywhere, so probably LP rejected it
<ricotz> sil2100, sorry, I don't know, hellsworth is quite new to the packaging process
<ricotz> sil2100, https://people.ubuntu.com/~ricotz/libreoffice/
<sil2100> bdmurray: hey! So regarding the u-r-u SRU: I'd like to make sure about one thing as this bit us multiple times already in the past
<sil2100> bdmurray: do you know if at any moment of time the tryMarkObsoleteForRemoval() function of MyCache in DistUpgradeCache is being used by update-manager?
<sil2100> bdmurray: since you know how stupid this is - update-manager uses MyCache from u-r-u but doesn't call it's constructor, so I just want to make sure that update-manager won't suddenly start crashing because of self.linux_metapackage being undefined
<sil2100> (as it's defined in the u-r-u constructor, not the update-manager MyCache-derivative)
<bdmurray> sil2100: I'll have a look
<sil2100> bdmurray: thanks!
<vorlon> sil2100: that's a check that doesn't happen until after the unapproved stage
<ahasenack> hi release team, do we have a release schedule for groovy? https://wiki.ubuntu.com/GroovyGorilla/ReleaseSchedule is empty
<ahasenack> oh
<ahasenack> it magically appeared
<ahasenack> it redirected to discourse, oh
<ricotz> sil2100, is the repackaged libreoffice sufficient?
-queuebot:#ubuntu-release- New binary: galax [riscv64] (groovy-proposed/universe) [1.1-16] (no packageset)
<bdmurray> sil2100: update-manager does not use "tryMarkObsoleteForRemoval" additionally I ran update-manger with the new focal u-r-u packages installed and it worked without issue
<sil2100> bdmurray: excellent, thanks for checking!
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (focal-proposed) [1:20.04.24]
<mwhudson> vorlon / ubuntu-archive: can you repromote libargon2-1-udeb to main please?
<mwhudson> (see https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#cryptsetup)
<RikMills> vorlon: lintian in proposed newly depends on lzip, which has no i386 build. can that be sorted?
<vorlon> mwhudson: done the other way, cryptsetup udebs demoted (since no longer used).  c-m output suggests something in main in -proposed still depends on them but we'll sort that out anon
<vorlon> RikMills: lintian is arch: all, so why does it need to be installable on i386?
<vorlon> RikMills: (lintian is not in the build-dep closure for i386, so I believe the answer is it doesn't need to be)
<RikMills> when pkg-kde-tools needs lintian for i386 builds
<mwhudson> vorlon: can we stop publishing udebs at some stage?
<vorlon> mwhudson: possibly
<vorlon> RikMills: ah, sounds like a bug in the germinate handling, blech
<vorlon> RikMills: otoh why is lintian being used at build-time?
<vorlon> it would be more convenient for me to fix this misfeature of pkg-kde-tools instead :)
<RikMills> vorlon: pkg-kde-tools uses it for kubuntu QA and CI scripts/pages
<vorlon> hmph
<vorlon> :)
<vorlon> ok I'll dig into it
<RikMills> thanks :)
<RikMills> vorlon: oh, and currently pkg-kde-tools does not depend on lintian, due to a separate bug with the lintian in -release, but we do want the depend back once fixed lintian in proposed migrates
 * RikMills thinks lintian is out to get me this week!
-queuebot:#ubuntu-release- New binary: album-data [amd64] (groovy-proposed/multiverse) [4.05-7.1] (no packageset)
<mwhudson> hmm how do we feel about removing src:frr i wonder
#ubuntu-release 2020-08-04
-queuebot:#ubuntu-release- New binary: frotz [amd64] (groovy-proposed/universe) [2.52+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: frotz [s390x] (groovy-proposed/universe) [2.52+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: frotz [ppc64el] (groovy-proposed/universe) [2.52+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: frotz [arm64] (groovy-proposed/universe) [2.52+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: frotz [armhf] (groovy-proposed/universe) [2.52+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nanoc [amd64] (groovy-proposed/universe) [4.11.14-1] (no packageset)
-queuebot:#ubuntu-release- New binary: frotz [riscv64] (groovy-proposed/universe) [2.52+dfsg-1] (no packageset)
<juliank> sil2100: I'd like to unblock shim again, see https://code.launchpad.net/~juliank/britney/hints-ubuntu--unblock-shim/+merge/388647 - the block was for the old (broken) version we wanted to keep in proposed, but didn't
<juliank> sil2100: Is there a chance you could merge this for me? :)
<juliank> Laney: ^ if something is blocked by a hint, update_excuses says to contact debian-release, probably should say to contact ubuntu-release :D
<juliank> Not touching package due to block request by ubuntu-release (please contact debian-release if update is needed)
<Laney> heh
<Laney> those guys can deal with it, that's fine by me
<sil2100> juliank: oh yea, indeed we can now proceed with stuff!
<sil2100> Let me check that and merge
<rbalint_> sil2100, could you please also merge https://code.launchpad.net/~rbalint/britney/hints-ubuntu/+merge/388558 ?
<rbalint_> (for systemd)
-queuebot:#ubuntu-release- Unapproved: wireguard (bionic-proposed/universe) [1.0.20200513-1~18.04.1 => 1.0.20200513-1~18.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: wireguard (focal-proposed/universe) [1.0.20200513-1~20.04.1 => 1.0.20200513-1~20.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: wireguard (xenial-proposed/universe) [1.0.20200513-1~16.04.1 => 1.0.20200513-1~16.04.2] (no packageset)
<jibel> sil2100, I just finished testing focal on hw with nvidia and rst drives. It's all good. I still have to test it on VMWare but I cannot at the moment, I've to reboot to disable secure boot.
<jibel> I'll do a PXE installation, then I think we're done for desktop.
<Laney> it shuld say ubuntu-release at the next run
<Laney> should
<Laney> give me message editing please
<sil2100> jibel: \o/
<sil2100> rbalint_: looking
-queuebot:#ubuntu-release- Unapproved: libglvnd (focal-proposed/main) [1.3.1-1 => 1.3.1-1ubuntu0.20.04.1] (core, i386-whitelist)
<mwhudson> ubuntu-archive: https://bugs.launchpad.net/ubuntu/+source/frr/+bug/1890259
<ubot5> Ubuntu bug 1890259 in frr (Ubuntu) "remove this package from release and proposed" [Undecided,New]
<apw> mwhudson, i believe if that gets removed from proposed then it will never come back; autosync will ignore it
<mwhudson> apw: i was under the impression that there was an explicit black list of Things We Do Not Want
<apw> mwhudson, why is demoting it to -proposed not sufficient ... obviously this would need blocking too
<apw> mwhudson, it is taken from the removals log
<mwhudson> hm
<apw> but why would it not be ok to pull it back to -proposed
<apw> and hold it there
<mwhudson> oh right yes probably just deleting the one in release would be fine
<mwhudson> no need to hold it there, the failing autopkgtests will do that part just fine
<apw> ok
<seb128> apw, mwhudson, if you delete from proposed the same version will not be synced again
<seb128> but the next one will
<mwhudson> yeah that's what i thought
<apw> hmmm, ok
<seb128> so it depends if you want the package to be out of the archive for good
<mwhudson> but apw is right that just deleting from release should let json-c migrate
<apw> nope we don't
<seb128> or if you want it back on the next debian upload
<seb128> k, then deleting from proposed would be fine
<seb128> but sounds like deleting from release is what you want there
<seb128> apw, are you doing the removal?
<apw> which what i am propsing to do yes
<apw> seb128, yes i am planning on it if the other assertions pan out
<apw> for clarity, i am proposing to remove it from -release only
<seb128> +1
<xnox> Laney:  sil2100: why is there ubuntu-release block in groovy? I don't see anything on the schedule.
<apw> xnox, where do you see that ?
<mwhudson> apw: yes release only deletiong please
<apw> mwhudson, gone
<mwhudson> apw: thanks
<apw> xnox, i only see 4 packages blocked, all by me
<xnox> right i am blind
<xnox> shim was blocked too, because of the old revert, and that got dropped now.
<xnox> everything is good
<rbalint> sil2100, please drop glibc from groovy-proposed, i'm preparing 2.32 soon to land instead
<rbalint> sil2100, also i've discovered issues with the nanosleep fallback
<doko> mwhudson, Laney: are the udebs issues now sorted out?
<mwhudson> doko: seems so
<doko> rbalint: why drop it?
<doko> ok, somebody looking now why they are up to demotion?
-queuebot:#ubuntu-release- New binary: shim-canonical [amd64] (groovy-proposed/universe) [2] (no packageset)
-queuebot:#ubuntu-release- New binary: shim-canonical [arm64] (groovy-proposed/universe) [2] (no packageset)
<mwhudson> doko: i wasn't planning to
<mwhudson> doko: i think it's probably reasonable that they are to be demoted, but the question is why not enough of them are being suggested for demotion, or something like that
<rbalint> doko, i think it is broken and should not be released so keeping it in -proposed is not useful
<rbalint> doko, i've saved the observed regressions to be triaged later and as a reference for next uploads
-queuebot:#ubuntu-release- Unapproved: libreoffice (focal-proposed/main) [1:6.4.4-0ubuntu0.20.04.1 => 1:6.4.5-0ubuntu0.20.04.1] (ubuntu-desktop)
<xnox> doko:  we dropped d-i in groovy, and removed d-i builds. Hence majority of udeb-only packages are falling off to universe as expected. We still need to remove / demote more things.
<xnox> doko:  or i guess we could seed them back to main, if that's too much churn.
<xnox> doko:  ideally i hoped for doing "noudeb" build profile in launchpad to stop generating them altogether. But that's not implemented.
<Laney> c-m is offering up udeb things for demotion that still have depends in main, seems like a bug in the report
<Laney> you could ignore it by doing more radical stuff, true, but the report does seem buggy right now
<Laney> mwhudson noted that in the +1 maint status report
<xnox> i see
<xnox> well imho, no udebs should exist =)
<mwhudson> is there a noudebs profile or something? or do we teach launchpad to stop publishing them?
<mwhudson> it's not worth having delta on packages just to hack the udebs out
<xnox> mwhudson:  there is noudeb profile, i'm not sure where/how to inject it.
<marcustomlinson> sil2100: please could you approve the libreoffice upload in focal. this actually was previously accepted but failed due to different orig tarball checksums. should be fixed now.
<xnox> mwhudson:  i wish we would inject build profile "ubuntu" to be fair. Would make so many things eaiser. I.e. specifying/excluding ubuntu-only build-deps in debian/control.
<mwhudson> xnox: sounds like a job for the asbestos pants
<mwhudson> although i don't really understand why profile stuff is as contentious as it is
<Laney> it would have some similar issues to the vendor-specific patch series that the tech ctte recently banned
<Laney> so yeah, don't expect a smooth ride imo
<xnox> true it would.
<xnox> mwhudson:  Laney: so at https://code.launchpad.net/~xnox/launchpad-buildd/+git/launchpad-buildd/+merge/386466
<xnox> i was asked to "is that we need to consider the plan for those when designing this."
<xnox> i.e. have a plan for arbitrary profiles i guess.
<cjwatson> Not necessarily a complete plan, but at least have thought about it so that we don't put a single-purpose hack in place only to have to supersede it with something else later
<xnox> ok
<xnox> also somehow i wonder if it needs to be in-distro anyway as well. for something that is applied so fundamental.
<xnox> i.e. if we break udeb build for some reason, then packages will fail to `debuild -- binary` locally, unless one knows to set `noudeb` profile.
<xnox> that would be sad too.
<cjwatson> It's not clear to me whether it's worth separating build and publish logic.  I know we do it for ddebs ...
<RikMills> will the new lintian deps need a proper MIR to promote them?
-queuebot:#ubuntu-release- New binary: frotz [amd64] (groovy-proposed/universe) [2.52+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: frotz [s390x] (groovy-proposed/universe) [2.52+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: frotz [armhf] (groovy-proposed/universe) [2.52+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mldonkey [s390x] (groovy-proposed/none) [3.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: frotz [arm64] (groovy-proposed/universe) [2.52+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: frotz [ppc64el] (groovy-proposed/universe) [2.52+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mldonkey [amd64] (groovy-proposed/universe) [3.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mldonkey [ppc64el] (groovy-proposed/universe) [3.1.7-1] (no packageset)
<xnox> vorlon:  uploaded rebuild of shim-canonical, and seeded it into a main seed, and seeded it. As signed things are not published for universe.
<xnox> vorlon:  also i wonder if we can reproducibly reubild existing shim, to allow normal archive signing of it.
<apw> xnox, i don't think that is an accurate statement about signed and universe; i believe the correct statement is "all signed things regardless of component are published in dists/main"
-queuebot:#ubuntu-release- New binary: mldonkey [armhf] (groovy-proposed/universe) [3.1.7-1] (no packageset)
<xnox> hmmmm
<xnox> ah
<xnox> apw:  signing has never been accepted yet.
<xnox> apw:  can you please reject _1_ from https://launchpad.net/ubuntu/groovy/+queue?queue_state=0&queue_text=shim
<apw> xnox, gone
-queuebot:#ubuntu-release- New: rejected shim-canonical [amd64] (groovy-proposed) [1]
-queuebot:#ubuntu-release- New: rejected shim-canonical [arm64] (groovy-proposed) [1]
-queuebot:#ubuntu-release- New binary: mldonkey [arm64] (groovy-proposed/universe) [3.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: frotz [riscv64] (groovy-proposed/universe) [2.52+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted album-data [amd64] (groovy-proposed) [4.05-7.1]
-queuebot:#ubuntu-release- New: accepted frotz [arm64] (groovy-proposed) [2.52+dfsg-1]
-queuebot:#ubuntu-release- New: accepted frotz [ppc64el] (groovy-proposed) [2.52+dfsg-1]
-queuebot:#ubuntu-release- New: accepted frotz [s390x] (groovy-proposed) [2.52+dfsg-1]
-queuebot:#ubuntu-release- New: accepted frotz [arm64] (groovy-proposed) [2.52+dfsg-2]
-queuebot:#ubuntu-release- New: accepted frotz [ppc64el] (groovy-proposed) [2.52+dfsg-2]
-queuebot:#ubuntu-release- New: accepted frotz [s390x] (groovy-proposed) [2.52+dfsg-2]
-queuebot:#ubuntu-release- New: accepted frotz [amd64] (groovy-proposed) [2.52+dfsg-1]
-queuebot:#ubuntu-release- New: accepted frotz [riscv64] (groovy-proposed) [2.52+dfsg-1]
-queuebot:#ubuntu-release- New: accepted frotz [armhf] (groovy-proposed) [2.52+dfsg-2]
-queuebot:#ubuntu-release- New: accepted nanoc [amd64] (groovy-proposed) [4.11.14-1]
-queuebot:#ubuntu-release- New: accepted frotz [armhf] (groovy-proposed) [2.52+dfsg-1]
-queuebot:#ubuntu-release- New: accepted frotz [riscv64] (groovy-proposed) [2.52+dfsg-2]
-queuebot:#ubuntu-release- New: accepted frotz [amd64] (groovy-proposed) [2.52+dfsg-2]
-queuebot:#ubuntu-release- New: accepted aseba-plugin-blockly [amd64] (groovy-proposed) [20180211+git-3]
-queuebot:#ubuntu-release- New: accepted galax [amd64] (groovy-proposed) [1.1-16]
-queuebot:#ubuntu-release- New: accepted galax [armhf] (groovy-proposed) [1.1-16]
-queuebot:#ubuntu-release- New: accepted galax [riscv64] (groovy-proposed) [1.1-16]
-queuebot:#ubuntu-release- New: accepted haskell-blogliterately [amd64] (groovy-proposed) [0.8.7-1]
-queuebot:#ubuntu-release- New: accepted haskell-blogliterately [armhf] (groovy-proposed) [0.8.7-1]
-queuebot:#ubuntu-release- New: accepted haskell-blogliterately [riscv64] (groovy-proposed) [0.8.7-1]
-queuebot:#ubuntu-release- New: accepted fvwm-crystal [amd64] (groovy-proposed) [3.4.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted galax [ppc64el] (groovy-proposed) [1.1-16]
-queuebot:#ubuntu-release- New: accepted haskell-blogliterately [arm64] (groovy-proposed) [0.8.7-1]
-queuebot:#ubuntu-release- New: accepted haskell-blogliterately [s390x] (groovy-proposed) [0.8.7-1]
-queuebot:#ubuntu-release- New: accepted galax [arm64] (groovy-proposed) [1.1-16]
-queuebot:#ubuntu-release- New: accepted haskell-blogliterately [ppc64el] (groovy-proposed) [0.8.7-1]
-queuebot:#ubuntu-release- New: accepted galax [s390x] (groovy-proposed) [1.1-16]
-queuebot:#ubuntu-release- New: accepted rails [amd64] (groovy-proposed) [2:6.0.3.2+dfsg-3]
-queuebot:#ubuntu-release- New: accepted rails [amd64] (groovy-proposed) [2:6.0.3.2+dfsg-4]
<cjwatson> apw: That would surprise me
<cjwatson> apw: Huh, you do appear to be correct
<cjwatson> I guess we didn't have a good alternative due to the incomplete data model
<apw> cjwatson, my memory is we literally do not have the component in the signing context
<jibel> sil2100, I've a very simple fix for bug 1890173 but it'll be for .2 at this point.
<ubot5> bug 1890173 in ubiquity (Ubuntu) "[kubuntu] "Release notes" link doesn't open" [Undecided,Confirmed] https://launchpad.net/bugs/1890173
<cjwatson> apw: Yeah, you're probably right.  Sigh @ custom uploads
-queuebot:#ubuntu-release- Unapproved: accepted wireguard [source] (focal-proposed) [1.0.20200513-1~20.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted wireguard [source] (bionic-proposed) [1.0.20200513-1~18.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted wireguard [source] (xenial-proposed) [1.0.20200513-1~16.04.2]
<bdmurray> sil2100: I've verified the fix for LP: #1889449 but was hoping somebody else would test it too just to be extra extra safe.
<ubot5> Launchpad bug 1889449 in ubuntu-release-upgrader (Ubuntu Focal) "18.04 to 20.04.1 upgrade on raspberry pi removes too many kernel meta packages" [High,Fix committed] https://launchpad.net/bugs/1889449
<bdmurray> sil2100: I'm also trying to fix LP: #1888916 but might be missing information.
<ubot5> Launchpad bug 1888916 in ubuntu-release-upgrader (Ubuntu Groovy) "upgrade from bionic to focal a server with molly-guard moves back sources.list to bionic entries" [Medium,Incomplete] https://launchpad.net/bugs/1888916
<sil2100> bdmurray: should we ping klebers?
<bdmurray> sil2100: he's testing it now
<klebers> sil2100, bdmurray: the upgraded worked now: https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1889449/comments/9
<ubot5> Ubuntu bug 1889449 in ubuntu-release-upgrader (Ubuntu Focal) "18.04 to 20.04.1 upgrade on raspberry pi removes too many kernel meta packages" [High,Fix committed]
<bdmurray> klebers: Great, thanks for testing it!
-queuebot:#ubuntu-release- Unapproved: accepted mutter [source] (focal-proposed) [3.36.4-0ubuntu0.20.04.2]
<sil2100> klebers, bdmurray: thanks!
<sil2100> I'd say let's leave it around in -proposed until tomorrow and release it then
<bdmurray> sil2100: Alright, sounds good
-queuebot:#ubuntu-release- Unapproved: probert (focal-proposed/main) [0.0.18 => 0.0.18build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rsyslog (focal-proposed/main) [8.2001.0-1ubuntu1 => 8.2001.0-1ubuntu1.1] (core)
-queuebot:#ubuntu-release- New binary: gitit [amd64] (groovy-proposed/universe) [0.13.0.0+dfsg-1] (no packageset)
<vorlon> xnox: I don't see a need for reproducibly rebuilding existing shim, vs just changing the shim source to include the efi signing tarball
<vorlon> RikMills: so I think the right ordering here is for pkg-kde-tools to restore its dependency on lintian, then let germinate do its thing, then get lzip bootstrapped into the whitelist
<vorlon> RikMills: also lzip is currently in universe, as is libipc-run3-perl, so lintian isn't going anywhere without an MIR
-queuebot:#ubuntu-release- Unapproved: rejected update-notifier [source] (trusty-proposed) [0.154.1ubuntu9]
<vorlon> sil2100, bdmurray: shim-signed/bionic is verified, should I release that?  that implies respins, doesn't it
<vorlon> sil2100: ah but this is respins for bionic, which we still have a week on - I'll go ahead and release it now
<sil2100> vorlon: yes, please o/
<sil2100> There's still kmod/systemd/d-i for bionic that need releasing, but I wanted to give systemd one more day of aging just-in-case
<vorlon> sil2100: yeah there are also some autopkgtest regressions on systemd that I'm hammering retry buttons on
<vorlon> doko: are there any behavior changes in gcc-10 regarding . being an implicit include path or something?  qtwebkit-opensource-src FTBFS saying it can't find XPathGrammar.hpp which is in the same directory as the source file
-queuebot:#ubuntu-release- New binary: gitit [s390x] (groovy-proposed/universe) [0.13.0.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gitit [ppc64el] (groovy-proposed/universe) [0.13.0.0+dfsg-1] (no packageset)
<ddstreet> vorlon autopkgtest regression for linux-aws-edge is lp: #1890178 and umockdev is lp: #1831467
<ubot5> Launchpad bug 1890178 in linux-aws-edge (Ubuntu) "autopkgtest fails 'rebuild' test due to missing/deleted spl-linux version in debian/dkms-versions" [Undecided,New] https://launchpad.net/bugs/1890178
<ubot5> Launchpad bug 1831467 in umockdev (Ubuntu Focal) "test-umockdev tests flaky on armhf (and sometimes other archs)" [Low,In progress] https://launchpad.net/bugs/1831467
<ddstreet> the linux-hwe-5.4 test failure is a timeout, but it's also armhf, so nothing surprising there, armhf is always slow
<ddstreet> well, our armhf-container-inside-arm64-instance is always slow, at least
<RikMills> vorlon: ack on pkg-kde-tools. probably versioning the lintian dep so it stays in proposed with the fixed lintian
-queuebot:#ubuntu-release- Unapproved: rpcbind (bionic-proposed/main) [0.2.3-0.6 => 0.2.3-0.6ubuntu0.18.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: rpcbind (xenial-proposed/main) [0.2.3-0.2ubuntu0.1 => 0.2.3-0.2ubuntu0.16.04.1] (core)
<mwhudson> argh json-c is entangled with boost?
<mwhudson> why was that not showing yesterday
<mwhudson> vorlon: has #include <> vs #include "" changed for gcc-10 i wonder?
-queuebot:#ubuntu-release- New binary: libtest-hexdifferences-perl [amd64] (groovy-proposed/none) [1.001-2] (no packageset)
-queuebot:#ubuntu-release- New binary: cava-alsa [amd64] (groovy-proposed/universe) [0.7.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mldonkey [amd64] (groovy-proposed/universe) [3.1.7-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libuev [amd64] (groovy-proposed/none) [2.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ayatana-indicator-datetime [amd64] (groovy-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: metamath-databases [amd64] (groovy-proposed/none) [0.0.0~20200715.git5b44899-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jc [amd64] (groovy-proposed/universe) [1.12.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: enki-aseba [amd64] (groovy-proposed/universe) [1:1.6.99-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wlogout [amd64] (groovy-proposed/none) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mldonkey [ppc64el] (groovy-proposed/universe) [3.1.7-2] (no packageset)
-queuebot:#ubuntu-release- New binary: nvidia-settings-tesla-450 [amd64] (groovy-proposed/none) [450.57-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mldonkey [s390x] (groovy-proposed/universe) [3.1.7-2] (no packageset)
-queuebot:#ubuntu-release- New binary: unison-2.48 [amd64] (groovy-proposed/none) [2.48.4-5] (no packageset)
-queuebot:#ubuntu-release- New binary: cava-alsa [ppc64el] (groovy-proposed/universe) [0.7.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ayatana-indicator-datetime [ppc64el] (groovy-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: enki-aseba [ppc64el] (groovy-proposed/universe) [1:1.6.99-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nvidia-settings-tesla-450 [ppc64el] (groovy-proposed/none) [450.57-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wlogout [ppc64el] (groovy-proposed/none) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cava-alsa [s390x] (groovy-proposed/universe) [0.7.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: unison-2.48 [ppc64el] (groovy-proposed/none) [2.48.4-5] (no packageset)
-queuebot:#ubuntu-release- New binary: librsb [ppc64el] (groovy-proposed/universe) [1.2.0.8+dfsg.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ayatana-indicator-datetime [s390x] (groovy-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: librsb [s390x] (groovy-proposed/universe) [1.2.0.8+dfsg.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: librsb [amd64] (groovy-proposed/universe) [1.2.0.8+dfsg.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libuev [s390x] (groovy-proposed/none) [2.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: unison-2.48 [s390x] (groovy-proposed/universe) [2.48.4-5] (no packageset)
-queuebot:#ubuntu-release- New binary: wlogout [s390x] (groovy-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: enki-aseba [s390x] (groovy-proposed/universe) [1:1.6.99-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kamailio [s390x] (groovy-proposed/universe) [5.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: kamailio [amd64] (groovy-proposed/universe) [5.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mldonkey [armhf] (groovy-proposed/universe) [3.1.7-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libuev [riscv64] (groovy-proposed/universe) [2.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mldonkey [arm64] (groovy-proposed/universe) [3.1.7-2] (no packageset)
-queuebot:#ubuntu-release- New binary: kamailio [ppc64el] (groovy-proposed/universe) [5.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: cava-alsa [arm64] (groovy-proposed/universe) [0.7.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libuev [arm64] (groovy-proposed/universe) [2.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cava-alsa [armhf] (groovy-proposed/universe) [0.7.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libuev [armhf] (groovy-proposed/universe) [2.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ayatana-indicator-datetime [armhf] (groovy-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cava-alsa [riscv64] (groovy-proposed/universe) [0.7.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: unison-2.48 [armhf] (groovy-proposed/universe) [2.48.4-5] (no packageset)
-queuebot:#ubuntu-release- New binary: wlogout [armhf] (groovy-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wlogout [arm64] (groovy-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cod-tools [s390x] (groovy-proposed/universe) [3.0.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: librsb [arm64] (groovy-proposed/universe) [1.2.0.8+dfsg.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ayatana-indicator-datetime [arm64] (groovy-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: unison-2.48 [arm64] (groovy-proposed/universe) [2.48.4-5] (no packageset)
-queuebot:#ubuntu-release- New binary: wlogout [riscv64] (groovy-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nvidia-settings-tesla-450 [arm64] (groovy-proposed/multiverse) [450.57-1] (no packageset)
-queuebot:#ubuntu-release- New binary: unison-2.48 [riscv64] (groovy-proposed/universe) [2.48.4-5] (no packageset)
-queuebot:#ubuntu-release- New binary: enki-aseba [arm64] (groovy-proposed/universe) [1:1.6.99-1] (no packageset)
-queuebot:#ubuntu-release- New binary: librsb [armhf] (groovy-proposed/universe) [1.2.0.8+dfsg.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ayatana-indicator-datetime [riscv64] (groovy-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cod-tools [amd64] (groovy-proposed/universe) [3.0.1+dfsg-1] (no packageset)
#ubuntu-release 2020-08-05
-queuebot:#ubuntu-release- New binary: kamailio [arm64] (groovy-proposed/universe) [5.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: cod-tools [ppc64el] (groovy-proposed/universe) [3.0.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kamailio [armhf] (groovy-proposed/universe) [5.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: enki-aseba [riscv64] (groovy-proposed/universe) [1:1.6.99-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mldonkey [riscv64] (groovy-proposed/universe) [3.1.7-2] (no packageset)
-queuebot:#ubuntu-release- New binary: cod-tools [arm64] (groovy-proposed/universe) [3.0.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: librsb [riscv64] (groovy-proposed/universe) [1.2.0.8+dfsg.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: cod-tools [armhf] (groovy-proposed/universe) [3.0.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted libglvnd [source] (focal-proposed) [1.3.1-1ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted zsys [source] (focal-proposed) [0.4.7]
-queuebot:#ubuntu-release- Unapproved: accepted pyflakes [source] (focal-proposed) [2.2.0-1~20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted pycodestyle [source] (focal-proposed) [2.6.0-1~20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted python-flake8 [source] (focal-proposed) [3.8.3-1~20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted flatpak [sync] (focal-proposed) [1.6.5-0ubuntu0.1]
-queuebot:#ubuntu-release- New binary: kamailio [riscv64] (groovy-proposed/universe) [5.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gitit [armhf] (groovy-proposed/universe) [0.13.0.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: base-files (bionic-proposed/main) [10.1ubuntu2.8 => 10.1ubuntu2.9] (core)
-queuebot:#ubuntu-release- New: accepted kamailio [amd64] (groovy-proposed) [5.4.0-2]
-queuebot:#ubuntu-release- New: accepted kamailio [armhf] (groovy-proposed) [5.4.0-2]
-queuebot:#ubuntu-release- New: accepted kamailio [riscv64] (groovy-proposed) [5.4.0-2]
-queuebot:#ubuntu-release- New: accepted kamailio [arm64] (groovy-proposed) [5.4.0-2]
-queuebot:#ubuntu-release- New: accepted kamailio [s390x] (groovy-proposed) [5.4.0-2]
-queuebot:#ubuntu-release- New: accepted kamailio [ppc64el] (groovy-proposed) [5.4.0-2]
-queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (bionic-proposed) [10.1ubuntu2.9]
-queuebot:#ubuntu-release- New: accepted librsb [amd64] (groovy-proposed) [1.2.0.8+dfsg.1-2]
-queuebot:#ubuntu-release- New: accepted librsb [armhf] (groovy-proposed) [1.2.0.8+dfsg.1-2]
-queuebot:#ubuntu-release- New: accepted librsb [riscv64] (groovy-proposed) [1.2.0.8+dfsg.1-2]
-queuebot:#ubuntu-release- New: accepted libtest-hexdifferences-perl [amd64] (groovy-proposed) [1.001-2]
-queuebot:#ubuntu-release- New: accepted libuev [arm64] (groovy-proposed) [2.3.1-1]
-queuebot:#ubuntu-release- New: accepted libuev [riscv64] (groovy-proposed) [2.3.1-1]
-queuebot:#ubuntu-release- New: accepted librsb [arm64] (groovy-proposed) [1.2.0.8+dfsg.1-2]
-queuebot:#ubuntu-release- New: accepted librsb [s390x] (groovy-proposed) [1.2.0.8+dfsg.1-2]
-queuebot:#ubuntu-release- New: accepted libuev [armhf] (groovy-proposed) [2.3.1-1]
-queuebot:#ubuntu-release- New: accepted librsb [ppc64el] (groovy-proposed) [1.2.0.8+dfsg.1-2]
-queuebot:#ubuntu-release- New: accepted libuev [s390x] (groovy-proposed) [2.3.1-1]
-queuebot:#ubuntu-release- New: accepted libuev [amd64] (groovy-proposed) [2.3.1-1]
-queuebot:#ubuntu-release- New: accepted enki-aseba [amd64] (groovy-proposed) [1:1.6.99-1]
-queuebot:#ubuntu-release- New: accepted enki-aseba [ppc64el] (groovy-proposed) [1:1.6.99-1]
-queuebot:#ubuntu-release- New: accepted enki-aseba [s390x] (groovy-proposed) [1:1.6.99-1]
-queuebot:#ubuntu-release- New: accepted enki-aseba [arm64] (groovy-proposed) [1:1.6.99-1]
-queuebot:#ubuntu-release- New: accepted enki-aseba [riscv64] (groovy-proposed) [1:1.6.99-1]
-queuebot:#ubuntu-release- New: accepted ayatana-indicator-datetime [arm64] (groovy-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted ayatana-indicator-datetime [ppc64el] (groovy-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted ayatana-indicator-datetime [s390x] (groovy-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted ayatana-indicator-datetime [armhf] (groovy-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted ayatana-indicator-datetime [riscv64] (groovy-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted mldonkey [amd64] (groovy-proposed) [3.1.7-1]
-queuebot:#ubuntu-release- New: accepted mldonkey [armhf] (groovy-proposed) [3.1.7-1]
-queuebot:#ubuntu-release- New: accepted mldonkey [s390x] (groovy-proposed) [3.1.7-1]
-queuebot:#ubuntu-release- New: accepted mldonkey [arm64] (groovy-proposed) [3.1.7-2]
-queuebot:#ubuntu-release- New: accepted mldonkey [ppc64el] (groovy-proposed) [3.1.7-2]
-queuebot:#ubuntu-release- New: accepted mldonkey [s390x] (groovy-proposed) [3.1.7-2]
-queuebot:#ubuntu-release- New: accepted mldonkey [arm64] (groovy-proposed) [3.1.7-1]
-queuebot:#ubuntu-release- New: accepted mldonkey [amd64] (groovy-proposed) [3.1.7-2]
-queuebot:#ubuntu-release- New: accepted mldonkey [riscv64] (groovy-proposed) [3.1.7-2]
-queuebot:#ubuntu-release- New: accepted mldonkey [ppc64el] (groovy-proposed) [3.1.7-1]
-queuebot:#ubuntu-release- New: accepted mldonkey [armhf] (groovy-proposed) [3.1.7-2]
-queuebot:#ubuntu-release- New: accepted ayatana-indicator-datetime [amd64] (groovy-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted cava-alsa [arm64] (groovy-proposed) [0.7.2-1]
-queuebot:#ubuntu-release- New: accepted cava-alsa [ppc64el] (groovy-proposed) [0.7.2-1]
-queuebot:#ubuntu-release- New: accepted cava-alsa [s390x] (groovy-proposed) [0.7.2-1]
-queuebot:#ubuntu-release- New: accepted cava-alsa [amd64] (groovy-proposed) [0.7.2-1]
-queuebot:#ubuntu-release- New: accepted cava-alsa [riscv64] (groovy-proposed) [0.7.2-1]
-queuebot:#ubuntu-release- New: accepted cava-alsa [armhf] (groovy-proposed) [0.7.2-1]
-queuebot:#ubuntu-release- New: accepted wlogout [amd64] (groovy-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted wlogout [armhf] (groovy-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted wlogout [riscv64] (groovy-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted wlogout [arm64] (groovy-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted wlogout [s390x] (groovy-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted wlogout [ppc64el] (groovy-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted jc [amd64] (groovy-proposed) [1.12.1-1]
-queuebot:#ubuntu-release- New: accepted nvidia-settings-tesla-450 [amd64] (groovy-proposed) [450.57-1]
-queuebot:#ubuntu-release- New: accepted nvidia-settings-tesla-450 [ppc64el] (groovy-proposed) [450.57-1]
-queuebot:#ubuntu-release- New: accepted metamath-databases [amd64] (groovy-proposed) [0.0.0~20200715.git5b44899-1]
-queuebot:#ubuntu-release- New: accepted nvidia-settings-tesla-450 [arm64] (groovy-proposed) [450.57-1]
-queuebot:#ubuntu-release- New: accepted unison-2.48 [amd64] (groovy-proposed) [2.48.4-5]
-queuebot:#ubuntu-release- New: accepted unison-2.48 [armhf] (groovy-proposed) [2.48.4-5]
-queuebot:#ubuntu-release- New: accepted unison-2.48 [riscv64] (groovy-proposed) [2.48.4-5]
-queuebot:#ubuntu-release- New: accepted unison-2.48 [arm64] (groovy-proposed) [2.48.4-5]
-queuebot:#ubuntu-release- New: accepted unison-2.48 [s390x] (groovy-proposed) [2.48.4-5]
-queuebot:#ubuntu-release- New: accepted unison-2.48 [ppc64el] (groovy-proposed) [2.48.4-5]
<xnox> vorlon:  ack.
<xnox> vorlon:  i think we do want to make shim builds to spit out public portion of the ephemeral cert & detached signatures of things it signed. Such that we can provide docker container with rebuild instructions to reproducibly rebuild shim for shim-review process.
-queuebot:#ubuntu-release- Unapproved: apport (focal-proposed/main) [2.20.11-0ubuntu27.6 => 2.20.11-0ubuntu27.7] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: ubiquity (bionic-proposed/main) [18.04.14.14 => 18.04.14.15] (core)
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (bionic-proposed) [18.04.14.15]
-queuebot:#ubuntu-release- New binary: cod-tools [riscv64] (groovy-proposed/universe) [3.0.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted cod-tools [amd64] (groovy-proposed) [3.0.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted cod-tools [armhf] (groovy-proposed) [3.0.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted cod-tools [riscv64] (groovy-proposed) [3.0.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted cod-tools [arm64] (groovy-proposed) [3.0.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted cod-tools [s390x] (groovy-proposed) [3.0.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted cod-tools [ppc64el] (groovy-proposed) [3.0.1+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: base-files (xenial-proposed/main) [9.4ubuntu4.11 => 9.4ubuntu4.12] (core)
-queuebot:#ubuntu-release- New: accepted golang-github-gcp-guest-logging-go [source] (groovy-proposed) [0.0~git20200113.6cbb518-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (xenial-proposed) [9.4ubuntu4.12]
-queuebot:#ubuntu-release- New binary: golang-github-gcp-guest-logging-go [amd64] (groovy-proposed/none) [0.0~git20200113.6cbb518-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ubiquity (xenial-proposed/main) [2.21.63.10 => 2.21.63.11] (core)
-queuebot:#ubuntu-release- New source: motd-news-config (groovy-proposed/primary) [1]
<ahasenack> vorlon: ^ motd-news-config
<ahasenack> vorlon: if/after that lands, then I have ubuntu-meta and base-files
<ahasenack> if you prefer, I can upload them now, but they won't migrate
-queuebot:#ubuntu-release- New binary: lrslib [amd64] (groovy-proposed/universe) [0.71-6] (no packageset)
-queuebot:#ubuntu-release- New binary: lrslib [s390x] (groovy-proposed/universe) [0.71-6] (no packageset)
-queuebot:#ubuntu-release- New binary: lrslib [ppc64el] (groovy-proposed/universe) [0.71-6] (no packageset)
-queuebot:#ubuntu-release- New binary: lrslib [arm64] (groovy-proposed/universe) [0.71-6] (no packageset)
-queuebot:#ubuntu-release- New binary: lrslib [armhf] (groovy-proposed/universe) [0.71-6] (no packageset)
-queuebot:#ubuntu-release- New binary: lrslib [riscv64] (groovy-proposed/universe) [0.71-6] (no packageset)
<rbalint> sil2100, please merge those for glibc's next upload https://code.launchpad.net/~rbalint/britney/hints-ubuntu/+merge/388675
<tumbleweed> seb128: hah, I was just about to apply that automake patch, thanks :)
<seb128> tumbleweed, yw!
<vorlon> sil2100: I don't see any updated autopkgtest hints for the systemd bionic SRU you accepted, could we have those marked so that future SRUs don't trip over the same things?
-queuebot:#ubuntu-release- New: accepted lrslib [riscv64] (groovy-proposed) [0.71-6]
<vorlon> ahasenack: I wonder if motd-news-config should be built from base-files source instead, to keep it close to the code whose behavior it modifies
-queuebot:#ubuntu-release- New: accepted gitit [armhf] (groovy-proposed) [0.13.0.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted lrslib [amd64] (groovy-proposed) [0.71-6]
-queuebot:#ubuntu-release- New: accepted lrslib [armhf] (groovy-proposed) [0.71-6]
-queuebot:#ubuntu-release- New: accepted lrslib [s390x] (groovy-proposed) [0.71-6]
-queuebot:#ubuntu-release- New: accepted gitit [ppc64el] (groovy-proposed) [0.13.0.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted lrslib [ppc64el] (groovy-proposed) [0.71-6]
-queuebot:#ubuntu-release- New: accepted lrslib [arm64] (groovy-proposed) [0.71-6]
-queuebot:#ubuntu-release- New: accepted gitit [amd64] (groovy-proposed) [0.13.0.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted gitit [s390x] (groovy-proposed) [0.13.0.0+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: glibc (focal-proposed/main) [2.31-0ubuntu9 => 2.31-0ubuntu9.1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New: accepted google-osconfig-agent [source] (groovy-proposed) [20200625.00-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted google-guest-agent [source] (groovy-proposed) [20200617.00-0ubuntu1]
<ahasenack> vorlon: that's a new approach
<ahasenack> vorlon: do you prefer that?
<vorlon> ahasenack: I do think there's less risk of things getting mistakenly out of sync if we do that.  It increases the delta vs Debian, but we already have a permanent delta and it shouldn't be problematic for merging
<ahasenack> vorlon: ok, let me work on that. Any other comment regarding the contents, like the postinst?
<ahasenack> which I will copy
<vorlon> ahasenack: I haven't looked at the contents yet :)
<ahasenack> can you, just do avoid another round trip?
<vorlon> sure
<ahasenack> or do you prefer I do the packaging change first
<vorlon> ahasenack: looks ok to me if it works
<ahasenack> vorlon: my testing was this: https://pastebin.ubuntu.com/p/JkV2ZFSVy6/
<vorlon> ahasenack: yep, looks good
<ahasenack> ok, thanks
<vorlon> ahasenack: oh, what about a test of upgrading ubuntu-server?
<ahasenack> vorlon: sounds good, it will pull in motd-news-config and force upgrade base-files
<ahasenack> vorlon: the relationships I have in groovy are: https://pastebin.ubuntu.com/p/P8BQrSwVdS/
 * vorlon nods
<ahasenack> motd-news-config was v1 there, will be the same version as base-files
<arnatious> Overseeing an SRU in proposed that caused an autopkgtest failure, anyone willing to guide me through the process of diagnosing/fixing?
<ahasenack> arnatious: did you get to the logs yet?
<ahasenack> arnatious: or you just got the notification that it failed?
<arnatious> ahasenack yeah, logs are up
<ahasenack> arnatious: can you determine if the failure is real and a result of the SRU?
<arnatious> ahasenack yes, the SRU causes a test failure in one package, some of the others are flakey or seem unrelated (files not found when initializing the test)
<arnatious> or just segfaulting right after saying "all tests passed"
<arnatious> SRU is for a python package, specifically flake8, a linter
<ahasenack> arnatious: are you the author of the sru?
<arnatious> ahasenack ish. Its a backport of a future version
<ahasenack> well, segfaults are bad
<ahasenack> next step would be to try to reproduce the error locally
<ahasenack> you can also check the history of that test, see if it was segfaulting before
<ahasenack> btw, this belongs in #ubuntu-devel, not here, sorry for only now noticing it
<arnatious> Ah darn sorry going off of https://wiki.ubuntu.com/StableReleaseUpdates#Publishing
<arnatious> Hopping over there
-queuebot:#ubuntu-release- New binary: mercantile [amd64] (groovy-proposed/none) [1.1.5-1] (no packageset)
#ubuntu-release 2020-08-06
-queuebot:#ubuntu-release- New binary: polymake [s390x] (groovy-proposed/universe) [4.1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: polymake [amd64] (groovy-proposed/universe) [4.1-4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: apport (bionic-proposed/main) [2.20.9-0ubuntu7.16 => 2.20.9-0ubuntu7.17] (core)
-queuebot:#ubuntu-release- New binary: polymake [ppc64el] (groovy-proposed/universe) [4.1-4] (no packageset)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Focal 20.04.1] has been marked as ready
-queuebot:#ubuntu-release- New binary: polymake [armhf] (groovy-proposed/universe) [4.1-4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted rtl8821ce [source] (focal-proposed) [5.5.2.1-0ubuntu4~20.04.2]
-queuebot:#ubuntu-release- New binary: polymake [arm64] (groovy-proposed/universe) [4.1-4] (no packageset)
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Focal 20.04.1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Focal 20.04.1] has been marked as ready
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (xenial-proposed) [2.21.63.11]
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Focal 20.04.1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Focal 20.04.1] has been marked as ready
<Laney> sil2100: keep an eye out for problems with the torrents, I think this is the first time that code will have been used for real
<Laney> also the first time we'll have tried to sync torrents to the tracker from the new machine, etc
<sil2100> Laney: will do!
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Focal 20.04.1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Focal 20.04.1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Focal 20.04.1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Focal 20.04.1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Focal 20.04.1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Focal 20.04.1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Focal 20.04.1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity arm64 [Focal 20.04.1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity ppc64el [Focal 20.04.1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Focal 20.04.1] has been marked as ready
-queuebot:#ubuntu-release- New: accepted intervals [source] (groovy-proposed) [0.8.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted intervals [source] (groovy-proposed) [0.9.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: intervals [amd64] (groovy-proposed/none) [0.9.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: intervals [amd64] (groovy-proposed/none) [0.8.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted intervals [amd64] (groovy-proposed) [0.8.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted intervals [amd64] (groovy-proposed) [0.9.0-0ubuntu1]
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Focal 20.04.1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Focal 20.04.1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Focal 20.04.1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Focal 20.04.1] has been marked as ready
-queuebot:#ubuntu-release- New: accepted raspberrypi-userland [source] (groovy-proposed) [0~20200520+git2fe4ca3-0ubuntu1]
<rbalint> Laney, sil2100, please merge those for glibc's next upload https://code.launchpad.net/~rbalint/britney/hints-ubuntu/+merge/388675
-queuebot:#ubuntu-release- Unapproved: grub2 (groovy-proposed/main) [2.04-1ubuntu27 => 2.04-1ubuntu27] (core)
-queuebot:#ubuntu-release- New binary: raspberrypi-userland [arm64] (groovy-proposed/none) [0~20200520+git2fe4ca3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: raspberrypi-userland [armhf] (groovy-proposed/none) [0~20200520+git2fe4ca3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: grub2 (groovy-proposed/main) [2.04-1ubuntu27 => 2.04-1ubuntu27] (core)
<seb128> rbalint, hey, did you have any chance to look at systemd and the new plymouth?
<rbalint> i've left a comment about the autopkgtest in LP: #1886886, looking at LP: #1871641
<ubot5> Launchpad bug 1886886 in plymouth (Ubuntu) "Plymouth 0.9.5 release" [Wishlist,Fix committed] https://launchpad.net/bugs/1886886
<ubot5> Launchpad bug 1871641 in plymouth (Ubuntu) "Ubuntu never finishes booting: A start job is running for Hold until boot process finishes up (3min 7s / no limit) -- removing 'splash' kernel parm fixes it" [High,Confirmed] https://launchpad.net/bugs/1871641
-queuebot:#ubuntu-release- New: accepted raspberrypi-userland [arm64] (groovy-proposed) [0~20200520+git2fe4ca3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted raspberrypi-userland [armhf] (groovy-proposed) [0~20200520+git2fe4ca3-0ubuntu1]
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi [Focal 20.04.1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi [Focal 20.04.1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Focal 20.04.1] has been marked as ready
-queuebot:#ubuntu-release- New source: microcode-initrd (groovy-proposed/primary) [1]
<rbalint> seb128, ah i see today is your archive admin day https://wiki.ubuntu.com/ArchiveAdministration#Archive_days , could you please accept golang-github-gcp-guest-logging-go in groovy NEW ?
<seb128> rbalint, done
<seb128> rbalint, thanks for the plymouth reply, I was subscribed to the new version bug and hadn't see it before
-queuebot:#ubuntu-release- New: accepted golang-github-gcp-guest-logging-go [amd64] (groovy-proposed) [0.0~git20200113.6cbb518-0ubuntu1]
<stgraber> https://releases.ubuntu.com/focal/ubuntu-20.04-live-server-amd64.iso is giving a 403, intentional?
<sil2100> We're in the middle of releasing
<sil2100> (sync-mirrors is disabled but yeah)
<stgraber> well, that's the oriignal 20.04 image though :)
<sil2100> It will be moved to old-releases as per the process!
-queuebot:#ubuntu-release- New: accepted polymake [arm64] (groovy-proposed) [4.1-4]
-queuebot:#ubuntu-release- New: accepted polymake [armhf] (groovy-proposed) [4.1-4]
-queuebot:#ubuntu-release- New: accepted mercantile [amd64] (groovy-proposed) [1.1.5-1]
-queuebot:#ubuntu-release- New: accepted polymake [ppc64el] (groovy-proposed) [4.1-4]
-queuebot:#ubuntu-release- New: accepted polymake [amd64] (groovy-proposed) [4.1-4]
-queuebot:#ubuntu-release- New: accepted polymake [s390x] (groovy-proposed) [4.1-4]
<Laney> chmodding sync-mirrors doesn't work, we should fix our process documentation :S
<sil2100> haha, yeah
<sil2100> Laney: what's the best trick to disable it then?
<sil2100> Anyway, 20.04.1 is out-ish!
<Laney> \o/
<sil2100> Torrents seem to be working
<Laney> I think you have to add a return into sync_mirrors() or whatever the function is
<sil2100> Had to uh, fix cdimage code to make torrent creation working, not sure how it worked on nusakan before!
<Laney> but we should provide a proper handle for that
<Laney> heh
<sil2100> Laney: +1
<Laney> it probably broke with the mktorrent change, I guess the old version worked ok with the flags it had
<Laney> hope the testsuite still passes ;-)
<sil2100> Laney: yeah, though when I tried the same command on the old nusakan, got the same result - which is why I have no idea what caused it to work as expected before, but actually nvm!
-queuebot:#ubuntu-release- New binary: google-osconfig-agent [amd64] (groovy-proposed/universe) [20200625.00-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: google-guest-agent [ppc64el] (groovy-proposed/universe) [20200617.00-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: google-guest-agent [amd64] (groovy-proposed/universe) [20200617.00-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: google-osconfig-agent [ppc64el] (groovy-proposed/universe) [20200625.00-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: google-guest-agent [s390x] (groovy-proposed/universe) [20200617.00-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: google-osconfig-agent [s390x] (groovy-proposed/universe) [20200625.00-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: cub [amd64] (groovy-proposed/universe) [1.9.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fcitx5-material-color [amd64] (groovy-proposed/universe) [0.0~git20200729.321f214-1] (no packageset)
-queuebot:#ubuntu-release- New binary: google-auth-oauthlib [amd64] (groovy-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: google-osconfig-agent [arm64] (groovy-proposed/universe) [20200625.00-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: annexremote [amd64] (groovy-proposed/universe) [1.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: axc [amd64] (groovy-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cwlformat [amd64] (groovy-proposed/universe) [2020.05.19-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gvm [amd64] (groovy-proposed/universe) [11.0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cachy [amd64] (groovy-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-golang-freetype [amd64] (groovy-proposed/universe) [0.0~git20170609.e2365df+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-creekorful-mvnparser [amd64] (groovy-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-rsc-pdf [amd64] (groovy-proposed/universe) [0.1.0+git20180525.c47d69c-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-less-loader [amd64] (groovy-proposed/universe) [5.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: project-el [amd64] (groovy-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-proxy-from-env [amd64] (groovy-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyjdata [amd64] (groovy-proposed/universe) [0.3.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-ansi-colors [amd64] (groovy-proposed/universe) [4.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-gvm [amd64] (groovy-proposed/universe) [1.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: raku-tap-harness [amd64] (groovy-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pybj [amd64] (groovy-proposed/universe) [0.2.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: raku-getopt-long [amd64] (groovy-proposed/universe) [0.1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: google-android-emulator-installer [amd64] (groovy-proposed/multiverse) [30.0.12] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-biocsingular [amd64] (groovy-proposed/universe) [1.4.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wlr-randr [amd64] (groovy-proposed/universe) [0.0.0+git20200721-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-unbzip2-stream [amd64] (groovy-proposed/universe) [1.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-suppdists [amd64] (groovy-proposed/universe) [1.1-9.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: axc [ppc64el] (groovy-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyjdata [ppc64el] (groovy-proposed/universe) [0.3.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-webpacker [amd64] (groovy-proposed/universe) [4.0.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: selint [amd64] (groovy-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tllist [amd64] (groovy-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wlr-randr [ppc64el] (groovy-proposed/universe) [0.0.0+git20200721-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pybj [ppc64el] (groovy-proposed/universe) [0.2.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: scrappie [amd64] (groovy-proposed/universe) [1.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tllist [ppc64el] (groovy-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: redmine-plugin-redhopper [amd64] (groovy-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: selint [ppc64el] (groovy-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-suppdists [ppc64el] (groovy-proposed/universe) [1.1-9.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: axc [s390x] (groovy-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-experimenthub [amd64] (groovy-proposed/universe) [1.14.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-biocsingular [ppc64el] (groovy-proposed/universe) [1.4.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: relacy [amd64] (groovy-proposed/universe) [0.0+git20191025.acc09bb-1] (no packageset)
-queuebot:#ubuntu-release- New binary: google-guest-agent [arm64] (groovy-proposed/universe) [20200617.00-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-bimap [ppc64el] (groovy-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-template-haskell-compat-v0208 [ppc64el] (groovy-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: google-guest-agent [armhf] (groovy-proposed/universe) [20200617.00-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: pybj [s390x] (groovy-proposed/universe) [0.2.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-template-haskell-compat-v0208 [amd64] (groovy-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyjdata [s390x] (groovy-proposed/universe) [0.3.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tllist [s390x] (groovy-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-suppdists [s390x] (groovy-proposed/universe) [1.1-9.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: selint [s390x] (groovy-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wlr-randr [s390x] (groovy-proposed/universe) [0.0.0+git20200721-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-bimap [amd64] (groovy-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-biocsingular [s390x] (groovy-proposed/universe) [1.4.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-bimap [s390x] (groovy-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wlr-randr [riscv64] (groovy-proposed/universe) [0.0.0+git20200721-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-template-haskell-compat-v0208 [s390x] (groovy-proposed/universe) [0.1.2-1] (no packageset)
* sil2100 changed the topic of #ubuntu-release to: Released: Focal 20.04.1, Bionic 18.04.4 | Archive: Open | Highlight ubuntu-archive for archive admin help | Groovy Release Coordination | We accept payment in cash, cheque or gin | melius malum quod cognoscis
-queuebot:#ubuntu-release- New binary: google-osconfig-agent [armhf] (groovy-proposed/universe) [20200625.00-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: tllist [riscv64] (groovy-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: axc [riscv64] (groovy-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyjdata [riscv64] (groovy-proposed/universe) [0.3.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pybj [riscv64] (groovy-proposed/universe) [0.2.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: selint [riscv64] (groovy-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: musescore2 [s390x] (groovy-proposed/universe) [2.3.2+dfsg3-9] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-suppdists [riscv64] (groovy-proposed/universe) [1.1-9.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-ghc-exactprint [amd64] (groovy-proposed/universe) [0.6.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: musescore2 [ppc64el] (groovy-proposed/universe) [2.3.2+dfsg3-9] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-ghc-exactprint [s390x] (groovy-proposed/universe) [0.6.2-1] (no packageset)
<bdmurray> vorlon: given python-ntlm has been removed from debian can the same be done in Ubuntu now? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=937959
<ubot5> Debian bug 937959 in src:python-ntlm "python-ntlm: Python2 removal in sid/bullseye" [Serious,Fixed]
-queuebot:#ubuntu-release- New binary: r-bioc-biocsingular [riscv64] (groovy-proposed/universe) [1.4.0+ds-1] (no packageset)
<tumbleweed> bdmurray: given it didn't build, seems pretty safe :P
-queuebot:#ubuntu-release- New binary: google-osconfig-agent [riscv64] (groovy-proposed/universe) [20200625.00-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-ghc-exactprint [ppc64el] (groovy-proposed/universe) [0.6.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: axc [armhf] (groovy-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-template-haskell-compat-v0208 [riscv64] (groovy-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: axc [arm64] (groovy-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pybj [arm64] (groovy-proposed/universe) [0.2.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyjdata [arm64] (groovy-proposed/universe) [0.3.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pybj [armhf] (groovy-proposed/universe) [0.2.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyjdata [armhf] (groovy-proposed/universe) [0.3.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-suppdists [armhf] (groovy-proposed/universe) [1.1-9.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-biocsingular [arm64] (groovy-proposed/universe) [1.4.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tllist [arm64] (groovy-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: selint [armhf] (groovy-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tllist [armhf] (groovy-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-biocsingular [armhf] (groovy-proposed/universe) [1.4.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: selint [arm64] (groovy-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wlr-randr [armhf] (groovy-proposed/universe) [0.0.0+git20200721-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-suppdists [arm64] (groovy-proposed/universe) [1.1-9.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wlr-randr [arm64] (groovy-proposed/universe) [0.0.0+git20200721-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-bimap [arm64] (groovy-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-template-haskell-compat-v0208 [armhf] (groovy-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-template-haskell-compat-v0208 [arm64] (groovy-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-bimap [riscv64] (groovy-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-bimap [armhf] (groovy-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: musescore2 [amd64] (groovy-proposed/universe) [2.3.2+dfsg3-9] (no packageset)
-queuebot:#ubuntu-release- New binary: musescore2 [armhf] (groovy-proposed/universe) [2.3.2+dfsg3-9] (no packageset)
-queuebot:#ubuntu-release- New binary: musescore2 [arm64] (groovy-proposed/universe) [2.3.2+dfsg3-9] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-ghc-exactprint [arm64] (groovy-proposed/universe) [0.6.2-1] (no packageset)
<vorlon> bdmurray: yes; I'm running process-removals now
-queuebot:#ubuntu-release- New: accepted haskell-ghc-exactprint [arm64] (groovy-proposed) [0.6.2-1]
-queuebot:#ubuntu-release- New: accepted musescore2 [arm64] (groovy-proposed) [2.3.2+dfsg3-9]
-queuebot:#ubuntu-release- New: accepted haskell-bimap [arm64] (groovy-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-bimap [riscv64] (groovy-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-template-haskell-compat-v0208 [armhf] (groovy-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted musescore2 [armhf] (groovy-proposed) [2.3.2+dfsg3-9]
-queuebot:#ubuntu-release- New: accepted pybj [armhf] (groovy-proposed) [0.2.6-1]
-queuebot:#ubuntu-release- New: accepted pyjdata [armhf] (groovy-proposed) [0.3.6-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-biocsingular [armhf] (groovy-proposed) [1.4.0+ds-1]
-queuebot:#ubuntu-release- New: accepted r-cran-suppdists [armhf] (groovy-proposed) [1.1-9.5-1]
-queuebot:#ubuntu-release- New: accepted selint [armhf] (groovy-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted tllist [armhf] (groovy-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-bimap [armhf] (groovy-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted musescore2 [amd64] (groovy-proposed) [2.3.2+dfsg3-9]
-queuebot:#ubuntu-release- New: accepted pyjdata [arm64] (groovy-proposed) [0.3.6-1]
-queuebot:#ubuntu-release- New: accepted r-cran-suppdists [arm64] (groovy-proposed) [1.1-9.5-1]
-queuebot:#ubuntu-release- New: accepted tllist [arm64] (groovy-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted wlr-randr [armhf] (groovy-proposed) [0.0.0+git20200721-1]
-queuebot:#ubuntu-release- New binary: node-less-loader [amd64] (groovy-proposed/universe) [5.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: project-el [amd64] (groovy-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyjdata [amd64] (groovy-proposed/universe) [0.3.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: raku-getopt-long [amd64] (groovy-proposed/universe) [0.1.6-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-template-haskell-compat-v0208 [arm64] (groovy-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-biocsingular [arm64] (groovy-proposed) [1.4.0+ds-1]
-queuebot:#ubuntu-release- New: accepted wlr-randr [arm64] (groovy-proposed) [0.0.0+git20200721-1]
-queuebot:#ubuntu-release- New binary: node-proxy-from-env [amd64] (groovy-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-gvm [amd64] (groovy-proposed/universe) [1.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted pybj [arm64] (groovy-proposed) [0.2.6-1]
-queuebot:#ubuntu-release- New binary: node-ansi-colors [amd64] (groovy-proposed/universe) [4.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: raku-tap-harness [amd64] (groovy-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted selint [arm64] (groovy-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New binary: pybj [amd64] (groovy-proposed/universe) [0.2.6-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted axc [arm64] (groovy-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted axc [riscv64] (groovy-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-bimap [s390x] (groovy-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-ghc-exactprint [ppc64el] (groovy-proposed) [0.6.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-template-haskell-compat-v0208 [riscv64] (groovy-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted musescore2 [ppc64el] (groovy-proposed) [2.3.2+dfsg3-9]
-queuebot:#ubuntu-release- New: accepted pybj [riscv64] (groovy-proposed) [0.2.6-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-biocsingular [riscv64] (groovy-proposed) [1.4.0+ds-1]
-queuebot:#ubuntu-release- New: accepted r-cran-suppdists [riscv64] (groovy-proposed) [1.1-9.5-1]
-queuebot:#ubuntu-release- New: accepted selint [s390x] (groovy-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted axc [armhf] (groovy-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-ghc-exactprint [amd64] (groovy-proposed) [0.6.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-template-haskell-compat-v0208 [s390x] (groovy-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted pyjdata [riscv64] (groovy-proposed) [0.3.6-1]
-queuebot:#ubuntu-release- New: accepted selint [riscv64] (groovy-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted wlr-randr [riscv64] (groovy-proposed) [0.0.0+git20200721-1]
-queuebot:#ubuntu-release- New binary: google-guest-agent [ppc64el] (groovy-proposed/universe) [20200617.00-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: google-osconfig-agent [amd64] (groovy-proposed/universe) [20200625.00-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: google-osconfig-agent [s390x] (groovy-proposed/universe) [20200625.00-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-bimap [amd64] (groovy-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted musescore2 [s390x] (groovy-proposed) [2.3.2+dfsg3-9]
-queuebot:#ubuntu-release- New: accepted tllist [riscv64] (groovy-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New binary: google-guest-agent [s390x] (groovy-proposed/universe) [20200617.00-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New source: microcode-initrd (groovy-proposed/primary) [1]
-queuebot:#ubuntu-release- New: accepted haskell-ghc-exactprint [s390x] (groovy-proposed) [0.6.2-1]
-queuebot:#ubuntu-release- New binary: google-guest-agent [amd64] (groovy-proposed/universe) [20200617.00-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted r-bioc-biocsingular [s390x] (groovy-proposed) [1.4.0+ds-1]
-queuebot:#ubuntu-release- New binary: google-osconfig-agent [ppc64el] (groovy-proposed/universe) [20200625.00-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted axc [s390x] (groovy-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-template-haskell-compat-v0208 [amd64] (groovy-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted pybj [ppc64el] (groovy-proposed) [0.2.6-1]
-queuebot:#ubuntu-release- New: accepted pyjdata [s390x] (groovy-proposed) [0.3.6-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-experimenthub [amd64] (groovy-proposed) [1.14.0+ds-1]
-queuebot:#ubuntu-release- New: accepted r-cran-suppdists [s390x] (groovy-proposed) [1.1-9.5-1]
-queuebot:#ubuntu-release- New: accepted ruby-webpacker [amd64] (groovy-proposed) [4.0.7-1]
-queuebot:#ubuntu-release- New: accepted tllist [s390x] (groovy-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-bimap [ppc64el] (groovy-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted pybj [s390x] (groovy-proposed) [0.2.6-1]
-queuebot:#ubuntu-release- New: accepted r-cran-suppdists [ppc64el] (groovy-proposed) [1.1-9.5-1]
-queuebot:#ubuntu-release- New: accepted selint [ppc64el] (groovy-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-template-haskell-compat-v0208 [ppc64el] (groovy-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted relacy [amd64] (groovy-proposed) [0.0+git20191025.acc09bb-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-biocsingular [ppc64el] (groovy-proposed) [1.4.0+ds-1]
-queuebot:#ubuntu-release- New: accepted wlr-randr [s390x] (groovy-proposed) [0.0.0+git20200721-1]
-queuebot:#ubuntu-release- New: accepted axc [ppc64el] (groovy-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted pyjdata [ppc64el] (groovy-proposed) [0.3.6-1]
-queuebot:#ubuntu-release- New: accepted r-cran-suppdists [amd64] (groovy-proposed) [1.1-9.5-1]
-queuebot:#ubuntu-release- New: accepted scrappie [amd64] (groovy-proposed) [1.4.2-1]
-queuebot:#ubuntu-release- New: accepted tllist [amd64] (groovy-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted wlr-randr [ppc64el] (groovy-proposed) [0.0.0+git20200721-1]
-queuebot:#ubuntu-release- New: accepted google-android-emulator-installer [amd64] (groovy-proposed) [30.0.12]
-queuebot:#ubuntu-release- New: accepted redmine-plugin-redhopper [amd64] (groovy-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted tllist [ppc64el] (groovy-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-biocsingular [amd64] (groovy-proposed) [1.4.0+ds-1]
-queuebot:#ubuntu-release- New: accepted selint [amd64] (groovy-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted google-osconfig-agent [amd64] (groovy-proposed) [20200625.00-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted google-osconfig-agent [armhf] (groovy-proposed) [20200625.00-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted google-osconfig-agent [riscv64] (groovy-proposed) [20200625.00-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted google-osconfig-agent [arm64] (groovy-proposed) [20200625.00-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted google-osconfig-agent [s390x] (groovy-proposed) [20200625.00-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted google-osconfig-agent [ppc64el] (groovy-proposed) [20200625.00-0ubuntu1]
<sergiodj> hi there, can any archive-admin take a look at the telegraf package that's on the NEW queue, please?  I'd like to get it included in the universe so that I can start the MIR process ASAP.  TIA!
-queuebot:#ubuntu-release- New: accepted node-ansi-colors [amd64] (groovy-proposed) [4.1.1-1]
-queuebot:#ubuntu-release- New: accepted project-el [amd64] (groovy-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted pyjdata [amd64] (groovy-proposed) [0.3.6-1]
-queuebot:#ubuntu-release- New: accepted raku-getopt-long [amd64] (groovy-proposed) [0.1.6-1]
-queuebot:#ubuntu-release- New: accepted wlr-randr [amd64] (groovy-proposed) [0.0.0+git20200721-1]
-queuebot:#ubuntu-release- New: accepted node-unbzip2-stream [amd64] (groovy-proposed) [1.4.2-1]
-queuebot:#ubuntu-release- New: accepted python-gvm [amd64] (groovy-proposed) [1.2.0-2]
-queuebot:#ubuntu-release- New: accepted pybj [amd64] (groovy-proposed) [0.2.6-1]
-queuebot:#ubuntu-release- New: accepted raku-tap-harness [amd64] (groovy-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted annexremote [amd64] (groovy-proposed) [1.4.3-1]
-queuebot:#ubuntu-release- New: accepted cachy [amd64] (groovy-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-creekorful-mvnparser [amd64] (groovy-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted golang-rsc-pdf [amd64] (groovy-proposed) [0.1.0+git20180525.c47d69c-2]
-queuebot:#ubuntu-release- New: accepted node-less-loader [amd64] (groovy-proposed) [5.0.1-1]
-queuebot:#ubuntu-release- New: accepted axc [amd64] (groovy-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted golang-github-golang-freetype [amd64] (groovy-proposed) [0.0~git20170609.e2365df+dfsg-2]
-queuebot:#ubuntu-release- New: accepted node-proxy-from-env [amd64] (groovy-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted cwlformat [amd64] (groovy-proposed) [2020.05.19-2]
-queuebot:#ubuntu-release- New: accepted gvm [amd64] (groovy-proposed) [11.0.1]
-queuebot:#ubuntu-release- New: accepted cub [amd64] (groovy-proposed) [1.9.8-1]
-queuebot:#ubuntu-release- New: accepted google-auth-oauthlib [amd64] (groovy-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New binary: fcft [s390x] (groovy-proposed/universe) [2.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted fcitx5-material-color [amd64] (groovy-proposed) [0.0~git20200729.321f214-1]
-queuebot:#ubuntu-release- New binary: fcft [ppc64el] (groovy-proposed/universe) [2.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fcft [amd64] (groovy-proposed/universe) [2.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fcft [arm64] (groovy-proposed/universe) [2.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fcft [armhf] (groovy-proposed/universe) [2.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted google-guest-agent [amd64] (groovy-proposed) [20200617.00-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted google-guest-agent [armhf] (groovy-proposed) [20200617.00-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted google-guest-agent [s390x] (groovy-proposed) [20200617.00-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted google-guest-agent [arm64] (groovy-proposed) [20200617.00-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted google-guest-agent [ppc64el] (groovy-proposed) [20200617.00-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted fcft [amd64] (groovy-proposed) [2.2.3-1]
-queuebot:#ubuntu-release- New: accepted fcft [armhf] (groovy-proposed) [2.2.3-1]
-queuebot:#ubuntu-release- New: accepted fcft [s390x] (groovy-proposed) [2.2.3-1]
-queuebot:#ubuntu-release- New: accepted fcft [arm64] (groovy-proposed) [2.2.3-1]
-queuebot:#ubuntu-release- New: accepted fcft [ppc64el] (groovy-proposed) [2.2.3-1]
<vorlon> sergiodj: I: telegraf source: unused-file-paragraph-in-dep5-copyright paragraph at line 119
<vorlon> I: telegraf source: unused-file-paragraph-in-dep5-copyright paragraph at line 15
<vorlon> I: telegraf source: unused-file-paragraph-in-dep5-copyright paragraph at line 263
<sergiodj> vorlon: I thought I'd fixed all of those.  let me double check here
<sergiodj> the copyright file was a nightmare to create :-/
<sergiodj> vorlon: ah, OK, I see them here.  strange.  anyway, I can fix this very quick.  should I contact you when I do so?
<vorlon> sergiodj: sure
<sergiodj> thanks
<vorlon> Laney: do you have insight into why proposed-migration isn't processing the amd64 binary build of libopenshot that's stuck in -proposed?
<vorlon> Laney: (previous version of libopenshot had ftbfs on amd64; new version succeeds but didn't build until after the source and other archs had migrated; old britney used to show these as "libopenshot/amd64" at the top of update_excuses...)
<sergiodj> vorlon: where would you like me to put the new package?  I'm maintaining everything in a git repo, but I can create a PPA if you prefer
<sergiodj> vorlon: PPA is here: https://launchpad.net/~sergiodj/+archive/ubuntu/telegraf-universe2
<vorlon> sergiodj: well I'd prefer you put it in the NEW queue? :)
<sergiodj> vorlon: I'd be happy to do that, but I'd have to look for another sponsor then, right?
-queuebot:#ubuntu-release- Builds: 26 entries have been added, updated or disabled
<sergiodj> vorlon: locutusofborg did the first sponsorship for me.  I can leave him a message and see if he can upload the package again
<vorlon> bdmurray: python-ntlm gone now
<bdmurray> vorlon: thanks, I'll close the bug
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Bionic 18.04.5] (20200806.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Bionic 18.04.5] (20200806.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Bionic 18.04.5] (20200806.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Bionic 18.04.5] (20200806.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Bionic 18.04.5] (20200806.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Bionic 18.04.5] (20200806.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Bionic 18.04.5] (20200806.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Bionic 18.04.5] (20200806.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Bionic 18.04.5] (20200806.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Bionic 18.04.5] (20200806.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Xenial 16.04.7] (20200806) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Xenial 16.04.7] (20200806) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Bionic 18.04.5] (20200806.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Xenial 16.04.7] (20200806) has been added
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Bionic 18.04.5] (20200806.1) has been added
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Bionic 18.04.5] (20200806.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Bionic 18.04.5] (20200806.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Xenial 16.04.7] (20200806) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Bionic 18.04.5] (20200806.1) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Bionic 18.04.5] (20200806.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Bionic 18.04.5] (20200806.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Bionic 18.04.5] (20200806.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi3 [Bionic 18.04.5] (20200806.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi3 [Bionic 18.04.5] (20200806.1) has been added
-queuebot:#ubuntu-release- Unapproved: irssi (focal-proposed/main) [1.2.2-1ubuntu1 => 1.2.2-1ubuntu1.1] (core)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Bionic 18.04.5] (20200806.1) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Bionic 18.04.5] (20200806.1) has been added
-queuebot:#ubuntu-release- New binary: golang-github-evilsocket-islazy [amd64] (groovy-proposed/universe) [1.10.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gvm-tools [amd64] (groovy-proposed/universe) [2.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-fogleman-gg [amd64] (groovy-proposed/universe) [1.3.0-1] (no packageset)
<vorlon> cpaelzer: LP: #1854362 the documented process is to mark the tasks 'fix committed', not to subscribe ubuntu-archive?
<ubot5> Launchpad bug 1854362 in urwid (Ubuntu) "[MIR] ceph-iscsi, tcmu, python-configshell-fb, python-rtslib-fb, urwid, targetcli-fb" [Undecided,In progress] https://launchpad.net/bugs/1854362
-queuebot:#ubuntu-release- New binary: prove6 [amd64] (groovy-proposed/universe) [0.0.12-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-github-evilsocket-islazy [amd64] (groovy-proposed) [1.10.6-2]
-queuebot:#ubuntu-release- New: accepted gvm-tools [amd64] (groovy-proposed) [2.0.0-2]
-queuebot:#ubuntu-release- New: accepted golang-github-fogleman-gg [amd64] (groovy-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted prove6 [amd64] (groovy-proposed) [0.0.12-1]
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Bionic 18.04.5] (20200806) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Bionic 18.04.5] (20200806) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Bionic 18.04.5] (20200806.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Bionic 18.04.5] (20200806.1) has been added
#ubuntu-release 2020-08-07
-queuebot:#ubuntu-release- New binary: golang-gonum-v1-plot [amd64] (groovy-proposed/universe) [0.7.0-2] (no packageset)
<cpaelzer> vorlon: you are right "Fix committed" (once it shows up in component-mismatch), but in the past it often seemed promotions needed pings to happen - so I thought it might be helpful to subscribe ubuntu-archive (not for the process, but for the purpose of the bug update being seen by the right people)
<cpaelzer> in any case - thank you for picking it up and doing the AA work on this bug.
-queuebot:#ubuntu-release- New binary: chirp [amd64] (groovy-proposed/universe) [1:20200227+py3+20200213-1] (no packageset)
-queuebot:#ubuntu-release- New binary: emacs-websocket [amd64] (groovy-proposed/universe) [1.12+18.g5aaf9d1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: nvidia-cuda-toolkit [amd64] (groovy-proposed/multiverse) [10.2.89-4] (no packageset)
<xnox> vorlon:  s390-sysconfig-writer wants to pull s390-tools-udeb back into main.... But i am failing to see why s390-sysconfig-writer is in main!
<Laney> vorlon: I'll have a look, might not be today though
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (focal-proposed) [2.20.11-0ubuntu27.7]
-queuebot:#ubuntu-release- Unapproved: accepted rsyslog [source] (focal-proposed) [8.2001.0-1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted probert [source] (focal-proposed) [0.0.18build1]
-queuebot:#ubuntu-release- New binary: nvidia-cuda-toolkit [ppc64el] (groovy-proposed/multiverse) [10.2.89-4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted irssi [source] (focal-proposed) [1.2.2-1ubuntu1.1]
<Laney> vorlon: ah, ok, fixed I think
<Laney> We were doing:
<Laney>  - read sources from release
<Laney>  - read binaries from release
<Laney>  - read sources from proposed
<Laney>  - read binaries from proposed
<Laney>   - merge {release, proposed} sources
<Laney>  - merge {release, proposed} binaries
<Laney> but that means that binary only migrations had no source to be associated with when they were read in, because the source is in release
<Laney> need to read all sources, merge them, then read binaries, then merge those
<juliank> ubuntu-archive grub2 in groovy unapproved needs approving :)
<juliank> [due to amd64, arm64 signed binary stuff]
<juliank> And I guess someone wants to delete the old 26.1 stuff that's in there too
<apw> juliank, the changelog delta is rather concerning ... seems to remove the word SECURITY a lot
<juliank> apw: it does?
<juliank> apw: I took the git branch for the focal security upload and rebased my stuff on top of it, is the tarball different?
<juliank> that would suck
<juliank> chrisccoulson, xnox ^
<apw> juliank, it may be launchpad diff as much as anything
<juliank> can confirm
<juliank> ugh
<juliank> wth
<apw> juliank, so the code delta is looking ok, just changelog is a mushfest
<juliank> not sure if there's a difference outside changelog
<chrisccoulson> juliank, aha, I think this came up last week - the git branch I pushed didn't quite match what I'd uploaded because I didn't commit the last minute changes I made to the changelog
<chrisccoulson> (which added all of the CVE references)
<juliank> ack
<juliank> I confirmed that it's only changelog differences
<juliank> Using git-ubuntu's focal-security branch and diffing against the focal branch
-queuebot:#ubuntu-release- New binary: thunderbird [s390x] (groovy-proposed/main) [1:78.1.1+build1-0ubuntu1] (mozilla, ubuntu-desktop)
<juliank> apw: I think it's a bit pointless waste of resources to re-upload with the changelog fixes, and I'll merge the proper changelog back in git, and do that in the focal SRU
<apw> juliank, ack
-queuebot:#ubuntu-release- Unapproved: accepted rpcbind [source] (bionic-proposed) [0.2.3-0.6ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (bionic-proposed) [1:2.11+dfsg-1ubuntu7.30]
-queuebot:#ubuntu-release- New source: sane-airscan (groovy-proposed/primary) [0.99.12-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (groovy-proposed) [2.04-1ubuntu27]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (groovy-proposed) [2.04-1ubuntu27]
-queuebot:#ubuntu-release- Unapproved: accepted stress-ng [source] (xenial-proposed) [0.05.23-1ubuntu4]
-queuebot:#ubuntu-release- New: accepted nvidia-cuda-toolkit [amd64] (groovy-proposed) [10.2.89-4]
-queuebot:#ubuntu-release- New: accepted nvidia-cuda-toolkit [ppc64el] (groovy-proposed) [10.2.89-4]
-queuebot:#ubuntu-release- New: accepted emacs-websocket [amd64] (groovy-proposed) [1.12+18.g5aaf9d1-2]
-queuebot:#ubuntu-release- New: accepted chirp [amd64] (groovy-proposed) [1:20200227+py3+20200213-1]
-queuebot:#ubuntu-release- New: accepted golang-gonum-v1-plot [amd64] (groovy-proposed) [0.7.0-2]
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Bionic 18.04.5] (20101020ubuntu543.17) has been added
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Bionic 18.04.5] (20101020ubuntu543.17) has been added
-queuebot:#ubuntu-release- New binary: thunderbird [ppc64el] (groovy-proposed/main) [1:78.1.1+build1-0ubuntu1] (mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Builds: Netboot armhf [Bionic 18.04.5] (20101020ubuntu543.17) has been added
-queuebot:#ubuntu-release- Builds: Netboot i386 [Bionic 18.04.5] (20101020ubuntu543.17) has been added
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Bionic 18.04.5] (20101020ubuntu543.17) has been added
-queuebot:#ubuntu-release- Builds: Netboot s390x [Bionic 18.04.5] (20101020ubuntu543.17) has been added
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Xenial 16.04.7] (20101020ubuntu451.29) has been added
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Xenial 16.04.7] (20101020ubuntu451.29) has been added
-queuebot:#ubuntu-release- Builds: Netboot armhf [Xenial 16.04.7] (20101020ubuntu451.29) has been added
-queuebot:#ubuntu-release- Builds: Netboot i386 [Xenial 16.04.7] (20101020ubuntu451.29) has been added
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Xenial 16.04.7] (20101020ubuntu451.29) has been added
-queuebot:#ubuntu-release- Builds: Netboot s390x [Xenial 16.04.7] (20101020ubuntu451.29) has been added
-queuebot:#ubuntu-release- Unapproved: linux-gcp-5.4 (bionic-proposed/main) [5.4.0-1021.21~18.04.1 => 5.4.0-1021.21~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed-gcp-5.4 (bionic-proposed/main) [5.4.0-1021.21~18.04.1 => 5.4.0-1021.21~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-oracle-5.4 (bionic-proposed/main) [5.4.0-1021.21~18.04.1 => 5.4.0-1021.21~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed-oracle-5.4 (bionic-proposed/main) [5.4.0-1021.21~18.04.1 => 5.4.0-1021.21~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted linux-gcp-5.4 [sync] (bionic-proposed) [5.4.0-1021.21~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed-gcp-5.4 [sync] (bionic-proposed) [5.4.0-1021.21~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted linux-oracle-5.4 [sync] (bionic-proposed) [5.4.0-1021.21~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed-oracle-5.4 [sync] (bionic-proposed) [5.4.0-1021.21~18.04.1]
-queuebot:#ubuntu-release- Unapproved: shim (focal-proposed/main) [15+1533136590.3beb971-0ubuntu1 => 15+1552672080.a4a1fbe-0ubuntu2] (core) (sync)
 * juliank is preparing SRUs for shim for post point-release and uploading/copy-packaging them to proposed queues
-queuebot:#ubuntu-release- Unapproved: shim (bionic-proposed/main) [15+1533136590.3beb971-0ubuntu1 => 15+1552672080.a4a1fbe-0ubuntu2] (core) (sync)
<juliank> oops, those should be binary copies
-queuebot:#ubuntu-release- Unapproved: shim (focal-proposed/main) [15+1533136590.3beb971-0ubuntu1 => 15+1552672080.a4a1fbe-0ubuntu2] (core) (sync)
<juliank> shims are hard
-queuebot:#ubuntu-release- Unapproved: shim (bionic-proposed/main) [15+1533136590.3beb971-0ubuntu1 => 15+1552672080.a4a1fbe-0ubuntu2] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: shim (xenial-proposed/main) [15+1533136590.3beb971-0ubuntu1 => 15+1552672080.a4a1fbe-0ubuntu2] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: shim-signed (focal-proposed/main) [1.40.3 => 1.40.4] (core)
-queuebot:#ubuntu-release- Unapproved: umockdev (focal-proposed/universe) [0.14.1-1 => 0.14.1-1ubuntu0.1] (i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: shim-signed (focal-proposed/main) [1.40.3 => 1.40.4] (core)
<juliank> (ubuntu-release: please reject old shim-signed/focal, it did not include a LP: bug reference)
-queuebot:#ubuntu-release- Unapproved: umockdev (bionic-proposed/universe) [0.11.1-1 => 0.11.1-1ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: shim-signed (bionic-proposed/main) [1.37~18.04.6 => 1.37~18.04.7] (core)
-queuebot:#ubuntu-release- Unapproved: shim-signed (xenial-proposed/main) [1.33.1~16.04.5 => 1.33.1~16.04.6] (core)
<marcustomlinson> tjaalton: hi, could you please have a look at LibreOffice in the Focal queue? It's actually been reviewed and approved before but had an issue with orig mismatches
-queuebot:#ubuntu-release- New binary: linux-signed-gke-5.3 [amd64] (bionic-proposed/universe) [5.3.0-1033.35] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-azure-5.3 [amd64] (bionic-proposed/main) [5.3.0-1035.36] (no packageset)
<xnox> bdmurray:  sil2100: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1890797 was just reported to me. I have now pushed
<ubot5> Ubuntu bug 1890797 in debian-installer (Ubuntu) "Can not load essential driver for HWE kernel on 20200806.1 bionic ISO" [Undecided,New]
<xnox> https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/commit/?id=bbc8d8b92b14cdb9f4dd502d728803e14fb02d9e
<xnox> to fix this
<xnox> bdmurray:  sil2100: but it means bionic d-i server needs respin
-queuebot:#ubuntu-release- Unapproved: chromium-browser (focal-proposed/universe) [84.0.4147.89-0ubuntu0.20.04.1 => 84.0.4147.105-0ubuntu0.20.04.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure-5.3 [amd64] (bionic-proposed) [5.3.0-1035.36]
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.3 [amd64] (bionic-proposed) [5.3.0-1033.35]
-queuebot:#ubuntu-release- New binary: thunderbird [arm64] (groovy-proposed/main) [1:78.1.1+build1-0ubuntu1] (mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: thunderbird [amd64] (groovy-proposed/main) [1:78.1.1+build1-0ubuntu1] (mozilla, ubuntu-desktop)
<sil2100> xnox: eek
-queuebot:#ubuntu-release- New source: telegraf (groovy-proposed/primary) [1.15.1+ds1-0ubuntu1]
<sergiodj> vorlon: new telegraf has been uploaded (thanks to kanashiro)
-queuebot:#ubuntu-release- New binary: thunderbird [armhf] (groovy-proposed/main) [1:78.1.1+build1-0ubuntu1] (mozilla, ubuntu-desktop)
<marcustomlinson> tjaalton: hey thanks for approving LO for focal today. Any idea why it's stuck though? https://launchpad.net/ubuntu/focal/+queue?queue_state=1&queue_text=libreoffice
<Laney> (taken up in #launchpad)
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (focal-proposed) [1:6.4.5-0ubuntu0.20.04.1]
<Laney> (and accepted, I did it myself based on tjaalton having previously tried to do it)
<Laney> (spank me if you feel the need)
<ginggs> ubuntu-archive: would someone please RM pyhst2's binaries on ppc64el in release?
<ginggs> it no longer builds there since the nvidia ppc64el drivers were dropped https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-418-server/418.152.00-0ubuntu1
-queuebot:#ubuntu-release- New binary: pixelmed-codec [amd64] (groovy-proposed/universe) [20200328-2] (no packageset)
-queuebot:#ubuntu-release- New binary: spoa [ppc64el] (groovy-proposed/universe) [3.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: spoa [amd64] (groovy-proposed/universe) [3.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: spoa [s390x] (groovy-proposed/universe) [3.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: flint [s390x] (groovy-proposed/universe) [2.6.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: spoa [riscv64] (groovy-proposed/universe) [3.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: spoa [arm64] (groovy-proposed/universe) [3.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: spoa [armhf] (groovy-proposed/universe) [3.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: flint [amd64] (groovy-proposed/universe) [2.6.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: flint [ppc64el] (groovy-proposed/universe) [2.6.2-1] (no packageset)
<Eickmeyer> ubuntu-archive: No clue what's going on with zita-ajbridge being stuck in focal-proposed from SRU bug 1889146. It has been over 7 days (and not a Mon-Thurs thing in this case) and there's nothing in excuses.
<ubot5> bug 1889146 in zita-ajbridge (Ubuntu Focal) "[SRU] Loss of USB device causes zita-ajbridge to run cpu at 100% and hang" [High,Fix committed] https://launchpad.net/bugs/1889146
<Eickmeyer> tjaalton, vorlon, sil2100 ^ (this is rather urgent as it's causing stuff to hang)
-queuebot:#ubuntu-release- New binary: flint [arm64] (groovy-proposed/universe) [2.6.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: flint [armhf] (groovy-proposed/universe) [2.6.2-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: bcache-tools (bionic-proposed/main) [1.0.8-2build1 => 1.0.8-2ubuntu0.1] (edubuntu, kubuntu, ubuntu-server)
-queuebot:#ubuntu-release- New binary: flint [riscv64] (groovy-proposed/universe) [2.6.2-1] (no packageset)
<vorlon> cpaelzer: so fwiw I do not read bug mail for ubuntu-archive, and only noticed this was ready to go because I happened to be reading through ubuntu-archive-subscribed bugs for package removals.  The 'fix committed' would've been a smoother workflow for me
<vorlon> xnox: s390-sysconfig-writer> well, let's just demote that too and see what happens
<vorlon> ginggs: I don't understand the pyhst2 build failure; it clearly succeeds at installing nvidia-cuda-toolkit before failing to find -lcuda at build time
-queuebot:#ubuntu-release- New binary: node-solid-rest [amd64] (groovy-proposed/universe) [1.0.7-2] (no packageset)
-queuebot:#ubuntu-release- New binary: spoa [amd64] (groovy-proposed/universe) [3.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: spoa [ppc64el] (groovy-proposed/universe) [3.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: spoa [s390x] (groovy-proposed/universe) [3.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: fpc [i386] (groovy-proposed/universe) [3.2.0+dfsg-5] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: fpc [amd64] (groovy-proposed/universe) [3.2.0+dfsg-5] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: spoa [armhf] (groovy-proposed/universe) [3.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: spoa [arm64] (groovy-proposed/universe) [3.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: spoa [riscv64] (groovy-proposed/universe) [3.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: fpc [arm64] (groovy-proposed/universe) [3.2.0+dfsg-5] (i386-whitelist)
<vorlon> Eickmeyer: zita-ajbridge> you know this week was focal .1 release, right?  So promotions from -proposed to -updates were frozen in order to not derail the ISO mastering.  If this was something that you felt should have gone into the .1 media, you would've needed to communicate it directly to the release team in time for inclusion.  But at this point it will need to wait until Monday
-queuebot:#ubuntu-release- New: accepted fpc [amd64] (groovy-proposed) [3.2.0+dfsg-5]
-queuebot:#ubuntu-release- New: accepted fpc [i386] (groovy-proposed) [3.2.0+dfsg-5]
-queuebot:#ubuntu-release- New: accepted spoa [armhf] (groovy-proposed) [3.4.0-2]
-queuebot:#ubuntu-release- New: accepted spoa [s390x] (groovy-proposed) [3.4.0-2]
-queuebot:#ubuntu-release- New: accepted fpc [arm64] (groovy-proposed) [3.2.0+dfsg-5]
-queuebot:#ubuntu-release- New: accepted spoa [riscv64] (groovy-proposed) [3.4.0-2]
-queuebot:#ubuntu-release- New: accepted spoa [arm64] (groovy-proposed) [3.4.0-2]
-queuebot:#ubuntu-release- New: accepted flint [amd64] (groovy-proposed) [2.6.2-1]
-queuebot:#ubuntu-release- New: accepted flint [armhf] (groovy-proposed) [2.6.2-1]
-queuebot:#ubuntu-release- New: accepted flint [riscv64] (groovy-proposed) [2.6.2-1]
-queuebot:#ubuntu-release- New: accepted node-solid-rest [amd64] (groovy-proposed) [1.0.7-2]
-queuebot:#ubuntu-release- New: accepted spoa [armhf] (groovy-proposed) [3.4.0-1]
-queuebot:#ubuntu-release- New: accepted spoa [ppc64el] (groovy-proposed) [3.4.0-2]
-queuebot:#ubuntu-release- New: accepted flint [arm64] (groovy-proposed) [2.6.2-1]
-queuebot:#ubuntu-release- New: accepted flint [s390x] (groovy-proposed) [2.6.2-1]
-queuebot:#ubuntu-release- New: accepted spoa [amd64] (groovy-proposed) [3.4.0-2]
-queuebot:#ubuntu-release- New: accepted flint [ppc64el] (groovy-proposed) [2.6.2-1]
-queuebot:#ubuntu-release- New: accepted spoa [arm64] (groovy-proposed) [3.4.0-1]
-queuebot:#ubuntu-release- New: accepted pixelmed-codec [amd64] (groovy-proposed) [20200328-2]
-queuebot:#ubuntu-release- New: accepted spoa [ppc64el] (groovy-proposed) [3.4.0-1]
-queuebot:#ubuntu-release- New: accepted spoa [s390x] (groovy-proposed) [3.4.0-1]
-queuebot:#ubuntu-release- New: accepted spoa [amd64] (groovy-proposed) [3.4.0-1]
-queuebot:#ubuntu-release- New: accepted spoa [riscv64] (groovy-proposed) [3.4.0-1]
<vorlon> xnox: answer: linux-5.7 is building di packages which depend on s390-dasd and friedns
-queuebot:#ubuntu-release- New binary: fpc [armhf] (groovy-proposed/universe) [3.2.0+dfsg-5] (i386-whitelist)
#ubuntu-release 2020-08-08
-queuebot:#ubuntu-release- New binary: r-cran-getoptlong [amd64] (groovy-proposed/none) [1.0.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ksamples [ppc64el] (groovy-proposed/none) [1.2-9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: raritan-json-rpc-sdk [amd64] (groovy-proposed/none) [3.6.0+ds1-1~exp2] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ksamples [amd64] (groovy-proposed/none) [1.2-9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ksamples [s390x] (groovy-proposed/none) [1.2-9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ksamples [arm64] (groovy-proposed/universe) [1.2-9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ksamples [armhf] (groovy-proposed/universe) [1.2-9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ksamples [riscv64] (groovy-proposed/universe) [1.2-9-1] (no packageset)
<ginggs> vorlon: -lcuda is provided by libnvidia-compute-* which no longer exists on ppc64el
<tjaalton> marcustomlinson, Laney: this is what I got when trying to accept it: b'The source libreoffice - 1:6.4.5-0ubuntu0.20.04.1 is already accepted in ubuntu/focal and you cannot upload the same version within the same distribution. You have to modify the source version and re-upload.'
<tjaalton> weird..
<cjwatson> tjaalton: Sorted out now
<tjaalton> yeah
<xnox> vorlon: demote them too?!
<marcustomlinson> tjaalton: yeah weird edge case indeed
-queuebot:#ubuntu-release- New binary: gxr-openvr [ppc64el] (groovy-proposed/multiverse) [0.15.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: raritan-json-rpc-sdk [amd64] (groovy-proposed/universe) [3.6.0+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gxr-openvr [s390x] (groovy-proposed/multiverse) [0.15.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gxr-openvr [amd64] (groovy-proposed/multiverse) [0.15.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gxr-openvr [arm64] (groovy-proposed/multiverse) [0.15.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gxr-openvr [armhf] (groovy-proposed/multiverse) [0.15.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gxr-openvr [riscv64] (groovy-proposed/multiverse) [0.15.1-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted gxr-openvr [amd64] (groovy-proposed) [0.15.1-2]
-queuebot:#ubuntu-release- New: accepted gxr-openvr [armhf] (groovy-proposed) [0.15.1-2]
-queuebot:#ubuntu-release- New: accepted gxr-openvr [riscv64] (groovy-proposed) [0.15.1-2]
-queuebot:#ubuntu-release- New: accepted gxr-openvr [arm64] (groovy-proposed) [0.15.1-2]
-queuebot:#ubuntu-release- New: accepted gxr-openvr [ppc64el] (groovy-proposed) [0.15.1-2]
-queuebot:#ubuntu-release- New: accepted gxr-openvr [s390x] (groovy-proposed) [0.15.1-2]
-queuebot:#ubuntu-release- New: accepted r-cran-ksamples [arm64] (groovy-proposed) [1.2-9-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ksamples [ppc64el] (groovy-proposed) [1.2-9-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ksamples [s390x] (groovy-proposed) [1.2-9-1]
-queuebot:#ubuntu-release- New: accepted raritan-json-rpc-sdk [amd64] (groovy-proposed) [3.6.0+ds1-1~exp2]
-queuebot:#ubuntu-release- New: accepted r-cran-ksamples [amd64] (groovy-proposed) [1.2-9-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ksamples [riscv64] (groovy-proposed) [1.2-9-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ksamples [armhf] (groovy-proposed) [1.2-9-1]
-queuebot:#ubuntu-release- New: accepted raritan-json-rpc-sdk [amd64] (groovy-proposed) [3.6.0+ds1-1]
-queuebot:#ubuntu-release- New: accepted fpc [armhf] (groovy-proposed) [3.2.0+dfsg-5]
-queuebot:#ubuntu-release- New: accepted r-cran-getoptlong [amd64] (groovy-proposed) [1.0.2+dfsg-1]
-queuebot:#ubuntu-release- New binary: r-bioc-complexheatmap [amd64] (groovy-proposed/universe) [2.4.3+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-complexheatmap [amd64] (groovy-proposed/universe) [2.4.3+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-itemloaders [amd64] (groovy-proposed/universe) [1.0.2-1] (no packageset)
#ubuntu-release 2020-08-09
-queuebot:#ubuntu-release- New: accepted python-itemloaders [amd64] (groovy-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-complexheatmap [amd64] (groovy-proposed) [2.4.3+dfsg-2]
-queuebot:#ubuntu-release- New: accepted r-bioc-complexheatmap [amd64] (groovy-proposed) [2.4.3+dfsg-1]
-queuebot:#ubuntu-release- Packageset: 35 entries have been added or removed
-queuebot:#ubuntu-release- New binary: r-bioc-degreport [amd64] (groovy-proposed/universe) [1.24.1+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cockpit (focal-backports/universe) [223-1~ubuntu20.04.1 => 225-1~ubuntu20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (focal-backports) [225-1~ubuntu20.04.1]
-queuebot:#ubuntu-release- New binary: libktorrent [s390x] (groovy-proposed/universe) [2.2.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libktorrent [amd64] (groovy-proposed/universe) [2.2.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libktorrent [arm64] (groovy-proposed/universe) [2.2.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libktorrent [armhf] (groovy-proposed/universe) [2.2.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libktorrent [riscv64] (groovy-proposed/universe) [2.2.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libktorrent [s390x] (groovy-proposed/universe) [2.2.0-2ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libktorrent [amd64] (groovy-proposed/universe) [2.2.0-2ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libktorrent [ppc64el] (groovy-proposed/universe) [2.2.0-2ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libktorrent [arm64] (groovy-proposed/universe) [2.2.0-2ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libktorrent [armhf] (groovy-proposed/universe) [2.2.0-2ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libktorrent [riscv64] (groovy-proposed/universe) [2.2.0-2ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: apport (focal-proposed/main) [2.20.11-0ubuntu27.7 => 2.20.11-0ubuntu27.8] (core, i386-whitelist)
-queuebot:#ubuntu-release- Packageset: Added lzip to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added python-stdlib-extensions to i386-whitelist in groovy
-queuebot:#ubuntu-release- New binary: jacksum-sugar [amd64] (groovy-proposed/none) [1.7.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cactoos [amd64] (groovy-proposed/none) [0.46-1] (no packageset)
-queuebot:#ubuntu-release- New binary: macopix [s390x] (groovy-proposed/universe) [3.4.0+dfsg.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: macopix [amd64] (groovy-proposed/universe) [3.4.0+dfsg.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: setzer [amd64] (groovy-proposed/none) [0.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: macopix [ppc64el] (groovy-proposed/universe) [3.4.0+dfsg.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gitaly [amd64] (groovy-proposed/universe) [13.2.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: macopix [arm64] (groovy-proposed/universe) [3.4.0+dfsg.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: macopix [armhf] (groovy-proposed/universe) [3.4.0+dfsg.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xrayutilities [s390x] (groovy-proposed/universe) [1.6.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: xrayutilities [ppc64el] (groovy-proposed/universe) [1.6.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: xrayutilities [amd64] (groovy-proposed/universe) [1.6.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: xrayutilities [arm64] (groovy-proposed/universe) [1.6.0-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted redkite [source] (groovy-proposed) [0.8.1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: xrayutilities [armhf] (groovy-proposed/universe) [1.6.0-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted bchoppr [source] (groovy-proposed) [1.6.2-0ubuntu1]
-queuebot:#ubuntu-release- New binary: redkite [ppc64el] (groovy-proposed/none) [0.8.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: redkite [s390x] (groovy-proposed/none) [0.8.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted cactoos [amd64] (groovy-proposed) [0.46-1]
-queuebot:#ubuntu-release- New: accepted jacksum-sugar [amd64] (groovy-proposed) [1.7.0+ds-1]
-queuebot:#ubuntu-release- New: accepted libktorrent [arm64] (groovy-proposed) [2.2.0-2]
-queuebot:#ubuntu-release- New: accepted libktorrent [riscv64] (groovy-proposed) [2.2.0-2]
-queuebot:#ubuntu-release- New: accepted r-bioc-degreport [amd64] (groovy-proposed) [1.24.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted gitaly [amd64] (groovy-proposed) [13.2.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted libktorrent [armhf] (groovy-proposed) [2.2.0-2]
-queuebot:#ubuntu-release- New: accepted setzer [amd64] (groovy-proposed) [0.2.5-1]
-queuebot:#ubuntu-release- New: accepted libktorrent [amd64] (groovy-proposed) [2.2.0-2]
-queuebot:#ubuntu-release- New: accepted libktorrent [s390x] (groovy-proposed) [2.2.0-2]
-queuebot:#ubuntu-release- New: accepted libktorrent [amd64] (groovy-proposed) [2.2.0-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted libktorrent [armhf] (groovy-proposed) [2.2.0-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted libktorrent [riscv64] (groovy-proposed) [2.2.0-2ubuntu1]
-queuebot:#ubuntu-release- New binary: redkite [arm64] (groovy-proposed/none) [0.8.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libktorrent [arm64] (groovy-proposed) [2.2.0-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted libktorrent [s390x] (groovy-proposed) [2.2.0-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted libktorrent [ppc64el] (groovy-proposed) [2.2.0-2ubuntu1]
-queuebot:#ubuntu-release- New binary: redkite [armhf] (groovy-proposed/none) [0.8.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted thunderbird [amd64] (groovy-proposed) [1:78.1.1+build1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted thunderbird [armhf] (groovy-proposed) [1:78.1.1+build1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted thunderbird [s390x] (groovy-proposed) [1:78.1.1+build1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted thunderbird [arm64] (groovy-proposed) [1:78.1.1+build1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: redkite [amd64] (groovy-proposed/none) [0.8.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted thunderbird [ppc64el] (groovy-proposed) [1:78.1.1+build1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted bsequencer [source] (groovy-proposed) [1.4.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted bshapr [source] (groovy-proposed) [0.9-0ubuntu1]
-queuebot:#ubuntu-release- New binary: bsequencer [amd64] (groovy-proposed/none) [1.4.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: bsequencer [s390x] (groovy-proposed/none) [1.4.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: bsequencer [ppc64el] (groovy-proposed/none) [1.4.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: bshapr [s390x] (groovy-proposed/none) [0.9-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: bshapr [ppc64el] (groovy-proposed/none) [0.9-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: bshapr [amd64] (groovy-proposed/none) [0.9-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: bsequencer [arm64] (groovy-proposed/none) [1.4.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: bsequencer [armhf] (groovy-proposed/none) [1.4.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: macopix [riscv64] (groovy-proposed/universe) [3.4.0+dfsg.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bshapr [arm64] (groovy-proposed/none) [0.9-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: redkite [riscv64] (groovy-proposed/universe) [0.8.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: bshapr [armhf] (groovy-proposed/none) [0.9-0ubuntu1] (no packageset)
