#ubuntu-release 2010-08-16
<ara> good morning!
 * ara sees that the ISOs are about to be respin
<ara> hello!
<ara> who's taking care of the 10.04.1 release process?
<ara> slangasek, is that you? ^
<Laney> ara: I think robbiew
<ara> Laney, thanks :)
<Riddell> gosh, mysterious appearance of lucid .1 candidates
<Riddell> spooky
<cjwatson> stgraber,highvoltage: done
<cjwatson> (edubuntu oem)
<highvoltage> cjwatson: just saw the mails, thanks!
<ScottK> Riddell: There were supposed to be Kubuntu Netbook images too.  Not sure if they are done, but not on the tracker or not done.
<cjwatson> ScottK: https://wiki.ubuntu.com/LucidLynx/ReleaseManifest doesn't list Kubuntu Netbook as LTS?  (similarly, no .1 images for Ubuntu Netbook at the moment)
<cjwatson> I don't mind spinning them; not sure what their status wrt releasing should be
<ScottK> cjwatson: It's not an LTS, but we discussed respinning it before.
<ScottK> IIRC the conclusion was that if I could get it tested, then it could be released.
<cjwatson> well, I don't mind giving it a shot - spinning
<ScottK> Thanks.
<ScottK> cjwatson: Kubuntu Netbook respin didn't end well and I don't know enough about the build system to have a clue what to make from the log.
<cjwatson> let's see
<cjwatson> my bad, missed an argument
<cjwatson> built the livefs for maverick by mistake
<ScottK> Thanks.
<cjwatson> W: Failed to fetch file:/srv/cdimage.ubuntu.com/ftp-universe/dists/lucid-proposed/Release  Unable to find expected entry  universe/debian-installer/binary-i386/Packages in Meta-index file (malformed Release fil
<cjwatson> e?)
<cjwatson> sigh, what now
<cjwatson> looks like a soyuz bug ...?
<cjwatson> universe/debian-installer/binary-i386/Packages (but not .gz or .bz2) is genuinely missing from dists/lucid-proposed/Release (but not lucid or lucid-updates)
 * cjwatson pulls lp source to try to figure out how this works
<cjwatson> oh, it's *that* problem.  deleting udebs from proposed is problematic :-/
<cjwatson> (because if you get down to zero udebs in a particular component, then it removes Packages but forgets to remove Packages.gz and Packages.bz2)
 * cjwatson nukes dists/lucid-proposed/universe/debian-installer and lets the next publisher run sort it out
 * ScottK is reading all the "Multi-touch is in Maverick" stuff on p.u.c and trying to figure out where it is and does the release team need to look at anything?
<slangasek> ara: I'm "taking care" of the release process, though the hand-off has been rockier than hoped
<ara> slangasek, OK, thanks
<ScottK> Did Kubuntu Netbook get spun yet?
<slangasek> ScottK: doesn't appear so.  This is wanted for i386, yes?
<ScottK> slangasek: And armel too.
<slangasek> hmm, ok
<slangasek> need to run that as two jobs; poking
<ScottK> Thanks.  The armel one is lower priority, but it has had some interest, so I'd like to see if we can get it updated and tested.
<slangasek> ok, I think this will work
<slangasek> lamont: I think I may have accidentally triggered some broken build attempts on acorn; could you find anything queued there with 'lucid' as its target and shoot it in the head?
<lamont> slangasek: looking now
<slangasek> ta
<lamont> slangasek: just fyi - lp-buildd rollout happening shorlty
<slangasek> lamont: only thing I care about right now are livefs builders; are those impacted?
<ScottK> slangasek: Can I ignore these failure logs rolling into my inbox?
<lamont> slangasek: maverick kubuntu-netbook running nwo
<lamont> slangasek: livefs is untouched
<slangasek> lamont: see the old jobs killed, thanks - the new ones I've just launched should not be killed :)
<slangasek> ScottK: yep
<lamont> slangasek: picky picky. :-p
<ScottK> Thanks.
<lamont> buildd world on manual
<ScottK> OK.  Apparently the release team either doesn't need to be consulted or the consulation isn't documented on multi-touch.
 * ScottK considers just marking all the pending FFe's approved in fairness.
<robbiew> ScottK: huh?
<robbiew> that stuff was in before FF
#ubuntu-release 2010-08-17
<ScottK> robbiew: Sorry.  So it was.  I was looking at when it way accepted, not when it was uploaded (my mistake).
<ScottK> way/was.
<slangasek> ScottK: kubuntu-netbook i386, armel+* built; i386 posted to the tracker, armel doesn't have a spot there
<ScottK> slangasek: Thanks.  I didn't expect armel to make the tracker (It wasn't there for the release either).
 * slangasek nods
<Riddell> after accepting a new linux ABI version from new queue should I be changing the seeds?
<cjwatson> Riddell: only if you also change the installer
<Riddell> ah
 * Riddell wonders why ubufox is in lucid-proposed New queue when the binary is already in lucid
<Riddell> cjwatson: can I close bug 374900 or is it still pending somehow?
<ubot4`> Launchpad bug 374900 in faac (Ubuntu) "Libfaac not LGPL (affects: 19) (heat: 128)" [High,Triaged] https://launchpad.net/bugs/374900
<cjwatson> I don't know
<cjwatson> sorry, my mental state on this is two months old
 * Riddell moves lame to universe
<bdrung> Riddell: thanks for processing (all?) ubuntu-archive bugs
<bdrung> \o/ lame in universe
<Riddell> we've had someone else process New and some syncs recently, means I finally have a chance to get to the bottom of the pile
<bdrung> Riddell: i processed ~100 (or even more) sync requests with ack-sync / syncpackage
<Riddell> what's syncpackage?
<bdrung> Riddell: wow. you haven't heard of it?
<Riddell> I won't know unless you remind me what it is :)
<bdrung> Riddell: ubuntu-dev-tools (maverick) -> man syncpackage
<mathiaz> slangasek: robbiew: what's the status on 10.04.1?
<bdrung> Riddell: isn't the name self explaining? it takes a dsc from debian and prepares a changes file for ubuntu
<mathiaz> marjo: hi!
<mathiaz> marjo: does anyone in your team have access to an ESX server?
<Riddell> bdrung: so if non archive admins can just upload syncs themselves, why do archive admins have anything to do with the process?
<bdrung> Riddell: it was discussed on the mailing list
<bdrung> Riddell: by using syncpackage we reduce the workload for the archive admins
<Riddell> bdrung: which list?
<Riddell> bdrung: well yes, so why isn't the workload for the archive admins reduced to zero?
<bdrung> Riddell: ubuntu-devel@
<cjwatson> Riddell: because there's a fundamental danger in having this done client-side
<bdrung> Riddell: because the process wasn't changed and some people use the "old" process.
<cjwatson> if somebody screws up their sync client then we have no way to repair it short of uploading a new version which is desynced again
<Riddell> cjwatson: so if it's dangerous why is it done at all?
<cjwatson> because (a) nobody listens to me (b) I didn't want to get in the way too much; pick your favourite answer
<cjwatson> the correct fix for this process is to have an API call in Launchpad, which I've been trying to get added for some time
<bdrung> cjwatson: once we have this in the launchpad API, i will update the syncpackage script
<cjwatson> sure - that's just why I don't want it to be standard process until then
<bdrung> cjwatson: will this API support sponsoring syncs?
<cjwatson> don't see why not, it would be "copy this version of this package from this suite into this other suite"
<cjwatson> the somewhat odd Launchpad name for this process is "native source syncing" if you want to search for progress on it
<bdrung> cjwatson: do you have a lp for me?
<cjwatson> not off the top of my head ...
<cjwatson> there is actually a syncSource method already, it's just broken in a few important ways (I filed bugs)
<persia> It's blocked on two things: 1) actually running the update jobs to get true changelogs and copyrights into librarian, and 2) applying the security model to the sync API call.
 * Riddell moves mplayer to universe
<highvoltage> Riddell: what changed? licensing or ubuntu policy?
<Riddell> both
 * Riddell does the empty archive admin bugs list dance
<bdrung> Riddell: empty? i count two: https://bugs.launchpad.net/~ubuntu-archive
<Riddell> empty of the ones that are going to be processed today at least
<Riddell> that one needs mvo around I think
<bdrung> Riddell: thanks for working on it and getting it shorten.
<slangasek> ara, Riddell: it appears there are some tests outstanding for both Ubuntu and Kubuntu desktops for 10.04.1, is someone covering wubi + migration assistant?
<Riddell> migration assistant isn't relevant for Kubuntu
<Riddell> I can't do wubi
<slangasek> yes, only wubi is outstanding for Kubuntu
<davmor2> slangasek: sorry on sprint can't help out no windows
<slangasek> hmm
<slangasek> maybe I'll just take a USB stick down to the coffee shop today and hand it to random people and record the results
<slangasek> that wasn't really a serious suggestion, I was hoping someone here had a better idea ;)
<ara> slangasek, I'll try to find someone for Wubi
<slangasek> ara: thanks
<ara> Riddell, can you cover Wubi in Ubuntu as well?
<ara> Riddell, we don't seem to find anyone
<Riddell> 18:05 < Riddell> I can't do wubi
<ara> Riddell, ah, sorry, I thought you said "I can do wubi" :D
<Riddell> unless canonical let me expense a windows computer :)
<ScottK> Riddell: It will be tomorrow before I can do Kubuntu Netbook tests (and I can't do wubi either).  If you knew of someone willing to test it, it would be helpful.
<slangasek> robbiew: the single wubi test we've gotten so far failed with bug #613288 - possibly a regression in a later release of wubiL
<ScottK> Actually it's way more tested than when I looked last.
<Riddell> maybe later tonight I could if still needed
 * Riddell out
<ScottK> slangasek: Looks like Kubuntu Netbook is done except wubi as well.
<slangasek> ScottK: ack
<robbiew> slangasek: perfect :/
 * robbiew looks at bug 613288
<marjo> robbiew: i suspect we would run into the same bug #613288 for ubuntu
<cjwatson> I suspect that it depends on the version of Windows
<cjwatson> beyond that I have zero idea what might be going on; at the moment I have no Windows system, following disk replacement
<cjwatson> if we have to address it, ISTR that OEM have some folks with Windows expertise, and perhaps we could pull somebody in
<robbiew> I don't see it getting fixed anytime soon though
<robbiew> as in for today's release...and I'm not too keen on holding up 10.04.1 for wubi
<slangasek> robbiew: needs more analysis; if it's not-a-regression and specific to some newer version of windows, we should release as-is.  If it's a regression in wubi (has wubi revved since 10.04?), we might be able to roll back to an earlier wubi release and do an ISO-only respin.
<robbiew> ack
<slangasek> robbiew: hum, I think wubi is fairly critical to have right on the CDs
 * ScottK can imagine a /. headline for delaying due to wubi.
<robbiew> exactly
 * robbiew sees if he can borrow his wife's windows machine....
<slangasek> as opposed to shipping a broken wubi and having a /. headline for that? :)
<ScottK> Well sure.  It's one of those can't win situations.
<robbiew> slangasek: so what do we need to test...and older version of wubi?
<slangasek> robbiew: first, we need someone we can work with who can reproduce the original issue as described
<slangasek> since the test report was from a community member we don't have contact with
 * robbiew will try to reproduce
 * ScottK suggests amending robbiew's job title to include "... and wubi tester."
<robbiew> heh
 * robbiew starts the install of Windows XP...Portuguese version...don't ask
<robbiew> lol
 * robbiew also grabs the wife's dual-boot netbook
<nigelb> Portuguese.  Sweet.
<slangasek> feedback from #ubuntu-testing: <KE1HA> Just FYI, all those users on the bug report have Vista or Later Windows Boxes, they all have that dreaded UIC ot UAC whatever it is that malfunctions everything.  I disabled it forever on Vista when I used it, else ran into stuff like that all the time.
<slangasek> ah, but KE1HA has just reported that it also fails on XP
<robbiew> slangasek: whew...as I don't have Vista or Win7
<cjwatson> hm, so wubi was changed
<cjwatson> in a rather odd way ...
<cjwatson> cjwatson@lillypilly:/home/evand/public_html/wubi/lucid$ ls -l
<cjwatson> ...
<cjwatson> -rwxr-xr-x 1 evand warthogs 1469477 2010-04-26 18:06 wubi-r189.exe
<cjwatson> -rwxr-xr-x 1 evand warthogs 1467844 2010-07-08 17:55 wubi-r190.exe
<cjwatson> and
<cjwatson> lrwxrwxrwx 1 evand warthogs      13 2010-07-08 17:56 stable -> wubi-r190.exe
<cjwatson> now:
<cjwatson> revno: 190
<cjwatson> committer: Colin Watson <cjwatson@canonical.com>
<cjwatson> branch nick: trunk
<cjwatson> timestamp: Wed 2010-06-30 11:45:57 +0100
<cjwatson> message:
<cjwatson>   Bump to 10.10.
<cjwatson> so I'm guessing that maybe that was accidental
<cjwatson> would it be worth trying a rebuild with .../wubi/lucid/wubi-r189.exe rather than .../wubi/lucid/stable?
<slangasek> cjwatson: likely - though does wubi need an update for the point release, period? https://wiki.ubuntu.com/PointReleaseProcess says it does
<cjwatson> I don't see how that commit could have caused this bug, but since it's wrong for lucid anyway then it seems worth giving a backout a go
<cjwatson> oh, I wonder if there is a branch
<cjwatson> ah, never mind, I think this was r190 on lp:~ubuntu-installer/wubi/lucid
<cjwatson> "Bump Ubuntu and Kubuntu to 10.04.1."
<slangasek> ah
<cjwatson> this doesn't leave me with any more idea of what's going on
<cjwatson> are we sure that the XP failure has the same error message?
<slangasek> KE1HA, cjwatson; cjwatson, KE1HA. :)
<cjwatson> god, I really don't want to be on the hook for wubi
<slangasek> well
<cjwatson> for one thing I don't have a build system set up for it
<KE1HA> Hello all, Im just downloading the Wubi.exe binary now.
<slangasek> should we ring ev?
<cjwatson> it might be a plan
<marjo> slangasek: yes, please
<cjwatson> is he on inaccessible-holiday or merely on holiday?
<slangasek> cjwatson: in any case, I have to dive out for the next 15 minutes for a phone call; can you do the needful? :)
<robbiew> I don't know
<KE1HA> I;ve got them two logs now if you want them.
<KE1HA> going to upd the bug 1st
<cjwatson> I'll SMS him now
<marjo> cjwatson: thx!
<cjwatson> sent, can't guarantee anything
<KE1HA> Ok, all done posting to the Bug.
 * cjwatson wonders if dding the backup of his Windows partition into a fresh partition in a VM will result in anything usable
<cjwatson> my guess is a big fat no
<ara> mine too :D
<KE1HA> 1st questoin, what is a Metalink ?  that's what it can't get fer some reason, the url to the ISO or somethign ?
<KE1HA> While you guys are looking that over, Im going to try the standalone version.
<cjwatson> KE1HA: er, that sounds like a different error from the one we were seeing on Windows 7
<cjwatson> metalink is a download manager file format
<KE1HA> Yes, I thought so too.
<cjwatson> please file a fresh bug
<KE1HA> Ok
<KE1HA> Let me try the standalone verson first here.
<cjwatson> your problem will actually magically resolve itself once 10.04.1 is released properly
<KE1HA> Does this thing really need 17GB of space ?
<cjwatson> the reason you're seeing it now is that wubi's set of metalink URLs haven't been updated for the new locations for lucid daily builds following lucid's release
<cjwatson> so KE1HA's test is actually confirmation that XP does not suffer from bug 613288
<KE1HA> Now that makes since.
<cjwatson> wait, no it's not, it doesn't get far enough for that
<KE1HA> Im trying the Standalone, I expect it will fail on the metalink as well. But I dont know if bug 613288 happens before or after the metalink.
<cjwatson> don't bother with standalone, not interesting
<cjwatson> let me install a really cheesy temporary hack
<marjo> cjwatson, davmor2 here I've said I can possibly head home from the sprint tomorrow and hit this on my windows boxes there
<marjo> cjwatson: and i support this idea, as necessary
<robbiew> marjo: I'd like to release 10.04.1 today if at all possible
<marjo> robbiew: +1
<robbiew> I'm running a test now
<cjwatson> I'm putting some HTTP redirects in place so that the old daily download URLs work
<robbiew> WindowsXP though
<cjwatson> KE1HA: could you please try your XP test from CD again, with no changes?
<KE1HA> Ok.
<KE1HA> Using the same Image i originalyl burned ?
<cjwatson> yes, the 10.04.1 candidate image
<KE1HA> rr ok
<cjwatson> I have caused the metalink URLs built into it to work
<cjwatson> nobody is to look too hard at how. :-)
<KE1HA> Aren't these metalinks hard coded in the API ?
<KE1HA> Or does it go fetch some data forst
<KE1HA> first*
<cjwatson> the metalinks are URLs; it fetches from them
<cjwatson> I control the server on which those URLs are hosted and so can make them work
<KE1HA> Oh, I see you out the re-direct on your end, got it.
<KE1HA> put*
<KE1HA> so it's gonna go fetch from the same place, only to be re-directed.
<cjwatson> this should hopefully get you past the previous error and then we can find out whether you're encountering the same bug as people are seeing on Windows 7
<cjwatson> since it happens after fetching the metalink
<KE1HA> Ah, that's what I didn't know before, which one happed first.
<robbiew> cjwatson: so I ran the wubi.exe file and it is currently downloading the iso
<KE1HA> Im on three KB's here, and can't type to begin wiht so excuse the typo's :-)
<cjwatson> 07-20 10:52 DEBUG  Distro:   checking Ubuntu ISO C:\ubuntu\install\installation.iso
<cjwatson> 07-20 10:52 DEBUG  Distro:     wrong size: 2003522560 > 900000000
<KE1HA> It went Past the Fetch, it's Downloading, Slow, but it's on its way.
<cjwatson> also suspicious from your log, but never mind if it seems to be working now
<cjwatson> not sure why it's downloading if you're running from a CD
<KE1HA> I dont know, says downloading lucid-desktop-iso.
<KE1HA> Its funny, cuz I can see all the folders it needs on the disk
<cjwatson> dinnertime
<KE1HA> Indeed, this has got at least 2h 20m to DL it says.
<cjwatson> did you actually boot from the CD you burned?
<cjwatson> or did you just run wubi.exe from it?
<cjwatson> oh, wait, if you booted from it it would boot into Ubuntu, duh. ignore me.
<KE1HA> No, opened it in Windows explorer
<KE1HA> :-)
<KE1HA> You may as well take a break, this is gonna take a while. Which Mirror did you re-direct me too ?
<cjwatson> same mirror, just a different URL on it
<cjwatson> RedirectTemp /daily-live/current/lucid-desktop-i386.metalink http://cdimage.ubuntu.com/lucid/daily-live/current/lucid-desktop-i386.metalink
<KE1HA> Is US west-cost mirror ?
<cjwatson> cdimage.u.c is London
<KE1HA> Ahh, thats why so long to DL. Im in MT. Near Idaho.
<cjwatson> there aren't many mirrors of daily builds
<KE1HA> Ok
<KE1HA> anyways, enjoy dinnrer, we've got 2hrs 15mins to go :-)
<KE1HA> flippen windows, I DL this in 20 / 30 mins with zsync on my workstation.
<robbiew> cjwatson: slangasek: I was able to successfully install to a WindowsXP machine using the wubi.exe file from the daily
<slangasek> robbiew: ok
<KE1HA> Is that the Wubi binary DL, not the one included on the image?
<slangasek> bladernr, ara: do you know if any of the wubi testing at release time was done against Vista?
<slangasek> KE1HA: "from the daily" -> the one included on the image
<KE1HA> ok
<robbiew> slangasek: skat can test against vista ;)
<robbiew> is downloading the iso now
<slangasek> ok
<ara> slangasek, davmor2 says yes
<slangasek> alrighty
<KE1HA> Yeah, I don't knwo what it's DLing, the ISO is already there, thats kinda daft.
<KE1HA> Why it's*
<robbiew> slangasek: Win7...not Vista, but still should be a useful test
<marjo> robbiew: davmor2 says he tested w/ Vista
<marjo> at release time
<robbiew> marjo: ack...skat is testing with Win7
<marjo> robbiew: ack that
 * robbiew spoke too soon...the wubi install completed...and launched the ubuntu install...which completed, but fails to boot :/
<davmor2> cjwatson would it help if I went home? if so robbiew can sanction my fuel cost right :)
<slangasek> robbiew: hmmm, probably an unrelated bug?
<robbiew> yeah
<slangasek> what's the failure?
<davmor2> robbiew did it drop straight into grub shell?
<KE1HA> I though Wubi was like LiveCD but fer within WonDoze ?
<KE1HA> It doen't actually mess wiht the MBR right ?
<robbiew> davmor2: no..I get a weird error message....I'll try to catch it
<davmor2> KE1HA no it  installs the image to virtual  drives inside  windows.
<slangasek> KE1HA: it injects Ubuntu into the boot process; I don't remember if it installs to the MBR, or if it sets itself up as a boot target from within the NT loader
<robbiew> disclaimer: this machine is dual-boot...so I boot into windows..then try to boot into Ubuntu...if that makes a difference
<robbiew> davmor2: ^
<davmor2> grub for windows
<KE1HA> i see.
<davmor2> slangasek, robbiew I can get home in 1 hour 30 to 2 hours but I would like to be back tomorrow if you guys sanction the fuel bill I'll drive home and back it'll cost you 50 quid
<KE1HA> Ok, while we wait, how does the LiveCD boot process differ from the Wubi Boot Process, or is that what is used on the live boot?
<slangasek> KE1HA: the liveCD boots from CD, Wubi boots from the hard drive
<slangasek> davmor2: I hold no purse strings :)
<davmor2> I have the advantages of knowing what it should do and windows 98 xp vista and win 7
<robbiew> davmor2: I don't have that authority
<SpamapS> I have a Dell mini10n here with a fresh install of Windows 7 .. would that help to test wubi?
<robbiew> SpamapS: yes!
<SpamapS> will start the process after the server team meeting
<robbiew> SpamapS: thnx
<KE1HA> Im abt 1/2 way though now. watching the cows come home.
<SpamapS> robbiew: where is the 10.04.1 wubi download?
<robbiew> SpamapS: http://cdimage.ubuntu.com/lucid/daily-live/current/lucid-desktop-i386.iso
<robbiew> you'll need to use the ISO version
<robbiew> this is the release candidate ISO
<robbiew> wubi.exe is on there
<SpamapS> right, downloading now
<SpamapS> davmor2: can you at least share with me what it should/shouldn't do since I have a windows 7 box here (and 4 minutes left on my download)
<davmor2> SpamapS: so there is a guide I'll grab you the link in a minute.  Basically you boot windows, insert the cd, nice menu pops you, you select install inside windows, type in a password, it sets up the virtual drives inside windows, copies the parts of the iso it needs then installs the windows side of stuff
<davmor2> you then on boot get windows for
<davmor2> or ubuntu option
<davmor2> choose the ubuntu option, this then does an automated ubiquity install
<KE1HA> Here's the one ara gave me: http://blog.cyphermox.net/2010/06/wubi-installing-ubuntu-inside-windows.html
<davmor2> SpamapS: you then have a full ubuntu install inside windows
<davmor2> SpamapS: does that help?
<SpamapS> davmor2: sure, do I have to burn the CD, or can I just run wubi after mounting the iso?
<davmor2> SpamapS: Helps if it is from cd as it would give a more realistic result but at this time anything that works is good
<SpamapS> having trouble actually finding the optical drive.. so I'm running it from the iso directly for now
<skat_> Spamap5, I'll burn a CD then.
<davmor2> robbiew: at this point it's getting to late in the day for me to go home,  if there is an issue and cjwatson needs to fix it that will mean respinning all the live cd's in which case it ain't happening till tomorrow.  At which point I'll go home and kill all the iso in the morning and come back for the afternoon.
<robbiew> davmor2: ok
<davmor2> ara: did you eat?
 * SpamapS reboots
<ara> davmor2, yes
<davmor2> SpamapS: talk to us, please
 * skat_ reboots too...
<SpamapS> 384% verifying configuration was a little weird..
<SpamapS> but its in the "Calculating files" stage
<SpamapS> and now "Copying files..."
<davmor2> yeah it is a liitle
<SpamapS> davmor2: is that a new bug?
<skat_> on splash screen when its working on config it says welcome to 10.4 LTS,  shouldn't that be 10.4.1?
<davmor2> SpamapS: no that's an old bug that they can't do much about currently
<SpamapS> ah ok. :)
<SpamapS> I never paid this close attention to the install. :)
<davmor2> SpamapS: it only does it on wubi, in the normal installer it does need to register the 100%'s for partitioning, formatting etc
<slangasek> skat_: ideally yes, but I don't think we synchronize those messages with the point release
<SpamapS> 60% copying files
<skat_> slangasek, cjwatson - install from CD with candidate via WUBI is working on Vista 7 - Dell Inspiron N5010
<SpamapS> skat_: I thin its reasonable to just show major versions in splash screens and installers. .1 is more important in an "About" screen, bug report, or release notes type situation.
<skat_> Ubuntu had never been installed on this system before, so its a clean install.
<davmor2> skat: it needs to get all the way through the windows part of the install then the linux part and then reboot into the fully installed system
<slangasek> skat_: ok, then it really sounds like the issues people are having are a corner case and not a regression - thanks for testing!
<skat_> davmor2,  yes.   it did.
<SpamapS> I'm at configuring hardware.
<davmor2> Yay!
<slangasek> skat_: can you record your results under the appropriate test on http://iso.qa.ubuntu.com/qatracker/build/all?
<robbiew> \o/
<robbiew> she may not have an account there yet
<skat_> just point me at what I need to do, and I'll try.. ;)
<slangasek> I bet it's faster for her to create an account than for someone else to retest, though :)
<SpamapS> I've got an iso testing account, will register my results there too as soon as it completes.
<davmor2> skat: just click on login create an account once that is done give me a ping I can talk you through the rest
<cjwatson> slangasek: corner case> agreed, more or less ...
<skat_> davmor2,  okie.
<slangasek> skat_: http://iso.qa.ubuntu.com/user/register to create an account, then once you're logged in you pick the image from the list that corresponds to what you've actually tested, then drill down into "wubi" and record your test as a success
<cjwatson> skat_: do file a bug about the bogus message, we should fix that for .2
<marjo> skat: ara can also help you or will record your results for you
<davmor2> cjwatson: which one?
<cjwatson> 21:08 <skat_> on splash screen when its working on config it says welcome to 10.4 LTS,  shouldn't that be 10.4.1?
<davmor2> the 384%
<cjwatson> I think there's already a bug about the stupid percentage
<cjwatson> tedium incarnate to track down though :-/
<davmor2> there is I filed it
<SpamapS> rebooting....
<SpamapS> I got a grub menu.. which is not mentioned in the testing steps
<SpamapS> booted, logging in
<davmor2> SpamapS: it is in the original I think
<cjwatson> the grub menu is supposed to be there
<cjwatson> I think
<SpamapS> hearing drums
<SpamapS> Once at the Windows Boot menu select Ubuntu again and press Enter
<SpamapS> At the login screen type in your user name and press Enter
<SpamapS> thats from http://testcases.qa.ubuntu.com/Install/DesktopWubi
<SpamapS> other than that grub menu, looks good
<robbiew> grub menu is expected
<ara> skat_, let me know if you need anything
<robbiew> Time to kick the tires and light the fires!
<SpamapS> Ok, well wubi works then on my Dell Mini1012 from pre-installed Windows 7 starter
<davmor2> SpamapS:  wdi-002  step5 I think you'll find the menu is there
<cyphermox> wubi was working for me from the CD on a Toshiba Tecra A10
<skat_> ara,  davmor2,  have created account,  now figuring out.... how to log it...
<cyphermox> sorry it took so long, windows wouldn't recognize the wifi or eth device, so I couldn't start wdi-004
<cjwatson> I have a fix for the issue that required an HTTP redirect workaround, but am leaving wubi bzr the hell alone until we're done with .1
<ara> skat_, are you logged in?
<robbiew> cjwatson: amen to that
<robbiew> cjwatson: I can burn through the change summary, assuming you figured out how to work around that python error I was getting
<SpamapS> Is there anything else I can do?
<cjwatson> robbiew: oh, I forgot about that
 * cjwatson goes to poke
<robbiew> SpamapS: nah...I think that was the last verification we needed
<cjwatson> maybe I should just use python3 for lucid-updates.py :P
<cjwatson> I bet launchpadlib isn't set up for it
<marjo> SpamapS, cyphermox, skat_, KE1HA: thx for all your help testing at the last minute
<SpamapS> np. :) My wife will be thrilled that I finally replaced dumpy old windows 7 on her netbook with lucid. :-D
<robbiew> lol
<marjo> SpamapS: this was a great excuse to do so
<slangasek> robbiew: "last verification" - are we not testing wubi across all images?  there are 4 desktop images total that I'm expecting to be in 10.04.1, each of which has a wubi test case
<robbiew> slangasek: I thought the others passed...grrr
<slangasek> robbiew: we had had a total of one test which was the failure; the only successes are the ones we've just heard about in this channel in the past couple of hours, and I'm not sure which images they were done on
<robbiew> SpamapS: skat_: I'm assuming you both did Ubuntu i386, correct
<robbiew> ?
<SpamapS> yes i386
<robbiew> cyphermox: your test was i386 as well
<skat_> robbiew,   yup did the one you pointed me at ;)
<marjo> robbiew: the missing wubi testing are: kubuntu desktop amd64, kubuntu netbook i386, ubuntu desktop amd64
<robbiew> skat_: you do the Kubuntu i386?
<robbiew> could you
<davmor2> no m-a tests either
<cjwatson> robbiew: (testing my fix, sorry, it takes a while to churn through all the language-pack .changes files)
<robbiew> cjwatson: no worries
<davmor2> marjo, robbiew: Migration assistant hasn't been tested either on Ubuntu 32bit or 64bit
<robbiew> davmor2: ack...I'll  test those in a virt machine now
<davmor2> robbiew: needs Windows to migrate against
<robbiew> davmor2: yeah...I know ;)
<davmor2> robbiew: I'm just taking nothing for granted right :)
<robbiew> aye
<skat_> robbiew,  download full, burn image, and repeat?
<davmor2> skat: yeap
<davmor2> robbiew: is someone able to test the 64bit wubi too?
<skat_> davmor2, ok - starting download now then....
<robbiew> davmor2: does she need to uninstall Ubuntu from the windows side first?
<davmor2> robbiew:  nope the windows side installer will do that
<robbiew> cool
<davmor2> detects that there is already a version on the system and removes it then triggers the install
<robbiew> davmor2: hmm...I don't now (re 64bit wubi).../me hunts for a 64bit XP CD
<davmor2> robbiew: you don't need 64bit xp
<cjwatson> robbiew: try lucid-updates.py from the same URL again - my test hasn't completed though, it's just taking too long
<cjwatson> but you might have faster internet than me
<robbiew> davmor2: oh cool
<davmor2> robbiew: you only need 64bit capable cpu
<robbiew> cjwatson: ack
<robbiew> I have that
<robbiew> thought the test needed wubi ran on a 64bit XP installation
<davmor2> robbiew: no it just installs 64bit ubuntu on the system.
<robbiew> gotcha
<KE1HA> Finally, 2h 11m 0.335 mins later, its work'en :-)
<marjo> KE1HA: are you able to test with kbuntu netbook i386?
<davmor2> marjo, robbiew, slangasek: is there no une for .1?
<KE1HA> well, yes and not, I spoke too soon. I can get to the Boot Option mention, but after the Plymouth splash, it's all locked up, but that's a different bug, nowt to do with Wubi.
<robbiew> davmor2: correct, as UNE was not an LTS
<davmor2> robbiew: thank god for that
<robbiew> :D
<KE1HA> I should have known better, this is the whole reason UB is not on this laptop to begin with.
<marjo> robbiew: cyphermox is trying to help out w/ ubuntu desktop amd64
<robbiew> marjo: perfect
<cyphermox> marjo, hey, I chose kubuntu!
<marjo> kubuntu desktop amd64, i meant
<robbiew> marjo: EVEN BETTER!
<robbiew> :D
 * robbiew stops his kubuntu 64bit ISO download
<cyphermox> ah, it's downloaded now, thx for zsync
<ara> long life
<marjo> yeah zsync!
<cyphermox> there may have something to give to the pipes in the office here, but I'm sure it's 95% zsync :)
<marjo> cyphermox: can you please go ahead and start download of ubuntu desktop amd64 on the side?
<cyphermox> sure
<marjo> cyphermox: thx
<cyphermox> this should go even faster, citron should already have it
<marjo> cyphermox: nice
<cyphermox> any reason amd64 would bomb on a 32 bit windows?
<davmor2> cyphermox: no the install should run exactly the same
<robbiew> cjwatson: FYI...got pass the previous issue...seems to be rolling along now
<cyphermox> davmor2, thx, that's what I thought
<marjo> cyphermox: you may as well go for "kubuntu netbook i386" if you've got the pipes, zsync, hw, windows
<cyphermox> marjo, I only have one windows machine -- ran the install for vista this morning/early afternoon
<davmor2> cyphermox: the only thing that windows actually provide the install is an ntfs partition and away to start the install
<marjo> cyphermox: ack
<KE1HA> Is anyone doing Migration pm UB-Desktop-AMD64 ?
<marjo> KE1HA: no, go for it! thx
<KE1HA> rr
<davmor2> KE1HA: that's another one against windows
<KE1HA> It just says resize the drive with the slider, I dont see Windows anywhere on the page, where's it say for Windows?
<davmor2> KE1HA: it's designed to run against windows that's what it migrates from properly
<KE1HA> Oh, ok, well bugger, I just installed a 20GB VM so I could resize it :-)
<KE1HA> Well things are looking pretty spiffy at this point I'd say.
<marjo> KE1HA: good to hear
<KE1HA> I could not reproduce either of the red-bugs today when I tried.
<marjo> KE1HA: which images did you test with? did you report your results at: http://iso.qa.ubuntu.com/qatracker/ ?
<KE1HA> I testes with 20100816.1 and 16.2 ... yes, I got though about 60 of them or so.
<KE1HA> tested*
<cjwatson> robbiew: oh good
<KE1HA> Over all, the only bugs I saw were minor, and certainly not show stoppers like this Wubi thing was.
<marjo> KE1HA: ack & thx
<cyphermox> is there a good reason to re-test wdi-004 with multiple flavours?
<cyphermox> so far kubuntu desktop amd64 is good w/ wdi-00[123]
<cyphermox> wdi-004 is downloading and using the standalone wubi instead of the one from the cd
<KE1HA> I would think so, Win7 FS is diff than Vista and XP, and then there UAC and all that noise on Vista.
<KE1HA> with XP comming in the easiest I'd say.
<cyphermox> KE1HA, no, I mean flavours of Ubuntu :) e.g. Ubuntu, Kubuntu, etc.
<KE1HA> Oh... SRI man, Im a bit knackerd at the moment :-)
<robbiew> cyphermox: the only difference is that wubi has to download the iso
<robbiew> so should probably start it
<robbiew> but if the iso downloads and the reboot into the installer works..I would think that's a pass
<robbiew> i.e. no need to complete the install as well...as that's the same as wdi-001 at that point
<cyphermox> robbiew, indeed.
<cyphermox> ok, I kept the pages open so I'll re-change to started and do that part once I'm done with ubuntu desktop amd64
<marjo> robbiew: when cyphermox is done with his two tests, that should finish the untested wubi cases
<marjo> since kubuntu netbook i386 is not a valid test case for 10.04.1
<robbiew> marjo: still need skat_ to complete the Kubuntu i386 wubi
<marjo> robbiew: ack
<robbiew> marjo: I just completed the migration assistant test...i386...pass
<marjo> robbiew: please extend our thanks to your wife for lending the equipment
<robbiew> marjo: heh...she was using her Mac at the time anyway
 * robbiew just used virtual machine...easier 
<robbiew> and if I mess something up...it's on MY machine ;)
<ara> wife/husband/partner datacentre is become more and more frequent in Canonical
<marjo> robbiew: i almost killed my eeepc running virtualbox today
<robbiew> ara: :)
<robbiew> marjo: lol
<slangasek> cyphermox: how is kubuntu amd64 wubi coming?
<ara> are we there yet?
<ara> :)
<slangasek> cyphermox: oh, I guess you're taking /both/ the outstanding wubi test cases... so.. how are /they/ going? :)
<slangasek> ara: did you and cjwatson have a chance to discuss bug #619353, or is that backburnered?
<cyphermox> slangasek, almost done :)
<slangasek> spiff
<robbiew> slangasek: testing migration assistant with Ubuntu Desktop 64bit now...had to download the ISO :/
<robbiew> "UnicodeDecodeError: 'utf8' codec can't decode byte 0xc3 in position 93: unexpected end of data" ugh...so maybe we don't need a change summary for 10.04.1
<cjwatson> ara: sort of looks like a network problem, from the logs - can't talk to ntp.ubuntu.com, fails to connect to the target at the network layer, and lots of chatter from dhclient ...
<cjwatson> hard to say though, guess I'll have to give it a try once I get my target working again
<cjwatson> robbiew: there's a debug print commented out I think; if you uncomment that we might get an idea of where it's failing
<robbiew> cjwatson: oh man...it took A LONG time to get through the k's :/
<cjwatson> yeah, I know :(
<cjwatson> hate python's unicode handling sometimes
<cyphermox> someone please remind me to rig the lab to do windows installs prior to maverick release... takes forever to test so many things with just one windows box :/
<cjwatson> it's one of the few unambiguously sucky bits of the core language.  fortunately better in 3, I'm told
<cyphermox> Ubuntu Desktop amd64
<cyphermox> ^ pass
<cyphermox> finishing up with kubuntu desktop amd64. I'm sure it's okay, but I messed up my password and couldn't get in, so I'm doing the install again
<robbiew> cyphermox: doh!
<cyphermox> robbiew, indeed.
<robbiew> Ubuntu 64bit migration assistant -> PASS
<ara> cjwatson, but the dhcp works, do you want me to test anything else?
<marjo> cyphermox: go easy there
<marjo> robbiew: ack
<cyphermox> Kubuntu Desktop amd64 wubi <--- PASS
<davmor2> Yay!
<robbiew> it's all on you now skat_....no pressure
<robbiew> :P
<marjo> cyphermox: good man
<skat_> robbiew, 88% of kubuntu ....  right now and counting..  ;)
<robbiew> didn't help her progress much that I gave her the wrong link earlier (to Kubuntu 10.10)...http://www.sadtrombone.com
<skat_> has same 10.4 vs. 10.4.1 issue in the splash screens.
<marjo> robbiew: you meant well
<robbiew> skat_: um, yeah....we can live with that bug :P
<robbiew> marjo: perhaps....uuaahahahahahhaaaa!
<robbiew> joking
<ara> mmm, it is the first day I heard about sadtrombone and the second time today...
<marjo> ara: you haven't been hanging around jono much
<robbiew> marjo: more like hanging around the managers much...we have "issues"...lol
<skat_> robbiew,  Kubuntu Desktop i386 WUBI ... pass  :0
<skat_> s/:0/:)/
<marjo> robbiew: i didn't want to tell ara that
<marjo> skat_: thx much!
 * robbiew does the pom-poms icon   *\o/*  
<marjo> robbiew: i think that covers all outstanding tests, agree?
<ara> :D
<robbiew> marjo: yes
#ubuntu-release 2010-08-18
<marjo> it's midnight in oxford, release?!
<cyphermox> marjo, midnight, does that mean it's more beer time for you?
<marjo> cyphermox: moved on to coffee a while back & ate at hotel
<robbiew> slangasek: okay...now I believe it's officially time to kick the tires and light the fires!
<robbiew> marjo: as long as it's 08/17 somewhere on the planet...we're good to go!
<robbiew> lol
<skat_> robbiew,  please let newz2000 know - he's still on.
<cyphermox> still 08/17 here
<marjo> robbiew: good release management practice
<ara> ok, ladies and gents, off to bed
 * cyphermox goes out to get dinner
<marjo> ara; thx and good night
<ara> night!
<cyphermox> good night ara
<skat_> ara;  thanks for your help.   :)
<marjo> cyphermox: thx man! have a good dinner
<cyphermox> marjo, thx, later
 * robbiew has to step away to watch the kids...but will be close enough to see his thinkpad light / hear his laptop
<slangasek> robbiew: burning tires, check
 * oubiwann-away chuckles
<marjo> skat_ isn't this fun?
<robbiew> skat_: btw, slangasek will let newz2000 know...so he can delay the website update for some trivial reason as usual
<skat_> marjo,  learned alot today.  :)
<robbiew> lol
<robbiew> skat_: now just imagine the fun a FULL release is...with all the ISOs/images :D
<elmo> and then imagine SOMEONE agreed to do it on a weekend!
<marjo> robbiew: don't jinx her! watch those kids!
<skat_> slangasek,  newz2000 asked to be paged when you're ready.
<slangasek> paged> ack
<slangasek> robbiew: on a full release, we plan / resource better :P
<robbiew> VERY TRUE
<skat_> robbiew,  slangasek,  :)
<marjo> davmor2: you get to stay with us tomorrow
<davmor2> Yay
<marjo> davmor2: buy you a coke tomorrow
<davmor2> haha :)
<davmor2> nn then all
<marjo> davmor2: nn
<slangasek> disabling sync-mirrors on antimony for publishing
<robbiew> ack
<slangasek> hmm, I think maybe we don't want kubuntu 10.10 alpha 2 on releases.u.c
<slangasek> ScottK: kubuntu netbook appears to not be done with validation, so I'm not publishing it right now; it can catch up in another round later tonight
<skat_> robbiew,  updated 613288 with steps I took,  see if figure out more about the difference later.
<robbiew> skat_: thnx
<slangasek> hmm, we didn't have UNE for 8.04, did we
<slangasek> makes for an additional challenge
<slangasek> (web indices are dropping all references to UNE because they don't match the filename pattern, but of course they're still published)
<robbiew> slangasek: was 8.10 the first UNR...or even 9.04?
<robbiew> slangasek: btw, mvo is out but sent me the instructions to enable the 8.04 -> 10.04.1 upgrades...though I think only he and the admins can do it on rookery...worst case scenario, he said he could do it Friday
<slangasek> robbiew: don't remember... 2008 was a long time ago :)
<robbiew> tell me about it
<robbiew> lol
<slangasek> ok, think I have make-web-indices doing what I want
<slangasek> a trifling edit
<robbiew> heh
<ScottK> slangasek: OK.  It just needs wubi, right?
<slangasek> ScottK: correct
<ScottK> slangasek: There's nothing wubi specific in the differences between Kubuntu desktop and netbook.  Can we call that "close enough"?
<ScottK> No idea who'd do the wubi bits (I can't).
<slangasek> Riddell: ^^ is that ok with you?
<robbiew> is Riddell awake?
<ScottK> wubi use case is a lot weaker on netbooks anyway, IMO.  They tend to have smaller drives.
<slangasek> robbiew: dunno, but ReleaseManifest says he's who I should poke for signoff of kubuntu netbook releases
<robbiew> ack
<ScottK> 5, 4, 3, 2, 1.
<ScottK> He didn't object ....
<slangasek> we can make an executive decision, but I'm still working on publishing anyway so we don't need the answer immediately
<slangasek> :)
<robbiew> I agree with ScottK...I don't see skipping wubi for kubuntu netbook as a big deal
<slangasek> actually, that makes kubuntu publishing much simpler than ubuntu was if we do it that way, since that means everything goes to .1 at the same time
<robbiew> of course now I've jinxed it...it will fail and be all over LWN and /.
<robbiew> slangasek: then in the words of Jean-Luc Piccard....make it so
<robbiew> lol
<ScottK> robbiew: If you need a quote for cover: Lead community developer for Kubuntu Netbook Remix, Scott Kitterman said, "I really don't care if it works on Windows.  If they are booting Windows, they've already got bigger problems."
<robbiew> lol
<slangasek> ok, got all the bits in order now
<slangasek> waiting for prepublishing confirmation before proceeding
<slangasek> paging newz2000 now
<robbiew> slangasek: cool....and the countdown begins
<newz2000> slangasek: howdy
<slangasek> newz2000: hi there
<newz2000> anything needed besides an update to the download page?
<slangasek> newz2000: so, I'm not sure if anyone has communicated you regarding which images are getting revved for 10.04.1 and have URL changes; I was only tagged in on this in the past week
 * slangasek inserts a preposition
 * ScottK hands slangasek some lube to ease the pain.
<slangasek> newz2000: Ubuntu desktop, alternate, and server CDs are all part of the point release and have new URLs; Kubuntu desktop, alternate, netbook also; Ubuntu netbook is *not* revved for the point release, so any download links for UNE must *not* change
<newz2000> oh no
<slangasek> newz2000: I'm not sure which of those you actually link to, but I know that UNE is among them
<slangasek> newz2000: right - sorry for the late notice.  Is it going to be painful to accomodate this on your side?  I would rather not be sticking incorrect 10.04.1 links in place on the mirror side to compensate
<newz2000> the way the system works is it assumes the file name matches a pattern like this: %1$s/lucid/%2$s-10.04-%3$s-%4$s.iso
<newz2000> sorry, that is unitelligible
<newz2000> I don't have an easy way to configure it one way for une and another way for server etc
 * newz2000 looks for a way
<newz2000> slangasek: are the mirrors already up to date?
<slangasek> newz2000: most of the main mirrors now have 10.04.1 in the pool; I haven't pushed the plunger yet for the lucid/ directory
<newz2000> is it possible to use the same name for une as for the other images?
<newz2000> actually, I'm going to have to change the download page code
<newz2000> to support diff names
<newz2000> give me a couple min
<slangasek> I /can/ stub something in to fix up the names, but it would be inaccurate
<slangasek> but if changing the download page code is too time consuming or risky, I'll do it
 * skat_ watching with interest...
 * ScottK waits for slangasek to show off.
<newz2000> slangasek: let me see if a sysadmin can help me out with a change
<slangasek> newz2000: ok
<slangasek> skat_: my thought process here is to use an http redirect via .htaccess, which is the same method used for redirecting to old-releases.ubuntu.com for no-longer-supported releases.
<newz2000> slangasek: ok so the file names for une are no diff than before, so no change should be made to the path for them
<slangasek> skat_: so I would put in RedirectPermanent rules for the netbook filenames the downloader is looking for; this would avoid having them show up in the index, but would forward the download links to the correct filenames.  It assumes reasonable support for .htaccess on the webserver, but we're already making use of these features extensively so that's not a stretch - *and* I can add the dummy names to the .manifest file so that the mirro
<slangasek> ... won't consider a mirror good unless it serves the filenames in question
<slangasek> newz2000: correct
<slangasek> newz2000: whereas all the others change from 10.04 to 10.04.1
<newz2000> ok, perfect, that was going to be my next question
<newz2000> slangasek, skat_: can we update the release process so that during that step where you contact the webmaster we confirm the file names?
<slangasek> skat_: but I have no way to know for sure before trying it how much that would reduce our set of available mirrors
<skat_> slangasek:  if we're already using the method elsewhere, sounds reasonable.    I'll look at it from firefox and explorer when its up and see what the experience is like.
<slangasek> newz2000, skat_: annotating this on https://wiki.ubuntu.com/PointReleaseProcess now
<skat_> slangasek:  :)
<newz2000> ok, working it's working on dev, just a min to get to staging
<ScottK> No one who normally works on kubuntu.org is around.  I guess I need to go dig up my userid and password and see if I still have access.
<newz2000> slangasek: ok, emergency change going live momentarily, then we'll be ready to push
<slangasek> newz2000: ack - sorry for the troubles
<slangasek> robbiew, skat_: who wants to send the announcement mail? :)
<robbiew> heh
<robbiew> given I have it cued up...and have delayed it numerous times...I can
<robbiew> we'll let her enjoy 10.10
<skat_> slangsek:  it's robbie's baby...
<newz2000> so I made this new system so that releases would be painless... :-)
<robbiew> and boy is it overdue
<robbiew> newz2000: how's that workin for ya?
<newz2000> :-)
<newz2000> ok, the website is now ready to be updated to point to 10.04.1
<newz2000> let me know when to push
<slangasek> newz2000: pushing the button here; probably want to change the website in about 15 minutes to catch the middle of the propagation, but I'll let you know when
<newz2000> ok, gonna put the kids to bed and I'll be right back
<robbiew> newz2000: I hear that...got one down...one more to go
 * robbiew is NickJR'd out!
 * skat_ wondering if robbiew will do another Jean-Luc Picard impression....
<slangasek> skat_: at this point I'm prodding IS to give us a probe of all the CD mirrors, so that launchpad is feeding good and timely information into newz2000's download script
<slangasek> skat_: this isn't documented on the PointReleaseProcess page, it's the same as the ReleaseProcess page
<skat_> slangasek,  thanks.   How do I learn more about the CD mirrors, and their space/capacity?
<slangasek> skat_: by talking to jpds, I would say :)
<jpds> Good evening.
<skat_> slangasek:  :)   jpds: stand by for some questions after this release is out ;)
<slangasek> robbiew: fixed some small alignment bugs in the wiki announcement draft
<jpds> skat_: Will do. :)
<slangasek> skat_: LP's official view of current CD mirrors is at https://launchpad.net/ubuntu/+cdmirrors
<robbiew> ack...thnx...cut-and-paste is AWESOME :/
<slangasek> robbiew: maybe s/can found tomorrow at/will be made available tomorrow at/?
<slangasek> hum, is this the "About Ubuntu" blurb from 2 years ago? :-)
<slangasek> someone invented netbooks since the last time we did an LTS
<skat_> slangasek,  thanks.
<robbiew> slangasek: details...details
<robbiew> slangasek: probably good to add netbooks
<slangasek> robbiew: yep - imported the /current/ boiler plate :)
<robbiew> slangasek: also +1 on "will be made available tomorrow at"
<robbiew> slangasek: I'm assuming you are editing...or I can
<slangasek> I am
<robbiew> slangasek: "an incredible variety of add-on software is just a few clicks away." also reads weird to me
<robbiew> does "add-on" need to be there?
<slangasek> robbiew: I have no strong opinion either way
<robbiew> ah, screw it
<robbiew> lol
<slangasek> it wouldn't hurt to mix up the announcement text from time to time IMHO, these mails tend to become ossified after a while :)
<robbiew> I'll throw in a quote at the beginning ;)
<ScottK> As long as robbiew gets the release name right, it'll be progress ...
<ScottK> ;-)
<newz2000> Jimmy John Jones is ready to color!
<robbiew> ScottK: ha..ha
<newz2000> (daughter's fav book)
<robbiew> newz2000: lol
<newz2000> have you read that one?
<robbiew> I thought you had a turrets syndrome-like irc outburst
<ScottK> No.  That's me.
<slangasek> robbiew: now, you know about the X-Ubuntu header you have to include to get mails into the ubuntu-announce mod queue?
<robbiew> slangasek: nope...which would explain why I've never been able to post to it
<slangasek> :-)
<newz2000> oh, it's skippy jon jones I mean. (must be hungry for a sandwich)
<slangasek> robbiew: the mailing list checks for the existence of this email header, it doesn't have to have any particular value
<slangasek> so 'X-Ubuntu: skippy jon jones is ready to color!' will work just fine
<skat_> X-Ubuntu header?
<robbiew> lol
<slangasek> skat_: if we didn't pre-filter posts to ubuntu-announce, we would be spending inordinate amounts of time on the moderation queue; so there's a filter in front that auto-rejects any mail that doesn't have an X-Ubuntu header set
<slangasek> (that doesn't let your mail through to the list - it just lets your mail through to the mod queue :)
<skat_> spotted 10.0.01 on http://releases.ubuntu.com   :)   how long to propigate to mirrors?
<newz2000> it's not there yet, tested three mirrors and 100% failure
<slangasek> skat_: I haven't actually pulled the trigger on that yet, was waiting for the CD mirror probe to finish
<newz2000> https://launchpad.net/ubuntu/+cdmirrors is looking bleak
<slangasek> ok; looks like I didn't count on a cronjob running sync-mirror behind my back at just the right moment
<slangasek> so I did pull the trigger, I just hadn't meant to :P
<slangasek> but no damage done except a little confusion
<skat_> so, when I went to look for it from another computer, and am not seeing, it now, as you expect?
<ScottK> BTW, http://www.kubuntu.org/getkubuntu/download#download-block claims Kubuntu Netbook Remix is LTS, which is not correct.  Is that kubuntu.org or Canonical IS to fix?
<slangasek> skat_: we're in that lovely period of quantum superposition when the release is both there and not there
<newz2000> I kind of like when the quantum superposition happens at night
<robbiew> heh
<newz2000> except the part about having to work at night of course
<ScottK> If you look at it right, you can see a green flash.
 * newz2000 is glad he loves his job
<robbiew> newz2000: the sun is up somewhere...I'm sure of it
 * skat_ bemused at concept of there and not there... going back to refresh the pages...
<newz2000> went from 2 mirrors down to 1
<slangasek> skat_: releases.ubuntu.com itself is a round-robin mirror, IIRC, so even without taking into account other mirrors, the release doesn't appear all at the same time
<robbiew> slangasek: figured out how to add custom headers in evo...and that took longer than it should have...talk about usability, sheesh
<slangasek> I could talk about usability - but then the release wouldn't happen tonight
 * skat_ see's release visible again...
<robbiew> lol
<ScottK> newz2000: kubuntu.org download page now appears to point to the no longer existing 10.04 and not 10.04.1.
<ScottK> http://www.kubuntu.org/getkubuntu/download#download-block
<newz2000> I will ping their webmaster
<newz2000> I forgot they took over management of that themselves
 * ScottK tries his password again, just in case he got it wrong last time.
<newz2000> skippy jon jones is ready to release!
<newz2000> cool music at www.skippyjonjones.com
<robbiew> ack
<slangasek> heyo, 67 mirrors known
<slangasek> newz2000: please flip the switch for ubuntu.com
<newz2000> cool, just a min
 * robbiew sends the email
<robbiew> ...so it can be moderated :P
 * skat_ watching the mirrors appear.... :)
<ScottK> OK.  So ryanakca appeared and he and newz2000 are sorting the kubuntu.org links.
 * ScottK now works on a Kubuntu release announcement.
<slangasek> robbiew: hasn't hit the mod queue
<slangasek> oh, perhaps you've already processed it:)
 * robbiew canceled it...had a random > character in it
<slangasek> ah
<newz2000> ooh, its working, its working
 * skat_ interesting - some picking it up (Canada, Europe) some not...   fun to watch.
<ScottK> OK.  No longer in imminent danger of disappearing.  Found the power brick.
<newz2000> cron prob on prod
<newz2000> I'm trying to get admins to run a cron manually, until then some expired mirrors are in there mix
<skat_> newz2000,  that would explain it. :)
<slangasek> newz2000: which expired mirrors? we went down to 1 mirror, everything that got readded after that should be confirmed good
<newz2000> could be an hour old
<robbiew> slangasek: ok...should be in the mod queue now
<slangasek> oh, this is your cron job on the web side, right
<slangasek> robbiew: approved
<slangasek> now to grab some grub
<slangasek> yell/call if anything blows up in the next 30min :)
<skat_> slangsek,  most of mirrors in US aren't picking it up.   Oregon has though.
<newz2000> skat_: it will be self healing. Either IS will run cron manually or sometime soon it'll run automatically
<ScottK> slangasek: Are you updating ports images too?
<skat_> newz2000,  :)
 * robbiew is done for the day...if something explodes, it can burn until tomorrow!
 * newz2000 too
<skat_> robbiew,  shouldn't the image names have 10.4.1 in them?
<newz2000> skat_: yes, don't they?
<skat_> newz2000,  not the ones I'm looking at on the Oregon server....
<robbiew> newz2000: yes..they do
<newz2000> skat_: that mirror is out of date then
<newz2000> (btw, IS just found the cron task and its running now I think)
<skat_> hmmm....   mirror effects?  directory says 10.4.1,  but images underneath not showing it.
<robbiew> all I know is I was able to download an ISO from  http://releases.ubuntu.com/10.04.1/  ...good enough for me to call it a day! ;)
<newz2000> http://mirrors.ccs.neu.edu/releases.ubuntu.com/lucid/ubuntu-10.04.1-desktop-i386.iso works
<newz2000> skat_: are you looking at netbook?
<newz2000> alternate/desktop/server should have 10.04.1
<skat_> robbiew - yup,  I see 10.4.1 on releases too.    download in progress.
<skat_> newz2000:  look at Oregon Open Source Lab mirror.   10.4.1 directory in place, but contents ref. 10.4
<ScottK> kubuntu.org is updated now.
<newz2000> skat_: they have old and new there
<newz2000> kind of odd imho
<newz2000> I'm still getting a lot of failures on the download, bad mirrors
<newz2000> I'm going to let it set for a few min and check again
<skat_> newz2000, you're right.   I didn't scroll down far enough.
<jpds> skat_: The Oregon graphs are now https://munin.osuosl.org/osuosl.org/ftp-osl.osuosl.org/if_eth0.html - you can see the first ISO push above the "W".
<skat_> jpds,  not figuring out what I'm seeing - "push above the W" has me scratching head.
<slangasek> ScottK: ports> haven't rerolled anything for ports generally, except for kubuntu-netbook/armel* at your request; have those been validated and should they be pushed?
<ScottK> slangasek: No.  It hasn't.  Still working on that.
<slangasek> ok
<ScottK> slangasek: You'll still have the image to push after we get it tested, right?
<slangasek> ScottK: yes
<ScottK> OK.  Thanks.
<newz2000> skippy jon jones is ready for bed. Good night all
<newz2000> congrats on the release robbiew and skat_
<cjwatson> robbiew: elmo said he could do the 8.04 -> 10.04.1 upgrade thing if need be, if we send him instructions.  tell me yes or not
<cjwatson> *no
<cjwatson> skat_: "ISO push" is a noun phrase, if that helps, so I think jpds is just indicating where you can see the spike corresponding to ISOs being pushed to the mirror in question
<cjwatson> ah indeed, above the "W" of "Wed" in the legend of the top-left graph - the downward-pointing graph is inbound traffic
<sla_> sorry just in, can i see these graphs too? sounds interesting..
<cjwatson> 03:27 <jpds> skat_: The Oregon graphs are now https://munin.osuosl.org/osuosl.org/ftp-osl.osuosl.org/if_eth0.html - you can see the first ISO push above the "W".
<robbiew> cjwatson: I see no need to wait for mvo to return on Friday, so "yes"
<robbiew> unleash the masses on 10.04.1
<cjwatson> robbiew: RTed
<robbiew> cjwatson: thnx
<cjwatson> robbiew: done, per Spads
<robbiew> cjwatson: ack, thx
<robbiew> 1054 updates made to 10.04.1...whew!
<seb128> robbiew, the number seems wrong, or do you count all language packs updates?
<robbiew> seb128: yeah...was just a raw number
<robbiew> from a script
 * robbiew needs to clean it up before posting
<robbiew> slangasek: any idea how the USN info is gathered for the Change Summary?
<slangasek> robbiew: I would have thought it's gleaned from the website based on date
<slangasek> but this is a guess
<mdeslaur> slangasek: is there a way to know what exact package versions went in?
<mdeslaur> (besides downloading the dvd...)
#ubuntu-release 2010-08-19
<jpds> mdeslaur: The .list of the DVD file should have a listing?
<mdeslaur> jpds: thanks
<slangasek> there hasn't been a DVD spin for the point release though
<slangasek> mdeslaur: I think the cutoff on security was right after the copy of openjdk
<mdeslaur> slangasek: openjdk didn't make it
<mdeslaur> at least, on the server cd I just looked at
<slangasek> oh
<slangasek> right, depends how you're counting
<slangasek> it was in the snapshot, not in the CD :)
<slangasek> that was the one delta between the two
<slangasek> so, right /before/ openjdk
<mdeslaur> ok, cool
<mdeslaur> slangasek: thanks
<slangasek> sure thing
<ScottK> robbiew: clamav doesn't show up on your list.  It's got a new upstream version.  Makes me wonder what else got missed.
<robbiew> ScottK:hmm...used the same script we usually do...let me see if it wasn't a cut-and-paste error from when I was arranging by Install, Upgrade, etc
<ScottK> If it's just that, it's not a big deal, but dunno how much stuff got missed.
<robbiew> ScottK: hmm...not in the raw list either
<robbiew> cjwatson: ScottK says clamav was updated but it didn't get pulled by the script :/
<robbiew> ScottK: FYI, I used the script referred to in wiki.ubuntu.com/PointReleaseProcess -> http://people.canonical.com/~cjwatson/lucid-updates.py
<cjwatson> it didn't list any bug closures so the script skipped it
<ScottK> Makes sense.
<cjwatson> if you want to change that behaviour, look for the two places where it says 'if bugnums:', delete those two lines and dedent the line immediately below each
 * ScottK marks it for TODO.
<robbiew> ScottK: if you make the change, I'll be happy to re-run the script and diff between my original ouput
<robbiew> output
<robbiew> then I can update the wiki with anything missed
<ScottK> It's unlikely to be soon enough I'll have time to make it sensible to update that, but we'll see.
<cjwatson> robbiew: it should be easy for you to change that using my instructions abov?
<cjwatson> *above
<robbiew> cjwatson: heh...good point
 * robbiew re-runs "the script" with changes to see what pops out
<robbiew> so there were changes...and I added those to the wiki...but still no clamav :/
#ubuntu-release 2010-08-20
<ogra> robbiew, hmm, your release team agenda looks weird for the arm team, the only bug thats listed under ARM is a bug i never heard about
<ogra> (and one that surely was never listed by the arm team either)
<robbiew> ogra: ack...sorry, it was a Linaro bug...I will remove from the agenda
<ogra> thanks
<ogra> just looked strange :)
<robbiew> slangasek: so apparently jcastro wants a full explanation of why DVD ISO creation is a PITA...maybe we can school him up for the release team :P
<slangasek> excellent! a volunteer!
 * robbiew crafts a reply to his email...to basically say we'd love to show him how it's all done...but there's a PRICE for such knowledge :D
<cyphermox_> I noticed I forgot to enable the new nmcli command-line tool for NetworkManager. Would I need a FF exception for this, or is it fine to do the change since it does not imply a new upstream version, just a new revision?
<robbiew> cyphermox_: hmmm
<robbiew> it's a new feature, even if the same version...so I would think so
<robbiew> cyphermox_: ^
<robbiew> just to have a record of it
<sistpoty|work> cyphermox_: if it's a new feature, go for a FFe to be sure, shouldn't be a big deal then to get it through
<robbiew> sistpoty|work: were you going to take care of pitti's FFes?
<robbiew> I suppose I "could" but as I'm not an official member of the release team...I try not to stir up controversy :)
<cyphermox_> sistpoty|work, robbiew, thanks
<sistpoty|work> robbiew: yes, but only once I'm home, I have a gut feeling wrt. to udev so just want to take a detailed look at the diff
<robbiew> ack
<robbiew> sistpoty|work: thank you sir
<sistpoty|work> yw
 * cjwatson is attempting to sort out a rebase of udev's ubuntu branch so that we don't lose history in the process
<sistpoty|work> cjwatson: of course I also wouldn't mind at all, if you want to take over udev ;)
<cjwatson> oh hell no
<sistpoty|work> heh
<cjwatson> just parachuting in with bzr assistance
<sistpoty|work> ah :)
 * sistpoty|work heads home now, l8er
<sistpoty> hmpf, just why did I volunteer to look at udev... *g* (about 1/3 through the diff)
<nigelb> heh
<sistpoty> ok, udev's FFe approved. and JTFR, if ScottK is going to make me fix regressions since I approved it, I'll kindly point to robbiew :P
<robbiew> heh
<robbiew> sistpoty: thanks...and thaaaanks :/
<sistpoty> robbiew: yw and heh :P
<ScottK> sistpoty: You're at least in the right country to go provide encouragement to pitti to deal with regressions.
<sistpoty> ScottK: still some way to drive, but yes, that's an option *g*
<cjwatson> hopefully pitti will see the message I sent him about unfeasibly clever revision control magic
<cjwatson> er, with added modesty
<sistpoty> haha
<ScottK> FYI (from the release meeting): I asked barry to have a look at python-numpy.  We'll either need to have a bit of a transition or live with pain of divergence from Squeeze.
<ScottK> skat: ^^^
<sistpoty> ScottK: define "a bit"
<ScottK> That's part of what barry's looking at.
 * barry nods
<sistpoty> ah, only thing I recall of -numpy is pain, but not the details
<ScottK> The rdepends list is not small, but Debian has done the transition, so we can see what needs doing based on what they had to do.
<ScottK> They introduced a dh_numpy to ease the pain a bit and I'd like to get it into Maverick if it's reasonable to do it.
<ScottK> At present it's blocking updating shogun to fix an FTBFS (and help with NBS).
<ScottK> Much easier if I can just sync numpy and shogun rather than have to revert the dh_numpy changes out of shogun and then do the equivalent.
<ScottK> I suspect we'll hit more cases of that.
<barry> plus it would fix py27 support <wink>
<ScottK> Yes.  That too.
<lamont> buildds all on manual pending a brief disturbance in the force
<ScottK> Is this the one that comes from sparc and ia64 going away on Maverick?
<wgrant> Or from me breaking amd64 builds again?
<ScottK> FWIW, the best way to keep buildd backlog low is to fail all builds as fast as possible.
<wgrant> Heh.
<ScottK> It may, however, have undesirable side effects.
 * cjwatson gets closer to understanding bug 544139
<ubot4> Launchpad bug 544139 in consolekit (Ubuntu Maverick) (and 3 other projects) "Active VT tracking can fail at startup (affects: 41) (dups: 6) (heat: 193)" [High,Triaged] https://launchpad.net/bugs/544139
<cjwatson> perhaps I should do something else at nearly midnight on a Friday, rather than trying to find my way around gdm patches
<sistpoty> wgrant: could this somehow have the side effect of changing a once published build log? (http://launchpadlibrarian.net/54040909/buildlog_ubuntu-maverick-i386.folks_0.1.14.1-0ubuntu1_FAILEDTOBUILD.txt.gz)
<sistpoty> wgrant: I could swear that was different once I last looked at it, but I might be wrong (and have looked a paste instead)
<sistpoty> *at a*
<wgrant> sistpoty: It only affected amd64 builds.
<wgrant> Failed logs can change, though, if somebody retries the build...
<sistpoty> wgrant: ah, and even have the same link on librarian?
<wgrant> sistpoty: No. A librarian file can never change.
<sistpoty> wgrant: ah, ok, thanks. then I guess I looked at a paste (only viable option left to explain it... of course my brain might also be permanently hurt by the udev FFe *g*)
<wgrant> Or a LOSA is editing files on mizuho just to confuse you ;)
<sistpoty> haha
#ubuntu-release 2010-08-21
<lamont> ScottK: this was me playing around with the buildd network firewall and possibly affecting NTP, which the buildd doesn't deal with very well
<lamont> so manual to make sure nothing goes through the check while the daemon is resyncing
<lamont> wgrant: testing your stuff ?  that's next
<lamont> wgrant: got a favorite build to play with on staging?
<wgrant> lamont: staging works now?
<wgrant> But no, I don't play favourites when building on shitty buildds.
<wgrant> I once chose hello, thinking it would take just a couple of minutes.
<wgrant> It naturally took 2.5 hours.
<wgrant> You probably have a better idea of what's going to build in a reasonable amount of time.
<lamont> heh.  yeah - I can test this with bind9, so I'm just doing that with my prod ppa and some quick footwork
<lamont> dear publisher. hurry up. kthx
<wgrant> Ah, if it's a prod builder that should be fine...
<wgrant> Why do you need a publisher?
<lamont> well... got a ppa with a convenient test package?
<lamont> I uploaded a package, you see
<wgrant> But building and publishing are independent.
<wgrant> (unless the PPA is private)
<lamont> well, ok.  I wanted upload processing then
<wgrant> Ah, right.
<lamont> and test build is building now (berkelium)
 * wgrant watches.
 * wgrant watches buildd-manager fail.
<lamont> I did not expect to ever be thankful that all the other buildds were busy with really long builds
<lamont> ?
<wgrant> Well, it's slow.
<wgrant> So we won't see much log for a while, probably.
<lamont> unpacking chroot
<wgrant> Hm, I guess since everything else is busy, it's being speedy.
<lamont> one of the other fixes in this is to flush stdout better in the early stages
<lamont> fewer builders atm, too
<wgrant> A lot of the problem is buildd-manager latency, though.
<lamont> checking build system type... x86_64-unknown-linux-gnu
<lamont> checking host system type... x86_64-unknown-linux-gnu
<lamont> checking whether make sets $(MAKE)... yes
<lamont> wgrant: dear sir, please to propose your branch for merging, so that I can +1 it.  that is all. kthx.
<wgrant> lamont: Is it easy enough to set it in LP to i386, and get a build dispatched?
<wgrant> Just to check that that still actually works too.
<wgrant> Since that is sorta the whole point of the change :)
<lamont> you're killing me. :-p
 * lamont applies the big hammer again
<lamont> Building i386 build of bind9 1:9.7.1.dfsg.P2-2 in ubuntu lucid RELEASE [lamont/ppa]
<wgrant> Now, let's hope it works.
<lamont> world order restored, I'll let this build finish
<wgrant> Thanks.
<lamont> and not just because I was only totally lucky on the timing that let me see those lines in the output on the amd64 run
<wgrant> Heh.
<lamont> -I./x86_32/include <-- but I'm hopeful
<wgrant> Yeah.
<lamont> wgrant: lp:~lamont/launchpad/lp-buildd-70 rev 11407 is what I plan to deploy on monday
<lamont> just pushed now, with changelog for rev 70
<wgrant> Looks good to me.
<wgrant> i386 build finishing up now.
<wgrant> And it works. Yay.
<wgrant> Thanks.
<lamont> checking build system type... i686-pc-linux-gnu
<lamont> checking host system type... i686-pc-linux-gnu
<lamont> \o/
<lamont> so... got any bzr-builder knowledge?
<wgrant> A little. You want to test that change?
<lamont> not really so much, no.
<lamont> I'll just plan on making them what wrote the change test it with me on monday before the rollout
<wgrant> Ah. Well, it's a pretty binary works-or-not thing that's easy to test.
<wgrant> james_w speculated last night that it might not.
<lamont> he had a patch for me this morning
<lamont> which is also in 70
<lamont> test cases are: (1) does it work on maverick (2) does it still work elsewhere
<wgrant> That can easily be tested now, if you want.
<lamont> I figured I'd let the build queue get smaller , while I have a weekend
<wgrant> Ah, fair point.
<sistpoty> robbiew, skat: are both of you reading the ubuntu-release ml? Just had some (yet entirely uncoordinated) thoughts about growing the release-team, that I tried to formulate in a mail sent there
#ubuntu-release 2010-08-22
<skat> sistpoty,  cool - will follow up on monday.
#ubuntu-release 2011-08-15
<ScottK> slangasek: I'm all for killing unsupportable stuff.  You'll get no argument from me.
<ScottK> Laney: Self approval is explicitly OK for backports.  It's a benefit of being a member.
<ScottK> (you do still need to meet the test criteria)
<tumbleweed> slangasek: don't we also need a multiarch-friendly nspluginwrapper for flash?
<slangasek> tumbleweed: ah; yes, but that part I consider a bugfix :)
<slangasek> I could upload that nowish, I guess
<tumbleweed> good to hear :) I have no intentions of installing ia32-libs again on my machine
<slangasek> actually, I guess I'd rather hold off on tha nspluginwrapper upload until we have multiarch enabled for amd64 users on upgrade to oneiric
<slangasek> tumbleweed: are you inclined to ack that FFe request?
<slangasek> I've spoken with doko; he hasn't started the rebuild test yet, and he says he can wait for them to upload/build before starting it
<slangasek> so if we're going to include bug #826601, now's the time to do it
<ubot4> Launchpad bug 826601 in rtmpdump (Ubuntu) (and 2 other projects) "FFe: multiarch dependencies of libcurl, needed for proper functioning of flashplugin-installer (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/826601
<slangasek> or if that's putting you too much on the spot, I can ask pitti or cjwatson :)
 * doko is waiting to pull the trigger ...
<doko> pitti: please no gnome/gtk uploads before this ^^^ (seb128 didn't yet show up)
<tumbleweed> yeah, holding abck on nspluginwrapper seems sensible. I'm inclined to ACK it, because it's something I'd like to see. I do feel hesitant, because I'm new around here, but I do trust you to sort out any issues resulting from it :)
<pitti> doko: this == libcurl multiach?
<pitti> "arch"
<doko> yes
<pitti> noted
<pitti> slangasek: is there a known fix for php5?
<slangasek> pitti: yes, attack the build system with a rusty spoon
<slangasek> (it's certainly fixable, it just requires hand-hacking for each library that transitions)
<pitti> i. e. hand-hack the -L paths or something like that?
<slangasek> rather, they have custom autoconf .m4 macros to do library detection
<slangasek> so for each dependency that's multiarched, the build system has to be updated
<pitti> eww
<slangasek> but really, that's the easy case
<slangasek> because we know about it... it's the "what else might break" that we don't know :)
<tumbleweed> yeah, at least that's obvious and FTBFS-triggering
<pitti> let's do that then
 * pitti approves above bug
<slangasek> cool, thanks
<pitti> doko: FYI, today is a national holiday for seb128, so he won't get online
<pitti> (actually, for me as well, oops)
<doko> ahh, then I'm safe!
<slangasek> openssl uploaded
<doko> bah, bavaria
<cjwatson> slangasek: I was planning to pull in the openssl098 source, BTW - I just hadn't done so yet because it requires reapplying Ubuntu customisations rather than just being a simple sync
<cjwatson> slangasek: partly because, even if we do manage to fix everything in the archive, libssl seems like the sort of thing people are not unlikely to have local binaries built against
<slangasek> ah, sure
<cjwatson> (and incidentally I'm not planning to multiarchify openssl098 ;-) )
<slangasek> :-)
<slangasek> doko: ok, openldap also uploaded
<slangasek> and I'm off to bed, 'night :)
<tumbleweed> slangasek: it appears we need cyrus-sasl2 too (for libldap)
<ScottK> tumbleweed: I think we need heimdal promoted before we can build that again.
<cjwatson> I thought it already had been
<cjwatson>    heimdal | 1.5~pre2+git20110804-1ubuntu2 |       oneiric | source
<ScottK> Ah.  I missed that.  Thanks.
<ScottK> cjwatson: If you aren't going to have time for a sync run today (of if you already did it), I'd appreciate it if you could go ahead and do Bug 826725.  If you're planning on doing syncs at some point today, no rush.
<ubot4> Launchpad bug 826725 in icecc (Ubuntu) "Sync icecc 0.9.7-2 (universe) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,Confirmed] https://launchpad.net/bugs/826725
<cjwatson> ScottK: in general I'm holding off the sync queue at the moment in order to keep hold of test cases for LP native syncing, but I'll do icecc now
<ScottK> cjwatson: Thanks.
<Laney> cjwatson: if that's the case, then please also do mono (it's from exp so isn't a candidate for native syncing anyway)
<cjwatson> actually it should be surely
<Laney> I thought that only supported one parent (i.e sid)
<cjwatson> oh bloody hell
<Laney> happy to be wrong
<cjwatson> it should be able to sync any gina-imported version
<Laney> perhaps that's just the UI
<cjwatson> oh bloody hell> that was a reaction to https://launchpad.net/debian/+source/mono only showing stable testing unstable, but actually, if you look closely, it has version 2.10.4-2 which is the version in experimental
<cjwatson> so it should be syncable using the API and I'd like to have that as a test case
<Laney> ack
<cjwatson> the API takes source_name, version, from_archive, to_pocket, to_series, include_binaries
<Laney> that's good actually â I thought multiple parents were required for exp syncing
<Laney> :-)
<cjwatson> it's probably strictly more capable than the UI
<robbiew> skaet: ping
<skaet> robbiew, yup?
<robbiew> skaet: do we have a FinalFreeze date for Universe?
<robbiew> or is it the same as in the past
<robbiew> i.e.  a few days before release
<skaet> robbiew,  it probably needs a good discussion,  since unseeded universe is different than seeded.   So Universe is ambiguous.
<robbiew> good point
<skaet> robbiew,  will start a discussion off on ubuntu-release mail list,  and see if there's some other data points that need to be considered too.
<skaet> thanks for raising it,   will see if we can get closure and updates before beta1.
<robbiew> skaet: cool, thx
<skaet> s/updates/updates to the WIKI pages/
<skaet> :)
<cjwatson> "seeded" is ambiguous too - what really matters is whether the package is on an image or not
<robbiew> cjwatson: right...so for packages *not* on an image
<SpamapS> robbiew: like, say, ensemble. ;)
<robbiew> heh
<Daviey> cjwatson: What about just 'supported' seed?
<cjwatson> Daviey: the very definition of supported is that it includes random stuff not on an image
<cjwatson> given that what we mean is "don't get in the way of image builds", we should say that rather than waffling about seeds
<Daviey> cjwatson: Okay.
<mterry> skaet, hello, where do the 11.10 release notes live?  Is that OneiricOcelot/TechnicalOverview?  I have a workitem to make sure there's a blurb for the new backup program
<skaet> mterry,   use the TechnicalOverview for now,  will use that as the basis for the offical release notes.
<mterry> skaet, OK, I'll look at adding a little something then.  Thanks!
<skaet> mterry,  Thanks!
#ubuntu-release 2011-08-17
<slangasek> oh wow, libedit is using dh_movefiles still
<slangasek> so fixing the build failure without multiarching it is seriously non-trivial
<slangasek> anyone object to me biting the bullet and just switching it over, knowing that there'll be ftbfs revdeps (php5 again, maybe others)?
<ScottK> slangasek: I don't object to you doing it, but I think you ought to make a tracking bug for all the affected packages so the work status is documented.
<slangasek> fair enough
<slangasek> currently holding off on syncing libedit from Debian until I can at least understand why the updated libedit causes php5 build to fail while trying to detect libpcre :P
<slangasek> huh.  so improbably, php actually detects libedit just fine w/o modification (once I account for $DEB_HOST_MULTIARCH not having been in my environment, sigh)
 * ogra_ looks for some livecd-rootfs help ... infinity convinced me to roll my boot-img file from live-build instead of doing it in antimony, my installed needs the md5 of the rootfs tarball in the initrd, that results in this code snippet: http://paste.ubuntu.com/668211/
<ogra_> now my installer uses the filename too from the md5sum file ... and indeed during the build process the tarball gets renamed several times
<ogra_> i wonder if anyone has an idea to work around it, i dont want my installer to scan all tarballs on a device
<ogra_> s/installed/installer/
<ogra_> cjwatson, is there some way to guess the final tarball name in advance ?
<cjwatson> sorry, I don't really know what tarball you mean
<cjwatson> not familiar with the arm initramfs stuff
<ogra_> the rootfs ... in trhe ac100 case i create a tarball
<cjwatson> I'd have to trace through the code just like you
<ogra_> the installer is an initrd script unpacking it to the target
<ogra_> hmm, k
<cjwatson> Could somebody process python-ecore through binary NEW, please?  FFe bug 828004
<ubot4> Launchpad bug 828004 in python-evas (Ubuntu) (and 4 other projects) "FFe: Upgrade Python EFL bindings to 0.7.3 (affects: 1) (heat: 8)" [Wishlist,Fix released] https://launchpad.net/bugs/828004
<slangasek> jjohansen: done
<slangasek> eh
<slangasek> cjwatson: done
<cjwatson> great, thanks
<cjwatson> now I just need to fix the python-elementary build failure and that NBS stack is GONE
<slangasek> woot
<Laney> is anyone looking at the libav nbs?
<micahg> Laney: fabrice_sp was working on it, but that seems to have stalled
 * Laney pings siretart
<micahg> slangasek: would a transition tracker instance for ia32-libs help so we know what we're up against?
<slangasek> micahg: I'm doubtful that it would... there are really only a handful of packages left in the ubuntu + partner archives that depend on it, and each has to be inspected to figure out what libraries it uses
<micahg> slangasek: ah, only ~45 binaries and ~20 sources
<slangasek> hmm?
<slangasek> that shouldn't be the count of packages depending on ia32-libs
<micahg> slangasek: http://paste.ubuntu.com/668542/
<slangasek> oh, lib32gcc1 is a false positive
<slangasek> ia32-libs only owns that binary package on ia64
<slangasek> ...which we no longer build for
<micahg> ah, ok
<slangasek> also, this list is somewhat incomplete because it doesn't encompass partner :)
 * micahg should fix that later...
<slangasek> micahg: so to ensure flashplugin pulls in nspluginwrapper, I think the right solution is to make nspluginwrapper M-A: foreign and make flashplugin-installer depend on it unconditionally (i.e., on i386)
<slangasek> this should cause apt to install nspluginwrapper from the "preferred" arch (amd64), plus the i386 nspluginviewer and flashplugin
<micahg> slangasek: ok, do we gain anything over the current implementation though?  also, i386 doesn't need it, so we're forcing an unneeded dependency
<slangasek> it ensures we actually get nspluginwrapper installed where we *do* need it, since currently nothing else ensures that on amd64
<slangasek> (pitti already ran into this problem yesterday when testing)
<micahg> slangasek: flashplugin-installer:amd64 should :)
<slangasek> I thought you wanted to get rid of that package?
<slangasek> also, even on i386 it's useful to have flashplugin in a container process... which firefox handles for us, but I think other browsers don't?
<micahg> slangasek: the only reason to get rid of it is if we can get rid of the installer entirely
<micahg> which we can't do at present
<slangasek> if we moved the nspluginwrapper dep to the adobe-flashplugin package in partner, couldn't we then?
<micahg> but I like the i386 in a container argument :)
<micahg> slangasek: yes, but we can't do that :)
<slangasek> hmm, can't we?
<slangasek> not us directly, but
<slangasek> so an amd64 flashplugin-installer package would have to have some other i386-only package to attach the library dependencies to
<slangasek> could be done, but just using nspluginwrapper everywhere might be simpler
#ubuntu-release 2011-08-18
 * lamont plans to freshen the oneiric chroot tarballs later today (in say an hour) unless someone screams at him.
<cjwatson> sounds good to me
<lamont> cjwatson: good. done.
<Laney> pitti: how do the pygobject regressions manifest? build or runtime failures?
<pitti> Laney: erm, runtime -- python isn't built, unless there are test suite runs
<Laney> ah, ok --- thought there might be a static pass.
<Laney> wait, what? I was thinking of gir. Sorry.
<ScottK> Sigh. Options:
<ScottK> 1.  Release Oneiric with kdelibs (KDE3) that's unbuildable.
<ScottK> 2.  Port kdelibs to work both with openssl1.0 and without avahi.
<ScottK> 3.  Post FF removal of all KDE3 stuff (Debian has already done this).
<ScottK> So we get no help from Debian on #1 or #2.
<ScottK> Thoughts?
<stgraber> do we still have a lot of kde3 stuff around?
<ScottK> It's all in universe.
<ScottK> Actually we may not.
<ScottK> It looks like most of it got auto cleaned up from when Debian did removals.
 * ScottK votes removal then.
<stgraber> rdepends gives me around 5 software actually using the old kdelibs, so option 3 would seem reasonable then
<slangasek> +1
#ubuntu-release 2011-08-19
<ScottL> ubuntu studio has been having some trouble getting an image built
<ScottL> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntustudio/oneiric/daily-20110818.log
<ScottL> can someone help me resolve this please?
<ScottK> slangasek: It'd make me very happy if you could do the removals in Bug #794513.
<ScottK> Turns out option 3 had already been asked for.
<ScottK> slangasek: I think between what's in that bug, what's already NBS, and Bug #829149 it'll make a clean sweep of KDE3.
<slangasek> ScottK: done
<ScottK> slangasek: Thanks.
<scott-work> cjwatson:  i was told to mention to you about a problem with the ubuntu studio image build which i believe is affecting other derivatives
<scott-work> cjwatson:  this is a typical problem: W: Failed to fetch file:/srv/cdimage.ubuntu.com/ftp-universe/dists/oneiric/main/binary-amd64/Packages.bz2  Hash Sum mismatch
<cjwatson> I can't do anything about it except retry
<scott-work> cjwatson: http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntustudio/oneiric/daily-20110819.log
<cjwatson> it's due to the archive sync being too slow
<scott-work> ah, okay, that's surprising because it has been happening for at least three days :(
<cjwatson> it's basically random
<cjwatson> and it's not remotely a new issue
<scott-work> okay, thank you for the infomration :)
<cjwatson> I've kicked a retry; who knows, it might work
<cjwatson> whenever we get the new hardware it should address this, I think
<scott-work> thank you again for your time :)
<cjwatson> scott-work: seems to have worked that time
<scott-work> cjwatson: thank you every so much!  :)
 * lamont stuffs all the buildds on manual for a bit
<lamont> and the world is coming back
 * highvoltage hides
<lamont> the ppa builders are either back on line or coming back online, and the chrootwait thing is fixed, dead and gone.
<NCommander> lamont: thanks:-)
<ogra_> hrm
<NCommander> ogra_: can you tell skaet I'm going to be a bit late for the release meeting?
<lamont> ogra_: hrm, you say?
<NCommander> (I shouldbe back in time, but just in case)
 * ogra_ fights with PREINSTALLED_IMAGE_FILESYSTEM
<ogra_> i somehow need to overrice the hardcoded default thats set in debian-cd based on a subarch search ... but i dont want to add additional code to debian-cd
<ogra_> overriding from cdimage code doesnt work since debian-cd always processes CONF.sh, which resets that var to default
<ScottK> tumbleweed: I do think we should generally approve things like dh_python2 changes as long as they've had a second set of eyes to verify their correctness.
<tumbleweed> ScottK: so you don't require any justification beyond "it looks ok"? I've always regarded FF as the point where I should justify my changes
<ScottK> tumbleweed: It depends on the change.  For dh_python2 we've got an overall goal to switch so there's an inherent reason.
<ScottK> IMO, YMMV, etc.
<tumbleweed> ok in that case I can ack the one I marked as incomplete, although I would have preferred to see a build log
<ScottK> I find the debc output it a lot more useful for dh_python2 changes.
<tumbleweed> I mean a build log including debc :)
<ScottK> Right.
<tumbleweed> I want to see the Depends, and the contents, and I'd generally like to see what dh_python2 said when it ran
<ScottK> Yep.
<ScottK> You might just build it yourself, for fun.
<tumbleweed> might as well, it's not like I don't have the time
 * ScottK wonders why people think "I'm not paid to do this work" is part of a rationale for an FFe?
<nigelb> srsly? :|
 * slangasek blinks
<ScottK> 829709
<elmo> wow, I can't believe I'm going to be defending kirkland and/or byobu, but...
<elmo> ScottK: he didn't make it part of the rationale, it's pretty clearly in the 'Additional Info' section, not the 'Rationale' section
<elmo> ScottK: not for nothing, but assuming a bit of good faith would, IMO, go a long way.  when I read the bug, I don't think kirkland's put that in there in the expectation that it's going to change the outcome, rather genuinely as non-actionable/influencing background info
<highvolt1ge> byoby and kirkland are both awesome and you shouldn't have to defend defending them!
 * tumbleweed reads it mostly as an "I've been busy" rather than "I'm not paid"
<nigelb> Sort of equal to "dayjob has been kicking me in the gut?"
<nigelb> :)
<tumbleweed> well, a sorry I couldn't get to it before FF
<tumbleweed> yeah
<slangasek> does anyone know what has changed in the past bit (last year or so?) that changed who's able to see private bug reports against packages?
<slangasek> we've just figured out mvo didn't see private bug reports filed against update-manager, and he ought to (also, apport shouldn't have filed the bugs as private, but that's a different bug)
<slangasek> and I've been seeing similar behavior on pam and grub bugs, where they're not visible to me until the security team unchecks the 'private' flag
<slangasek> now that I know that it's not me, it sounds like a significant regression
<slangasek> s/not me/not just me/
<slangasek> kees, jdstrand, micahg, mdeslaur: ^^ maybe you guys have some insight into what may have changed in LP on this score?
<nigelb> slangasek: *maybe* security bugs are only visible to security team?
<jdstrand> sorry, I don't
 * nigelb checks code
<kirkland> slangasek: funny enough, aliguori tackled me today at LinuxCon saying he hasn't been getting private bug notices against the qemu upstream project in Launchpad
<mdeslaur> slangasek: security bugs are only visible to the security team
<jdstrand> I think if it is both private and security, only we see it
<kirkland> slangasek: he said he was "embarassed" when a guy who filed a number of CVEs asked him why he hadn't taken any action in several weeks :-o
<jdstrand> but I don't know of anything that has changed recently that would alter behavior
<kees> slangasek: that's certainly a regression -- the package owner should be able to see it, I thought
<kees> slangasek: are those bugs marked "security"? that's the only time the package subscribers can't see it, I thought.
<mdeslaur> kees: I don't remember it ever being any different
<kees> mdeslaur: right, _security_ bugs. but "just" private...
<slangasek> mdeslaur: a) my update-manager bugs aren't tagged security, b) I would expect trusted package owners to still be able to see them, like kees says
<kees> the problem is the order of operations.
<slangasek> and see above for the upstream case kirkland mentions
<kees> you check 'security' at the start, no one is subscribed but us, the reporter unchecks 'security', and then it should be visible to the package owners. wait, I've just talked myself out of this.
<mdeslaur> slangasek: so, basically, nobody can see it except for the reporter? what good is that? :)
<slangasek> I guess this should be taken to #launchpad then
<kees> there is no such thing as "package owner"
<slangasek> mdeslaur: no kidding!
<slangasek> kees: well, I would expect package bug subscribers who are part of some "trusted" group wrt the bug task, to be able to see them
<kees> so, right, mdeslaur is right, after running through this a few times in my mind.
<kees> slangasek: that would be good, but where is that defined in LP? I don't think such a thing exists.
<slangasek> kees: well, it used to be defined for Ubuntu in order for people to poke at backtraces when the retracer has failed
<slangasek> in fact, the retracer itself needs to get access to private reports
<mdeslaur> private bugs are supposed to be visible to whoever signed up to get bugmail for a particular package, and the reporter can remove people
<kees> mdeslaur: but anyone can subscribe...
<mdeslaur> kees: yes, but if you subscribe, you aren't added to the bugs which are already private
<mdeslaur> anyway, #launchpad probably knows more
<kees> slangasek: so, it must be related to the project contacts or something
<kees> mdeslaur: right
<mdeslaur> huh, actually, the only person subscribed to a private bug I've opened earlier today is apport
<mdeslaur> and if I look at an _old_ private bug I had opened last year, a whole slew of people are subscribed to it
<jdstrand> I think it's wrong for someone to subscribe to get bugmail and then automatically get all security bugs
<jdstrand> if we uncheck the security box, then yes. otherwise, we bring in who is needed
<slangasek> right, subscribing to bugmail shouldn't automatically get you access to security bugs
<slangasek> but if you're the owner of the project (cf. qemu-kvm above), you certainly should!
<jdstrand> yes!
<jdstrand> by all means :)
<jdstrand> I may be lacking context, but that's ok
<mdeslaur> no, owners of projects should _not_ be getting security bugs
<slangasek> er, what
<cjwatson> oh god.  if I touch a package called "php5-ffmpeg", will I go to hell?
<slangasek> the Ubuntu security team shouldn't be setting the policy for security bugs filed against upstream
<jdstrand> maybe we are talking about different things
<jdstrand> if we get a bug against qemu in Ubuntu, then only the security team should get the bug initially
<slangasek> we're talking about an *upstream* security report - the registrant of the qemu project in launchpad should certainly be able to see bugs filed against qemu in launchpad, security or not
<slangasek> cjwatson: that depends on how you touch it :P
<jdstrand> if upstream qemu gets a bug, they should get the bug
<mdeslaur> slangasek: what's an upstream security report?
<jdstrand> cjwatson: I think the safe answer is 'yes'
<slangasek> mdeslaur: there are projects other than Ubuntu that use launchpad
<mdeslaur> ok, if I type "ubuntu-bug qemu" and on the webpage check "security", I expect only the security team to see it
<slangasek> that's not an upstream bug report
<jdstrand> mdeslaur: that's correct
<slangasek> an upstream bug report is one filed against the qemu *project* in launchpad
<jdstrand> but if you go to https://bugs.launchpad.net/apparmor/+filebug, that's an upstream bug
<kirkland> http://bugs.launchpad.net/qemu -> Report a bug
<mdeslaur> right, ok, we're all in agreement
<mdeslaur> jdstrand: do we even see those? I didn't think so
<jdstrand> mdeslaur: no, and we should not
<slangasek> or if someone uses 'also affects project' -> qemu on a security bug filed against Ubuntu, the qemu upstream bug contact should be able to see it
<kirkland> you don't, no
<mdeslaur> slangasek: yes, agreed
<jdstrand> https://bugs.launchpad.net/ubuntu/+source/foo/+filebug (we see). https://bugs.launchpad.net/foo/+filebug (wee should not)
<kirkland> but aliguori was complaining to me just today that he didn't think he was receiving the bug mail for which he's marked as the security contact
<jdstrand> s/wee/we/
<jdstrand> slangasek: I'm not as enthusiastic about 'also affects project', but I think I don't disagree
<slangasek> jdstrand: well, the set of people who are in a position to *add* such a task to a bug are finite; you don't have to do it, but if you do those are the sensible semantics :)
<kees> cjwatson: elmo made me audit php5-ffmpeg ! it's not so bad, actually.
<elmo> hey, hang on, I rick trolled you into auditing it, I didn't expect you to fall for it!
<mdeslaur> rofl
<jdstrand> hehe
 * cjwatson wonders what to do about mplayer - attempt to bodge it into libav 0.7 support in ways different from what was done upstream, or pull in a new snapshot from Debian experimental
<cjwatson> neither is massively appealing
<micahg> slangasek: sinzui has been working on a disclosure story for LP, there was a thread on launchpad-devel about it
<slangasek> micahg: oh; does the thread touch on this issue we're hitting?
<micahg> slangasek: yes, who can see what was a large part of the issue discussed
 * micahg looks for the thread
<micahg> slangasek: https://lists.launchpad.net/launchpad-dev/msg07445.html
<slangasek> micahg: thanks for the link
<micahg> slangasek: sorry, I was out before
#ubuntu-release 2011-08-20
<Laney> will native syncs land in queues as for normal uploads?
<cjwatson> yes
<cjwatson> we made sure of that part
<Laney> grand
<Laney> and just saw the branch got merged, double grand
<cjwatson> which one?
<cjwatson> oh, ubuntu-dev-tools?
<Laney> yep
<cjwatson> awesome, I hadn't got the mail yet
<Laney> ...which I just subscribed to a bug for some reason (~ubuntu-dev-tools)
<Laney> stupid brain
<Laney> cjwatson: have you seen http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libav07;users=jmm@debian.org ?
<Laney> just saw it come by in #-release
<cjwatson> no, that's handy, I should start usertagging my bugs then
<cjwatson> assuming Moritz is OK with that?
<cjwatson> I've followed up to a couple of his bugs
<cjwatson> (with patches)
<cjwatson> tumbleweed: hm, you're the last uploader of ptlib; AFAICS in order to get opal building, we need to bump ptlib to a new upstream version (e.g. merge from Debian experimental)
<doko_> cjwatson, would a sync of rootskel from unstable be safe to fix the ftbfs?
<tumbleweed> cjwatson: sure I can do that
<charlie-tca> seems like the server is having problems building the ubuntustudio images. Can some one kick the thing and try to get them a respin?
<charlie-tca> log shows a lot of :
<charlie-tca> W: Failed to fetch file:/srv/cdimage.ubuntu.com/ftp-universe/dists/oneiric/main/binary-amd64/Packages.bz2  Hash Sum mismatch
<charlie-tca> E: Some index files failed to download, they have been ignored, or old ones used instead.
<charlie-tca> make[1]: *** [/srv/cdimage.ubuntu.com/scratch/ubuntustudio/daily/apt/oneiric-amd64/status] Error 100
<tumbleweed> cjwatson: the merge is trivial (configure option), but isn't enough to get opal building
<tumbleweed> opal-3.8.4~dfsg/src/opal/ivr.cxx:191:40: error: 'class OpalVXMLSession' has no member named 'GetSessionVars'
<tumbleweed> and the new opal requires a new spandsp, I don't know how far down this rabbit hole I want to go :)
<tumbleweed> aha, with the new spandsp, opal 3.10.1 builds a little further, and hits a libav api change
#ubuntu-release 2011-08-21
<Laney> https://launchpad.net/ubuntu/oneiric/+queue
 * Laney likes the shiny
<nigelb> ooh. neat
<Laney> does launchpad email for normal uploads which end up in NEW?
<cjwatson> doko: syncing rootskel would be bad and wouldn't help anyway - it's a klibc problem I think.  I was going to fix it on Monday
<cjwatson> Laney: yes
<ScottK> cjwatson: For NBS, kdenlive on armel (for mlt3) will been a binary removal.  It's no longer buildable on armel (direct GL calls that we don't support with Qt anymore).
<Laney> cjwatson: ok, couldn't find any. didn't get any mail for that sync: will bug it when i get home
<tumbleweed> wrote up my concerns on +localpackagediffs in bug 830584
<ScottK> tumbleweed: Sounds reasonable.
#ubuntu-release 2012-08-13
<micahg> is an AA is around, libav-extra could use a binary NEW review in quantal (breaking upgrades)
<stgraber> ScottK or any other SRU team member who's around: I just marked bug 1032256 verification-failed and the above upload should fix the problem, would appreciate if someone could quickly review and let it in
<ubot2> Launchpad bug 1032256 in edubuntu-artwork "Incorrect menu items appear in Edubuntu due to incorrect path in debian/edubuntu-artwork.install" [Medium,In progress] https://launchpad.net/bugs/1032256
<stgraber> diff should be an obvious one liner (/me checks the diff in the queue)
<stgraber> yep, diff is indeed a one liner ;)
<stgraber> slangasek: hmm, do you know what's supposed to happen with the firefox-locale-XYZ packages in -proposed? they are built from the same sources as the langpacks, but they haven't been copied to -updates and weren't mentioned on that wiki page dpm mentioned
<stgraber> it also looks like firefox-locale-km is in universe instead of main
<infinity> I can fix the latter issue.
<infinity> stgraber: Override for firefox-locale-km fixed, and edubuntu-artwork accepted.
<stgraber> infinity: thanks
<infinity> micahg: Accepted.
<infinity> Hrm, I should refresh the quantal chroots tonight, they're getting a bit old.
<stgraber> cjwatson: yay! that new getAllPermissions API just landed and it just took a couple of minutes to get the data I wanted. thanks!
<stgraber> cjwatson: http://people.canonical.com/~stgraber/ppu/ppu-report is the result for the data I wanted (people with PPU)
<micahg> stgraber: infinity: the firefox-locale-* were from the Firefox SRU, not the langpack update
<micahg> infinity: thanks for the accept
<slangasek> stgraber: no, don't know anything about firefox-locale-* :/
<micahg> slangasek: see my statement above :)
<didrocks> the unity stack should be good to copy to the release pocket (I can do it myself if needed): bamf, dee, libunity, unity, nux, unity-lens-applications, unity-lens-files, unity-lens-music
<TheDrums> Much chance for a mosh backport?
<micahg> TheDrums: see requestbackport script in ubuntu-dev-tools (followup in #ubuntu-motu if need be)
<TheDrums> Suppose I was more wondering if it was already on the "agenda", though thanks.
<micahg> TheDrums: happy to discuss in -motu
<cjwatson> stgraber: great, you're welcome
<xnox> I'd like to nominate bug 699802 for precise & quantal.
<ubot2> Launchpad bug 699802 in grub2 "error:: no video mode activated" [Medium,Confirmed] https://launchpad.net/bugs/699802
<xnox> or is it too late for precise, especially 12.04.1?
<seb128> xnox, hard freeze is thursday for 12.04.1
<xnox> seb128: thanks.
<seb128> so you still have a slot if you convince people the fix should really make it
<xnox> cjwatson: what do you think about this comment https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/699802/comments/24
<ubot2> Ubuntu bug 699802 in grub2 "error:: no video mode activated" [Medium,Confirmed]
<xnox> i hit this bug myself with crypt+lvm in VM with ubiquity testing
<cjwatson> The problem about copying those is that they're fairly large
<xnox> =(
<cjwatson> But I suppose it's acceptable in the absence of a new enough GRUB to have LUKS support
<cjwatson> So go ahead if you want to get that sorted out and tested
<xnox> ok
<cjwatson> I agree it's a fairly unfortunate bug in that it confuses people
<didrocks> cjwatson: hey, did you see above my reminder about the unity stack copy? (I can do it if needed)
<cjwatson> I'll do it now, thanks
<didrocks> thanks :)
<cjwatson> done
<didrocks> thanks colin!
 * cjwatson fixes the bogus uninstallables on server images, hopefully for good this time
<mvo_> could someone from the sru team review the glib-networking sru in precise-proposed? it will unblock all users who need "3dsecure" when purchasing applications via software-center
<stgraber> mvo_: is that critical for 12.04.1? if not, it's going to wait there until we enter final freeze on thursday
<mvo_> ok stgraber, thanks for the update
<stgraber> micahg: oops, my bad (wrt firefox-locale-), not sure where I saw langpack as the source... checking again it's quite clearly coming from firefox :)
<stgraber>  I changed that early PPU-specific script into a more generic one reporting all team and individual upload rights at: http://people.canonical.com/~stgraber/permissions
<stgraber> I guess that output may be interesting for people outside of the DMB
<stgraber> slangasek: so, jibel confirmed that the SRUs I pushed last week to fix the upgrade path are fine and don't show any regression on the automated testing. Should we have them moved to -updates now?
<jibel> stgraber, this time auto upgrade *really* upgrades with proposed enabled. I retested the cdrom/no-network upgrade this morning manually
<warp10> join #d-a-t
<warp10> ops... missed '/', sorry
<infinity> cjwatson: Looking at stgraber's PPU permissions dump, why does -core-dev have explicit permissions on a bunch of packagesets, when it already has implicit permissions via components?
<Laney> the DMB is going to get that fixed
<infinity> Laney: Ahh, I assumed it was perhaps something technical, rather than DMBish.
<infinity> (Like, perhaps implicit permissions showing in the dump due to group memberships?)
<cjwatson> err, isn't it just because ... what infinity said
<Laney> stgraber told me that it's only showing direct permissions
<cjwatson> oh, maybe that was part of my initial ->packageset conversion
<cjwatson> ubuntu-core-dev might be the owner of those sets
<Laney> and it's only the first-ish packagesets
<Laney> so I suppose it's just something wot woz dun back at the start
<cjwatson> that does look a bit odd
<infinity> Not that there's anything "wrong" with it, per se, it just makes it a bit harder to parse.
<cjwatson> core, desktop-core, and ubuntu-server don't have any other permissions
<cjwatson> (IIRC)
<cjwatson> but the others have no excuse, and even in those cases, there's no reason packagesets have to have permissions attached as such
<Laney> server is ubuntu-server-dev
<infinity> cjwatson: Server has ~ubuntu-server-dev
<infinity> Laney: Jinx.
<cjwatson> ah yes
 * cjwatson amends coe
<cjwatson> *code
 * Laney nominates infinity to the DMB due to clearly demonstrated interest and knowledge
<infinity> Laney: Half of that assertion is true.
<Laney> Do mobile/unr/netbook have any continuing relevance?
<cjwatson> Doubt it.
<infinity> cjwatson: It also misses the partner relationship.  Is that handed at a sketchy spot earlier in the soyuz upload pipeline, rather than via PPUish/ArchiveReorg machinery?
<infinity> handled*
<micahg> isn't partner just another pocket?
<infinity> micahg: Sort of.
<infinity> micahg: And pocket rights are represented in this dump (see backports and security).
<micahg> infinity: less visible pocket :)
<infinity> Partner is a bit weirder, in that it's published to a parallel archive, but I'm not sure how much of that is a publisher construct, and how much of that is (perhaps mistakenly) represented in structure elsewhere.
<cjwatson> Partner is more like a component than a pocket.
<cjwatson> Which ends up in a different archive, yes.
<cjwatson> Partner upload permissions are just component upload permissions.
<cjwatson> edit-acl -c partner query
<infinity> Right, but not represented in this dump, for some reason.
<cjwatson> I don't think stgraber included component permissions.
<infinity> === motu ===
<infinity>  - Archive Upload Rights: component 'multiverse'
<infinity>  - Archive Upload Rights: component 'universe'
<cjwatson> Oh, he did.  Odd then.
<cjwatson> Ah, I know
<infinity> Maybe he just only queried the 4 components.
<cjwatson> I bet those permissions are on a different Archive
<cjwatson> They would kind of have to be
<infinity> Or that, yeah.
<cjwatson> And stgraber's query was Archive.getAllPermissions()
<infinity> Anyhow, not a big deal.
<cjwatson> So he just needs to run it on all of lp.distributions["ubuntu"].archives, rather than just [0]
<micahg> well, partner is irrelevant for the DMB as well
<cjwatson> stgraber: BTW your login_with in that script is wrong :)
<infinity> micahg: Indeed, entirely irrlevant, was just a curiosity. ;)
<slangasek> stgraber: https://jenkins.qa.ubuntu.com/view/Precise/view/Upgrade%20Testing%20Dashboard/ shows an awful lot of yellow; have these been checked over and confirmed to not be regressions?
<slangasek> stgraber: as long as that's done, I'm happy to consider those packages v-done and copy them over, yes
<stgraber> infinity, cjwatson: I was only looking at .archives[0] not .archives[1], I'll change that so partner shows up too
<stgraber> cjwatson: oh, indeed, bad copy/paste, will fix the login_with ;)
<infinity> stgraber: I'm not sure it's important that partner shows up (as pointed out, it's irrlevant to most people), I was curious why it wasn't there, though.
<stgraber> slangasek: the yellow is because of conffiles left around and other unrelated failures, jibel says that the upgrade at least works
<stgraber> infinity: well, checking partner will probably make the cron 5s slower and it's quite easy to change, so might as well ;) the initial script was specifically written to spot inconsistency with PPU in the primary archive, but it evolved into a generic dump-everything script without that bit of the code being changed
<xnox> Anyone has a spare intel matrix raid controller?
<stgraber> no spare ones, sorry
<xnox> stgraber: can you test that at least an existing array can be assembled / activated using precise-proposed mdadm package without dmraid package present
<slangasek> xnox: is that the correct test?
<slangasek> I thought the point was we were *not* using mdadm for imsm
<slangasek> because dmraid has already claimed it and if we're going to change that we need a migration plan
<xnox> slangasek: true, but I still want to find out whether or not we can use mdadm for imsm.
<stgraber> xnox: I'd have to check if I have another machine with one, the one I know has one is my server here and has all 4 ports used with standalone non-RAID drives. (I have an HP smartarray P212 for the various RAID arrays)
<slangasek> xnox: you mean whether it can be used by hand?  (since the udev rules won't do it)
<xnox> slangasek: and then see how to migrate from dmraid to mdadm. Yes, by hand.
<slangasek> ok
<xnox> slangasek: from https://bugs.launchpad.net/ubuntu/precise/+source/mdadm , the bug 1002357 is the last one not marked as verification-done. Do you think it's enough to be marked as done?
<ubot2> Launchpad bug 1002357 in mdadm "sort out udev rules madness (3 editions installed into 4 files)" [Medium,Fix committed] https://launchpad.net/bugs/1002357
<slangasek> xnox: yep, I'm happy with that
<xnox> slangasek: in that case it's all green \0/
<slangasek> huzzah
<slangasek> jibel, stgraber: the lucid main amd64 upgrade test has been consistently failing for the past several days, which means we aren't actually getting any confirmation of a successful upgrade to -proposed for this test case: https://jenkins.qa.ubuntu.com/view/Precise/view/Upgrade%20Testing%20Dashboard/job/precise-upgrade-lucid-main/ARCH=amd64,LTS=lts,PROFILE=main-all,label=upgrade-test/
<slangasek> jibel: is this on your radar?  fixable soon-ish?
<stgraber> jibel: oh yeah, I think jibel mentioned the lack of the -d parameter to do-release-upgrade
<stgraber> slangasek: ^
<stgraber> slangasek: jibel's comment regarding the testing of these fixes is https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1029531/comments/19 (not sure whether you saw it already)
<ubot2> Ubuntu bug 1029531 in update-manager "cdromupgrade from Lucid to Precise failed with unmet dependencies without network connection" [Critical,Fix committed]
<skaet> slangasek, stgraber - are we still good to switch from -proposed to -updates for the precise dailies today?
<stgraber> skaet: we should be once we do a bunch of copies for the upgrade changes. I'm also working on doing verification testing for a bunch more stuff in the queue
<stgraber> skaet: I'll probably come up with a list of known-safe things in the queue that we may want to copy before the 7 days limit
<slangasek> stgraber, skaet: yes, once the CD upgrade fixes are published to -updates I think it's fine to switch
<slangasek> there's also bug #1034668, but that seems to have not involved a CD upgrade
<ubot2> Launchpad bug 1034668 in indicator-appmenu "Upgrade from Lucid to Precise does not install packages for Global Menu: indicator-appmenu" [High,Triaged] https://launchpad.net/bugs/1034668
<skaet> stgraber, slangasek,  ok,  thanks.
<skaet> re:  103466 - ack.
<jibel> slangasek, re precise-upgrade-lucid-main/ARCH=amd64. It was a problem with our proxy in the lab. I fixed it this morning and restarted the job 9h 6 minutes ago, and still running (it usually runs in 8h or so)
<jibel> it seems to be stuck on "Processing triggers for postgresql-common"
<slangasek> jibel: ah, ok.  is it actually stuck?
<jibel> slangasek, it must have heard your incantation, it just finished :)
<jibel> dist-upgrade.py returned: 0
<jibel> slangasek, https://jenkins.qa.ubuntu.com/view/Precise/view/Upgrade%20Testing%20Dashboard/job/precise-upgrade-lucid-main/203/
<slangasek> jibel: huzzah, thanks
<stgraber> please reject network-manager from the unapproved queue
<stgraber> I just found and tracked down a pretty nasty bug that cyphermox is going to fix before we attempt to SRU again
<stgraber> (dnsmasq not being allowed to reply to NM, leading to NM reaching the maximum number of established dbus connection after a day or so, freezing the system bus)
<infinity> stgraber: Done.
<infinity> stgraber: dnsmasq is fine to leave there?
<stgraber> yep
<cyphermox> infinity : as far as I'm concerned you might as well reject that one too
<cyphermox> we'll put in another patch to allow NM to use it's own custom bus name
<infinity> I feel like I'm getting mixed messages. ;)
<stgraber> cyphermox: oh right, because you want to get the new dbus parameter stuff in there, right
<stgraber> yeah, reject both then :)
<cyphermox> upstream is finishing up on testing that patch, and it will be in quantal prior to FF... or at least, that's the plan
<stgraber> slangasek: hmm, looks like the fix for bug 1017822 doesn't work here... trying to figure out exactly why though. Would still be tempted to have it copied regardless, assuming it's no worse than it used to (as the other bugfix is the one we want for 12.04.1)
<ubot2> Launchpad bug 1017822 in fglrx-installer-updates "[quantal] fglrx fails to build on i386" [High,Fix committed] https://launchpad.net/bugs/1017822
<stgraber> hmm ... or my setup was just bad ... just cleaned up the system and retried and it now works...
<stgraber> right, re-tested both packages, seems to be building fine. Marked verification-done, so fglrx and fglrx-updates should be good to go.
<slangasek> ok then :)
<stgraber> with my Edubuntu hat on, I'd be happy to see edubuntu-artwork copied to -updates without waiting an extra 7 days. The original SRU was a bit broken and I fixed it and tested yesterday. The fix was a one word fix in a .install file.
<infinity> stgraber: Yeah, I'm okay with fast-tracking that one.
<slangasek> stgraber: did we conclude that the OOo SRU was or wasn't needed?
<stgraber> slangasek: I didn't have to seed it in the end, so it might be helping in some cases but none of those we identified. In short, I'd go with not needed.
<slangasek> ok, I'll drop it from -proposed again
<slangasek> stgraber: bug #1029021 got a regression-test with the lucid->precise upgrade case?
<ubot2> Launchpad bug 1029021 in apt-clone "python implementation of apt-clone should remove usernames and passwords" [High,Fix committed] https://launchpad.net/bugs/1029021
<slangasek> (which was what triggered a re-upload last week)
<infinity> stgraber: edubuntu-artwork released.
<stgraber> infinity: thanks
<stgraber> slangasek: right, we know that at least the export function works as expected (didn't crash)
<slangasek> ok
<slangasek> releasing the SRUs for update-manager, apt-clone, launchpad-integration, nspr, update-notifier
 * stgraber pokes queuebot 
 * skaet notes that...
<infinity> stgraber: queubot won't tell you about sru-releasing.
<stgraber> infinity: oh right, because you can do it in one go now
<infinity> stgraber: Yeah, it bypasses the queue and just DTRT now.
<stgraber> I got used to seeing the package land in -updates Unapproved
<slangasek> oh neat, I got an oops-by-mail for one of the package copies
<ubot2> https://lp-oops.canonical.com/oops.py/?oopsid=by
<infinity> ubot2: That was some VERY clever parsing, bravo.
<ubot2> infinity: Error: I am only a bot, please don't think I'm intelligent :)
<slangasek> heh
<stgraber> skaet: will switch to -updates + kick respins at 21:00 UTC. Will see if I can do some more verification testing before that
<skaet> stgraber,  sounds good.   :)   Thanks.
<stgraber> tjaalton: ping
<tjaalton> stgraber: pong
<stgraber> tjaalton: hey, do you have someone you can poke to get bug 1031784 tested?
<ubot2> Launchpad bug 1031784 in mesa "Artifacts on screen with ivy bridge" [Critical,In progress] https://launchpad.net/bugs/1031784
<stgraber> at least the xserver-xorg-video-intel part of it?
<tjaalton> it needs both mesa and -intel
<stgraber> it sounds like something that we really should have on the 12.04.1 release media as ivy bridge is getting quite common these days
<tjaalton> don't think just -intel would help much
<stgraber> hmm, ok...
<tjaalton> it's only GT1 chips, so the slower ones
<tjaalton> but still..
<stgraber> do you have any way of getting the current mesa in -proposed tested?
<stgraber> according to the pending-sru report, the one currently in -proposed didn't get much testing
<stgraber> once that one is out, the ivy bridge fix seems trivial and should be easy to test and get to -updates
<tjaalton> bryce ran some piglit tests but they showed some regressions, which looked surprising. I promised to have another look at testing with my hw, but didn't get to it today
<tjaalton> there's also 8.0.4 available, I'd also test that to see if it helps with the regressions
<tjaalton> and 8.0.5 scheduled later this month
<tjaalton> one option would be to push 8.0.3.really.8.0.2-0ubuntu0.1 with the ivb patch
<stgraber> as ugly as that version number is, I think I'd prefer that for 12.04.1
<tjaalton> and postpone the point release(s) until after .1
<stgraber> the ivy bridge fix is really simple, clean and easy to test and a whole lot less scary than getting a new upstream mesa
<tjaalton> yeah we could hopefully get 8.0.5 soon enough that it wouldn't matter :)
<tjaalton> and at least test it properly with some more time
<infinity> tjaalton: If we drop the current proposed one, you shouldn't need the icky version number... I think.
<tjaalton> no?
<tjaalton> I think it's needed, since it's in -proposed and not the queue
<infinity> You can't *reuse* the current version, but I suspect the machinery won't prevent us from going backward if there's no published version with the higher number.
<infinity> (I'd have to delete it from proposed first, obviously)
<tjaalton> ok
<tjaalton> well, people who have used -proposed would not get the "new" version then
<infinity> Is that preferable to just testing more with the current one?
<infinity> Yes, there's that.  proposed users would be stuck with the deleted one.
<infinity> Though, that's true any time we drop an SRU from proposed.
<tjaalton> what is the deadline for .1? probably too soon to get enough testing..
<tjaalton> indeed
<stgraber> tjaalton: well, the deadline was a week and a half ago ;) so we're talking about last minute exception in any case ;)
<tjaalton> ah :)
<stgraber> tjaalton: having just the ivy bridge stuff tested should be fine, the diff is readable and backed by a spec, so it's really just about having someone confirm that it works
<infinity> mesa's been in proposed for weeks, how has it not had testing?
<tjaalton> then I think the most sensible option is to only add the ivb fix. It'll get tested asap by the hwe guys in taipei
<tjaalton> infinity: i've been running it for weeks
<stgraber> infinity: well, apparently it had some testings and some regressions found... (without the bugs being updated it'd seem)
<tjaalton> but those that had the single bug mentioned in the changelog haven't bothered adding any info on the bug..
<stgraber> tjaalton: ok, can you take care of uploading a new mesa based on 8.0.2-0ubuntu3.1 with just the ivy bridge change then?
<tjaalton> also, the piglit regressions were on nouveau/radeon, I've only used it on intel
<tjaalton> stgraber: sure. ok if I do it in the morning?
<tjaalton> EEST morning :)
<infinity> I'll drop the current one from proposed, then.
<tjaalton> ie. 10h from now
<stgraber> tjaalton: once that's in the queue, we'll get the current one removed from -proposed, accept that one, test it, get it in -updates and then post-12.04.1 you can get the new mesa upstream
<tjaalton> excellent
<stgraber> tjaalton: yeah, it's unlikely to make it to the next CD build anyway (30min from now), so if that's done in the european morning, that's fine
<infinity> (I'll just remove it now.  If it's never going to be the binaries we ship, there's no point having it there)
<stgraber> infinity: yep, sounds good
<tjaalton> thanks, I'll let #ubuntu-x know about this
<infinity> tjaalton: I could be wrong about being able to go backward with versions, but if -0ubuntu3.2 gets rejected, renumbering and reuploading isn't rocket science. :P
<infinity> tjaalton: And I'm kinda curious to find out.
<tjaalton> infinity: heh, we'll find out soon enough
<micahg> ISTR one can go backwards with sources, but not binaries...(and even that cjwatson warns not to do it)
<tjaalton> well, let me know what the version should look like and I'll upload whatever works
<infinity> micahg: Even binaries that are no longer published?  It's possible that the complete history is checked, yeah.
<micahg> infinity: that's what I seem to remember, but if you find out otherwise, I'd be kinda happy personally :)
<infinity> micahg: Well, there's a fair argument for walking the entire binary publishing history for sane upgrade paths.
<infinity> micahg: I would argue that -proposed should, perhaps, not be subject to this, but I really doubt it has special-casing.
<infinity> tjaalton: The more I think about it, the more I suspect you'll need some sort of 8.0.3+8.0.2-0ubuntu3.2 ickiness.
<tjaalton> infinity: yeah
<infinity> Thankfully shortlived, if you plan on an 8.0.4-0ubuntu1 shortly after. :P
<tjaalton> yeah, and possibly even pulling the current 8.0 branch.. ivb gpu hang fixes/workarounds there
<tjaalton> ivb & snb
<stgraber> skaet: updated debian-cd and cdimage-deployment to turn off proposed, disabled the cron jobs for now. Will wait an extra 10min and start kicking the rebuilds.
<stgraber> slangasek, infinity: can you also move d-i to -updates? we'll need it if we want a working alternate/server image.
<stgraber> slangasek: it looks like you missed fglrx-installer-updates when you copied fglrx-installer earlier
<stgraber> infinity: light-themes contains a UI fix for Edubuntu (gnome-panel font and distributor logo), it's currently at 6 days and all fixes have been tested apparently, can you move it?
<infinity> stgraber: Done, done, and done (the fglrx one too).
<stgraber> yay! will wait for the publisher before starting with the respins
<slangasek> stgraber: no, I didn't miss it, that was the oops ;)
<slangasek> thanks, I hadn't quite tracked down yet which package had caused it
<stgraber> slangasek: ah ;)
 * slangasek tries again
<stgraber> slangasek: heh, now I see it being copied twice to -updates ;)
<stgraber> slangasek: once by infinity and now once by you, though your copy is lacking any kind of content in the confirmation e-mail (to precise-changes@lists.u.c) :)
<stgraber> seb128: FYI marked bug 1024480 as verification-failed. It's not a 12.04.1 targeted bug, so no hurry fixing it.
<ubot2> Launchpad bug 1024480 in remmina "should use keywords in its .desktop entry" [Low,Fix committed] https://launchpad.net/bugs/1024480
<slangasek> stgraber: well, fun
<seb128> stgraber, crap, yeah, autoreconf is not run during build, that's ok it was a low hanging fruit one
<phillw> hi guys & gals, are you confident in the cadence testing for http://iso.qa.ubuntu.com/qatracker/milestones/219/builds/20963/testcases to be popped onto a VM and tested in the 'real world'? The tester is aware that it may break.
<stgraber> phillw: if you're hoping for one of us to say "yeah sure a dev release is fine to be used in production" you'll never get that, so no
<stgraber> it's a dev release, use it at your own risk and expect it to break at the worst possible time
<phillw> stgraber: I hold the isos for that team on a stable server :) The question was, will I be able to install it? :P
<phillw> stgraber: can it now install LAMP, that was the last bug I saw on it.
<phillw> well, I will find out in the next hour or two :)
<stgraber> skaet: half way through in the rebuilds, should all be done in an hour or so
<stgraber> skaet: leaving for a few hours now, I started the rest of the images in the background, so they should build in a fairly random order but should all be published in a little while
<skaet> stgraber,  ok
<stgraber> (only live images are left, all the alternate and server images are already built)
<skaet> thanks stgraber
<stgraber> skaet: no amd64+mac for kubuntu in the point release?
<stgraber> skaet: I just noticed it's not getting updated on the tracker and default-arches has been changed to prevent it from building
 * skaet checking
<skaet> stgraber,  its not in Kubuntu's manifest,  https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest/12.04.1
<skaet> ScottK,  Riddell ^ can you confirm no amd64+mac
<skaet> if you do want it,  please update ReleaseManifest/12.04.1
<stgraber> skaet: ok, removing it from the tracker for now then, no point in having an outdated build on there
 * skaet nods
 * skaet --> dinner,  back in a bit
#ubuntu-release 2012-08-14
<phillw> Hi, is dns-nameservers still command in the new server release? As if it is, it is not.
<micahg> stgraber: can we get the blueman crash fix in for 12.04.1
<infinity> phillw: If by "command", you mean "/etc/network/interfaces option", then yes, but it requires having resolvconf installed.
<phillw> infinity: is this another thing that needs installing>
<phillw> with not wishing to start a war.... the fact I have to go back into Ubuntu system just to add ssh access, does seem rather crazy.
<phillw> and now, it cannot access the outside world.... Okies, i learn as i install ubuntu server onto VM's
<infinity> phillw: The installer does offer you the otion to install ssh...
<stgraber> micahg: I'd be fine with that, it's a frequent crasher and isn't on the Ubuntu images
<stgraber> infinity: if you have a minute, can you look at blueman? it's a frequent crasher and the diff is quite small
<stgraber> micahg: I'm assuming you have some people with that bug ready to verify the fix when it lands?
<phillw> infinity: it did, I did, I also installed LAMP from the tick-list, but now I have to add one aditional areas just so it can work?
<stgraber> skaet: world rebuilt, turned the cron jobs back on. Will disable again on Thursday 21:00 UTC
<infinity> phillw: I don't see how resolvconf configuration in interfaces(5) has anything to do with "making ssh work".  In a pure dhcp network setup, that's not necessary, and in a pure static setup, it tends to get done for you by the installer, or you do it all at once yourself by hand...
<infinity> stgraber: Done.
<micahg> stgraber: I can verify myself
<phillw> infinity: this was not a problem with 12.04. Adding ssh seemed daft, but I was aware of that. But the loss of the ability to set up resolve.conf is really taking the micky... That is only my personal view & I'm sure you server people know why we should not have a server that will actually work.
<phillw> infinity: next time, i will use minimal iso & just add in the basic requirements for a server that talks under a VM
<infinity> phillw: I'm not sure what you mean by "loss of the ability to set up resolv.conf", nor do I think that anyone's intention is "a server that [won't] actually work".
<phillw> infinity: a VM does note use dhcp.
<phillw> it requires manaully setting up.
<infinity> Yep.
<phillw> infinity: the loss of the app that does it is is silly.
<infinity> What "app"?
<phillw> I cannot command the new system, yet the system removes it at boot.
<phillw> infinity: dns-nameservers
<infinity> That wasn't an "app", it was a config option in /etc/network/interfaces.
<infinity> And it's still there.
<infinity> And it still works.
<phillw> I can assure that it is not and does not
<infinity> It's on ALL the images.
<infinity> It's in the minimal task.
<infinity> (Well, all the images except ubuntu-core, but since you used an installer, you clearly didn't use core)
<phillw> infinity: I used todays spin
<infinity> Kay.
<phillw> for server
<infinity> And the package "recolvconf" isn't installed?
<phillw> command not found
<infinity> It's.  Not.  A.  Command.
<infinity> I've said this three times.
<phillw> dns-nameservers == command not found
<infinity> See above.
<infinity> Not a command.
<infinity> Never was.
<phillw> dns-nameservers is the command
<infinity> It's an config option in /etc/network/interfaces.
<phillw> accoroding to your instructions
<infinity> Dude.  It was never a command.  And it's still not.
<infinity> My instructions?
<phillw> infinity: dns-nameservers 213.186.33.99 # OVH DNS Server dns-search ovh.net # To quickly fix the hosts on the OVH network
<phillw> for get all about after the #. that is a comment
<infinity> phillw: I'm not sure where you're pasting that from, but it's an /etc/network/interfaces snippet.
<infinity> phillw: Not a shell command.
<phillw> infinity: no, the file the holds them gets overwritten
<phillw> I can manually edit /etc/resolve.conf
<infinity> phillw: "The file that holds them" is supposed to be (wait for it, it's fun repeating myself, I love it) /etc/network/interfaces
<phillw> but it will get over written
<phillw> so, the command dns-nameservers is now obsoluete?
<infinity> phillw: No, this is EXACTLY how it worked in precise.
<infinity> phillw: It had no command.
<stgraber> phillw: can you stop typing and read what infinity told you at least 4-5 times over the past 10 minutes? as the de-facto maintainer of both ifupdown (/etc/network/interfaces) and resolvconf (/etc/resolv.conf), I can ensure you that what he's telling you is right and WORKS on up to date quantal
<infinity> phillw: It had an interfaces(5) option.
<stgraber> phillw: none of it changed since 12.04
<phillw> It worked in 12.04, I have 12,04 VMs which work perfectly happy.
<stgraber> phillw: just set dns-nameservers in /etc/network/interfaces (<-- NOT /etc/resolv.conf), reboot and you'll magically see your /etc/resolv.conf containing the right thing
<infinity> phillw: dns-nameservers was never a command.  And if you put it in resolv.conf, that also did nothing useful.
<infinity> phillw: If it's in interfaces, it writes a resolv.conf for you.
<phillw> http://help.ovh.co.uk/BridgeClient
<stgraber> phillw: you may also want to read the documentation (linked from the 12.04 release notes): http://www.stgraber.org/2012/02/24/dns-in-ubuntu-12-04/
<infinity> phillw: Quoting from that page:
<infinity>     For Debian 6*, the DNS server configuration is done directly in the file /etc/network/interfaces or you find it in this section:
<infinity>     dns-* options are implemented by the resolvconf package, if installed (default)
<phillw> if this has changed recently, let me know.....
<phillw> so, by default?
<infinity> phillw: It's been installed by default in Ubuntu on all installs since precise, yes.
<stgraber> resolvconf hasn't changed since at least warty, though we only started using it in 12.04
<phillw> so, why does it not work for 12.10?
<infinity> It DOES.
<phillw> infinity: I can assure you that those instructions do not work
<stgraber> phillw: can you pastebin your /etc/network/interfaces please?
<phillw> I've just tried to set up a server VM for 12.10 for a vilunteer.
<infinity> phillw: That adding "dns-nameservers 12.3.4.5 5.4.3.21" to your eth0 stanza in interfaces doesn't work?
<infinity> phillw: And yes, please pastebin it.
<phillw> stgraber: they are as stated on those simple instructions
<phillw> what is not happening is the stable of resolve.com Which *used* to need the command, as the file gets written over.
<stgraber> phillw: use that: http://paste.ubuntu.com/1146080/
<phillw> If now I need to enter it into the static area, I'm happy to do so & will alert them of the subtle change.
<infinity> stgraber: You missed the "dns-search ovh.net" ;)
<stgraber> which is what the ovh help page is trying to tell you to do, but apparently you don't seem to agree with that interpretation
<ScottK> skaet: I'm not sure.  I'll leave it for Riddell  to answer.
<phillw> i cannot copy and paste whilst I'm accessing via the MAC address of a VM
<phillw> I'll just delete it & put back on 12.04 - I know that works.
<phillw> but, there is a bug somewhere.
<infinity> phillw: This works exactly the same in 12.04.  Honest.
<phillw> infinity: it does not, honest!
<stgraber> phillw: the only difference with what ovh has on their site besides the fact that I moved to a reasonable layout and non-broken auto line, is that I added that dns-nameservers line to the config, the rest is identical
<phillw> the instructions are the same, and I have 12,04 VM's working - same instructions
<phillw> 12.10 VM is not working.... the evidence says....
<infinity> phillw: Compare the configs between the two.
<infinity> phillw: The evidence says you're not setting up interfaces(5) correctly.
<stgraber> and don't just assume they are the same, because they're not
<phillw> infinity: I can see them, I have followed the same instructions. This is the 1st time I've tried a 12.10
<infinity> stgraber: Well, the other possibiliy is that he broke the resolvconf resolv.conf links and forced a static version, and hence his broken interfaces config would be a no-op.
<stgraber> believe it or not, but we test that stuff and I can ENSURE you there's absolutely no difference between 12.04 and 12.10, any difference you see is the result of a mistake you did, either on 12.04 or 12.10
<phillw> infinity: If you'd lime to have a play, i do still one free ipV4 that you can set up with a MAC address and try yourself.
<infinity> phillw: I use the software every day.
<phillw> I'd really like this to be solved, ovh have a shit load of servers around the world, if an edit is needed; I'm sure they will do it.
<phillw> infinity: PM please.
<infinity> phillw: I have a gin calling my name.  But compare stgraber's pastebin above to the ovh instructions, and you'll see that he's just formatting their directions in a more pleasantly readable way (and his paste will work correctly).
<infinity> phillw: And add the dns-search bit to his paste as well, for correctness, if you care about search domains.
<phillw> stgraber: you want to prove it?
<phillw> I'll hand the VM over to you, all I want is for it to work. If there are alterations to be made in the instructions; I'm sure they will be swiftly made.
<phillw> the VM is alive, it just needs to IP stuff to be sorted.
<phillw> stgraber: here goes :)
<phillw> :)
<phillw> :(
<phillw> stgraber: do you have a decent internet speed, I'm on sub 1Mb, which makes doing stuuf via 'X' painful
<stgraber> not as fast as I'd like, but still reasonable (30Mb)
<phillw> stgraber: my link at ~1Mb at best is painful, could you install the VM for 12.10?
<phillw> it requires -X access which really does make it slow for me :(
<tjaalton> stgraber, infinity: uploading mesa now..
<tjaalton> oh there it is
<infinity> Oh lord, LP is going to diff it against the deleted 8.0.3.  USEFUL.
 * infinity does a slightly more manual audit.
<infinity> tjaalton: Thanks for that, accepted.
<tjaalton> :) thanks
<seb128> cjwatson, hum, NBS report screwed again, should I rm .launchpadlib/api.launchpad.net/cache on p.c.c ... anything else to do out of waiting then?
<cjwatson> seb128: feel free to remove the cache.  a more complete workaround is tedious in excelsis; the right fix is to get the lazr.restfulclient fix released and SRUed, which I'm prodding about on and off
<seb128> cjwatson, ok, I did move the directory away since I was unsure ;-)
<seb128> let's wait for the next run
<cjwatson> just nuke it, been done several times before
<seb128> cjwatson, right, I did the mv before you replied in case it was a stupid idea to rm it ;-) now that you replied I can rm it
<stgraber> micahg: can you spend a few minutes testing the blueman in proposed?
<stgraber> slangasek, infinity: just noticed that we're missing two more copies to get the upgrade to work fine, perl and libxml-sax-perl, would be nice to have these copied now.
<stgraber> seb128: I created http://pad.ubuntu.com/12-04-1-preparation with an early list of packages that I'm tracking for 12.04.1, can you add the desktop ones that you want to see in 12.04.1?
<stgraber> seb128: (thinking of at least compiz, nux, ... I haven't checked the exact bugs so don't know whether they are planned for inclusion in 12.04.1)
<seb128> stgraber, thanks ... is that a list of things in proposed that we want to see acked and in updates?
<stgraber> yep
<stgraber> I'm going to start nagging people to get these tested, then for most of them will get them copied early to -updates if there's not much risk involved
<seb128> checking
<seb128> I dropped a bit on that recently, things have been crazy, I did need to catch up on quantal work before ff and I'm on quantal +1 team as well
<stgraber> jibel: now that we're building the CDs without proposed, can you also turn off proposed in jenkins?
<jibel> stgraber, done. Running server upgrades to verify it is disabled.
<stgraber> jibel: thanks
<seb128> stgraber, ok, I've done a round of reviews,comments and put some notes on the etherpad
<stgraber> seb128: tested gnome-settings-daemon, windows+p now works here
<stgraber> jocarter: looks like we were both right... /usr/share/gnome-fallback is used when starting gnome in "no effect" mode, /usr/share/gnome-classic/ is used in the "with effect" mode.
<stgraber> jocarter: so both our SRUs were wrong... I'll SRU again with the overrides in both paths and push that to quantal too...
<seb128> stgraber, great
<stgraber> jocarter: uploaded
<stgraber> infinity, slangasek, ...: can someone accept that edubuntu-artwork please?
<stgraber> (only difference should be that the .desktop files are now pushed to both /usr/share/gnome-classic and /usr/share/gnome-fallback)
<skaet> stgraber,  looks like we've got the commitment for testing the chinese images for precise,   should be some results showing up tomorrow (for the test build I did last week).    I'll add them to cron.
<stgraber> skaet: ok
<micahg> stgraber: sure
<jamespage> stgraber, I'm assuming its to late for bug 973741 to make 12.04.1 now?
<ubot2`> Launchpad bug 973741 in openssl "[SRU] segmentation fault for all https operations in libcrypto.so.1.0.0 on 'legacy' Intel Xeon CPUs" [High,Confirmed] https://launchpad.net/bugs/973741
<ScottK> From the bug title it sounds scary enough to at least be considered.
<jamespage> ScottK, it did enter proposed but caused a number of issues in its first version
<jamespage> adam_g proposed a second patch but its not been uploaded (fell off my list unfortunately)
<stgraber> jamespage: upload to -proposed, we'll discuss it once it' there
<jamespage> stgraber, ack
<stgraber> the diff is quite readable at least and I don't see much regression potential in there, so it might still make it to .1
<infinity> If it's the patchset I proposed, it's entirely reasonable.
 * infinity wishes LP would actually load the bug...
<stgraber> infinity: https://launchpadlibrarian.net/111702599/lp973741-2.debdiff
<infinity> stgraber: Yup, that matches the upstream bits I pointed at.  Works for me, if it's tested, which the bug claims it is.
<jamespage> I'll upload it now...
<infinity> Danke.
<stgraber> infinity: can you copy perl and libxml-sax-perl?
<stgraber> these two are also required for the lts to lts upgrades but weren't copied yesterday
<infinity> stgraber: Do I get a cookie?
<infinity> stgraber: (done)
<jamespage> stgraber, thats now in the -proposed queue
<stgraber> infinity: thanks!
<stgraber> infinity: there'll likely be a few more we'll want to fast track into -updates but I'll review the list with skaet first
<ScottK> jamespage or infinity: Is there a chance that openssl bug would affect ssh?  I have an affected server (right CPU type) that I was about to upgrade to precise.  If it's not going to affect SSH, I can do that and then test the fixed package.
<infinity> ScottK: It won't affect ssh if you're already logged in.  Can't say otherwise.
<infinity> ScottK: So, log in to several root sessions, just in case, and then test away. :P
<ScottK> Which, of course, I won't be if I reboot into the new install.
<ScottK> It's a remote system, so I think I'm not going to experiment.
<infinity> ScottK: You could probably test in a precise chroot on said system.
<ScottK> Good point.
<slangasek> stgraber: were the perl and libxml-sax-perl SRUs needed for the CD upgrade case?  I thought they weren't so I was going to let them age a little more
<slangasek> (but I see that's done now anyway, so)
<stgraber> slangasek: yeah, they were. They are causing an upgrade failure (not a resolution failure)
<slangasek> stgraber, jibel: I don't think we should be turning off proposed in jenkins so soon.
<slangasek> I think we should have that there still for continued pre-testing of any other SRUs that might be accepted at the last minute.
<stgraber> slangasek: hmm, I guess we probably want both actually... we don't want to get in the case where -proposed somehow magically fixes an upgrade path
<slangasek> stgraber: that would be optimal, but I'm not sure jenkins would keep up with the job load
<slangasek> anyway, I guess which of the two is more important depends on what other way-past-the-deadline SRUs are getting accepted
<jibel> slangasek, stgraber I can setup server and desktop for both -updates and -proposed, and main and universe for either -updates or -proposed.
<slangasek> stgraber: ^^ what do you think?  both for server+desktop, and -proposed for now for main and universe, until we're sure we're done?
<stgraber> slangasek: sounds good
<stgraber> just re-tested edubuntu-artwork with the fix I pushed this morning, it's all good with both fallback sessions this time, would be good if someone could copy it over (so both fallback sessions are consistent)
<slangasek> ok, copying
<slangasek> anybody want to take care of the SRU verification for bug #928596?
<ubot2`> Launchpad bug 928596 in indicator-weather "Flurries condition is marked as 'Unknown'" [Medium,Fix committed] https://launchpad.net/bugs/928596
<stgraber> yeah, it was next on my list
<ScottK> infinity: I can't replicate it on i386, which is what I have on that CPU.  So I guess no help from me.
<slangasek> looks like firefox is ready for copying to precise-updates
<slangasek> but maybe somebody not on vicodin should check me on that ;)
<micahg> slangasek: it fixed the issue, but it was compounded by other issues, chrisccoulson should probably comment on whether or not it should go
<slangasek> micahg: ah; nobody documented that in the bug tags?
<chrisccoulson> slangasek, there's going to be another upload, with the fix for bug 1035305
<ubot2`> Launchpad bug 1035305 in firefox "Crash when switching apps back to Firefox (may be Firebug related)" [Critical,Fix released] https://launchpad.net/bugs/1035305
<slangasek> chrisccoulson: and is that a regression in the package currently in -proposed, vs. the one in -updates?
<chrisccoulson> slangasek, no, neither of them are really a regression. they were both dormant bugs that are no longer dormant thanks to http://code.google.com/p/fbug/issues/detail?id=5809
<slangasek> chrisccoulson: so, is there any reason to hold up publication of this SRU?
<stgraber> slangasek: finding a place where it's snowing is surprisingly more difficult than I thought it'd be ;)
<chrisccoulson> slangasek, other than to avoid providing 2 separate updates, not really
<slangasek> chrisccoulson: I guess the original bug report is also about firebug; so maybe the -proposed version provides insufficient benefit to push out to everyone?
<stgraber> oh, looks like norway will do the trick
<chrisccoulson> slangasek, yeah, it probably isn't worth pushing out just yet. it seems a lot of people will still get a startup crash afterwards, but just a different one
<slangasek> chrisccoulson: ok, setting to v-failed then
<chrisccoulson> thanks
<balloons> seems the server images today won't boot with today's kernel
<xnox> stgraber: i would have thought it would be snowing in the yukon & territories
<stgraber> xnox: nope, it's around 10-15C according to environment canada
<stgraber> xnox: I found a few palces in new zealand that were cold enough, but no flurries, so couldn't reproduce the bug :)
<xnox> stgraber: Flurries is not a new game in the Humble Bundle?! /me goes to check dictionary
<xnox> stgraber: aboug bug 1036612
<ubot2`> Launchpad bug 1036612 in linux "Quantal Server failed to install with LVM: VFS: Cannot open root device "mapper/ubuntu-root" or unknown-block(0,0): error -6" [Critical,Incomplete] https://launchpad.net/bugs/1036612
<xnox> do you think it's the live-build which got out of sync, and we simply need to respin the image.
<xnox> or do you think it is something else?
<xnox> initramfs got out of sync with the kernel
<xnox> on the squashfs install media, and the installed system
<slangasek> xnox: flurries are the thing that people in the UK call "snow" :)
<stgraber> xnox: sounds like either d-i or the seeds are out of sync
<stgraber> xnox: last d-i was for -9
<xnox> well not just snow - a lot of snow with wind =)
<xnox> A small swirling mass of something, esp. snow or leaves, moved by sudden gusts of wind: "a flurry of snow".
<infinity> xnox: Yeah, d-i and seeds needed updating.
<xnox> stgraber: so a new d-i stack upload is required?
 * infinity will do that.
<stgraber> xnox: seed also says -9 not -10
<xnox> infinity: thanks. is it documented anywhere?
<slangasek> xnox: flurry != "a lot of snow"; it's light snow + enough wind that it doesn't come straight down
<infinity> xnox: I'm not sure there's a "how to do ABI bumps" doc, nor where one could put it that's discoverable enough to make it useful.
<xnox> infinity: i'd expect something in the wiki.ubuntu.com Archive or Installer pages
<infinity> xnox: Installer, potentially.
<stgraber> slangasek: gnome-settings-daemon, telepathy-mission-control-5, gcalctool and indicator-weather are all > 7 days and fully tested, so ready to copy
<infinity> Anyhow, it's entirely my fault for doing the copy without the other bits, I was a bit out of it.
<slangasek> stgraber: anything urgent in that set?  Otherwise I'll leave it to someone with better attention to detail currently
<infinity> xnox: Fixed.
<stgraber> slangasek: nope, nothing urgent in there
<infinity> Aaaand, I just got a call from the bank that the cheque from Australia they've been trying to cash for the last 2 months just got returned again.  I need to run and yell at someone.
<infinity> Back in a bit.
<tjaalton> stgraber: the mesa fix for .1 is now confirmed
<balloons> stgraber, have we ever considered marking images for rebuild when we discover critical errors in automated testing?
<stgraber> tjaalton: thanks
<stgraber> balloons: I guess that'd make sense, no point in wasting everyone's time on it
<stgraber> balloons: not sure how reliable the detection of "critical" errors in the automated testing is
<balloons> stgraber, yea i know.. but manual testing kind of has the same issue
<stgraber> balloons: I think it'd be best to first implement that as a manual action to whoever looks at the Jenkins results
<balloons> I was thinking about last thursday's massive image breaking as well
<balloons> I don't believe any automated tests failed, since it was a ubiquity bug.. but since we were cadence testing we found it :-) But we all got to confirm the bug across many images and people
<balloons> stgraber, yes, something for whomever files the bug
<micahg> stgraber: Bug #962469 test case verified (didn't actually try bluetooth though)
<ubot2`> Launchpad bug 962469 in blueman "blueman-applet crashed with KeyError in card_cb(): 'bluez.path'" [High,Fix committed] https://launchpad.net/bugs/962469
<seb128> cyphermox, thanks for the blueman fix
<seb128> cyphermox, micahg: we should probably look at replacing blueman btw, it seems very poorly maintained, we are lucky that cyphermox took time to fix the issue, it was on top of the errors report for months without anyone caring
<micahg> seb128: well, gnome-bluetooth fell out of sorts for Xubuntu since it started requiring heavier integration wtih GNOME
<micahg> seb128: as I mentioned to cyphermox, I"ll all for a better replacement :)
<xnox> infinity: are you respining cd, or will we just wait for tomorrows daily?
<seb128> micahg, gnome-bluetooth is maintained at least...
<stgraber> xnox: I don't see any respin in progress for quantal. What needs respinning?
<xnox> stgraber: server+amd64
<xnox> stgraber: if the seed/d-i upload landed
<xnox> stgraber: that is quantal
<stgraber> xnox: not published yet
<xnox> kk
<infinity> xnox: I didn't see much point in a manual respin, but I can if you're waiting on the image to test something.
<xnox> infinity: well... i am not sure about uploading newer lvm2, if the image & jenkins are borked on the lvm test cases.
<xnox> infinity: can wait till tomorrow, i'll do something more fun instead =)
<infinity> xnox: Good plan.  I was pondering a bit of fun this evening myself.
<xnox> infinity: i have numbers to crunch ;-)
<slangasek> seb128: what do you mean, "replacing" blueman?  It's not part of the Ubuntu desktop stack at all
<slangasek> people are either hitting this on one of the other community flavors, or they're going out of their way to install it
<seb128> slangasek, well it was on the top 5 errors.ubuntu.com reports for some weeks
<slangasek> yes, it was
<slangasek> but I don't know what you think it would mean to replace it
<slangasek> because Ubuntu already isn't using ti
<slangasek> it
<seb128> so it seems somewhat buggy software is pushed to users
<micahg> xubuntu and lubuntu switched to it to avoid pulling in gnome-control-center
<micahg> the upstream was active when we switched, then they disappeared :)
<infinity> seb128: All software is buggy.  The bug is fixed now, I'm failing to see the issue.
<seb128> it's fixed because somebody from our team went out of his way to fix the bug
<seb128> which is my issue
<slangasek> seb128: not pushed by Ubuntu.  If you want to take it up with the xubuntu and lubuntu teams, feel free
<seb128> we shouldn't have to spend desktop resources to fix stuff we don't ship
<slangasek> seb128: er, *why* did somebody from your team go out of the way to fix it?
<infinity> seb128: It's fixed because... A software developer... Fixed the bug... Is an issue?
<slangasek> you're right, you shouldn't have to
<micahg> seb128: and I thanked him for it :)
<slangasek> and as far as I see you shouldn't have done so
<infinity> seb128: Did he do it on "work time"?
<seb128> slangasek, I guess because it was on top of the report and nobody else was doing it
<infinity> seb128: Cause there's nothing wrong with paid folks doing other things in their spare time.
<seb128> infinity, right, well it just seemed like a buggy unmaintained piece of software
<seb128> so I was wondering if there was a way xubuntu could use the same bluetooth stack than Ubuntu
<seb128> but it's a low priority issue,question
<seb128> probably the wrong channel to discuss it as well ;-)
<seb128> slangasek, btw while you are around, what's the deal with whoopsie and 12.04.1
<slangasek> seb128: ev's report is still running and we should have some real numbers by tomorrow
<seb128> slangasek, I'm concerned we are getting no news on why the bug report curves dropped to some 10% of their value on 05/17/12
<seb128> slangasek, does it mean our stats are off by a 10 times factor?
<seb128> slangasek, and if not what's the other explanation?
<seb128> did we loose 90% of our users on that day?
<slangasek> I don't know the answer to that
<seb128> that's an important question though :-(
<seb128> how do we get an answer to it?
<slangasek> yes, it is; but I'm not going to rush to judgement here
<seb128> I'm not for rushing
<seb128> but 12.04.1 hard freeze is getting close and we need to decide what to do
<slangasek> I don't think we're going to know the answer for that dip in time for the 12.04.1 hard freeze
<slangasek> ev is working on it but hasn't found the answer yet
<seb128> :-(
<seb128> so what's the process at this point that makes us decide what to do with whoopsie for 12.04.1?
<seb128> it seems like we might need to take a decision without a complete picture
<seb128> does it mean we will likely go for the status-quo and do nothing?
<slangasek> well, I think we want to still get the best information we can about how often users are getting prompted
<slangasek> and make sure that we're below the agreed threshold, one way or the other
<seb128> ok
<slangasek> understanding that this "best information" won't account for the anomalous drop in May
<seb128> so we still count on getting the infos (out of the drop reason) this week?
<slangasek> yes
<slangasek> the necessary update is running
<seb128> who will decide and when then? release meeting on friday?
<seb128> .1 meeting on thursday might be better?
<slangasek> I think the .1 meeting makes sense
<seb128> ok, great
<seb128> slangasek, thanks!
<chrisccoulson> could someone please accept the firefox packages in to *-proposed? :)
<slangasek> hmm, why should there be a sharp uptick in update-manager -related crash reports today? (https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fbin%2Fupdate-manager%3AAttributeError%3A_on_config_file_conflict%3Arun%3Ashow_diff, https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fbin%2Fupdate-manager%3Alibnspr4%3A_inline_callbacks%3Acommit%3A_inline_callbacks%3A_run_in_dialog)
<slangasek> chrisccoulson: looking
<chrisccoulson> thanks
<slangasek> chrisccoulson: can you fill out the SRU template for the bug description?
<slangasek> (test case, regression potential)
<chrisccoulson> slangasek, sure, i'll do that in a moment
<slangasek> oh, sigh
<slangasek> stgraber: the 'libnspr4' in this one refers to the package name; this is somehow related to the SRU we just did. https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fbin%2Fupdate-manager%3Alibnspr4%3A_inline_callbacks%3Acommit%3A_inline_callbacks%3A_run_in_dialog
<infinity> Unmet deps?  What did we break?
<slangasek> I don't know
<slangasek> but the error appeared the day the SRU went into -proposed
<slangasek> and has spiked now that it's published to -updates
<stgraber> oh, there's actually one change
<stgraber> stgraber@castiana:~$ apt-cache show libnspr4 | grep ^Depends
<stgraber> Depends: libc6 (>= 2.15)
<stgraber> Depends: libc6 (>= 2.4)
<stgraber> caused by the rebuild
<slangasek> which ... should not be a problem at all
<infinity> Though curious that it started using new symbols.
<stgraber> well, it might change the upgrade ordering a bit I guess, but yeah, it shouldn't cause any problem
<infinity> But yeah, given that libc6 is kinda crucial to almost all system upgrades, that seems odd.
<infinity> And the Breaks doesn't look particularly harmful.
<slangasek> infinity: implies that the previous build of the package was before 2.15 was in precise
<infinity> slangasek: Sure, but 2.4 to 2.15 is quite a jump, if it really was only using fairly old symbols before.
<infinity> Anyhow, that *should* be a non issue, and working as advertised.
<infinity> So, still a big WTF here.
<slangasek> and we don't have anyone turning this into a bug report yet, so we apparently don't get logs
<slangasek> 00000000      DF *UND*  00000000  GLIBC_2.15  __fdelt_chk
<slangasek> FYI
<slangasek> so it's a hardening symbol
<infinity> slangasek: Ahh, that makes some sense.
<infinity> I suppose it could be the combination of both the breaks and the new libc dep, but really, I can't see how either would cause a problem alone or together.
<infinity> A chroot that could reproduce it and some apt pkgProblemResolver output would be stellar.
<infinity> Or whatever that option is that I always have to look up EVERY TIME.
<infinity> Debug::pkgProblemResolver ... I was close, for once.
<slangasek> infinity: so, we have some data on the aptdaemon SRU; I'm not sure if I think it's convincing enough to publish
<slangasek> infinity: https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fsbin%2Faptd%3AUnicodeDecodeError%3A_simulate%3A_set_error is pretty convincing that bug #926340 is fixed; but https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fsbin%2Faptd%3AUnicodeDecodeError%3Afail%3A_emit_acquire_item , which is for the SRU regression, is still accumulating hits
<ubot2`> Launchpad bug 926340 in aptdaemon "aptd crashed with UnicodeDecodeError in _set_error(): 'ascii' codec can't decode byte 0xc3 in position 9: ordinal not in range(128)" [High,Fix committed] https://launchpad.net/bugs/926340
<slangasek> (bug #1034806, for that regression)
<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)" [Critical,Fix committed] https://launchpad.net/bugs/1034806
<infinity> slangasek: And it's definitely still being hit by the new version?
<slangasek> no
<infinity> Oh, see, that would be handy to know. :P
<slangasek> it's not definite at all, I think there's a bug in stuff being misreported to errors.u.c when the version on disk doesn't match the running version
<infinity> slangasek: Does it pass your manual testcase?
<slangasek> yes
<infinity> slangasek: If so, I'd be willing to call it an improvement, even if it might still be broken.
<slangasek> infinity: if it passes my manual test case for the -proposed regression, but the -proposed regression is still there in some way we can't yet discern?
<infinity> That, of course, is a big if.  I'm willing to assume errors.u.c is wrong here.  But that would be nice to hunt down.
<infinity> Was this a regression introduced in -0ubuntu3, then, or something already published to -updates in -0ubuntu2?
<infinity> I guess if it was confined to -proposed, then yeah, letting it cook a tiny bit longer while we sort out if the bug's still there or the infrastructure is broken seems sane.
<slangasek> introduced in -0ubuntu3 as a direct consequence of the change
<slangasek> (unicode-colored bubbles in the wallpaper)
<slangasek> so, found a reference to our libnspr4 issue on the interwebs. http://askubuntu.com/questions/175722/unmet-dependencies-for-libnspr4/175920
<infinity> slangasek: Oh, huzzah.  Hopefully we can get something useful from that.
<slangasek> hope so :)
<marrusl> so RAOF, on bug 993694, I'm going to email the fix author... well if I can figure out who made the change
<ubot2`> Launchpad bug 993694 in d-conf "unity-2d does not start if user has logged in on unity" [High,Fix committed] https://launchpad.net/bugs/993694
<marrusl> SpamapS sponsored it, but I don't think it was his patch.
<marrusl> in any case, I'll find out and ask if they think it's a low risk patch.
<infinity> slangasek: Oh, did you want to have a quick eyeball of the 37 tzdata SRUs?
<slangasek> infinity: not terribly
<infinity> Excellent.  Then don't!
<RAOF> marrusl: Thanks.
<infinity> Oh, I guess it's technically RAOF's day.  Except that it's Wenesday for him, because he lives in the future.
<infinity> RAOF: Get a sane timezone.
<marrusl> SpamapS, do you know who actually made the fix in bug 993694?
<ubot2`> Launchpad bug 993694 in d-conf "unity-2d does not start if user has logged in on unity" [High,Fix committed] https://launchpad.net/bugs/993694
<RAOF> infinity: Damn straight!
<RAOF> marrusl: https://launchpad.net/ubuntu/+source/d-conf/0.12.0-0ubuntu1.1 makes it look like seb128 uploaded it, and it's a patch from upstream git.
<infinity> RAOF: Actually, how do you work that?  Do we just end up doubling-up on the same (ish) day, or do you do your "Tuesday" on Australia's Wednesday, so the rest of us don't get confused? :P
<RAOF> infinity: I think I might start doing my Tuesday on my Wednesday.
<marrusl> RAOF, thanks
<RAOF> infinity: Because I have, in the past, been somewhat confused by you doing stuff on my day :)
<slangasek> heh
<marrusl> RAOF, I should CC which list?
<RAOF> I don't think we actually have a list.
<marrusl> ok, you and...?  :)
<RAOF> Probably just me is fine. Although you might also want to CC whoever is SRU-point-man for tomorrow, too.
<marrusl> RAOF, sounds good.  will do.
<RAOF> marrusl: https://wiki.ubuntu.com/StableReleaseUpdates#Publishing
<marrusl> well then, you and clint it is.  thanks!
<slangasek> chrisccoulson: oh, your firefox SRU needs to be built with -v$last_version_in_updates, too.  The diff looks fine, but it needs an update for this
<slangasek> chrisccoulson: (rejecting for now)
#ubuntu-release 2012-08-15
<knome> skaet or somebody else with power: can you accept https://blueprints.launchpad.net/ubuntu/+spec/other-q-xubuntu-marketing for quantal? thanks!
<knome> skaet, ^ also, can set that as medium :)
<ScottK> The equivalent changes for ^^^ will have to go through -security for n/o/p.
<stgraber> knome: done
<knome> stgraber, ta :)
<diwic> Hi, I'm preparing an SRU for PulseAudio in 12.04. Would it be best to 1) upload as soon as possible to make sure it gets into 12.04.1 or 2) wait until 12.04.1 is released and after that upload? It's not critical.
<jibel> slangasek, stgraber infinity unmet dep issue with nspr4 is bug 1036794
<ubot2`> Launchpad bug 1036794 in update-manager "unmet dependencies during update of nspr4: libnspr4 : Breaks: evolution-plugins (< 3.2.0-0ubuntu2) but 2.32.2-0ubuntu7 is to be installed" [High,Triaged] https://launchpad.net/bugs/1036794
<jibel> this occurs when there is an old version of evolution-plugins (2.32.2-0ubuntu7 from natty) installed on the system and the user upgrade to the latest version of nspr in Precise which breaks evolution-plugins
<njin> hallo
<njin> hallo
<njin> today's build of amd64 server isn't updated on cdimage (still preent the one of yesterday)
<njin> preent/present
<xnox> njin: patience. has it been more than 24h since the last one?
<xnox> even then the window between the two is 48h to call it "daily"
<xnox> it should be there in 1.5h
<njin> xnox, it is published in the iso tracker but not in the cdimage
<xnox> as it's UTC time used
<xnox> njin: now that is interesting.
<njin> generally is a daily build and it cames up at 8.00 utc
<njin> njin@quantic:~/Ubuntu$ zsync http://cdimage.ubuntu.com/ubuntu-server/daily/20120815/quantal-server-amd64.iso.zsync
<njin> failed on url http://cdimage.ubuntu.com/ubuntu-server/daily/20120815/quantal-server-amd64.iso.zsync
<njin> could not read control file from URL http://cdimage.ubuntu.com/ubuntu-server/daily/20120815/quantal-server-amd64.iso.zsync
<xnox> njin: daily preinstalled are there http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/20120815/
<xnox> njin: but not daily
<xnox> well for omap4 anyway
<njin> xnox, that is the link that i copied from the iso tracker
<xnox> sure. but you can predict the URLs ;-)
<njin> yes, now i go to daily-preinstalled to see
<xnox> well stgraber is the one who knows everything about the iso tracker.
<xnox> i am not sure who is available and knows about cd publishing.
<njin> could not read control file from URL http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/20120815/quantal-server-amd64.iso.zsync
<xnox> hmmm
<xnox> njin: there is only this one published already http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/20120815/quantal-preinstalled-server-armhf+omap4.img.gz.zsync
<njin> xnox, ok let's wait
<xnox> yeah, lets wait.
<xnox> njin: to be honest, I wait for automated jenkins results before testing myself
<njin> xnox, don't know how to use it
<xnox> njin: https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO%20Testing%20Dashboard/
<xnox> this tells you per image pass/fail for daily images on i386 & amd64
<njin> xnox, thanks, bookmarked this too
<njin> ok, is on thanks
<knome> can we get a SRU exception for #1001936 ?
<tumbleweed> SRU exception?
<knome> isn't there such a thing. isn't SRU stuff frozen at some point? :)
<knome> micahg told we need one!
 * knome hides
<tumbleweed> oh, right point release
<knome> yes :)
 * tumbleweed has been a little out of it for the last couple of weeks
<xnox> knome: bug #1001936 will make the bot print a link!
<ubot2`> Launchpad bug 1001936 in xfwm4 "GTK3 Grab/Move Triggered on Mouse Click" [Undecided,Confirmed] https://launchpad.net/bugs/1001936
<xnox> tadah! =)
<xnox> knome: oh that one is funny =)
<knome> xnox, i know
<chrisccoulson> could someone please approve firefox in {natty,oneiric,precise}-proposed please? i've filled out the SRU template for the bug now....
<smartboyhw> Question: What time does a Ubuntu Daily Build been regularly released?
<Laney> look at the timestamps in (for example) http://cdimage.ubuntu.com/daily-live/current/ for an idea
<xnox> smartboyhw: it takes time so depends on when it started and finished. They are published one by one for each flavour so times can vary a bit.
<smartboyhw> Ok, thanks
<smartboyhw> Waiting for a Ubuntu Studio daily build to test
<smartboyhw> Laney and xnox: Do a new daily build release get announced here?
<Laney> no
<Laney> http://cdimage.ubuntu.com/ubuntustudio/dvd/current/
<Laney> studio images come later in the day
<Laney> are you waiting for a particular pressing issue?
<smartboyhw> No, I'm responsible for 64-bit testing of Ubuntu Studio in the team
<Laney> so, you can expect them around 18:45 UTC daily
<smartboyhw> 18:45 UTC?
<Laney> date -u
<davmor2> smartboyhw: basically in the morning you are running a day behind in the current folder as long as everything built
<smartboyhw> Oh
<Laney> well, depends where in the world you are ;-)
<smartboyhw> Hong Kong
<davmor2> smartboyhw: so now is morning in the UK so now if you test you will be using yesterdays.   In 8+ hours time you will be using todays packages
<davmor2> Laney: good point though :)
<stgraber> jibel: hmm, the "Holding Back evolution-plugins:i386 rather than change evolution:i386" part is quite weird... I'm wondering why apt is doing that.
<smartboyhw> Hi stgraber
<ScottK> diwic: It's too late to make sure anything gets into 12.04.1.  If you have a very targeted fix for a very severe bug, it might be considered.  Otherwise it'll go in post 12.04.1.  It does not hurt to upload it, it'll just stay in the unapproved queue.
<diwic> ScottK, okay, thanks, I'll wait for 12.04.1 then.
<knome> ScottK, re: your comment on severe stuff, do you think we could get bug #1001936 through?
<ubot2`> Launchpad bug 1001936 in xfwm4 "GTK3 Grab/Move Triggered on Mouse Click" [Undecided,Confirmed] https://launchpad.net/bugs/1001936
<ScottK> You'd have to ask stgraber  and only if there's a clearly low risk patch available in any case.
<stgraber> can someone review ubuntu-sso-client? it's a frequent crasher and the diff looks reasonable so we might be able to get it in 12.04.1 if it's tested quickly
<knome> stgraber, ^ :]
<stgraber> knome: I don't see a debdiff in this bug so can't review it at this point
<knome> the original commit-diff is at http://git.xfce.org/xfce/xfwm4/commit/?h=xfce-4.10&id=099614e3f045e06db7ab509e174510ea74857adb
<stgraber> looks reasonable, if you can get it in -proposed in a couple of hours and have testers available to verify it, it might make it
<knome> i'll look at it.
<infinity> stgraber: That pkgProblemResolver output in #1036906 is kinda special.
<smartboyhw> Bug #1036906
<ubot2`> Launchpad bug 1036906 in nspr "libnspr4 bug report (unmet dependencies)" [Undecided,Confirmed] https://launchpad.net/bugs/1036906
<slangasek> jibel: 1036794> great, thanks for catching that
<stgraber> infinity: am I reading it wrong or is it language-support-translations-en creating a bit of a mess there?
<infinity> stgraber: langpackish stuff may well be why evolution refuses to upgrade (which, in turn blocks the plugins, which then blocks nspr)
<infinity> stgraber: I suppose we might need to build a bit of a dependency map here to see what's happening, but at least that output shows all the packages involved, so it should be vaguely reproducible.
<stgraber> infinity, slangasek: hmm, if I'm reading these logs right, it looks like a natty -> oneiric upgrade that held evolution and evolution-plugins, then the oneiric -> precise upgrade caused the failure... trying to reproduce
<infinity> stgraber: That sounds about right, given the version(s) in play.
<stgraber> the system was Edubuntu apparently, trying with a clean natty -> oneiric -> precise upgrade, will take a while though as Edubuntu is quite big and I don't have a local mirror of oneiric
<stgraber> SpamapS: ping
<stgraber> SpamapS: I believe it's your SRU day? If so, the following are ready to copy to updates: gnome-settings-daemon, telepathy-mission-control-5, nux, gcalctool, indicator-weather and sqlite3.
<stgraber> SpamapS: we'll also probably get an early copy for a few others, but I'll get back to you after my meeting with skaet in a couple of hours
 * skaet nods
<stgraber> SpamapS: looking at unapproved, mesa seems to be a duplicate of what we have in -proposed but with a different version number. Can probably be dropped.
<stgraber> SpamapS: ubuntu-sso-client and ubuntuone-installer should be considered for inclusion into -proposed as they are frequent crasher that we might want fixed for 12.04.1 (though not high priority)
<skaet> stgraber,  SpamapS,   walinuxagent also appears to be verified, and should probably get copied over.
<stgraber> skaet: right, didn't list it because it's only been there for 5 days, but as it's a new package, there's no risk of regression, so copying is fine indeed
<knome> stgraber, ^ that
<stgraber> knome: waiting for LP to generate the diff
<knome> stgraber, ok. mr_pouit said he had to go now, but he will be back later today to reupload, IF we need something.
<SpamapS> stgraber: ACK on all
<SpamapS> skaet: ACK to you as well :)
<skaet> :)
<slangasek> chrisccoulson: firefox accepting
<balloons> stgraber, do you feel this bug should be handled as an SRU? https://bugs.launchpad.net/ubuntu/+source/abiword/+bug/1019621
<ubot2`> Ubuntu bug 1019621 in abiword "Precise abiword version needs to be reverted to stable release prior to 12.04.1" [Undecided,Confirmed]
<stgraber> balloons: reverting would cause regression and upgrading would cause new features. We need an upstream fix cherrypick.
<stgraber> balloons: and that certainly won't happen to 12.04.1
<balloons> stgraber, no of course not.. But I was wondering how it needed to be handled
<balloons> ok, so it's not an SRU.. it needs development attention
<balloons> err.. well, it would still go through as an SRU then or no?
<balloons> I mean, if I cherrypick fixes, the update is still an SRU, right?
<stgraber> if someone can cherry-pick the fix without causing regression or feature change, yes
<balloons> stgraber, well that should be the point.. it's unstable and needs a fix.. we don't want to simply rebase to a new or old version
<balloons> ok.. but let's say a feature change and/or regression can't be avoided. For my learning sake, what would happen then?
<stgraber> most likely and as bad as it sounds, nothing, we'd just wait until someone finds a way of doing it without these side effects
<stgraber> FWIW, only Xubuntu is supporting abiword in 12.04, so I wouldn't count on the bug getting fixed real soon as they seem to be a bit short on resources
<knome> what bug?
<balloons> stgraber, ok.. in short when dealing with issues like this, you etheir meet the requirements for an SRU, or it doesn't get fixed?
<knome> oh, that.
<balloons> knome, yes.. speaking i reference.. but I'm trying to understand on a more general scale how this works
<knome> yeah, sure
<stgraber> balloons: pretty much, yes. There are some specific exceptions for new upstream releases as MRE, but they still should be bugfix only and regression free.
<balloons> k, makes sense.. I think that clears it up for me
<stgraber> balloons: the only exceptions I'm aware of for the bugfix only part of that is firefox and thunderbird
<stgraber> SpamapS: add xfwm4 to the list of packages in Unapproved to review for inclusion in -proposed
<SpamapS> stgraber: will do
<marrusl> So SpamapS, RAOF... I'd still like to push out the dconf SRU early if possible.  It's not a huge difference (2 days), but it will still provide Customer Happiness.
<marrusl> said customer could use some extra love right now.  :)
<stgraber> marrusl: it's on the tracking list for 12.04.1 already
<slangasek> stgraber: I believe he's asking for it to be released before the 7 day mark
<SpamapS> stgraber: when do things have to hit -updates to be included in 12.04.1 ? Monday?
<marrusl> indeed.
<SpamapS> because it won't go to updaets on Friday, we don't do that. :)
<stgraber> SpamapS: ideally, before tomorrow 21:00 UTC where we enter final freeze
<stgraber> slangasek: yep, I know that, it's on my list of things that we will want to copy before the 7 days
<SpamapS> marrusl: would that work for you then? Tomorrow instead of Friday?
<marrusl> SpamapS, I think it does, surely.  So i can say "by tomorrow 21:00 UTC" ?
<SpamapS> stgraber: ^^ yes?
<stgraber> yep, I'm expecting everything for 12.04.1 to be accepted by then, after that we'll only copy in case of emergency
<marrusl> I'm taking that as a yes.  :)  Thanks, folks!
<SpamapS> marrusl: any time
<stgraber> slangasek, skaet, infinity: http://pad.ubuntu.com/12-04-1-preparation
<ScottK> skaet: Is $SOMEONE going to update the common infrastructure parts of the release notes?
<ScottK> stgraber: ^^^
<skaet> ScottK,  yes,  have asked slangasek to take a pass
<ScottK> OK.  Thanks.
<slangasek> stgraber: hmm.  do you know why gnome-language-selector says I should install 'poppler-data' as part of the not-completely-installed language support?
<slangasek> I'm not sure where this is coming from
<slangasek> n/m, figured it out
<stgraber> slangasek: I'll let you poke at the nspr bug and will look at the chinese issues (as I had no luck trying to reproduce the evolution packages hold after a natty to oneiric upgrade)
<slangasek> ok
<stgraber> ok, sure enough the chinese media comes with /etc/default/locale containing en_US.UTF-8
<stgraber> slangasek: hmm, ubuntu-defaults-zh-cn is missing on the media, I guess that'd explain the issue ;)
<stgraber> hmm, that doesn't match the manifest... /me checks it's the right image
<stgraber> gah, VM had an older version of the file opened... starting from scratch
<slangasek> stgraber: ubuntu-defaults-zh-cn is not missing on the media, where do you see that it is?
<slangasek> stgraber: it's definitely in the .manifest
<stgraber> slangasek: as I said, VM was using a bad media... I overwrote another image with the same name and libvirt still had an open fd so it never used the real chinese image
<slangasek> ah, ok :)
<stgraber> booting the chinese image indeed has ubuntu-default-zh-cn and /etc/default/locale set to zh_CN.UTF-8
<stgraber> the installer starts in chinese but the indicators are in english
 * slangasek nods
<stgraber> oh, might be as simple as sourcing /etc/default/locale in ubiquity-dm
<slangasek> seems plausible
<stgraber> oh, actually ubiquity-dm is the thing writing /etc/default/locale apparently and /etc/locale.gen and /etc/environment
<stgraber> anyway, I think I know how to fix it while not making too many changes
<skaet> thanks stgraber.
<stgraber> slangasek: here's what ubiquity.conf contains and the reason why LANG and LANGUAGE are empty ;) http://paste.ubuntu.com/1149469/
<slangasek> arrrgh
<slangasek> well, we aren't going to be fixing that in pam for 12.04.1
<stgraber> no, but dropping that code and replacing by "[ -r /etc/default/locale ] && . /etc/default/locale" + export should work
<skaet> stgraber,  slangasek,   was talking with superm1, and it sounds like mythtv is pretty much as verified as it can be.   Last bug is going to need to have someone with that specific hardware.   Let it through?
<stgraber> superm1: can you update the bugs? last I checked they were all still in verification-needed state
<slangasek> and it would require a ubiquity change anyway
<slangasek> can you just source /etc/default/locale?
<superm1> stgraber: they got updated today earlier
<stgraber> slangasek: just sourcing doesn't seem to be enough from the upstart job, trying source + export of LANG and LANGUAGE now (if set)
<slangasek> stgraber: yes
<slangasek> stgraber: fwiw the nspr fix may be to add a Breaks: evolution (<< $modern) as well
<slangasek> stgraber: do you have an env where you can reproduce this bug?
<stgraber> slangasek: nope, had no luck reproducing the same situation on Oneiric (apt holidng evolution from natty)
<stgraber> well, I guess I could pin it, but I'm not sure it'd cause the same upgrade failure
<slangasek> the debug log on the bug shows language-support-translations-en, which is obsolete
<slangasek> pre-lucid
<stgraber> slangasek: does that look sane to you? http://paste.ubuntu.com/1149486/
<slangasek> stgraber: yep
<stgraber> ok, pushing that one then
<stgraber> slangasek: latest release to include language-support-translations-en was jaunty
<stgraber> and it had: Depends: openoffice.org-help-en-us, openoffice.org-help-en-gb, openoffice.org-l10n-en-gb, openoffice.org-l10n-en-za, thunderbird-locale-en-gb, gimp-help-en, evolution-documentation-en
<slangasek> yeah
<slangasek> so I think we should add a Breaks: evolution-documentation-*
<slangasek> but I don't know if that's sufficient; we may need other handling of language-support-translations-*
<slangasek> infinity: the nspr in the precise-proposed queue is my educated shot in the dark
<infinity> slangasek: That's not a comforting description.
<slangasek> when have you known me to be comforting :)
 * slangasek wonders if we should trim down some of the obsolete code in DistUpgrade/DistUpgradeQuirks.py
<slangasek> the real question is if we can get a viable test case for it
<slangasek> because step one is "make sure you have an obsolete package from 5 releases ago installeD"
<stgraber> I've been trying to reproduce the upgrader's system by hand in a chroot but he has a lot of packages coming from out of distro repositories
<stgraber> and a few that look like the result of alien...
<stgraber> my chroot has apt sources for all releases since hardy (using old-releases), trying to get all of them to the right version ;)
<stgraber> that's where apt-clone would be kind of useful...
<slangasek> stgraber: I think only the language-support-en stack should be needed to reproduce
<slangasek> I'd suggest starting there, and only if that fails try to reproduce the identical environment
<stgraber> slangasek: yeah, that's what I tried first but that didn't seem to be enough
<stgraber> I'd just have evolution be upgraded as evolution-common provides evolution-documentation-en
<slangasek> oh, it does?
<stgraber> well, not in precise, but it used to, yeah
<slangasek> hmm
<slangasek> well, getting evolution upgraded is certainly where we want to get to
<stgraber> slangasek: and I can perfectly have language-support-translations-en, evolution, evolution-common and evolution-documentation-en installed on an oneiric system at the same time... time to retry that on natty I guess
<jibel> slangasek, stgraber on the system affected evolution, is not installed, just evolution-plugins.
<jibel> evolution-plugins always depends on evolution excepted in maverick and natty
<stgraber> ah, interesting, will try that
<jibel> so a test case would be to install language-support from jaunty, evolution-plugins from natty and upgrade
 * xnox wonders how one managed to mix packages from jaunty & natty
<stgraber> xnox: they just upgraded all the way from jaunty to oneiric
<stgraber> or even before that
<stgraber> by dist-upgrading at every release
<xnox> stgraber: ok, so why wasn't language-support upgrade ( me jumping half way in to a conversation....)
<xnox> maybe I should read context first before wasting your time =)
<knome> stgraber, any progress on our little bug?
<slangasek> xnox: the language-support-* packages no longer exist
<xnox> slangasek: news to me =)))) /me doesn't pay attention to languages packages these days
<xnox> i did went i had dual boot and constantly were purging them.
<xnox> it's langpacks now with dictionaries isn't it.
<stgraber> knome: it's been granted an exception, now you need an sru team member to review it and let it through
<knome> stgraber, okay. who can do that? :)
<knome> stgraber, i mean, is there a list somewhere, where should i ask etc...
<micahg> knome: https://wiki.ubuntu.com/StableReleaseUpdates#Publishing
<knome> to what should i point to, when i want them to process stuff?
<stgraber> jibel: that's not enough, with these, evolution-plugins is still upgradable to the oneiric version and then to precise...
<skaet> stgraber, Daviey, slangasek;   http://pad.ubuntu.com/ubuntu-release has been set up for 12.04.1 now.
<stgraber> The following packages have been kept back:
<stgraber>   evolution-common evolution-indicator evolution-plugins
<stgraber> yay, looks like what we want!
<slangasek> stgraber: what was the key?
<stgraber> forced the natty version of these 3 and got language-support-translations-en from jaunty
<stgraber> though that's not enough, update-manager still resolves the upgrade fine...
<slangasek> man
<slangasek> then how are so many people affected by this?
<stgraber> they probably have another package installed that makes things even worse
<stgraber> slangasek: found an apt-clone state tarball in one of the bugs!
<stgraber> that guy had a lot of stuff installed on his system... will have to wait 40min to have the clone restored...
<jibel> stgraber, here is the recipe
<jibel> On Precise up to date, enable natty
<jibel> apt-get install evolution-plugins/natty evolution-common/natty
<jibel> this will downgrade libnspr4 to the version from natty
<jibel> Install libnspr4 4.8.9-1ubuntu2 from precise-release
<jibel> Download http://launchpadlibrarian.net/24623320/language-support-translations-en_9.04%2B20090401_all.deb
<jibel> Install it and the required dependencies from Precise
<jibel> apt-get dist-upgrade
<jibel> tada !
<stgraber> nice!
 * stgraber stops fighting with oneiric and follows these
<jibel> now, does it affect Oneiric to Precise ? I haven't tried
<stgraber> jibel: right, reproduced with your instructions
<stgraber> testing slangasek's fix now
<stgraber> slangasek: your package doesn't seem to fix it
<stgraber> slangasek: or at least, installing the new package on a broken system doesn't fix it
<stgraber> oh, ignore me, wrong version
<stgraber> rebuilding ubuntu2.2 now...
<stgraber> The following packages will be REMOVED:
<stgraber>   language-support-translations-en
<stgraber> slangasek: looks like success ^
<slangasek> is that the only removal?
<stgraber> yep
<slangasek> what about language-support-en?
<slangasek> was that not in your test?
<stgraber> nope, I followed jibel's instructions so didn't have language-support-en installed
<slangasek> ok; I think we need to test that too
<stgraber> let me grab it from natty too
<slangasek> because every added layer of dependency affects apt's preference for removal vs. hold
<stgraber> The following packages will be REMOVED:
<stgraber>   language-support-en language-support-translations-en
<stgraber> so that's leaving me with language-support-writing-en around but apparently not causing any problem
<slangasek> ok
<slangasek> sounds like it's at least suitable for precise-proposed, then?
<slangasek> stgraber: do you mind updating the test case on the bug description to match what you've used?
<slangasek> infinity: ^^ stgraber has shown that the nspr in the queue at least does something; do you mind reviewing?
<stgraber> slangasek: testcase updated
<stgraber> re-trying with that exact testcase as mine was mostly done with manually grabbing stuff from LP
<stgraber> slangasek: right, works in a clean chroot with the instructions I put in the description
<stgraber> SpamapS: the remaining unapproved entries to review are: nspr, ubiquity, xfwm4 and ubuntu-sso-client
<SpamapS> stgraber: I got pulled into some other stuff today, but I'll take a look at them tonight after family time.
<SpamapS> stgraber: should any be given priority?
<micahg> SpamapS: if you have time after those, icedtea-web would be nice
<stgraber> nspr is the highest priority one, the rest are all wanted for 12.04.1 too but aren't as urgent
<stgraber> (nspr fixes an upgrade regression introduce by the previous one)
<micahg> (icedtea-web is after all the 12.04.1 ones)
<slangasek> SpamapS: nspr, it's iterating an upgrade issue
#ubuntu-release 2012-08-16
<micahg> stgraber: oops, I just got the blueman crash again, it seems that the update helped, but didn't fully resolve the issue
<micahg> stgraber: hrm, maybe not...could be that the applet didn't restart, but the package is there
<micahg> in any event, I don't think it made it any worse
<stgraber> micahg: will check https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fbin%2Fblueman-applet%3AKeyError%3Afunction%27%3A__list_callback%3Ahandler%3Acard_cb tomorrow, but so far it seems to be improving anyway
<infinity> slangasek: I'd question those conflicts belonging to nspr (cause they really shouldn't), but if it works, it works.  Accepting.
<infinity> micahg: It's quite likely the applet doesn't restart, which will cause a bit of confusion until reboot (including for errors.u.c, I bet)
<infinity> stgraber: ^
<slangasek> infinity: well, they belong there because nspr needs to win the tie in apt.  In theory a Breaks would have also been sufficient.
<infinity> slangasek: Would it not work for evolution(-$something) to have the conflicts, which seems like a more obvious package relationship?
<slangasek> infinity: no, because apt is happy to hold back all the evolution-$somethings
<infinity> slangasek: (Again, just nitpicking, cause a bit of cruft in two packages that don't really relate on a massive LTS->LTS upgrade path doesn't really annoy me, especially as we're not carrying the delta forward)
<infinity> slangasek: Sure, it's happy to hold them back, but maybe it wouldn't be with the conflict, was my point. ;)
<infinity> I really need to try to understand that part of the resolver some day, cause my only "understanding" of it tends to be "add/remove conflicts in curious orders until I beat its internal scoring engine, but without actually knowing why it worked".
<infinity> Maybe it was intended as a video game for really, really boring people.
<slangasek> heh
<tjaalton> hey, I think the x stack can be moved to quantal now
<infinity> tjaalton: \o/
<tjaalton> -msm got fixed yesterday, and i'm not letting -glamo block this..
<infinity> Oh, crap, I didn't get a chance to discuss the state of omap/omapfb with the various parties.
<infinity> Though, I'm still not entirely convinced that omapfb can go away.
<SpamapS> Ok I see nspr was accepted...
<tjaalton> infinity: hmm ok
<SpamapS> are there any others w/ exceptions that need reviewing?
<infinity> SpamapS: Yeahp.
<infinity> SpamapS: Yeahp to the accepting, not the needing.  I grabbed ubiquity as well.
<infinity> SpamapS: sso-client is all yours, if you want it.
<infinity> tjaalton: Give me a 12/24h window to get some round-trips on some pings between people, and I'll either release the X stack as is, or come back with a "wait, no, we need to fix omapfb, not remove it".
<tjaalton> infinity: heh, sounds ok
<infinity> Or I'll test it all myself, instead of relying on third parties, but I don't feel like reinstalling my Panda at 10:21pm.
<tjaalton> hmm, mlankhorst has one too, I could ask him what it uses
<infinity> tjaalton: Upgrading to quantal-proposed, making sure that -omapfb isn't even removetly installed on disk, rebooting, and seeing if he has a workable X, would probably be enough.
<infinity> tjaalton: s/removetly/remotely/ ...
<tjaalton> infinity: it would fall back to -fbdev if it used to use -omapfb, i think
<tjaalton> but yes
<tjaalton> as long as it works
<infinity> tjaalton: Well, sure.  Doing the above, and then seeing if it's using a driver that's not fbdev would be nice. :P
<infinity> tjaalton: But if it functions at all, that's also something of a bonus.
<tjaalton> it might need tweaks to the patch for xserver that handles driver autoloading on arm
<tjaalton> which is a gross hack currently, but rsalveti is on it
<tjaalton> but shouldn't be too hard to add some more glue just to get -omap load
<tjaalton> +ed
<rsalveti> we can, I have the hack in hands
<rsalveti> but I don't see it's that critical at this point
<rsalveti> it'll still be using fbdev, which is the one used in the past
<infinity> Alright.
<tjaalton> oh?
<infinity> rsalveti: I disagree on the criticality, but no, it shouldn't block the xorg ABI transition.
<infinity> rsalveti: It absolutely should happen before release, though.
<tjaalton> sure
<rsalveti> infinity: sure, but not critical at *this* point :-)
<rsalveti> the driver is needed for sgx to work properly
<rsalveti> and that's my goal
<infinity> Alright.
<tjaalton> -omap?
<rsalveti> yeah
<rsalveti> omap is the open part of it, which enables exa acceleration
<rsalveti> but there's also a hook for the omap_pvr proprietary module
<rsalveti> which is part of the sgx package
<infinity> Kay...
<rsalveti> I requested a new rebuild of the sgx driver from TI, to match the latest ABI
<rsalveti> after that is available, we can work on a solution to have the omap driver to work by default
<rsalveti> and get sgx to work as well
<infinity> tjaalton: In light of the above, can you poke me in ~9h and I'll start processing all your removals, and then jam the transition in?
<infinity> (I might do it tonight, if I can't sleep, but otherwise, that maps vaguely to "when I get up")
<tjaalton> infinity: yup
<slangasek> rsalveti: so is there any word from TI about when the sgx rebuild will be available?
<slangasek> rsalveti: is the sgx package separate from the pvr-omap4 package?
<rsalveti> slangasek: it's all part of the pvr-omap4
<slangasek> ok
<rsalveti> hopefully this week still
<rsalveti> my goal is to get everything in place before feature freeze
<slangasek> ah, wonderful :)
<rsalveti> but I believe today was holiday in france
<rsalveti> so that's why I should get some answer from the ti folks by tomorrow or friday
<slangasek> that's very good news, given that unity2d is now gone from quantal
<rsalveti> yup
<rsalveti> it'll not be perfect still, due a bug at the kernel side, but it'll at least work
<rsalveti> meanwhile robclark is working with the omapdss guys at TI to try to fix the kernel
<tjaalton> oh unity2d gone.. means software fallback really should work then?
<slangasek> tjaalton: meaning it would be nice if someone would make the software fallback work, yes...
<tjaalton> duh :)
<slangasek> I hear it's not working so well yet
<tjaalton> well, at least we can now pull in current mesa master, and hope for the best
<tjaalton> it was the plan anyway
<rsalveti> yeah
<tjaalton> the unity blocker bug got fixed recently
<tjaalton> (no icons)
<tjaalton> so I'll probably prepare the new mesa today and test it with llvmpipe
<tjaalton> to see if it's as 'flashy' as before
<RAOF> Probably :/
<tjaalton> oh hai
<RAOF> Hullo
<tjaalton> yeah could be that there will be some "issues" to overcome..
<tjaalton> gnome-shell apparently works with it, so why can't unity
<tjaalton> unless it's hitting the driver in ways g-s doesn't
<RAOF> tjaalton: We know what unity's doing that g-s doesn't: unity does partial back-to-front copies, rather than buffer swaps.
<RAOF> For hysterical raisins.
<tjaalton> RAOF: are those raisins still good?
<tjaalton> probably a silly question :)
<RAOF> I'm not sure they were ever particularly good, actually.
<tjaalton> anyway, I'll prepare mesa git now
<tjaalton> -> #ubuntu-x
<rsalveti> slangasek: ogra_: can any of you take a look at bug 1018907 later?
<ubot2`> Launchpad bug 1018907 in plymouth "plymouth in quantal on arm does only boot with black screen" [High,In progress] https://launchpad.net/bugs/1018907
<rsalveti> I included a debdiff with a patch from upstream that adds a generic drm driver
<rsalveti> which is now the only one supported by upstream, and that also works at omap
<rsalveti> didn't decide to update the package as it could break other use cases at this point (due the large diff we have for ubuntu)
<babyface> anybody know why is there no new build for  precise desktop on 2012.08.15 ?
<babyface> is it becasue of the 12.04.1 release?
<infinity> rsalveti: Why aren't you a core-dev yet? :P
<rsalveti> infinity: yeah, was asking myself the same question today
<rsalveti> need to apply asap :-)
<infinity> Indeed, you do.
<infinity> Also, that autotools skew is icky.  Surely, you could have used the same version? :)
<rsalveti> infinity: the old one was generated at natty
<rsalveti> don't even know if it'd be safe to use the old version here, as I'm already using the same major version
<rsalveti> but with a newer minor version, which generally provide bugfixes
<infinity> +-# Makefile.in generated by automake 1.11.3 from Makefile.am.
<infinity> ++# Makefile.in generated by automake 1.11.5 from Makefile.am.
<infinity> ^-- Looks like precise versions t ome.
<smartboyhw> babyface: There is: http://cdimage.ubuntu.com/daily-live/20120815/
<rsalveti> could be, was using the changelog as reference
<infinity> rsalveti: Yeah, it was precise's autoconf/automake.  So, refreshing the autoreconf patch in a precise chroot would cut down the diff a lot.
<rsalveti> and the last one pointing out that updated the same patch, uploaded the package to natty
<babyface> smartboyhw, I mean precise desktop build
<infinity> (And maybe make it auditable)
<babyface> smartboyhw, you know there is no precise desktop build on 2012.08.15
<rsalveti> yeah, seems to be the one at precise, way easier
<smartboyhw> Ur, use the alternate one then
<rsalveti> let me refresh it then
<rsalveti> I just hate these kind of patches
<babyface> smartboyhw, no, I can't , I'm responsible for the watching all the automated testing on quantal & precise in Jenkins,  you know we perform automated test on daily precise desktop build everyday, so I can not use alternate instead
<smartboyhw> Hi babyface
<smartboyhw> I like testing
<smartboyhw> Doing a hell lot on Ubuntu Studio
<babyface> smartboyhw,  cool!
<smartboyhw> Yeah, I'm their staff member
<babyface> Anybody else know the reason why there are no new builds for  precise desktop on 2012.08.15 ?
<smartboyhw> Maybe they forgot
<smartboyhw> :)
<babyface> HAHA,  NO, that's not making sense
<rsalveti> infinity: yup, with automake/autoconf from precise it reduces quite a bit already
<rsalveti> but, it'd probably be updated at some point anyway
<rsalveti> will also attach the one generated at precise
<infinity> rsalveti: Oh, indeed, it'll be regenerated by someone else, and that's no big deal, but I'm sponsoring the upload, so I want to audit the macro expansions sanely. :)
<rsalveti> infinity: https://launchpadlibrarian.net/112819168/plymouth_0.8.4-0ubuntu2-2.debdiff
<rsalveti> way easier to read
<infinity> rsalveti: I don't suppose you had a chance to test it on an nvidia system to make sure it's still happy?
<rsalveti> infinity: don't have any nvidia-based system around to test, unfortunately
<rsalveti> by upstream this is now the only supported method, and the nvidia one is still enabled, in case the generic fails
<rsalveti> so it should work, but it'd be good if someone could help testing it
<infinity> Mmkay.  Let me give it a test build and see if it looks saneish, and I'll upload.
<rsalveti> infinity: if you have a nvidia system, that would be awesome
<infinity> I have a silly hybrid intel/nvidia thing.  Not sure it actually ever worked right, so it might not be the best test. :P
<rsalveti> :-)
<njin> rsalvet, have you fixed something in nvidia ?
<njin> rsalvetI:^^
<njin> rsalveti:^^
<rsalveti> no, I fixed at the generic use case (using a valid drm driver), we're just wondering if this didn't break anything at the nvidia side
<rsalveti> :-)
<njin> I can test it, then
<rsalveti> njin: are you using the proprietary drivers?
<rsalveti> or the nouveau one?
<njin> actually no
<njin> usually the nouveau, but not on this machine
<rsalveti> I don't remember if plymouth ever worked right with the proprietary driver
<njin> I'm going to install Ubuntu amd64 desk on that machine
<infinity> rsalveti: Hrm, strange.  After applying your debdiff and rebuilding a source package, I get a patches/debian-changes with some cruft.
<rsalveti> infinity: it's probably because the previous patches are already applied
<infinity> Oh, I might need to pop autoreconf and push the new one.
<infinity> Unclever.
<infinity> Let's see.
<rsalveti> it's because it's refreshing the old patch
<infinity> Yeah, that went better.  autoreconf patches are messy. :/
<rsalveti> always
<smartboyhw> babyface: Are you a Canonical employee or what?
<babyface> smartboyhw, yes, I'm
<infinity> I need to move my Ubuntu and Debian mirrors to a host with GigE.  Having them on my mx53 isn't bright.
<babyface> smartboyhw, are you ?
<smartboyhw> babyface: So why can't I see a Canonical or ubuntu cloak on it?
<smartboyhw> No!
<smartboyhw> Mate, my age doesn't fit to do any work
<rsalveti> infinity: well, at least you're using your imx53 for something :-)
<babyface> you mean you are too young to be employed?
<smartboyhw> Yep, I'm 14
<rsalveti> after I got the imx6, my imx53 is mostly doing nothing
<babyface> omg!  really young!
<njin> rsalveti, after published I will install amd64 desktop, do you need me to report you something ?
<rsalveti> njin: only in case you can't see the bootsplash while booting your system
<rsalveti> which is that ubuntu symbol with the animated dots (plymoth ubuntu theme)
<njin> rsalveti, ok
<babyface> welcome to do more test on ubuntu,  you know, young people brings fresh idea
<infinity> rsalveti: Right, well, the binaries come out looking sanely linked, at any rate.  That's something. :P
<smartboyhw> babyface: Yeah, I would
<infinity> rsalveti: Uploaded.
<rsalveti> infinity: :-) that's because of the nouveau patch I also had to apply
<rsalveti> due latest libdrm changes
<rsalveti> otherwise you'd get a missing symbol
<infinity> rsalveti: Was it linking to drm-nouveau2 without the patch?
<infinity> rsalveti: Or just failing to link?
<rsalveti> which also reminds me that we need to look for any software linking with the old libdrm_nouveau library
<infinity> (My assumption is that we want to switch to -nouveau2 at some point, but I really don't know what the master plan is there)
<rsalveti> it was linking, but later it was saying that it could not find all the symbols
<infinity> Fun.
<rsalveti> and continuing thinking it could be a plugin
<smartboyhw> babyface: Just finished testing Ubuntu Studio 12.04.1 amd64 build
<infinity> rsalveti: Of course, with an entirely generic interface, one would assume plymouth should eventually stop linking intel/radeon/nouveau entirely, no?
<rsalveti> otherwise it'll all break on an archive rebuild
<babyface> smartboyhw, how about it?
<smartboyhw> A pass given
<rsalveti> infinity: yup, and that's the upstream plan as well
<babyface> smartboyhw, good news! ;)
<smartboyhw> Anyway, you live in China? Looks like a Chinese name
<rsalveti> as it's now just using the drm ioctl
<babyface> smartboyhw, yes, I do.  you ?
<rsalveti> infinity: and thanks for the upload
<smartboyhw> Hong Kong here
<babyface> smartboyhw, Chinese?
<smartboyhw> Yep
<babyface> smartboyhw, oh! nice to meet you here!
 * rsalveti annoyed that flash-kernel is not updating the boot parameters properly yet
<infinity> rsalveti: No problem.  On the one hand, I want to get you and apw core-dev, so you can stop being blocked on sponsorship, on the other hand, if I stop sponsoring for you two, the quality of code I get to review will go way down.
<infinity> rsalveti: So, maybe I'll sabotage you for the sake of my own sanity.
<rsalveti> infinity: lol
<RAOF> infinity: libdrm-nouveau1 will drop out once the new mesa is uploaded; it's the final piece (assuming that plymouth now links to libdrm-nouveau2) that wasn't transitioned to the new API.
<infinity> RAOF: plymouth currently links to nouveau1a.  If you'd like to take the version just uploaded and mangle it for nouveau2 (and test that it works) to go with the new mesa and such, please do.
<infinity> RAOF: rsalveti forced it to link to nouveau1a specifically because it seemed a bit goofy (unresolved symbols) when linking to 2.
<RAOF> I believe the API is different; it's not just an ABI bump, so I'm not surprised that linking against nouveau2 fails.
<infinity> RAOF: Though, as dicussed, the ultimate goal should be plymouth not linking to any drm-* modules, so maybe that's the way forward.
<RAOF> That would be ideal, yes.
<RAOF> It should be possible to just link to libkms.
<RAOF> Touching plymouth is not one of my burning ambitions at the moment, though âº.
<infinity> With his backport of the generic interface, I assume it's just a matter of tearing out some intel/radeon/nouveu-specific bits and it would all Just Work.
<infinity> And then we'd need to adjust some seeds or other fiddly things, since plymouth will suddenly stop pulling drm-* libs into images.
<infinity> Which will end in tears.
<infinity> I assume.
<RAOF> I don't suppose libdrm will drop out of the transitively-essential set?
<rsalveti> guess the easiest way would be to disable nouveau then
<rsalveti> and make it to use the generic driver
<rsalveti> otherwise you'd need to port the plymouth nouveau plugin just to match the libdrm_nouveau 2
<rsalveti> and upstream already assumed that the way to go is with the generic driver
<infinity> RAOF: As long as we insist on having plymouth in that list, no.
<infinity> Also, argh.
<infinity> rsalveti: Looks like plymouth-theme-kubuntu-text is now provided by something other than plymouth.
<infinity> I so love when people coordinate this sort of thing..
<rsalveti> =\
<rsalveti> currently plymouth will try the generic one, radeon, nouveau and libkms
<infinity> Comes from kubuntu-default-settings now.  Grr.
<rsalveti> so we could just disable the nouveau support, hopping the generic or libkms will work as expected
<rsalveti> why would another package provide the plymouth support if it was already maintained there?
<infinity> https://bugs.launchpad.net/ubuntu/+source/kubuntu-default-settings/+bug/1005512
<ubot2`> Ubuntu bug 1005512 in kubuntu-default-settings "move kubuntu-text from plymouth to kubuntu-default-setting" [Low,Fix released]
<infinity> I'll fix that up now and close the bug.
<rsalveti> oh, ok, it's "expected"
<infinity> Yeah.  Just not by you or me. ;)
<rsalveti> :-)
<rsalveti> setting the by as incomplete doesn't help much I guess
<rsalveti> at the first moment it seems it's not really a bug
<rsalveti> *bug
<rsalveti> but, anyway, another bug to be fixed :-)
<rsalveti> time to get some sleep, back in a few hours
<infinity> 'Night.
<smartboyhw> Hi babyface
<babyface> smartboyhw, hi
<Laney> It's likely there will be no images today, fyi.
<smartboyhw> Why?
<Laney> maintenance on the hardware
<smartboyhw> OK
<njin> infinity: ubuntu amd64 server measure only 460 MB
<babyface> Laney, you mean the build server for precise desktop image are under maintaining ?
<Laney> babyface: indeed
<babyface> Laney, do you know when will it be ok?
<Laney> Afraid not
<babyface> Laney, ok, thank you for the info.
<njin> infinity, I think that is not the case to open a bug report for this or I'm wrong ?
<infinity> njin: All the server CDs seem to have gotten a lot lighter.  Not sure why.
<njin> I've run it and it retunr that cannot find live-installer
<infinity> njin: Could have just been a hiccup with kernel mismatches or something, waiting on another daily might be worth the effort.
<smartboyhw> Hmm, when will the server finish maintenance?
<infinity> smartboyhw: "sometime"... There's a massive DC move and other pain in progress.
<njin> no respin planned for today ?
<infinity> Dunno.
<infinity> We'll see what happens.
<xnox> Does anybody know fontconfig good enough to give advice on bug 1034928 ?
<ubot2`> Launchpad bug 1034928 in fonts-unfonts-core "Fontconfig warning: Having multiple values in <test> isn't supported and may not works as expected" [Undecided,Confirmed] https://launchpad.net/bugs/1034928
<ara> skaet, ping
<skaet> hiya ara
 * smartboyhw waves at skaet too
 * skaet waves good morning to smartboyhw
<stgraber> bdmurray (or any other SRU team member around): xfwm4 is the last package in the Unapproved queue to be targeted for 12.04.1 would be great to have it reviewed ASAP as we're going to start spinning candidates in 8 hours
 * smartboyhw waves at stgraber for a greeting
<Laney> xnox: Is it meant to be "or"?
<Laney> (I think so)
<Laney> so you have to duplicate the matches
<xnox> Laney: the hints are vague as to how it is currently implemented. ok. thanks. I will also check how it was fixed in the one font package it was fixed in.
<xnox> cause this bug annoys me a lot during daily cd testing!
<Laney> http://freedesktop.org/software/fontconfig/fontconfig-user.html
<Laney> Patterns which match all of the tests are subjected to all the edits.
<xnox> Error 503 Service Unavailable
<Laney> ffs, why did I refresh to check?
 * xnox giggles
<xnox> Laney: stop crashing freedesktop!
<Laney> I'm preparing a language-selector upload so don't bother fixing that one yet
<seb128> Laney, I've a fixed accountsservice ready to upload (or almost) btw
<Laney> seb128: oh cool, what was it?
<seb128> Laney, the entry in the iface table was dropped from the patch
<Laney> ah
<Laney> so I think I'll upload my l-s and the georgian font probably tomorrow
<Laney> it involves a preinst change though which always gives me fear
<seb128> Laney, and there are some code bugs in the patch that I fixed as well (side effect for the port to gdbus)
<Laney> is gunnarhj still around?
<seb128> not that I can say
<seb128> I didn't see him for a while
<Laney> yeah, me neither
<stgraber> skaet: we have a problem: http://cdimage.ubuntu.com/precise/daily-live/20120814/
<stgraber> skaet: amd64 became oversized between yesterday and today...
<skaet> stgraber,  *sigh*  :P
<micahg> that might not technically be oversized...
<stgraber> micahg: how so?
<Laney> xnox: perhaps something like http://paste.debian.net/183910/ is what I'm getting at
<micahg> CDs support 703.XXX (45?)
<Laney> not sure if it's right though, and it's not the most aesthetic
<stgraber> micahg: we're checking for the maximum possible size of a CD
<smartboyhw> Yeah, that's my question, it isn't oversized, just fit
<micahg> stgraber: ah, that was finally fixed :)
<stgraber> micahg: 736665600
<ogra_> http://en.wikipedia.org/wiki/CD-ROM#Capacity
<xnox> Laney: will that make fontconfig painfully slow, by unwinding it all like this?!
<stgraber> micahg: which gives you 702.5390625
<Laney> dunno
<Laney> you'd hope it does some caching ...
<Laney> I don't see any other way to do disjunction though
<ogra_> stgraber, according to wikipedia thats to small
<Laney> so it's either have it like this or drop it; the behaviour at the minute is undefined
<Laney> then again if it's never worked perhaps nobody cares that it's broken so we could drop it?
<ogra_> 703.125 and 737.280
<cjwatson>                         # http://en.wikipedia.org/wiki/CD-ROM#Capacity
<bjf> why are there no powerpc builders?
<cjwatson>                         # gives a maximum of 737280000; RedBook requires
<cjwatson>                         # reserving 300 sectors, so we do the same here
<cjwatson>                         # Just In Case.  If we need to surpass this limit
<cjwatson>                         # we should rigorously re-test and check again
<cjwatson>                         # with ProMese, the CD pressing vendor.
<cjwatson>                         SIZELIMIT=736665600
<cjwatson> size limit for precise with rationale.
<cjwatson> bjf: there's general chaos due to datacentre move
<bjf> cjwatson: thanks
<cjwatson> bjf: ask on #launchpad-ops (internal) if you think it's more than that
<bjf> cjwatson: we have kernels building in our ppa for the current sru cycle. should we go ahead and copy them without ppc builds?
<Laney> bah, +t
 * Laney tried to edit the topic to inform people of downtime
<cjwatson> bjf: Please don't
<bjf> cjwatson: ok, won't
<cjwatson> I don't want to have to deal with missing binaries
<bjf> cjwatson: understand, that's why i asked
<stgraber> skaet: well, looks like we no longer have our livefs builders so will have to wait a bit more to figure out what's going with the images being oversized...
<skaet> stgraber,  ack.
<skaet> :(
<stgraber> doing a manifest diff, it looks like a rebuild with the SRUs that were copied yesterday may be enough to get us back to a reasonable size, will check as soon as the machines are back online (probably being moved to the new DC)
<Laney> yeah
<stgraber> skaet: poked IS to confirm these are indeed being moved and that it's not an unrelated failure as I didn't see any email about downtime for these
<ev> jibel, skaet: RT 55370
<jibel> ev, I'll try r270. ta
<ev> jibel: thanks!
<jibel> ev, it's a bit confusing to have the same version of wubi r270 for Quantal and Precise but different binaries.
<ev> jibel: shrugs, they're different branches. There's nothing I can really do about that.
<stgraber> slangasek: still on the call?
<cjwatson> bjf: -ops speculates that we might get them back today, but not sure.
<slangasek> stgraber: yeah
<bjf> cjwatson: thanks for letting me know
 * cjwatson spies his home account auto-logging-on, and returns home on the offchance that it'll stay that way
<slangasek> ev: hey, what's the per-user crash count for today?  the graph *looks* like it's way down
<ev> slangasek: I haven't replaced the graph with the 90 day window yet. I was just about to start doing that.
<ev> because the current calculation goes up to today, it's showing a dip because we haven't had a full days set of reports yet
<ev> looking up the per user crash count for today
<ev> slangasek: there have been 46859 error reports so far today. There were 1,669,672 unique systems in the past 90 days.
<ev> You may want to factor in the percentage of the day remaining to that
<ev> yesterday there were 80399 reports
<stgraber> so that's 6.74% less reports today if we continue at this rate
<bdmurray> but keep in mind the 11th had 73329 so it varies a fair bit
<stgraber> ev: hmm, how did we get the 3.3/user/week number again, checking again now, I seem to be off by a factor of 10 when checking again today... (0.314/user/week with the numbers above)
<ev> yeah, it tends to fluctuate between 73k and 85k
<slangasek> stgraber: out of the call now
<stgraber> slangasek: ok.
<stgraber> slangasek, seb128, ev: so I think the first thing to check is what the actual number of crash/user/week is as past discussion said that we were fine with < 3 to keep whoopsie on
<stgraber> for some reason I'm not getting a number anywhere close to what we had yesterday, so I certainly did something wrong, either yesterday or today in figuring out the magic number (though I remember slangasek getting to the same result yesterday...)
<ev> http://people.canonical.com/~evand/tmp/Screen%20Shot%202012-08-16%20at%2016.14.25.png - shows the aforementioned fluctuation
<slangasek> stgraber: which calculation are you doing?
<slangasek> hmm, yes, I'm also low by a factor of 10
<stgraber> slangasek: <crash for a full day> / <number of unique systems for past 90 days> * 7
<slangasek> 80399/1669672*7 -> .33 crashes/user/week?
<stgraber> slangasek: that's getting me 0.33706 based on yesterday's number
<slangasek> right
<ev> It might be worth noting that the number of unique users is lower than it should be as not every system has a system UUID, and the code to fall back to the MAC address only landed in quantal
<ev> but have no way of guessing at the real number
<slangasek> which would bias the per-user crash count even lower
<bdmurray> should the MAC address fallback be SRUed to precise?
<ev> bdmurray: yes, definitely
<stgraber> ok, so I like that number a lot more than what we came up with yesterday
 * ev opens a bug task for that
<seb128> 0.3 issue/user/week?
<seb128> I don't believe in that number
<slangasek> that's the number we're seeing now
<slangasek> but we came up with a number 10x bigger yesterday and don't know why
<seb128> that number doesn't seem realistic
<bdmurray> crash for a full day * 90 days / number of users?
<seb128> I've more than that on any stock install test setup I did
<seb128> and that's not using the box
<seb128> just booting it and running a few apps
<slangasek> seb128: well, it can only capture the crashes that users actually report
<mpt> But it's dividing by only those machines that actually report, too, so that cancels out.
<mpt> (Mostly.)
<seb128> sure, but that seems off by a magnitude
<seb128> we didn't explain the 90% drop in number in june though
<slangasek> seb128: maybe all the crashes you've seen are one-time, first-use crashes?
<seb128> nor why some component have no bug reported where they should
<slangasek> seb128: bdmurray and I believe the drop has to do with a change in apport that broke our ability to correctly bucket the reports
<seb128> so it means it put our calculation off as well?
<slangasek> so many reports that actually match known reports are coming in with very partial data that doesn't match any of the *buckets*
<slangasek> but the overall *count* of reports is still correct
<slangasek> and we have a fix in progress; so we should see the counts bounce back up for the most-common crashes
<scott-work> has anyone else noticed that status.ubuntu.com appears to be down?
<ev> one possibility is that there are certain errors common to every system that get reported in large numbers early on in the installation. But the MaxReports of 3 kicks in and you're suddenly not reporting those anymore. So you could have a lot of reports initially and then very few to none as the weeks pass
<seb128> sorry, wifi disconnected
<ev> just a theory though
<seb128> that would assume we don't get new install and users over time
<ev> I suspect the number of new users we get is heavily weighted towards the first few days after release
<slangasek> seb128: I think that's a theory for why the per-user average, over 90 days, is lower than you expect based on the new install experience
<ev> yes
<seb128> ok, so it raises another issue
<slangasek> seb128: did you see my last comments explaining that the per-day crash count should still be accurate, even though the individual bug lines take a dip?
<seb128> the first contact those users will have will be that first week
<seb128> where the count is much higher
<seb128> slangasek, yes I did, thanks
<stgraber> scott-work: being moved to new DC
<seb128> so even if the count drop after a while we still have the issue that the first impression will be bad
<ev> seb128: I suspect those issues are also the ones that have appeared at the top of the graph
<ev> since they would have such a high initial frequency
<scott-work> stgraber: ty :)
<ev> and would thus be largely fixed for the 12.04.1 installations
<ev> but this is just speculation
<seb128> yeah, we have too much guess work and speculation there, it's hard to take an informed decision :-(
<slangasek> ev: do you recall how we did the calculation differently yesterday, that we came up with the bigger number?  I want to make sure we're not missing something
<slangasek> but, *if* we're not missing something there, our per-user average over time is clearly below the threshold seb128 and I agreed to
<bdmurray> (number of crashes per day * number of days)/(number of submitters during the period)
<ev> slangasek: no idea, sorry
<seb128> slangasek, well as said I don't trust that number, but that's not something we will resolve before .1
<bdmurray> ^- that gets you 4.337 vs the 0.3 which stgraber had earlier
<slangasek> and while we should continue driving the crash count down, it looks to me like there's no further action we should take on whoopsie for 12.04.1
<seb128> slangasek, there are other issues, like I asked early on #ubuntu-devel why gconf2 doesn't have any record for gsettings-data-convert issues where we know they are common and we get quite some bugs on the launchpad retracers side
<slangasek> bdmurray: yeah... the number stgraber and I both came up with yesterday is 3.34/week
<mpt> bdmurray, I don't understand your formula. Why are you multiplying the number of crashes per day by the number of days?
<slangasek> mpt: he's trying to reverse-engineer our buggy calculation from yesterday :)
<ev> lol
<bdmurray> seb128: what gconf2 bug is this?
<slangasek> seb128: agreed.  so let's keep poking at the edges of this thing and see if there are things we can do to further improve the user experience immediately after .1?
<ev> for what it's worth, I'm still planning on landing the aggregate error dialog - just obviously not by the 12.04.1 cutoff.
<ev> would like pitti to be back to provide code review, for a start
<seb128> bdmurray, bugs like https://bugs.launchpad.net/ubuntu/+source/epiphany-browser/+bug/945144
<ubot2`> Ubuntu bug 945144 in epiphany-browser "gsettings-data-convert crashed with signal 5 in g_settings_set_value()" [Medium,Fix released]
<seb128> that one got reassigned, but they usually are opened against gconf2 since "gsettings-data-convert" abort on broken .convert
<seb128> we have one in quantal atm on evolution
<ev> seb128: there are gconf2 problems in the database - 628 different ones.
<seb128> so I'm puzzled that doesn't show up on whoopsie
<ev> but they might not hit the threshold of the most common errors table to show up (need to have 20 instances or more)
<seb128> ev, the e.u.c ui gives me 2 lines and none about "gsettings-data-convert" here, selecting all series on a year
<ev> (I'm fixing that, for what it's worth)
<slangasek> ok, I think the conclusion is to not disable whoopsie for .1 and we'll keep improving both the UI and the reporting
<slangasek> I have to duck out now
<slangasek> thanks for the discussion, guys
<seb128> thanks slangasek
<seb128> slangasek, I'm not really happy with the conclusion and how we came to it, I just feel like it's a "we know little, let's decide to not decide and keep it as it is"
<seb128> but I guess it's late to put it in front of the TB now
<stgraber> bdmurray, infinity: can one of you two review xfwm4?
<seb128> so I will just move on, quite demotivating though
<stgraber> slangasek: thanks
<bdmurray> stgraber: I'll do it soon
<stgraber> bdmurray: thanks. I'll nag the xubuntu folks as sonn as it's in -proposed as they want it for their 12.04.1 image.
<bdmurray> seb128: I think I found some of the gesttings ones https://errors.ubuntu.com/bucket/?id=/usr/bin/gsettings-data-convert:5:g_settings_schema_get_value:g_settings_schema_key_init:g_settings_set_value:g_settings_set:handle_file
<bdmurray> ev: that looks quite odd
<seb128> bdmurray, how,where did you find it?
<bdmurray> seb128: I handcrafted the url uses the signature from http://people.canonical.com/~ubuntu-archive/apport-duplicates/sig/_usr_bin_gsettings-data-convert_5
<bdmurray> ev: there are package versions on that page
<bdmurray> er are no
<ev> bdmurray, seb128: http://paste.ubuntu.com/1150888/
<ev> the failed: ones are the retracer failing. It may be because we didn't have debs (as is sometimes the case with the launchpad retracers), or it could be the period when the 12.04 retracers weren't working due to broken oneiric entries in the sources.list)
<ev> I'll be feeding those back through the retracer, hopefully next week
<stgraber> knome: please test ^
 * stgraber locally rebuilds the chinese image to test ubiquity
<stgraber> hmm, looks like at least the livefs from yesterday didn't pull the updates from -updates... really hoping to have the builders back soon to get a clean build, hoping it was just a temporary issue caused by the DC move...
 * skaet nods
<stgraber> dobey: can you get someone to test ubuntu-sso-client and ubuntuone-installer please?
<micahg> bdmurray: if you have a minute, can you accept my sync for icedtea-web into -proposed?
<micahg> bdmurray: for natty/oneiric
<jibel> stgraber, FYI I verified FF + FIrebug crash on Precise.
<jibel> (well, I verified that it didn't crash with the version from -proposed)
<stgraber> jibel: thanks. I don't think this one will be copied for 12.04.1 though as it depends on having firebug installed which isn't part of the default install, so people installing firebug post-install will also get the updated firefox
<jibel> stgraber, ok. I think there is nothing more I can test in the pending sru list.
<jibel> for 12.04.1
<stgraber> jibel: can you maybe help with the ubuntuone-installer ones?
<stgraber> ubiquity looks good on a repacked image
<jibel> stgraber, I can verify #1004003 #1004524 #1015709. 1018991 is a general bugfix without specific test and 853060 has no test case.
<stgraber> skaet: did you hear anything back from slangasek regarding cedarview?
<skaet> stgraber, nope
<stgraber> skaet: hmm, ok... I forgot to ask him while he was still around... we basically need to know whether cedarview will be in the archive by the time we release 12.04.1, if it's, then we need to get jockey copied from -proposed
<skaet> stgraber,  ok,  I'll see if I can chase down the info from some other directions...
<dobey> stgraber: sure
<stgraber> bdmurray, infinity: considering nspr fixes a regression in -updates, can we get it copied to -updates now?
<infinity> stgraber: Depends on how nicely you ask.
<infinity> stgraber: (And done)
<stgraber> hmm, I'm actually wondering what update-manager will do as the upgrader will require removing packages on these weird precise systems
<stgraber> though at least it'll do the right thing when upgrading from oneiric, so that's already a big win
<stgraber> infinity: thanks!
<infinity> stgraber: update-manager pretty much flat out refuses to remove packages (same as "apt-get upgrade"), but there's not much we can do about that situation. :/
<infinity> stgraber: Thanfully, we didn't really have nearly as many "normal users" back in jaunty times, and even fewer "normal users" who've probably upgraded through all the releases since, so there's a fair chance that anyone in said predicament can hit a console and type "apt-get dist-upgrade", which should work.
<bjf> infinity: have the new ppc builders been ordered?
<infinity> bjf: Dunno.  Ask pgraner.
<infinity> bjf: Not that it would matter right now if they had, since the world is in transit. :P
<bjf> infinity, yup, it just made me think of it right now
<bdmurray> micahg: what is this sync?
<micahg> bdmurray: it's for the chromium regression that was accepted into precise, I wanted it to bake in -proposed before it's pushed to -security as a regression update
<bdmurray> micahg: I imagine there is a precedent for this and I just don't know about it...
<micahg> bdmurray: well, security team can generally stage updates in -proposed that should have further testing before release
<micahg> bdmurray: I'll get jdstrand to accept them, please disregard
<stgraber> skaet: missing package on the chinese media is thunderbird-locale-zh-cn, checking why it's and if there's enough space for it
<bdmurray> micahg: okay, I'm just not familiar with this
<micahg> bdmurray: sure, no problem
<skaet> stgraber,  thanks!  :)
<micahg> (it's more an AA thing than an SRU thing)
<SpamapS> Hey just checking in. Is there any need for man power today from me?
<stgraber> skaet: looks like it needs an SRU of ubuntu-defaults-zh-cn to add thunderbird-locale-zh-cn, to the Depends. I'll do that now, last chinese build shows that there's enough space on the media for it
<skaet> :)
<bdmurray> stgraber: so should the jockey in -proposed not be released?
<stgraber> bdmurray: correct, it needs to stay in -proposed until we know what's happening to cedarview
<stgraber> skaet: doh... pad.ubuntu.com is also being moved to the new DC apparently...
<stgraber> skaet: do you have a note of the chinese bugs somewhere?
<cjwatson> hmm.  I suppose it wouldn't be a good idea for me to upgrade the xorriso version in use by nusakan during .1 prep.  maybe I can upgrade it just for quantal
<stgraber> skaet: looks like I want bug 1036994
<ubot2`> Launchpad bug 1036994 in ubuntu-defaults-zh-cn "[zh_CN] Language packages not installed completely" [Undecided,New] https://launchpad.net/bugs/1036994
<stgraber> bdmurray: ^ can you review ubuntu-defaults-zh-cn?
<stgraber> only change should be the addition of thunderbird-locale-zh-cn
<bdmurray> stgraber: looking
<stgraber> bdmurray: thanks
<sbeattie> hrm, so the libotr security update awaiting approval is on the kubuntu, xubuntu, and other images. Are we frozen for 12.04.1 yet?
<sbeattie> or can libotr be accepted?
<mdeslaur> stgraber: ^
<stgraber> before 21:00 UTC is fine, we're going to be in final freeze after that
<skaet> stgraber,  looks like we've got builders again.
<Laney> still don't ping or respond to http yet
<skaet> Laney,  yeah you're right.
 * skaet misinterpreted a message - being optimistic :(
<stgraber> skaet: yeah, I'm monitoring port 80 and 22 on kapok and cardamom, ready to respin a bunch of 12.04.1 images as soon as it's back
<stgraber> oh, actually, cardamom is back
<skaet> stgraber,  based on the fact we still don't have all the builders up,  I think we're going to need to push the image freeze out to tomorrow,  doc freeze to monday.
<skaet> what time tomorrow do you think we'll get all bits sorted?
<stgraber> skaet: well, I expect kapok to be back online any minute now, so in theory we could make it to the 21:00 deadline for the image freeze (doc freeze should still be moved to Monday)
<stgraber> depends on cedarview more than on the DC stuff I think
<stgraber> because we won't be able to build real candidates until that thing is sorted
<skaet> stgraber,  agree.
<stgraber> skaet, Laney: I'm going to turn off all the cronjobs on nusakan as they're mostly failing anyway and I want to have all of nusakan for the 12.04.1 respin
<skaet> stgraber,  yes.
<stgraber> bdmurray: mythtv looks good to go (fully tested, targeted for 12.04 and 7 days old), can you release it?
<knome> stgraber, what's the testing "deadline" ?
<knome> i can do today, but if tomorrow is okay, i'll rather do that
<skaet> knome,  freeze was scheduled for 2100 today (which would have been the deadline), but due to the builder fun, it looks like we'll be rescheduling to a bit later.   Getting it tested today would be best
<knome> ok, i'll boot my machine up in the next hour
<balloons> seems the ARM builds for today are kernel panicing on reboot
<stgraber> knome: oh, I was just poking #xubuntu-devel about it ;) we're discussing moving the freeze a little, but consider the deadline as 21:00 UTC still
<knome> sure. i'll do that
<bdmurray> stgraber: okay, looking
<bdmurray> stgraber: it was at 6 days when I looked earlier ;-)
<knome> stgraber, let me confirm that it is today's daily we should test? :)
<stgraber> bdmurray: hehe, yeah, last I looked it was 6 days and 50% tested, refreshed a few minutes ago and it's all tested and 7 days now :)
<stgraber> knome: there's no build with proposed enabled, get a clean 12.04.1 system, enable -proposed and upgrade xfwm4, then test
<knome> stgraber, or, that it's in today's daily where the fix is...
<knome> aha! ok, thanks
<knome> stgraber, i'll get it tested a few times and test myself too
<bdmurray> its odd that bug 982162 has no mythtv (ubuntu) task
<ubot2`> Launchpad bug 982162 in mythbuntu "keyword missingok is missing in mythtv-backend logrotate config" [High,In progress] https://launchpad.net/bugs/982162
<stgraber> superm1: ^
<bdmurray> weird in that the approver didn't notice and that it shows up on the sru reeport - I'll still release it
<bdmurray> the task just won't get auto-closed
<infinity> bdmurray: Or you could add the right task. :P
<infinity> Oh, too late.
<stgraber> skaet: hmm, actually, moving the freeze to tomorrow won't achieve much as we don't release SRUs on Fridays...
<skaet> stgraber,  only exception that should go in after 2100 today is likely to be cedarview.
<skaet> if all the ducks line up.
<knome> quack!
<stgraber> skaet: ok, I'll need a bunch of copies before 21:00 then, most of them are still being tested as we speak
<skaet> infinity,  ^ can you help with the copies?
<infinity> I'm sure I can.
<stgraber> infinity: Please copy ubiquity, ubuntu-defaults-zh-cn and tzdata, these are the safe ones on my list (fully tested, diff makes sense, very low risk of regression).
<stgraber> dobey: what kind of testing did you do for bug 937132? I see you changed it to verification-done but didn't leave a comment and there's no testcase in the bug description.
<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,Fix committed] https://launchpad.net/bugs/937132
<infinity> stgraber: Done, done, and done.
<stgraber> infinity: thanks
<skaet> thanks infinity, stgraber.   :)
<dobey> stgraber: sorry, added a comment; verified from the diff
<stgraber> skaet: we'll probably have to accept some stuff after 21:00 UTC as xfwm4 isn't built on all architectures because of missing arm and powerpc buildds :(
<stgraber> I re-scored to make sure they build as soon as a buildd appears
<skaet> stgraber,  understood.
<skaet> stgraber,  I've done task 4 and part of 5 (will finish it when london's online tomorrow) on the release minus 7 day tasks
<stgraber> skaet: ok
<stgraber> infinity: did you make any progress on bug 1017001?
<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
<infinity> stgraber: Not yesterday, it's on my list this afternoovening.
<infinity> stgraber: Unless you've suddenly found yourself flush with free time, you're welcome to it.
<stgraber> hehe, well, I might at least try the reproducer, kind of stuck on having the DC offline for the next things on my todo...
<knome> verification-done on #1001936 !
<knome> bdmurray, stgraber, skaet ^
<stgraber> knome: thanks
<knome> np, happy to do that
<skaet> thanks knome
<knome> :)
<infinity> stgraber: Alright, in the interest of not duplicating too much effort, I'm going to attack the quantal X stack with an axe.
<stgraber> infinity: at least the reproducer works as expected
<stgraber> now to figure out how to fix it
<infinity> stgraber: Have you got a pkgProblemResolver we can unwind?
<dobey> looks like all the bugs for ubuntu-sso-client and ubuntuone-installer are verification-done now as well
<stgraber> infinity: http://www.stgraber.org/download/bug1017001/dist-upgrade/ is what do-release-upgrade left on the system after trashing it
<infinity> Hrm.  So ifupdown, initscripts, and upstart all correctly land in the same dpkg run.
<infinity> Which means this isn't an apt issue.
<infinity> If there's a loop there, dpkg should be breaking it.
<infinity> But it could be a pre-depends loop, which I suspect leads to undefined and/or broken behaviour.
<stgraber> I'll reinstall the system as there's essentially no easier way to recover it... before I do that, here's the output from a dpkg --configure -a: http://www.stgraber.org/download/bug1017001/dpkg-configure-a
<stgraber> I believe the on screen output might actually have been better than the logs, will use tee on the next run to save it
<infinity> stgraber: FYI, the jockey bug has been set back to v-needed.  I'd really like to know that someone tested it against the cedarview binaries in the archive, rather than just pseudo-tested that it's executing the right codepaths.
<stgraber> sounds good
<stgraber> infinity: full terminal log: http://www.stgraber.org/download/bug1017001/terminal.log
<infinity> I kinda wonder why udev doesn't end up in that same dpkg run.
<infinity> But it probably doesn't relate.
<infinity> It could, mind you...
<stgraber> initscripts breaks udev (<< 146-2~boot6)
<stgraber> upstart depends on initscripts and libudev0 (>= 151)
<infinity>   Version of udev on system is 151-12.
<stgraber> ifupdown depends on initscripts (>= 2.88dsf-13.3)
<stgraber> right, so these aren't the problem
<infinity> We could build a mess of pre-depends here to "fix" it, but that's almost never a good answer.
<infinity> (Like, I bet you'd find that, maybe, a completely BS pre-dep from mountall to plymouth, or similar, might magically funroll the loop)
<infinity> Oh, and indeed, there's the only Pre-Dep in the whole chain.
<infinity> Package: resolvconf
<infinity> Pre-Depends: initscripts (>= 2.88dsf-13.10)
<infinity> I wonder if that's breaking the world.
<infinity> And if it needs to.
<infinity> Hrm, changelog has a viable argument for why.
<infinity> Oh, and to be fair, that log never even gets around to upgrading resolvconf.
<infinity> Or installing it, rather.
<infinity> stgraber: Bleh.  Well, to obvious loop is between ifupdown and upstart.  What's not obvious is how to solve it.
<stgraber> infinity: the upgrade is still running but it looks like getting rid of friendly-recovery pre-upgrade works around the problem
<infinity> stgraber: That's... Curious.
<stgraber> ah, blows up later apparently, checking for the reason
<infinity> stgraber: And not particularly helpful, since it's in the standard task.
<stgraber> ok, unrelated explosion, it blows up on libgtk/libcairo/... stuff later on
<infinity> Same sort of "large unpack, then mess up the ordering" issue, or entirely unrelated?
<stgraber> good old postinst failure ;)
<stgraber> in fontconfig-config apparently
<infinity> No dbus running?
<stgraber> "failed to remove /var/lib/defoma/fontconfig.d: Directory not empty"
<infinity> That shouldn't be a failure.
<infinity> Anyhow.
<infinity> Definitely unrelated.
<stgraber> yep, that just shows me what will need fixing once the other one is fixed ;)
<infinity> Have a full terminal log of that?  Removing friendly-recovery isn't an option, but if doing so subtly changes the unpack/configure order, we might be able to sort out how to fake it.
<stgraber> sure, let me grab a tarball of /var/log/dist-upgrade
<stgraber> infinity: http://www.stgraber.org/download/bug1017001/dist-upgrade-without-friendly-recovery/
<infinity> stgraber: Hrm, that might actually tell us nothing.  It never gets around to configuring any of the problem packages.
<infinity> stgraber: Unless none of upstart, ifupdown, initscripts, etc have postinsts, which seems unlikely. :P
<infinity> stgraber: So, that was just a wildly different configuration order that broke on something else before it got around to (potentially) breaking on configuring ifupdown.
<stgraber> infinity: FWIW, after doing an rm -Rf of that directory, the upgrade happily continued without any extra error, though that's probably because it just took a different path
<stgraber> infinity: well, removing friendly-recovery and wiping /var/lib/defoma/fontconfig.d before install makes the upgrade succeed
<stgraber> s/install/upgrading/
<infinity> stgraber: Curious.
<infinity> stgraber: So, a terminal log of that successful run might be helpful, if it shows a different config order.
<stgraber> infinity: http://www.stgraber.org/download/bug1017001/dist-upgrade-success/
<infinity> Right, so that clearly shows upstart being configured earlier than everything else in the loopy mess.
<infinity> The question is why, and how can we force that situation...
<infinity> stgraber: I wonder if just changing the upstart-job dep to a versioned upstart (>= preciseish) would magically break the loop differently.
<stgraber> I can try that. It's not likely we're going to get another package to provide usptart-job anytime soon anyway
 * stgraber builds a new ifupdown and a custom upgrader to avoid wiping extra source entries
<infinity> stgraber: A less drastic but possible loop-breaker could be to Breaks: upstart (<< precise)
<stgraber> infinity: not sure I can easily drop upstart-job though, it comes from dh and is added when calling dh_installinit
<stgraber> infinity: I'll try the Breaks instead
 * infinity decides he could use a break for breakfast.
<infinity> Or whatever you call it when you've been up for 11 hours but forgot to eat.
<stgraber> infinity: looks like the Breaks made me hit the fontconfig-config bug. Will confirm once it's done upgrading and I have logs
<stgraber> if that's indeed the case, then we have a workaround and I'll just SRU a fix for fontconfig-config's postinst to do an rm -Rf and be done with that one
 * skaet thinks food is a good idea...
<infinity> stgraber: Is the rm really the right answer there?  Doesn't something own that directory that can properly clean up if you just make the failing rm non-fatal?
<infinity> stgraber: But if it's unowned, and belongs (more or less) to fontconfig-config, then yeah, that'd do.
<stgraber> infinity: yeah, checking what's in there and what owns it is on my list for my next clean upgrade, for now I just wanted that problem gone to test the other fix properly ;)
<RAOF> Oh, oh. Looks like cups 1.5.3-0ubuntu3 regressed a fix from 1.5.3-0ubuntu2. (See last two comments on https://bugs.launchpad.net/ubuntu/+source/cups/+bug/973270)
<ubot2`> Ubuntu bug 973270 in system-config-printer "Printer does not provide REQUIRED job history." [High,Fix released]
<RAOF> !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
<stgraber> infinity: so, the Breaks moved the problem away from ifupdown but the same kind of mess is now showing up with procps
<stgraber> the good news is that moving the problem although it's causing a bunch of critical looking errors during the upgrade, actually leads to an almost working system that turns into a fully working system after a dpkg --configure -a + apt-get install resolvconf
<stgraber> will upload the logs somewhere
<stgraber> infinity: http://www.stgraber.org/download/bug1017001/dist-upgrade-with-ifupdown-and-fontconfig/
<stgraber> infinity: the file in fontconfig.d is an unowned id-cache file
<stgraber> disappearing for a couple of hours
<stgraber> all the logs are at http://www.stgraber.org/download/bug1017001/
<infinity> stgraber: Still looks like a case of "upstart not configured early enough"... Ugh.
<stgraber> infinity: yeah, the new one is pretty much identical to the ifupdown one, just hitting procps
<stgraber> so I'm suspecting we'd get that until we add a Breaks to every single package containing an upstart job
<infinity> stgraber: It breaks way before procps (still an upstart-job thing, though)
#ubuntu-release 2012-08-17
<infinity> I suspect it related to upstart-job being a virtual package somehow breaking the world here, but... Meh.
<infinity> relates*
<infinity> I'll give it some more brain time to sink in
<RAOF> Oh, *urgh*. cups 1.5.3-0ubuntu2 was broken.
<RAOF> infinity: Can I get a second opinion on this: http://launchpadlibrarian.net/109781750/cups_1.5.3-0ubuntu1_1.5.3-0ubuntu2.diff.gz - you're looking at the postinst, âif dpkg --compare-versions "$2" lt-nl "1.5.3-3"; thenâ...
<RAOF> infinity: That looks like it'll break on any upgrade to cups, such as the 1.5.3-0ubuntu3 update that's
<RAOF> recently been published.
<infinity> RAOF: It certainly could, depending on the contents of said file, yeah...
<infinity> RAOF: Same broken comparison later in the postinst too.
<RAOF> I don't know how widespread the problem is, so I'm not sure quite what to do next
<RAOF> Also, baby impedes my typing speed
<skaet> RAOF,  any other evidence that folks are seeing this,   or isolated incident?
<skaet> (possible user error)
<RAOF> Still possible user error
<RAOF> The packaging *is* wrong, though
<skaet> RAOF, can you start off a new bug to track the packaging error?
<RAOF> skaet: bug #1037845 is your winner.
<ubot2`> Launchpad bug 1037845 in cups "[precise-updates] Cups 1.5.0-0ubuntu2 has incorrect postinst" [Undecided,New] https://launchpad.net/bugs/1037845
<skaet> Thanks RAOF.
<skaet> infinity,  stgraber,  any updates on when we'll be getting cardamom and kapok back on line?
<skaet> stgraber, infinity - chinese images appear to have built on the buildds now.    Am kicking off the rest of the rebuilds for precise on nusakan.
<stgraber> skaet: I'm back, looking at all the highlights. Will trigger whatever's left
<skaet> stgraber,  I've kicked off the desktop ones (executed set from pad),  if you want to do the alternates and core,  that will complete the set.
<stgraber> right, done catching up, starting a rebuild of everything (might as well)
<skaet> full desktop is already building
<skaet> all of them...
<RAOF> skaet: Ok, the poster followed up on that bug; it's still not entirely clear what's happening, but user-error is increasing in probability.
<skaet> RAOF,  thanks for following up.
 * skaet keeping fingers crossed its user error.  ;)
<skaet> just an update for anyone reading the backscroll and intersted in the state of the builds...
<skaet> full set of precise daily images is being produced and published to iso tracker right now.
<skaet> crontab has been turned back on for quantal,  so those images should be emerging as well in their regularily scheduled times.
 * skaet --> EOD
<jocarter> night skaet
<skaet> thanks.
<cjwatson> Subject: LiveFS (built by kate) ubuntu-studio-dvd/precise/amd64 failed to build on 20120817
<cjwatson> skaet: looks like a typo in the pipeline, ubuntu-studio -> ubuntustudio
<ScottK> Did the -updates regression get passed off to anyone?
<infinity> ScottK: The cups one?
<infinity> ScottK: RAOF was looking into it further to see if it might actually have just been user error.
<ScottK> Yes.
<RAOF> There's a definite chance of user-error; the user has replied on the bug that the bug they replied on is not actually the bug they were seeing. I've asked to verify that they're seeing an actual regression.
<RAOF> On the other hand, the cups postinst is *definitely* wrong.
<ScottK> Was it wrong in the previous release or is this new wrongness?
<RAOF> There was some wrongness introduced in 1.5.0-0ubuntu2
<RAOF> There was also some wrongness introduced in 1.5.0-0ubuntu1. I don't think 1.5.0-0ubuntu3 introduced any further wrongness.
<ScottK> That's all regression-update though.
<RAOF> Right.
<ScottK> My vote is fix it ASAP then.
<RAOF> I need to ask til what the practical upshot of that wrongness is; it looks like it might be as benign as needlessly deleting a cache.
<ScottK> If that's it, I guess it can wait until after 12.04.1, but since we've got a zero tolerance policy on regressions in updates it needs to be addressed.
<RAOF> Yes.
<ScottK> I updated your bug.
<ScottK> I pointed it at 12.04.1 for the moment.
<babyface> are the quantal desktop isos under building now?   still can not find them on the cdimage server
<cjwatson> You probably should expect continuing disruption there until the datacentre move is complete.
<cjwatson> i.e. check back next week.
<babyface> cjwatson,  ack. thanks for the info
<cjwatson> If you get anything today, it's a bonus. :-)
<babyface> cjwatson, hehe
<Laney> Well, looks like we have i386/amd64 buildds for the images at least.
<Laney> ah, someone recronned it
<Daviey> cjwatson: hey, would you be able to NEW review ubuntu-cloud-keyring please?
<cjwatson> Daviey: It occurred to me while I was offline: any reason this shouldn't just go into cloud-utils, which already includes a keyring?
<Daviey> cjwatson: well they serve different purposes TBH
<cjwatson> Yes, they would need to be different actual keyring files.  But is cloud-utils perhaps already installed everywhere that might want this keyring?
<Daviey> cloud-utils means installing software people potentially don't need
<cjwatson> So it isn't already installed everywhere relevant?
<Daviey> hmm
<Daviey> i didn't think it was in the server seed, but i'll double check
<cjwatson> Only cloud-image apparently.
<cjwatson> OK, so perhaps that wouldn't make a great deal of sense.
<Daviey> cjwatson: The funny thing is.. this package only really makes sense on Precise. :)
<Daviey> ie, there won't be an archive series for Quantal
<cjwatson> well, accepted anyway and you can figure out what to do with it in post-precise series later
<Daviey> cjwatson: thanks.
<mdeslaur> uhm, nspr on precise is trying to uninstall my language packs
<mdeslaur> infinity: ^
<mdeslaur> oh, hrm, I see they are obsolete packages
<mdeslaur> trouble is, update-manager refuses to uninstall packages, so some precise users will be unable to update now
<mdeslaur> slangasek: ^
<Laney> mdeslaur: I thought that was debugged in ubuntu2.2
<Laney> https://launchpad.net/ubuntu/+source/nspr/4.8.9-1ubuntu2.2
<mdeslaur> 2.2 is what's causing it
<mdeslaur> actually, update-manager seems to now handle uninstalling properly if you go through the "partial upgrade" dialogs
<mdeslaur> ok, the partial upgrade worked...so, it's not critical...just probably confusing for users
<mdeslaur> no biggie
<mvo> mdeslaur: uh, unattended-upgrades will probably hold it back too, what package is causing this? could we do something to woraround it?
<mdeslaur> mvo: it's nspr ubuntu2.2, see #1036794
<mdeslaur> oh right, unattended-upgrades...hrm, yeah, we probably need to fix it then
<mvo> mdeslaur: its ok(ish) as update-manager will at least popup on the next session
<mdeslaur> mvo: assuming the usual user of the machine who has unattended upgrades turned on actually has admin rights
<mvo> mdeslaur: yep
<stgraber> 17:04 < stgraber> hmm, I'm actually wondering what update-manager will do as the upgrader will require removing packages on these weird precise systems
<stgraber> 17:04 < stgraber> though at least it'll do the right thing when upgrading from oneiric, so that's already a big win
<stgraber> 17:04 < stgraber> infinity: thanks!
<stgraber> mvo, mdeslaur: ^
<stgraber> 17:05 < infinity> stgraber: update-manager pretty much flat out refuses to remove packages (same as "apt-get upgrade"), but there's not much we can do about that situation. :/
<stgraber> 17:06 < infinity> stgraber: Thanfully, we didn't really have nearly as many "normal users" back in jaunty times, and even fewer "normal users" who've probably upgraded through
<stgraber>                   all the releases since, so there's a fair chance that anyone in said predicament can hit a console and type "apt-get dist-upgrade", which should work.
<mdeslaur> stgraber: why jaunty? this will hit anyone who's upgraded from lucid
<mdeslaur> or natty
<mdeslaur> stgraber: I don't see how installing natty and upgrading to oneiric and precise is considered to be a "weird precise system"
<skaet> cjwatson,  thanks for sorting the typo and respinning up the images for ubuntu studio.  Have fixed it in the ubuntu-release pad now.
<cjwatson> skaet: I didn't respin
<xnox> "* lamont fires off the  buildlive command and watches|
<xnox> at like 1am today, not sure if it is related.
<stgraber> xnox: unrelated
<xnox> stgraber: oh well... =)
<stgraber> skaet: rebuilding
<Laney> was me, sory forgot to mention
<stgraber> Laney: oh well, they'll have two rebuilds then ;)
<Laney> makes them twice as good
<Laney> it was 10ish UK
<skaet> thanks Laney.
<lamont> mdeslaur: if "installing an old release and upgrading to each new release as it comes out, with the upgrader" is considered a "weird and unsupported system", then we hate our installed base and should all be shot in the head
<lamont> stgraber: ^^
<mdeslaur> the original problem only occurred to systems that were upgraded from jaunty, but the fix that went in now triggers an issue for people coming from lucid or natty
<stgraber> mdeslaur: hmm, I think we somehow missed that language-support-en was only removed in oneiric... the initial problem was with language-support-translations-en which was indeed deprecated after jaunty
<mdeslaur> stgraber: yeah, that makes sense
<stgraber> slangasek: what was the reason for also breaking against language-support-en? I vaguely remember language-support-translations-en being the real problem here
<mdeslaur> stgraber: so this is going to hit a _lot_ more users than you had planned
<stgraber> mdeslaur: yeah, will check with slangasek for the reason of the breaks against language-support-en, we might get away with re-SRUing another update breaking only language-support-translations
<stgraber> but slangasek rarely does something without a very good reason, so we'll see...
<mdeslaur> stgraber: yeah, isn't that annoying? it makes the rest of us look bad :)
<stgraber> mdeslaur: so, from a UI point of view, what's happening to the user at the moment? do they have to go to a terminal to force a dist-upgrade or can they somehow do it from update-manager?
<mdeslaur> stgraber: update manager will give a scary dialog that says updates can't be installed, and suggests trying a partial upgrade
<mdeslaur> you then go through a few dialogs that asks to remove packages, etc.
<mdeslaur> stgraber: if you use unattended-upgrades, it stops working
<mdeslaur> stgraber: ie: if someone changed their preferences to automatically install updates, or in a corporate environment
<stgraber> right, though in my experience unattended-upgrades stops working every month or so (whenever there's a potential conffile prompt), so users should be used to doing a standard upgrade from time to time
<mdeslaur> stgraber: there shouldn't be any conf file prompt on normal desktop systems
<mdeslaur> stgraber: or rather, no conf file changes in security updates and srus
<mdeslaur> mvo: what happens to unattended-upgrades if there are conf file changes? so it keep those packages back, or does it default to something?
<stgraber> keeps them back
<mdeslaur> stgraber: so the other updates still get installed?
<stgraber> I mostly see that on my servers/containers with updates like apache
<stgraber> yeah, it usually updates as many as possible
<mdeslaur> stgraber: I believe the partial upgrade situation grinds unattended upgrades to a half
<mdeslaur> halt
<mvo> mdeslaur: by default keeps it back and notifies about it
<mvo> mdeslaur: all the ones that can be installed wil lbe installed
<mdeslaur> mvo: ok, and in the partial upgrade scenario, it just aborts?
<mvo> mdeslaur: it will skip the package that requires the removal but upgrade everything else
<mdeslaur> mvo: oh, good, that's not as bad as I thought
<mdeslaur> thanks mvo
<mvo> yw
<mpt> stgraber, mvo, if you can figure out a safe way to verify that yes, this upgrade really should remove a package, please do so ... I hate that partial upgrade dialog with a passion
<mpt> (bug 955022)
<ubot2`> Launchpad bug 955022 in update-manager ""Not all updates can be installed" requires a decision most people can't make" [Medium,Confirmed] https://launchpad.net/bugs/955022
<mvo> I wonder if we could add some metadata, something like "XB-Removal-Ok: old-package-that-really-really-can-go-away"
<mvo> i totally agree with the bugreport fwiw
<stgraber> slangasek, mdeslaur: I uploaded a new nspr to -proposed removing the language-support-LANG Breaks, only keeping the language-support-translations-LANG ones. I'm not sure that'll work, but at least we'll have it in the queue if it does.
<stgraber> mvo: I think extra metadata on the binary package would be reasonable. That way when we add a Breaks in a SRU we can just add it there too and give a good upgrade experience to the users.
<mpt> mvo, and in <https://wiki.ubuntu.com/ReleaseUpgrades> I included a "These applications conflict and must be removed:" list that could take care of the rest.
<mdeslaur> stgraber: that would help with security updates too, we've been doing some crazy things to prevent package removals in security updates
<mvo> in preparation for a sru it would be great if the build score for https://launchpad.net/~mvo/+archive/freeglut-multiarch could be raised
<stgraber> mvo: rescored the individual builds
<mvo> mdeslaur, stgraber: that actually makes me wonder if security updates simply should always trump and allow removal, but I guess its safer if we have a allowed-removal list - do you have a good example case where htis is used/needed?
<mvo> stgraber: \o/
<stgraber> mvo: hmm, I'm wondering, could we get away with a breaks/provides/replaces kind of thing or would that still lead to partial upgrade?
<mvo> stgraber: currently I think any removal will cause it to be defensive :/
<mdeslaur> mvo: this was an example I can think of: http://launchpadlibrarian.net/36531850/bind9_1%3A9.4.2.dfsg.P2-2ubuntu0.3_1%3A9.4.2.dfsg.P2-2ubuntu0.4.diff.gz
<mdeslaur> wow, 2009, back when I was young and fresh-faced
<jocarter> ah those were the days
<mvo> mdeslaur, stgraber: but I think you have a point about using conflicts/provides/replaces, it could similar honor that and we don't need a extra field or am I missing something?
<mvo> mpt: thanks for the spec link
<stgraber> mvo: both seem equally ugly, so I guess we might as well support conflicts/provides/replaces as it's already part of the standard :)
<slangasek> stgraber, mdeslaur: were lucid and natty actually installing language-support-en?  It hadn't been revved since karmic, and AIUI was supposed to have been obsolete as well.  I didn't miss that it was still present in natty, but didn't anticipate that forcing its removal on upgrade would cause problems.  Is this actually a problem when dist-upgrading?  Or only when trying to install the SRU?
<mdeslaur> slangasek: my laptop was installed with natty, and I had it installed
<slangasek> hmm.
<stgraber> slangasek: dist-upgrade isn't a problem, it's just causing the problem for people on precise with language-support-LANG
<slangasek> ok, then it was less obsolete than I believed, sorry
<stgraber> slangasek: do you expect any problem by removing these from the Breaks?
<slangasek> stgraber: so we need to test whether the Breaks: on language-support-$thingy-en is enough to get the right lucid->precise upgrade path
<slangasek> there's a *possibility* of problems if we leave those out
<slangasek> because apt may go "oh, language-support-en is broken, let's try readding language-support$thingy-en" and it'll cascade from there
<stgraber> slangasek: right. If you can review my upload to -proposed and accept it, I have a VM I can use to test the new package
<mvo> fwiw https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1038113
<ubot2`> Ubuntu bug 1038113 in update-manager "support conflicts/provides/replaces and allow removal in this case" [Undecided,New]
<slangasek> mdeslaur: fyi, my system was installed as lucid and I don't have language-support-en installed
<slangasek> so I don't think "anyone who has upgraded" is accurate
<mdeslaur> slangasek: hrm...isn't that the metapackage that gets installed by the language support tool? I usually install in english, and install french using the language tool for testing
<stgraber> slangasek: I guess we should SRU a new update-manager (can be post-12.04.1) adding these to the obsolete list so the dist-upgrader takes care of removing them
<mdeslaur> I'm not quite sure why I had it installed
 * mdeslaur fires up lucid vm
<stgraber> mdeslaur: can you kill one of the security builds on PPC? they just came back to life and we need to have two SRUs built in the next hour or so (if we want them to make it by the time we freeze)
<mdeslaur> slangasek: my pristine lucid vm that's installed using preseeding has language-support-en installed
<slangasek> mdeslaur: ok, my mistake
<stgraber> I scored them at 9000 in the past but apparently that wasn't enough to get in front of your security builds... I now bumped to 50000 which should ensure I get the buildd as soon as one of the two security builds disappear
<jdstrand> stgraber: those will be done within that time frame
<stgraber> jdstrand: good, was affraid it was libreoffice, kernel or some other fun things like that
<jdstrand> no
<jdstrand> there are a lot of things queued, but they shouldn't take long
<stgraber> well, with my last rescore, I should get ahead of these anyway
<stgraber> (IIRC private PPAs get 15000 and I rescored at 50000)
<stgraber> mdeslaur, slangasek: confirmed that a clean 10.04.4 + updates comes with language-support-en and language-support-writing-en
<slangasek> well, then I guess the alternate CD doesn't do this correctly and it's yet another reason to get rid of the alternates :)
<ScottK> Is anyone on the cups regression in -updates?
<stgraber> slangasek: running a test upgrader with a locally built nspr
 * cjwatson tries to think of a way to do an HFS+ mount as root during image building
<cjwatson> the hfsplus tools are just complete no-hopers :-(
<cjwatson> I wonder if I could abuse the fact that bits of livecd-rootfs run as root
<cjwatson> lamont: do the livefs builds have specially trimmed-down kernels, or is it possible that I might be able to do mount -t hfsplus?
<lamont> Linux kapok 2.6.32-42-server #95-Ubuntu SMP Wed Jul 25 16:10:49 UTC 2012 x86_64 GNU/Linux
<lamont> cjwatson: does that clarify things?
<lamont> it's not particularly cut back other than being lucid
<cjwatson> So basically a normal Ubuntu kernel image
<cjwatson> I might just about be able to wedge something useful out of that
<stgraber> slangasek: upgrade succeeded
<stgraber> slangasek: I'll grep through the logs to ensure it used the new nspr though :)
<stgraber> slangasek: no mention of -1ubuntu2.2 in the logs, only of -1ubuntu2.3 so that looks like a success
<stgraber> will mark the bug verification done
<stgraber> jibel: can you re-trigger the jenkins upgrade for 12.04.1 (these with -proposed enabled)?
<stgraber> want to check we don't get any regression with the nspr in proposed
<jibel> stgraber, started profiles desktop, server, server-tasks for lucid and oneiric. main and universe are scheduled to start in 90min
<stgraber> thanks
<slangasek> stgraber: great, thanks!
<stgraber> slangasek: I think we should copy directly to -updates once we have the result from Jenkins. I know it's Friday but I don't see how that change can make it any worse ;)
<slangasek> stgraber: agreed, this is effectively an SRU regression
<slangasek> speaking of which, let me catch up on this cups thing
<stgraber> knome: so, xfwm4 is finally built on all architecture. Do you guys want it pushed to -updates today so it makes it by freeze time (in 30 minutes) or do you prefer to wait until Monday, meaning the Xubuntu images built today won't be true candidates.
<stgraber> oops, forgot to rescore nspr on powerpc... done now, should be built soonish
<slangasek> ScottK: I'm confused by bug #1037845; we're never going to have 1.5.0-3 in precise-updates, true, because the version in precise is already greater than this
<ubot2`> Launchpad bug 1037845 in cups "[precise-updates] Cups 1.5.0-0ubuntu2 has incorrect postinst" [High,Confirmed] https://launchpad.net/bugs/1037845
<ScottK> slangasek: Isn't 1.5.0-0ubuntu2 < 1.5.0-3
<slangasek> ScottK: certainly, but that's not the version we have in precise
<slangasek>       cups | 1.5.2-9ubuntu1 |       precise | source, amd64, armel, armhf, i386, powerpc
<slangasek>       cups | 1.5.3-0ubuntu3 | precise-updates | source, amd64, armel, armhf, i386, powerpc
<ScottK> Both of which are < 1.5.3-3
<ScottK> So I'm now confused about your confusion.
<stgraber> ScottK: you just said < 1.5.0-3 (15:34 UTC)
<ScottK> Can't type
<ScottK> Meant that.
<ScottK> Oh.
<ScottK> Can't read either.
<cjwatson> You're sorted, then.
<ScottK> Yeah.
<ScottK> RAOF: ^^^ so that's not the problem.
<stgraber> right, the condition will never match, so not a problem
<ScottK> Yeah.
<ScottK> There's still apparently some undiagnosed issue with Bug 973270
<ubot2`> Launchpad bug 973270 in system-config-printer "Printer does not provide REQUIRED job history." [High,Fix released] https://launchpad.net/bugs/973270
<cjwatson> balloons: do we have any non-zero number of currently-engaged community Mac testers?
<slangasek> in which the commenter says his bug is probably actually bug #995111
<ubot2`> Launchpad bug 995111 in cups "Print failure since upgrade to 12.04" [High,Fix released] https://launchpad.net/bugs/995111
<cjwatson> balloons: I am in the middle of an evil plan, but it only works if I can get it validated on some Macs
<balloons> cjwatson, by mac do you mean ppc or amd64mac?
<ScottK> We have one, sometimes two for Kubuntu.
<cjwatson> balloons: the latter
<ScottK> shadeslayer: ^^^
<balloons> k.. then yes, we have some
<cjwatson> ideally a range of models
<shadeslayer> sec, need to read the backlog
<balloons> I know at least one persn with a imac and a couple with macbook pros
<shadeslayer> cjwatson: hey hey, I have a mac :)
<shadeslayer> I was told that the amd64+mac iso was there because the standard ISO can't boot on some machines
<stgraber> cjwatson: if you just need to boot a media to check the xoriso change, I can probably borrow jocarter's mac ;)
<cjwatson> stgraber: well, I did commit a preliminary change earlier today yes, but that's not the whole thing
<shadeslayer> I also have a technique that allows you to EFI boot the ISO using GRUB's loopback mechanism, though I haven't documented it anywhere
<cjwatson> so I'm working on incorporating something that's roughly equivalent to the technique used in Fedora
<shadeslayer> \o/
<cjwatson> I'm having to be a bit creative, because the Fedora approach relies on being able to loop-mount a filesystem as root
<stgraber> oh, that explains the hfsplus question ;)
<cjwatson> I *think* that if I rely on all the features of xorriso 1.2.4 that I can lay my hands on and run it twice, I can work around that
<cjwatson> (because it has code to generate ISO9660/HFS+ hybrid filesystems, and I can by definition presumably rely on that being readable as HFS+)
<shadeslayer> cjwatson: any plans for the install stage ?
<cjwatson> what I'll want to do is generate a test ISO and get people to boot it on as many Macs as possible, and find out (a) whether it boots at all (b) what the boot screen looks like (c) whether it boots as BIOS or UEFI (d) what ubiquity does as a result
<slangasek> ev: errors still gives timeouts for all the lists... what's the status of breaking out the launchpad bits?
<shadeslayer> I'm particularly interested in d)
<ev> slangasek: RT 55342
<cjwatson> I will probably need somebody with hardware to work on that
<cjwatson> but hopefully the answer can be that it just does an EFI install
<ev> slangasek: webops is in the middle of a datacenter move this weekend, so getting deployments out is unlikely to occur before monday
<shadeslayer> cjwatson: oh and fwiw, there's a bug in X where it tries to address out of bound memory under EFI boot
<shadeslayer> ( macbook pro 8,2 )
<cjwatson> well that's unfortunate, perhaps you could harass the X people?
<balloons> cjwatson, ohh. awesome.. so this would let us drop the amd64+mac iso?
<slangasek> ev: phooey, escalating
<balloons> if so.. you better believe I'm all for helping make it happen :-)
<slangasek> ev: why are we not being all devops on this? :)
<cjwatson> balloons: that's the intention, but it relies on quite a lot of bits
<ev> slangasek: :)
<shadeslayer> cjwatson: one just needs to put this into xorg.conf : http://paste.kde.org/536090
<shadeslayer> but yeah, the X people would know
<cjwatson> shadeslayer: X needs to auto-figure-that-out by default, then
<ev> slangasek: charms of the infrastructure are in progress, but so are lots of things
<shadeslayer> *nod*
<cjwatson> we aren't going back to the bad old days of writing xorg.conf
<cjwatson> especially not during live CD boot :)
<shadeslayer> hehe :)
<balloons> cjwatson, yes.. let's put up an image, and I'll put together a mini call for testing specific for mac users
<ev> I do miss hand rolled mode lines
<cjwatson> slangasek: ^- FWIW the other purpose of this plan is making EFI USB hybridisation work
<shadeslayer> just saying that just getting EFI boot is not enough ;)
<cjwatson> slangasek: I think the change I committed to debian-cd earlier today should take care of that
<cjwatson> shadeslayer: yeah, I know, but I suspect it's a more viable forward path
<cjwatson> balloons: before doing that, I think I'd like to work with one or two people like shadeslayer directly - since otherwise if it's completely broken I'll be swamped
<slangasek> cjwatson: yes, I'm sitting here cackling gleefully at the discussion :)
<shadeslayer> :)
<shadeslayer> feel free to ping when you have a ISO, it'll take a bit of time since my connection is a bit slow, but I can surely help
<cjwatson> it'll take even longer to squeeze up my connection, I expect
<shadeslayer> ^_^
<cjwatson> shadeslayer: do I recall correctly that your Mac(s) boot the amd64 images natively?
<cjwatson> as EFI?
<shadeslayer> cjwatson: yes
<cjwatson> I mean, leaving aside X and installer troubles
<shadeslayer> I can even install it, just need to pre partition the disks
<cjwatson> OK; ideally I'd also like coverage from systems that don't, but perhaps that can be the second stage
<shadeslayer> cjwatson: however, if I write the image to a usb, the system doesn't boot the USB
<shadeslayer> I have to take special measures to partition the USB, write grub efi to the USB, etc
 * xnox managed to boot EFI usb sticks, if in Mac OS X I wrote into nvram that the usb stick is blessed for next boot only
<balloons> cjwatson, yes,. I wouldn't push it out to tons of people
<balloons> I have a couple in mind I would ask directly
<cjwatson> shadeslayer: Most of that may just be hacks in the installer to try to avoid doing things on Macs that previously didn't work
<shadeslayer> ah :)
<shadeslayer> cjwatson: any progress on the lb merge?
<seb128> infinity, hey, did you break nvidia users on purpose by moving the xorg stack from quantal-proposed to quantal? ;-)
<seb128> infinity, e.g did you know there was issues with nvidia?
<shadeslayer> seb128: not to mention ATi users  :P
<seb128> ATI users can use the ati driver
<seb128> it's harder to use nouveau
<cjwatson> shadeslayer: not as yet sorry
<shadeslayer> card too new
<shadeslayer> cjwatson: ah ok ... because my merge is a bit screwed up, the iso it builds doesn't boot, doesn't have a boot/preseed/other files and folders
<shadeslayer> just isolinux and casper :P
<balloons> cjwatson, ping and send me the link as well
<balloons> I'll onboard a couple folks to test
<cjwatson> balloons: I'll let you know when I'm ready; I'd prefer to work with a single person initially
<balloons> cjwatson, yes.. don't want to overload
<slangasek> ok, why in the world am I looking at bug #837054
<ubot2`> Launchpad bug 837054 in ubuntu-geonames "Time Zone selection shows about 20 different "New York"s and doesn't autoselect my location" [Medium,Confirmed] https://launchpad.net/bugs/837054
<xnox> slangasek: because it takes time to scroll past New York, before you get to 17 Portlands?
<ogra_> slangasek, because plan moving to new york and want to know about the dangers in advance ?
<slangasek> xnox: no... someone must have mentioned this bug somewhere, but I've now lost track of the reference
<skaet> dobey, we're contemplating  letting ubuntuone-installer, ubuntuone-sso-client in to 12.04.1 without 7 day period in proposed?   what is the testing confidence like,  how great is the regression risk?
<skaet> slangasek, stgraber, Daviey, ^
<infinity> seb128: Blame tjaalton, he's the one who told me it was good to go.
<slangasek> Riddell: can you please do qt4-x11 uploads to quantal-proposed, not to quantal?  As a core library, architecture skew has an impact on multiarch installability of the dev release
<seb128> infinity, I though it was clearly flagged last week that nvidia was broken :-(
<dobey> the risk is minimal i think. there's basically no risk for  ubuntu-sso-client. there's a little more risk with  ubuntuone-installer as the main fixes are basically an invasive  behavioral change (not ignoring errors where we once were  before), but i don't think there should be any new crashes in  installer as it should just show the errors in the UI now and let  the user retry or cancel
<Riddell> slangasek: mm right, yes
<slangasek> skaet: is that informational only, or is there a question for me?
<slangasek> Riddell: ok, thanks :)
<skaet> slangasek, for information only,  and a chance to raise concerns ;)
<ScottK> When did it become a policy that only X updates with binary only support were allowed in the development release?
<Riddell> slangasek: when uploading to -proposed is there a convenient way to remind yourself when it's ready to be copied over or do you just have to check back lots?
<ScottK> infinity: As far as I can tell it was 'ready'.
<slangasek> Riddell: I think infinity has made the copies his problem :)
<skaet> thanks dobey,  stgraber,  you ok with including it too?
<stgraber> I still want to look at errors.ubuntu.com first, but if nothing bad showed up there (when it eventually loads ...), we should be good
<slangasek> stgraber: per-package reports should still load I think
<infinity> Riddell: Yeah, until the automation is all sorted, I just look at the list occasionally, it's not rocket surgery (except when people decide to stage a large transition there).
<skaet> stgraber,  how much time with errors.ubuntu.com before it makes sense to spin the first set of images?
<stgraber> skaet: I'm looking at it now. Other issue is cedarview... at this point if we want candidates, that means they'll miss .1
<stgraber> skaet: as they haven't been tested
<infinity> stgraber: All it takes is verifying jockey DTRT by one person.  Surely, someone with hardware in, say, PES, can make that happen. :P
 * infinity pokes jmleddy again.
<infinity> Or, rather, I would poke him, were he online.
<infinity> I'm going to think really hard about poking him and see what happens.
<stgraber> skaet: ubuntu-sso-client looks good, no spike on the release in -proposed
<stgraber> skaet: nothing scary for ubuntuone-installer either
<stgraber> skaet: so these two are good to go I think
<stgraber> still waiting on knome for xfwm4
<dobey> awesome
<stgraber> slangasek, infinity: can one of you please release ubuntu-sso-client and ubuntuone-installer?
<stgraber> I'll keep monitoring errors.ubuntu.com for the next 5 hours in case we missed something
<infinity> stgraber: Sure.
<slangasek> stgraber: what's our rollback plan if there are problems?
<slangasek> because we can't assume there will be time to fix any regressions before 12.04.1
<stgraber> slangasek: re-upload of former version with an ugly version number
<slangasek> dobey: ^^ you're ok with that rollback plan in the event of a regression?
<dobey> i guess so
<slangasek> ok
<slangasek> infinity: pull the trigger (if you haven't already) :)
<infinity> slangasek: I can pull it again, if you like echoes.
<slangasek> nah
<knome> stgraber, for what?
<knome> stgraber, ah, today works if you can do it. :)
<stgraber> knome: are you happy with the same plan as dobey? that's if anything breaks in the new xfwm4 we simply revert to the previous version for 12.04.1?
<knome> stgraber, sure. i don't expect anything to break though :)
<slangasek> stgraber: https://errors.ubuntu.com/?launchpad=false for more reliable loading
<stgraber> slangasek: yay!
<stgraber> infinity: based on the above, can you also release xfwm4 please?
<knome> stgraber, infinity: thanks
<skaet> stgraber, sounds good.
<infinity> stgraber: Copied, BTW.
<stgraber> thanks
 * slangasek reopens bug #734376 for seb128_ 
<ubot2`> Launchpad bug 734376 in jockey "jockey-gtk crashed with DBusException in call_blocking(): org.freedesktop.DBus.Error.NoReply in shutdown()" [High,Triaged] https://launchpad.net/bugs/734376
<seb128_> slangasek, thanks, I wish we had a maintainer for jockey :-(
<slangasek> seb128_: no one on desktop team is maintaining it?
<seb128_> slangasek, same as that half a dozen list of unmaintained component that get most of the top issues atm that I listed on one of my -release emails
<seb128_> slangasek, no, in fact it's deprecated in quantal, the only one who ever really worked is pitti and I think he lost interest for it, especially since he move to Qa
<stgraber> jibel: how are the Jenkins tests going?
<seb128_> slangasek, same as update-manager, update-notifier, sessioninstaller, etc
<infinity> "Deprecated in Quantal" is no reason to not maintain it in previous LTSes...
<slangasek> seb128: incorrect; update-manager and update-notifier are maintained by the foundations team
<seb128> slangasek, ok, so jockey is "maintained" as well ;-)
<seb128> it's as maintained as update-manager and update-notifier are
<slangasek> seb128: I'm not handwaving definitions here.  Foundations ported update-manager and update-notifier to python3, and we've fixed the top crashers for them in 12.04.1.
<slangasek> they're on the list of packages owned by foundations, and we're responsible for keeping them in working order
<slangasek> I would expect the same to be true for desktop and jockey
<stgraber> slangasek: did you have a chance to look at the logs I posted at http://www.stgraber.org/download/bug1017001/ ?
<stgraber> slangasek: based on the discussion with infinity yesterday it seems to be linked to upstart-job being virtual (provided by upstart) and that somehow messing with the resolver
<slangasek> stgraber: I've looked at them but they don't really give me any more insight on how to resolve this
<slangasek> stgraber: what does apt-get with the -o debug::pkgResolverThingie option show?
<seb128> slangasek, desktop maintains it, I don't think we have suffisant resources to do a good job about it
<stgraber> slangasek: well, that's the problem, I have no idea how to get apt-get to run manually... as it requires the backported stack
 * skaet --> lunch,  biab
<slangasek> stgraber: oh, indeed :/
<ScottK> Need help on a licensing question in New.  print-manager is GPL-2+, but there is one file that has a code snipped copied from cups 1.4.2 which is LGPL-2 only with openssl exception.  I believe that's distributable under GPL-2 only, but I'm not sure (needs some Debian copyright fixes in any case, but I want to give proper feedback).
<slangasek> ScottK: yes, the intersection of those licenses would be GPL-2 only
<ScottK> Thanks.
<stgraber> slangasek: precise-upgrade-oneiric-desktop looks good, will wait some more to get testing results for lucid too
<slangasek> stgraber: that's for the nspr regression test?
<stgraber> yeah
 * slangasek nods
<jibel> stgraber, oneiric desktop passed but there is no language-support-* and lucid desktop with -proposed enabled picked nspr 4.8.9-1ubuntu2.2. I'll restart it
<jibel> stgraber, I'll do a manual verification after diner with the packages that caused problem
<stgraber> jibel: thanks
<jibel> I could reproduce the unmet dep issue when upgrading from oneiric, I'd like to verify that the fix is still valid.
<slangasek> hmm, strange profile on this crash. https://errors.ubuntu.com/bucket/?id=failed%3A%2Fusr%2Fbin%2Findicator-weather%3A11%3Ax86_64%3A%2Flib%2Fx86_64-linux-gnu%2Flibglib-2.0.so.0.3200.3%2B1cf08%3A%2Fusr%2Flib%2Fx86_64-linux-gnu%2Flibdbusmenu-glib.so.4.0.13%2Baca2%3A%2Fusr%2Flib%2Fx86_64-linux-gnu%2Flibdbusmenu-glib.so.4.0.13%2Bcafa%3A%2Flib%2Fx86_64-linux-gnu%2Flibglib-2.0.so.0.3200.3%2B47d53%3A%2Flib%2Fx86_64-linux-gnu%2Flibglib-2.0.so.0
<slangasek> ... a0%3A%2Flib%2Fx86_64-linux-gnu%2Flibglib-2.0.so.0.3200.3%2B4849a%3A%2Fusr%2Flib%2Fx86_64-linux-gnu%2Flibgtk-x11-2.0.so.0.2400.10%2B1342f7%3A%2Fusr%2Flib%2Fpython2.7%2Fdist-packages%2Fgtk-2.0%2Fgtk%2F_gtk.so%2B1ac046%3A%2Fusr%2Fbin%2Fpython2.7%2B9890a%3A%2Fusr%2Fbin%2Fpython2.7%2B98602%3A%2Fusr%2Fbin%2Fpython2.7%2B9f1c0%3A%2Fusr%2Fbin%2Fpython2.7%2Ba9081%3A%2Fusr%2Fbin%2Fpython2.7%2Ba9311%3A%2Fusr%2Fbin%2Fpython2.7%2Baa8bd%3A%2Flib%
<slangasek> ... x-gnu%2Flibc-2.15.so%2B2176d
<slangasek> also, a lovely url
<slangasek> indicator-weather had a recent SRU... but the crashes don't seem to be tied to the SRUed version
<slangasek> yet they appear to have only started happening recently
<infinity> slangasek: Recently?  That crash has been happening in pretty much every version, no?
<infinity> slangasek: If the frequency has gone up recently, I would contend that it's a direct result of the SRU being successful.
<infinity> slangasek: (ie: now that indicator-weather isn't crashing in the other fashion, it runs long enough to break in this old and familiar way)
 * skaet ->back
<slangasek> infinity: the graph shows it's only been happening since July 31
<slangasek> I don't know why that should be
<slangasek> infinity: ah... possibly because there was a previous SRU on July 30
<slangasek> so in fact, this is a new crash only since the first SRU, which was not published to -updates
<infinity> I don't see an SRU on Jul 30... I see an upload to quantal, though.
<slangasek> 11.11.28-0ubuntu1.1 has a 30 Jul 2012 changelog entry
<infinity> Yeah, but it wasn't accepted until 08-04
<slangasek> didn't get published until the 3rd though
 * slangasek nods
<slangasek> also, the *versions* it's reported in include the one from precise release
 * slangasek thinks it's time for us to get better tooling for auto-analyzing regressions
<infinity> Hrm.  So, if the graph curve is useful here, I assume we're looking for something that entered proposed around 07-30, and hit updates around 08-08...
<slangasek> and is related to unity and/or indicators, most likely
<infinity> Maybe.
<infinity> Or hit quantal at similar times, messing with the graph.
<slangasek> the version breakdown shows nearly all of it is with precise versions of the indicator-weather package
<slangasek> (in fact, indicator-weather first revved in quantal on Jul 30)
<infinity> Indeed.  In fact, the i386 version of the same trace doesn't have any quantal versions.
<infinity> And has pretty much the same curve.
<infinity> That was an awfully quick NEW review...
<seb128> yeah, we do pre-upload reviews
<seb128> so it's just checking that the upload matches the preupload version :p
<skaet> slangasek,  the bugs associated with the cedarview drivers are not inspiring confidence that anyone's actually verified them.  Who is supposed to be doing the checking?
<slangasek> skaet: jmleddy, and no, no one has actually verified them yet
<slangasek> infinity and I have both sent nagmails today
<slangasek> skaet: we appear to have cc:ed you, for that matter ;)
<skaet> slangasek, yes, but was hoping it had progressed since that email ;)
<slangasek> nope
<skaet> :(
<skaet> slangasek, stgraber, what's the risk like on npsr?  looks like its verified now.
<stgraber> skaet: waiting for Jenkins
<skaet> and is there anything else we want to consider for 12.04.1 candidate images?
<stgraber> though the test runs might be done now, in the middle of a pretty tricky lxc merge, will check after that
<stgraber> skaet: cedarview...
<slangasek> I think those are the only two to consider
<slangasek> and I think that if nobody is testing the cedarview today, it should be off the table
<skaet> stgraber,  cedarview hasn't been tested yet,  so if they don't get to by the time everything else is ready, I see no point in holding up on them now.
<skaet> slanagasek,  agreed.
<slangasek> let me see if I can raise vanhoof
<skaet> thanks slangasek,  I've put a ping into jmleddy
<skaet> other thing I'm worried about with them, at this point, is that with the rest of the data center shifting tomorrow,  if theres something serious we may not hear about it.
<skaet> ScottK,  did you start off an incident report earlier about the cups?
 * skaet just cross checked and looks like its not user error. :/
<ScottK> skaet: I did not because RAOF was the first man on the scene.
<slangasek> skaet: oh, where did you find jmleddy that he was pingable?  He doesn't seem to have been on IRC
<skaet> ScottK,  yes, but it was ambiguous as to whether it was user error or not and we didn't hear back until this morning when he's zzzing
<ScottK> Agreed.
<ScottK> I went to sleep not knowing.
<ScottK> Someone should grab Til and shake him until we have an answer.
<ScottK> BTW, just did a successful 10.04 -> 12.04 server upgrade.
<jibel> stgraber, skaet manual verification from oneiric to precise and lucid to precise with nspr 4.8.9-1ubuntu2.3 is ok.
<jibel> calculation of the upgrade is successful, language-support-translations-en is removed during upgrade.
<jibel> for oneiric if evolution-plugins/natty and evolution-common/natty are installed, evolution is installed during the upgrade instead of blocking it.
<skaet> :)  glad to hear upgrade smooth, ScottK
<jibel> I'm currently testing a dist-upgrade on precise with language-support-*-en installed
<skaet> Thanks jibel.  :)
<jibel> automated test ran for desktop, server and server-tasks for lucid and oneiric to precise and nothing found.
<skaet> even better news.  :)
<slangasek> skaet, ScottK: the only end user reporting a regression in cups in precise-updates clarified later that his symptom matches an existing bug report related to USB-connected printers that has been present all along - possibly intermittently so
<skaet> slangasek,  ping'd in a stale PM session it appears.  :P
<slangasek> skaet: right ;)
<ScottK> OK.  That's good to know.
<skaet> slangasek,  not sure if incident report makes sense or not given the limited scope.   If its matching a known bug, am tempted to just let it follow regular flow rather than incident report it.    But agree with ScottK need to get Til on it.
<slangasek> skaet: given that there's no evidence of an actual incident, I don't think we should spend time on an incident report
<skaet> slangasek,  I can live with that.
 * skaet considers it off her worry about list.
<seb128> skaet, slangasek: +1 on no-incident-report, Till was off this end of week but I will ask him to have a look monday morning when he's back
<slangasek> so https://bugs.launchpad.net/ubuntu/+source/cups/+bug/973270/comments/86 redirects to bug #995111; the latter seems to be the known outstanding, intermittent issue
<ubot2`> Launchpad bug 995111 in cups "Print failure since upgrade to 12.04" [High,Fix released] https://launchpad.net/bugs/995111
<ubot2`> Ubuntu bug 973270 in system-config-printer "Printer does not provide REQUIRED job history." [High,Fix released]
<jibel> window manager crashed during a desktop upgrade from lucid to precise. desktop becomes unusable (no keyboard only mouse). Reproduced twice.
<stgraber> slangasek: based on feedback from jibel, I think we should copy nspr now.
<slangasek> stgraber: ack
<slangasek> I've also just gotten feedback from jmleddy, he says he's tested the packages but didn't get a chance to update the bugs before he had to leave the office
<skaet> stgraber,   looks like we've got our set then.
<stgraber> yep, so we can copy cedarview-*, jockey and nspr
<stgraber> then wait for all that to publish and start building candidates
<infinity> Well, assuming jmleddy's feedback was going to be positive...
<infinity> slangasek: Is that what we should assume from the above? :P
<slangasek> it is ;)
<infinity> Alright, then I can get to copying.
<jibel> slangasek, what's the status of bug 1034668 ? it's target for .1
<ubot2`> Launchpad bug 1034668 in indicator-appmenu "Upgrade from Lucid to Precise does not install packages for Global Menu: indicator-appmenu" [High,Triaged] https://launchpad.net/bugs/1034668
<infinity> stgraber: Released nspr jockey cedarview-vaapi-driver cedarview-graphics-drivers cedarview-drm-drivers
<infinity> stgraber: The whole mess should hit disk in ~30m.
<tjaalton> hmm, no seb128
<ScottK> He's not usually around on the weekend.
<infinity> Smart man.
<tjaalton> infinity: nvidia was already in quantal, and it occured to me today that the workaround to block the upgrade for it's users was  trivial
<tjaalton> too late anyway
<tjaalton> hope tseliot uploaded it, after checking the new version was just as broken
<jibel> stgraber, did you try a cdromupgrade from lucid to precise with alternate i386 20120817 ?
<stgraber> jibel: didn't try i386, but I believe that's the version of the amd64 one I used
<jibel> stgraber, ok, it fails with unmet deps. I'll upload the logs.
<stgraber> slangasek, jibel: uploaded indicator-appmenu to -proposed
 * skaet --> appt.   back on line later.
<slangasek> tjaalton: the workaround to make the nvidia package not claim to support an X ABI before it's ever seen it? :)
<slangasek> stgraber: are we looking to get indicator-appmenu into .1 still?
<stgraber> slangasek: not sure, I don't have a clear understanding of the bug, just blindly applied your suggested fix
<slangasek> heh
<stgraber> AFAICT they seem to be internet enabled upgrade problems, so in theory we don't need it on the media
<slangasek> ok
<stgraber> but maybe we do as jibel said he still had upgrade issues using media only on i386...
<stgraber> I guess it'll depend on jibel's log
<tjaalton> slangasek: yep, now that they are hardcoded and not generated during package build..
<tjaalton> which was always wrong for the blobs
<slangasek> yep
<jibel> bug 1038272
<ubot2`> Launchpad bug 1038272 in update-manager "lucid to precise i386 - cdromupgrade without network failed" [Undecided,New] https://launchpad.net/bugs/1038272
<stgraber> jibel: looking
<jibel> stgraber, I did a ./cdromupgrade and answered 'no' when it asked to use a network connection
<stgraber> right, that's how I tested amd64
<stgraber> slangasek: any idea on jibel's log?
<slangasek> idea: is it too late to drop alternate CDs for 12.04? ;)
<slangasek> ok, let's see here
<stgraber> ;)
<slangasek> gah, nspr
<slangasek> is libnspr4-0d on the CD?
<stgraber> I think so
 * stgraber checks
<slangasek> the error suggests it isn't
<stgraber> stgraber@castiana:~/data/code/seeds/ubuntu.precise$ grep -r nspr .
<stgraber> ./ship: * libnspr4-0d
<stgraber> though the media doesn't agree
<slangasek> $ grep nspr-0d precise/daily/20120817/*.list
<slangasek> $
<slangasek> yep, so that's the problem
<infinity> slangasek: That regex could be wrong, of course. :P
<slangasek> it could, but that's not actually the issue ;)
<stgraber> No new revisions or tags to push.
<infinity> Yeah, I'm going to ask the logs.
<stgraber> so the seed is up to date...
<infinity> ? Unknown ship package: libnspr4-0d
<infinity> Did we promote it?
<slangasek> checking
<infinity> Nope.
<slangasek> no
<infinity> Let me fix that.
<stgraber> oh, that'd explain it
<infinity> Fixed in the nextr publisher.
<stgraber> 16:47 < infinity> stgraber: libnspr4-0d will be in main (in proposed) after the next publisher.
<stgraber> that was from a few days ago FWIW :)
<stgraber> so did something move it back to universe while we weren't watching
<infinity> stgraber: And it was probably true until a new version came in.
<stgraber> that'd explain it indeed
<infinity> overrides in pockets are a bit sketchy at times, as far as weird inheritance bugs go.
<infinity> Though, I'm kinda curious now...
 * infinity goes to look.
<infinity> Yeah, 2.1 was in main, and then 2.2 and 2.3 landed in universe, due to the fact that pockets only inherit from -release.
<infinity> We even had this conversation back then, if I recall.
<infinity> Every time that source package gets updated, we'll need to re-promote. :/
<infinity> Or fix the LP bug. :P
<slangasek> sweet
<stgraber> slangasek: right, so indicator-appmenu should go to -proposed and ideally be moved to -updates before 12.04.1 release
<stgraber> the rest should be good to go after the next publisher run
<infinity> I wonder if seeds have a keyword/char that can cause germinate to hard fail on a missing package.
<infinity> That would at least catch this if it slips out of main again later.
<infinity> Hrm, not according to the manpage.  Drat.
<infinity> stgraber: Pending fixing the actual LP bug, maybe some hackery on cdimage to verbosely fail ubuntu-daily/precise builds that don't have libnspr4-0d in the .list or something?
<infinity> Cause Murphy is so going to update that package between now and 12.04.2
<slangasek> stgraber: indicator-appmenu accepted; do we have a way to test this without another CD build from -proposed?
<slangasek> infinity: I don't understand why we haven't pulled that guy's upload privileges by now...
<stgraber> slangasek: using the same system with a patched dist upgrader that allows for local packages
<infinity> slangasek: Because Murphy is good for our job security.
<slangasek> ok
<stgraber> ok, so I'll start building everything but the alternates now
<stgraber> all started now, didn't bother trying to get them in any particular order
<stgraber> EOD, will be back in a little bit to start the live images, then disappear for the rest of the evening
<slangasek> stgraber: thanks!
<slangasek> infinity: hmm, what did we say the cutoff point should be after which we kick unverified SRUs out of -proposed?
<infinity> slangasek: I don't recall, I suspect it might have been in the google doc of meeting note doom.
<slangasek> hmm
<stgraber> ok, that's everything started on nusakan, will check in a few hours that everything built properly
<slangasek> well, I'm guessing at least that "528 days" exceeds the limit
<infinity> slangasek: Seems plausible, yes. ;)
<slangasek> infinity: fwiw I've looked over https://lists.ubuntu.com/archives/precise-changes/2012-August/ and can't find any SRUs matching those dates that would be a plausible culprit for the indicator-weather problem
<slangasek> I conclude that indicator-weather just doesn't like August
<cjwatson> just so people know, the publisher run currently in progress is cocoplum's last
<cjwatson> or so I'm given to understand
<wgrant> Right
<slangasek> hmm
<slangasek> I guess that means we don't get indicator-appmenu into precise-updates before the cut
<cjwatson> we're in the advertised outage window now
 * slangasek nods
<slangasek> stgraber: ^^
<cjwatson> when was the override change made?
<slangasek> this is a package that's still pending publishing to -updates
<slangasek> the override for libnspr4-0d is all settled, no problems there
<cjwatson> depends how quickly pepo comes up then, I guess
<slangasek> pepo?  are we reduced to using genus of garden vegetables now? :)
<slangasek> ah, I guess that's the species rather than the genus
<slangasek> still
<cjwatson> I didn't even look it up; I'm just assuming hostnames are pwgenned now
<infinity> I heartily approve of pepo, I can both remember and type that.
 * infinity might go shower and get an early start on his weekend, since the rest of the world is going asplodey.
<infinity> I'll check in later/tomorrow.
 * slangasek waves
<cjwatson> shadeslayer: http://people.canonical.com/~cjwatson/tmp/quantal-desktop-amd64-hacked.iso - would be interested to see what that does, per previous conversation
 * shadeslayer downloads
<shadeslayer> cjwatson: can I get the md5sum as well?
<cjwatson> yeah, was just doing that :)
<shadeslayer> it's going to take a couple of hours to download
<cjwatson> quantal-desktop-amd64-hacked.sha256sum and quantal-desktop-amd64-hacked.sha256sum.gpg alongside now
<shadeslayer> awesome
<shadeslayer> I'll download it to my VPS and then make a torrent out of it :P
<cjwatson> please don't :
<cjwatson> :P
<shadeslayer> ah ok
<shadeslayer> downloading to vps and rsync'ing
<shadeslayer> no point in using wget over this connection
<cjwatson> totally unstable URL and moreover it's based off some random image which is whatever I had to hand
<shadeslayer> right
<cjwatson> the image from 2012-08-01 by the looks of things
<shadeslayer> cjwatson: so basically, I use usb creator to burn it to a usb stick, and efi should pick it up and do a native boot
<cjwatson> don't use usb-creator
<shadeslayer> dd?
<cjwatson> either write it to a DVD or whatever, or dd it straight to a USB stick
<cjwatson> I'd actually like both tests if possible
<cjwatson> usb-creator will introduce variables I don't want, and is unlikely to work
<shadeslayer> alright, will have to go out and buy a DVD
<cjwatson> basically I unpacked the old image, fiddled with xorriso arguments per advice from xorriso upstream on getting more reliable EFI hybridisation in general (now works for me from a USB stick), and added an HFS+ EFI image
<cjwatson> generated by a subsidiary pass of xorriso
<shadeslayer> hmm
<cjwatson> and roughly based on what Fedora are doing in their images
<shadeslayer> assuming there's a EFI/ folder on the top leve dir, it /should/ boot
<cjwatson> waaaaaaay not that simple on macs
<shadeslayer> *level
<cjwatson> there's all sorts of fiddly stuff to get the boot chooser working
<cjwatson> theoretically
<shadeslayer> yeah, blame APPL and MSFT
<shadeslayer> :P
<cjwatson> if I got this right, the boot chooser (is it still "hold down Option at boot"?) should show an Ubuntu icon with "Ubuntu" underneath
<shadeslayer> yay
<shadeslayer> I was trying to get that, but never could figure it out
<cjwatson> I'd be pretty surprised if it worked first time though
<shadeslayer> hah :D
<cjwatson> now doing that on the installed system as well is a whole other kettle of fish I don't care about right now
<shadeslayer> *nod*
<shadeslayer> Lets just get it to boot the Desktop atm
<shadeslayer> one step at a time ;)
<cjwatson> quite
<shadeslayer> cjwatson: btw, the custom ISO that I built only has 2 folders, casper and isolinux
<shadeslayer> is that what's expected?
<cjwatson> not sure I can think about that tonight :)
<shadeslayer> alright :)
<cjwatson> I'm mostly up in case any help is needed with the ftpmaster bits of the DC move
<cjwatson> hopefully won't be but you never know
<shadeslayer> cjwatson: will you be available tomorrow
<cjwatson> unlikely
<cjwatson> sleep catchup, family stuff, housework, friend's stag do
<shadeslayer> ok, will poke you on Monday then ;_
<shadeslayer> :)
<shadeslayer> though I managed to get the ISO building to work with live build from the archive
<shadeslayer> as expected, md5sums don't match >.>
<cjwatson> you're still trying to build quantal images with precise's live-build, which is ambitious at the very least and basically unwise
<cjwatson> you need to use quantal's tools
<cjwatson> even if you get it working now with precise there's absolutely no guarantee of it staying working
<shadeslayer> mmmmm .... guess I could upgrade the server to quantal
<cjwatson> use a quantal chroot
<cjwatson> that's how all our builds work
<shadeslayer> hm ... will do
<shadeslayer> ah
<cjwatson> livefs builds for $release are always in a $release chroot
<shadeslayer> understood
<shadeslayer> plus, qemu is all weird
<cjwatson> qemu would be massively overkill for this
<cjwatson> Unless you have some kind of complicated arrangement where you're doing arm livefs builds on a really fast x86 box or something
<cjwatson> (Even then the tradeoffs aren't necessarily obvious due to things like memory limitations in the emulated machines)
<shadeslayer> cjwatson: no, I meant, testing a iso on qemu
<shadeslayer> over VNC
<shadeslayer> because for some reason, -hda and -vnc don't work together
<cjwatson> Ah, uh, I've never been that ambitious
<shadeslayer> :D
<shadeslayer> 0.o
<shadeslayer> md5sum mismatch again
<shadeslayer> cjwatson: are you sure the md5sum is right?
<shadeslayer> because I'm getting 78be4c9b4b8bb81fd384ebc616485d81
<shadeslayer> ( for the past 2 downloads )
<cjwatson> I gave you a sha256sum, not an md5sum
<shadeslayer> ergh
<cjwatson> clue's in the filename :)
<cjwatson> that said, the md5sum should be 2d3f192d06054546950e8acedf307402
<shadeslayer> mm ... still doesn't match
<shadeslayer> I clearly need more coffee
<cjwatson> wait, what
<cjwatson> oh damnit
<cjwatson> rsync -avP quantal-desktop-amd64-hacked.iso lillypilly:public_html/quantal-desktop-amd64-hacked.iso
<cjwatson> is not equal to public_html/tmp/...
<shadeslayer> ...
<cjwatson> sorry about that
<shadeslayer> not a issue
<cjwatson> I've moved the file to the right place now
<shadeslayer> http://people.canonical.com/~cjwatson/tmp/quantal-desktop-amd64-hacked.iso right?
<cjwatson> Yeah
<shadeslayer> ok, just confirming :P
<cjwatson> rsync should get you about half of it
<cjwatson> assuming you can rsync from that
<cjwatson> otherwise let me know and I can set up zsync
<shadeslayer> nope
<shadeslayer> can't
#ubuntu-release 2012-08-18
<shadeslayer> that's fine
<shadeslayer> I just need to download it to my VPS
<shadeslayer> I can rsync from there
<cjwatson> running zsyncmake now
<cjwatson> .zsync file up now
<shadeslayer> downloading
 * skaet checks the backlog,  checks iso tracker,  sees images posted, and figures time for EOD.
<cjwatson> A couple failed due to firewall trouble in the DC, now fixed; I don't think there was anything .1-critical
<cjwatson> Though it's possible I missed something
<skaet> cjwatson, am not seeing the mythbuntu ones up - were they the ones that failed?
<cjwatson> Yes
<cjwatson> And kubuntu-active
<skaet> stgraber,  I've gone and marked Precise daily as released now, so no confusion on the testing now that 12.04.1 is up.
<cjwatson> If there's anything you need to respin, they should work now
<skaet> hmm... kubuntu-active isn't part of 12.04.1 but mythbuntu is.
 * skaet goes to kick off a respin of mythbuntu.
<cjwatson> Ah, yes, it was mythbuntu/precise but kubuntu-active/quantal
<cjwatson> I didn't look very hard
 * skaet nods,   its late after all.  
<skaet> mythbuntu for precise rebuild has started.
<shadeslayer> cjwatson: so, ISO downloaded and dd'd
<shadeslayer> now is the moment for truth
 * shadeslayer reboots
<skaet> and mythbuntu now posted.  :)
 * skaet --> EOD
<shadeslayer> cjwatson: it tries to read the disk, then shuts it off and now I have blank gray screen
<cjwatson> Suck.  I'll have to look again next week.  Thanks for testing.
<shadeslayer> no
<shadeslayer> problem
<cjwatson> So it didn't even make it to the boot menu?
<shadeslayer> nope, holding down the option key is suppossed to list bootable media
<shadeslayer> doesn't even show that
<cjwatson> I'll have to sit and byte-by-byte things against the Fedora image, I guess. :-(
<shadeslayer> I think you made efi crash or sth :P
<cjwatson> (Though if you feel particularly enthusiastic and want to try dding the Fedora 17 live image to a USB stick and seeing if that boots, that would be a useful control ...)
<shadeslayer> will do ..
<shadeslayer> again, will take a couple of hours
<stgraber> right, everything's on the tracker so we can get some results over the weekend
<shadeslayer> cjwatson: good news and bad news
<shadeslayer> good news, it picks up fedora
<shadeslayer> bad news, this is all I get : http://db.tt/otgCV0mG
<xnox> shadeslayer: remove splash or try console options?
<shadeslayer> xnox: tjat
<shadeslayer> erm
<shadeslayer> that's with nomodeset
<shadeslayer> and without splash
<xnox> shadeslayer: nice =)
 * xnox feels sorry for shadeslayer 
<shadeslayer> though fedora doesn't have a splash option, they have quiet, so I just removed that
<shadeslayer> xnox: no need, I've already managed to install ubuntu a long time ago ;)
<shadeslayer> feel bad for Fedora
<shadeslayer> I should tweet this to Mathew Garret though :P
<shadeslayer> he probably would have a idea
 * shadeslayer goes back to poking live build
#ubuntu-release 2012-08-19
<phillw> Hi guys, has splash screen removed from server?
<xnox> phillw: are you using LUKS+LVM? =)
<phillw> xnox: I have a dedicated server running under CentOS, it is LVM for the hard drive, but I have not used LUKS on a VM within it.
<xnox> phillw: interesting.
<xnox> phillw: we have this bug 1030094
<ubot2`> Launchpad bug 1030094 in plymouth "LVM encrypted, screen turned off after grub" [Undecided,New] https://launchpad.net/bugs/1030094
<xnox> phillw: which despite having luks sounds similarish.
<phillw> xnox: my problem was / is that server install fails at splash screen.... you know.... the 4 dots bit.... As to why the heck that is on a server boot...pass. I cannot do more testing until that issue is resolved :(
<xnox> phillw: ah that... well... i do not know, sorry. #ubuntu-server?
<phillw> The dedicated server is a remote one. I can ssh -X into it, I can drop in via virt-manager; but I cannot get 12.10 to start up (12.04 runs fine).
<njin> nallo, is cdimage down ?
<njin> nallo/hallo
<phillw> hi guys, is the server transfer done?
<Laney> no, but parts are
<Laney> what are you interested in?
<phillw> Laney: zsync is timing out with [phillw@piglet ~]$ zsync http://cdimage.ubuntu.com/daily-live/20120819/quantal-desktop-amd64.iso.zsync
<phillw> cdimage.ubuntu.com: Connection timed out
<phillw> failed on url http://cdimage.ubuntu.com/daily-live/20120819/quantal-desktop-amd64.iso.zsync
<phillw> could not read control file from URL http://cdimage.ubuntu.com/daily-live/20120819/quantal-desktop-amd64.iso.zsync
<phillw> trying http gives.. Oops! Google Chrome could not connect to cdimage.ubuntu.com
<stgraber> cdimage works from here
<phillw> stgraber: I'm just following up an email on QA, I have the same issue. any ideas?
<tumbleweed> it was down until fairly recently (according to my complaining cron mail)
<tumbleweed> fairly recently being 3 hours ago or so
<phillw> fairly recent being two minutes ago.
<phillw> OK, so how long will the relocation take?Â  When will the servers be back on track?
<phillw> two minutes ago on email.
<phillw> sorry guys, you are the only channel I can ask on. It is from QA, but you look after the servers!
<phillw> stgraber: can you check grabbing a couple of iso images from http://iso.qa.ubuntu.com/qatracker/milestones/219/builds
<phillw> I've tried a couple at random and they are a fail.
<tumbleweed> http://cdimage.ubuntu.com/ubuntu-server/daily/20120819/quantal-server-amd64.iso.zsync works fine for me
<phillw> tumbleweed: can you try http://www.google.com/url?sa=D&q=http://cdimage.ubuntu.com/lubuntu/daily/20120819/quantal-alternate-i386.iso&usg=AFQjCNEBoafSRvng93U55R6hOSG_opiMbA
<phillw> oops, long name, let me track it back!
<phillw> http://iso.qa.ubuntu.com/qatracker/milestones/219/builds/21490/downloads
<stgraber> downloads fine here
 * tumbleweed sees no trobule either
<phillw> Hmm, any ideas why more than one person cannot use them?
<tumbleweed> did the machine change IP address?
 * tumbleweed sees a 10 minute TTL on the DNS record, so assuming it wasn't recently lowered, that shouldn't be much of an issue...
<phillw> 'thinks' - clear cache from browser would help, but at CLI zsync it is a bit more problemitcle.
<phillw> tumbleweed: [phillw@piglet ~]$ zsync http://cdimage.ubuntu.com/ubuntu-server/daily/20120819/quantal-server-amd64.iso.zsync
<phillw> cdimage.ubuntu.com: Connection timed out
<phillw> failed on url http://cdimage.ubuntu.com/ubuntu-server/daily/20120819/quantal-server-amd64.iso.zsync
<phillw> could not read control file from URL http://cdimage.ubuntu.com/ubuntu-server/daily/20120819/quantal-server-amd64.iso.zsync
<phillw> so, I cannot 'see' cdimage.ubuntu.com
<tumbleweed> phillw: getent hosts cdimage.ubuntu.com
<phillw> tumbleweed: bash: getents: command not found
<tumbleweed> singular
<phillw>  getent cdimage.ubuntu.com
<phillw> Unknown database: cdimage.ubuntu.com
<phillw> Try `getent --help' or `getent --usage' for more information.
<tumbleweed> left out hosts ):
<phillw> don't you hate a n00bie :P
<phillw> yup, that worked.
<phillw> Let me go tell the people on ubuntu QA mailing list of the fix. but, it is a fairly major bug!
<tumbleweed> that wasn't a "fix" just an attempt to understand what your problem is
<tumbleweed> but debugging this over IRC is not likely to be particularly profitable
<phillw> tumbleweed: no, it was a fix... As it worked perfectly for QA people until recently, then something quite fundamental changed.
<micahg> umm...a datacenter move perhaps
<tumbleweed> :)
<phillw> micahg: indeed, which has happened this weekend. Still, better to alert people early before the channels melt down with bug reports :)
<phillw> tumbleweed: micahg is this okay to send?
<phillw> Hi guys and gals,
<phillw> over the weekend the "behind the scenes" team were busy. You may find that you cannot upload / zsync etc. If this happens please issue
<phillw> getent hosts cdimage.ubuntu.com
<phillw> It will refresh your local cache for cdimage area.
<phillw> Regards,
<phillw> Phill.
<micahg> getent just queries a DB...
<phillw> micahg: So for us lesser mortals, does it work? It did for me.
<elmo> no it won't "work"
<elmo> cdimage is behind a DNS round robin rotation that only returns 1 answer at a time
<phillw> elmo: it did for me.
<tumbleweed> phillw: getent does nothing, I just wanted to see what the output was
<elmo> phillw: no, it didn't
<elmo> phillw: all that happened is you happened to change to the working server
<elmo> completely unrelated to your getent command
<micahg> elmo: I would think with the TTL, by now, any old entries should've been refreshed, right?
<elmo> micahg: it's not an old entries problem
<elmo> or related to the DC move
<elmo> one of the servers is just dead
<micahg> orly?  ok
<elmo> I'll stab it in the face
<micahg> elmo: thanks
<elmo> (well, I mean the DC made it more visible, cdimage is running at reduced capacity, so a dead server is more obvious - but it's not the root cause)
<tumbleweed> elmo: out of interest, why return only 1 answer at a time? (it makes it entirely non-obvious that there's round-robbining behind the scenes)
<phillw> I'll go and have a ciggie while you guys work out an official answer for the QA people which is guaranteed to work.
<elmo> tumbleweed: because Microsoft broke DNS
<tumbleweed> heh
<nigelb> nice
<elmo> tumbleweed: given N answers in a RR set, Microsoft (and glibc for a time, but we got that fixed at least in Debian/Ubuntu) will return the "closest" one, which in IPv4 terms is meaningless
<tumbleweed> ah, that's fairly crazy
<elmo> we only do  it for services that are likely to be used by non-Ubuntu users
<elmo> so, e.g. archive.u.c does more traditional RR
<elmo> goldenapple (the problematic server) is backup, FWIW
<njin> not working at all
<njin> from this morning
<elmo> njin: pardon?
<njin> cdimage is down
<elmo> njin: as I said, it just came back up
<njin> ok
<njin> is back
<phillw> elmo: so the answer to the email list is "It is now working okay"?
<elmo> phillw: sure, if you like - it should be and is from my testing
<phillw> elmo: thanks :)
<phillw> elmo: is this okay to release?
<phillw> Hi guys and gals,
<phillw> over the weekend the "behind the scenes" team were busy. You may have found that you could not upload / zsync etc.
<phillw> Moving servers is not for the faint of heart, I still have the scars.Â 
<phillw> Thank you to all those who did the server transfer to enable ubuntu testing and dev team to be able to take up the higher work load on.
<phillw> Regards,
<phillw> Phill.
 * micahg invites phillw to use a pastebin next time
<phillw> micahg: it wasn't that much of paste :P
<micahg> phillw: 6 lines belongs in a paste
<phillw> micahg: I consider myself told told off, I'll use paste in future. sorry :(
<micahg> phillw: thanks :)
<phillw> hi, any people around for http://iso.qa.ubuntu.com/qatracker/milestones/230/builds/21391/downloads
<phillw> the hhtp is pointing to a zsync.
<xnox> stgraber: see the message from phillw ^^^^
<phillw> I've not checked others, I've just had a poke via email over it
<phillw> Download links for Ubuntu Alternate amd64
<phillw>  seems okay
<phillw> xnox: hiyas, sorry to be once again the bringer of bad news. C'est la vie.
<phillw> I'll be happy when -testing channel wakes up after the weekend :)
#ubuntu-release 2013-08-12
<tseliot> any archive admins around?
<stgraber> tseliot: I'm sort of here (at a conference)
<tseliot> stgraber: I have some packages approved for an SRU but the binaries are stuck in NEW (precise-proposed)
<stgraber> tseliot: ah, ok, I'll take a quick look then
<tseliot> stgraber: nvidia-prime, fglrx-pxpress, nvidia-graphics-drivers-319, nvidia-graphics-drivers-319-updates, nvidia-graphics-drivers-304, nvidia-graphics-drivers-304-updates, nvidia-graphics-drivers-173-updates, nvidia-settings-319, nvidia-settings-319-updates, nvidia-settings-304, nvidia-settings-304-updates, nvidia-persistenced, fglrx-installer-updates, fglrx-installer-experimental-13
<tseliot> stgraber: nvidia-prime and fglrx-pxpress belong in main, the nvdia and fglrx drivers in restricted, nvidia-settings* in main (same as nvidia-persistenced)
<stgraber> tseliot: hmm, fglrx-pxpress is in universe in saucy
<tseliot> stgraber: I have a MIR for that, let me find the bug report...
<stgraber> tseliot: hmm, I'm not fond of the idea of promoting this in the LTS before it's done in the dev release...
<tseliot> stgraber: I guess the MIR hasn't been approved yet. Using universe should be ok for now, I'll have the packages moved as soon as the MIR is approved
<stgraber> ok, accepting to universe for now then
<tseliot> thanks
<tseliot> didrocks: please have a look at bug #1204820 when you can
<ubot2`> Launchpad bug 1204820 in nvidia-prime (Ubuntu) "[MIR] nvidia-prime & fglrx-pxpress" [Undecided,New] https://launchpad.net/bugs/1204820
<stgraber> tseliot: all done
<tseliot> stgraber: excellent, thanks!
<stgraber> (restarting queuebot as it didn't notice)
<didrocks> tseliot: looks both good. is anything build-dep on them or will you add them to the support seed?
<tseliot> didrocks: nothing really depends on them now
<didrocks> tseliot: ok, please add them to the support seed then
<didrocks> then, once pushed, I'll promote them
<tseliot> didrocks: I'm not sure how to do that or why
<didrocks> tseliot: if we don't do that, nothing will pin them in main
<didrocks> and so someone will demote them
<tseliot> didrocks: ok, so maybe either supported-hardware-common or supported-hardware-desktop?
<didrocks> tseliot: oh, I don't know those, I'm sued to "supported" in bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.saucy/, but if there is anything else
<didrocks> tseliot: just push to the one which makes sense and give me a sign so that I do the promotion
<tseliot> didrocks: ok, shall I do that for precise too? (the packages are also in precise-proposed)
<didrocks> tseliot: yeah
<tseliot> didrocks: ok, good
<didrocks> tseliot: but wait for it to be out of proposed to remember me to promote it there as well
<didrocks> (the override is lost between proposed and update if it's the same than proposed -> release)
<tseliot> didrocks: ok
<tseliot> didrocks: ok, I've just committed revision 2152 for saucy, so the two packages should be pinned
<didrocks> tseliot: thanks! promoting
<tseliot> didrocks: great, thanks!
<didrocks> tseliot: yw, done :)
<tseliot> :)
<stgraber> tseliot: ok, I'll promote it in precise too then
<tseliot> stgraber: ok, thanks
<stgraber> tseliot: done
<tseliot> stgraber: great, thanks again :)
<tseliot> stgraber: BTW, is nvidia-persistenced in saucy?
<stgraber> tseliot: doesn't look like it
<tseliot> stgraber: it was reviewed by cjwatson, then I applied his changes, reuploaded but it was never reviewed or approved again
<rtg> infinity, are you ready to promote linux 3.11 ?
<tseliot> stgraber: still around?
<stgraber> tseliot: yeah
<tseliot> stgraber: I don't see fglrx-installer-experimental-13 in precise-proposed
<tseliot> (same bug report)
<tseliot> i.e. 1198942
<stgraber> tseliot: I only processed the new binaries this morning, not new sources. fglrx-installer-experimental-13 is a new source pending review in precise-proposed
<stgraber> (so is nvidia-persistenced apparently)
<tseliot> stgraber: oh, so they haven't been approved yet
<stgraber> right
<tseliot> ok, I should probably ask slangasek about that then
<stgraber> tseliot: is fglrx-installer-experimental-13 mostly an identical copy from saucy? if so, I can confirm that part and let it in based on that, otherwise I don't think I've got the time to do a full New review of it
<tseliot> stgraber: fglrx-installer-experimental-13 is the same as fglrx and fglrx-updates in saucy
<stgraber> tseliot: note that cjwatson, doko, slangasek and I are all at Debconf this week, so it may be difficult for us to find enough time in a row to do a full New review
<tseliot> oh
<stgraber> tseliot: ok, I'll grab the saucy source and do a diff, if they seem sufficiently identical (just obvious packaging changes), I'll let it in and then let its binaries in too
<tseliot> stgraber: thanks a lot
<stgraber> ae8f805e52508dd2fde55be3dc7dffd1  fglrx-installer-updates_13.101.orig.tar.gz
<stgraber> 12ae4dc15542382eb0c119729af6fd70  ../precise/fglrx-installer-experimental-13_13.101.orig.tar.gz
<stgraber> tseliot: ^
<stgraber> ok, they're actually identical except for the precise one being shifted one level (no top level fglrx-installer in that tarball)
<stgraber> -PATCH_MATCH[0]="^3.[10-11]"
<stgraber> +PATCH_MATCH[0]="^3.[10]"
<stgraber> tseliot: ^ is that going to be a problem once we backport the saucy kernel to precise?
<stgraber> tseliot: debian/pxpress also indicates some code that's in precise but not in saucy (_find_process function and code to call dpkg --configure -a)
<slangasek> tseliot: is fglrx-installer-experimental-13 already in saucy?
<stgraber> besides that the rest seems mostly identical to saucy's
<slangasek> ah, so it is
<slangasek> stgraber: thanks for tending :)
<stgraber> slangasek: as fglrx-installer-updates, yes
<tseliot> stgraber: that would be a problem for 12.04.4, it shouldn't be for 12.04.3 (Which won't ship 3.11)
<tseliot> stgraber: that part of code (debian/pxpress) is only used when called from jockey and there's no jockey in saucy
<tseliot> slangasek: no, but the same driver is in fglrx and fglrx-updates (it only has a different name)
<stgraber> tseliot: ok, thanks for the answers. I'll let it in now (the rest indeed is a copy + rename)
<tseliot> stgraber: right, thanks
<rtg> stgraber, do you have time to promote Saucy linux from -proposed ?
<cjwatson> That isn't a manual task
<cjwatson> Except in that it needs some problem resolved
<stgraber> let me check what we're missing, is that just d-i?
<rtg> stgraber, it might be, but I'm not sure.
<cjwatson> d-i's missing (Adam was going to do it today, I thought), and I think it's also mysteriously hung up on an autopkgtest
 * cjwatson fires up the VPN
<stgraber> hmm, indeed, stuck on autopkgtest
<cjwatson> Spuriously - I think I'll force it
<rtg> cjwatson, it is a major transition from 3.10 to 3.11
<cjwatson> I know
<cjwatson> But proposed-migration doesn't care about that :)
<cjwatson> I'll sort out d-i
<stgraber> cjwatson: will you also do the seed changes?
<cjwatson> Yes
<ScottK> It looks like there's a mess around linphone/sipwitch that needs ucommon ported to a newer GNUtls (not done upstream yet).
<ScottK> Way beyond me to sort out.
<jbicha> we can clear up the linphone situation by removing ucommon 6 from Debian since it may take a while for the Debian maintainer to get around to fixing http://bugs.debian.org/716855
<ubot2`> Debian bug 716855 in libucommon-dev "libucomon-dev: Dependency on libgnutls28-dev makes sflphone unbuildable" [Important,Open]
<jbicha> *remove ucommon from -proposed and then rebuild sipwitch
<ScottK> Except ucommon doesn't build with libgnutls-dev
<ScottK> Oh.
 * ScottK tries.
<jbicha> I've so far been unsuccessful at convincing the Debian maintainer that it's a big problem
<ScottK> Lovely.
<ScottK> jbicha: The current sipwitch in proposed doesn't build with the older ucommon.  So I think both have to go.  Trying that now.
<ScottK> Nope.  That fails on the newer libexosip.
<jbicha> ScottK: oh :(
<ScottK> I think the whole lot needs to go.
<jbicha> if we cared enough, we could add a ucommon5 source package...
<ScottK> No, I don't think that would do it.
<ScottK> sipwitch depends ucommon >= 6
<jbicha> ScottK: I mean have both ucommon and ucommon5 so that packages could build with whichever one they need...but I didn't test that either
<ScottK> Cleared out.
<ScottK> Doesn't seem to have made anything worse.
<infinity> rtg: Yeahp, I'll get it shoved along after my morning meeting.
<rtg> infinity, too late, cjwatson already gave it the nudge it needed
<infinity> rtg: Oh.  So he did.
<rtg> infinity, he updated d-i, and I just received emails that all have been promoted
 * infinity nods.
<rtg> now, I'm gonna upload -rc5.
<infinity> I just twiddled the seeds to match, since I didn't get to mucking with making that all work automagically over the weekend.
<cjwatson> ta, I had it uncommitted for when it landed
#ubuntu-release 2013-08-13
<sil2100> infinity: hi!
<sil2100> infinity: for raring, someone proposed a fix as an SRU (LP: #1204664) which basically disables a default key combination - this key combination seemingly works only once, all subsequent other keycombination-presses of this shortcut fail - I guess it's a bit wrong for an SRU, right?
<ubot2`> Launchpad bug 1204664 in compiz (Ubuntu Raring) "control+super+d works just the first time running Ubuntu Unity." [Undecided,New] https://launchpad.net/bugs/1204664
<tseliot> stgraber, slangasek: I've found and fixed an issue in fglrx-experimental-13. I'm about to upload a new revision for the same SRU. The diff is minimal
<tseliot> stgraber, slangasek: ok, uploaded and here's the diff http://paste.ubuntu.com/5981051/
<rtg> cjwatson, infinity: the autopackage test failure for linux 3.11.0-2.5 appears to be bogus (closeall.op: No space left on device). Can I get it promoted ?
<infinity> sil2100: How is that inappropriate for an SRU?
<sil2100> infinity: as it's modifying default behavior, disabling a keyboard shortcut that was in during the release
<infinity> sil2100: One that doesn't work? :P
<sil2100> infinity: even thought it wasn't really working... ;p
<infinity> sil2100: Though I think I misunderstood initially.  Why not just fix the bug instead of disabling it?
<sil2100> infinity: someone said it was working when you used it for the first time!
<infinity> sil2100: It seems to work for me in saucy, so clearly, there's a fix for unity7 to make it work...
<sil2100> infinity: yeah, I had a discussion with upstream after asking you the question, and I think we somehow resolved it, since there is a way of fixing it somehow from what I know
<sil2100> infinity: and they'll be backporting the fix to raring
<infinity> sil2100: Excellent, then I'll pretend this conversation never happened.
<sil2100> infinity: thanks ;)
<sil2100> hehe
<tseliot> infinity: can you approve the new revision of fglrx-experimental-13 in precise-proposed please? diff: http://paste.ubuntu.com/5981051/
<mdeslaur> so...can someone explain why squid3 has not migrated from -proposed if the excuses page says "Valid Candidate"?
<rbasak> mdeslaur: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt is saying migrating squid3 would make sqcwa and squid-prefetch uninstallable.
<rbasak> (AFAICT)
<mdeslaur> rbasak: ah! thanks, I didn't know that page existed
<rbasak> mdeslaur: is this because the "squid" transitional package has disappeared in -proposed?
<mdeslaur> rbasak: that seems plausible, yes
<mdeslaur> rbasak: are you adding it back?
<rbasak> mdeslaur: I wasn't planning on touching it. I wonder if Debian have intentionally removed it, and if so then perhaps Debian needs to fix packages depending on it, too?
<mdeslaur> rbasak: debian still has "squid" in the archive
<rbasak> Oh
 * rbasak looks
<rtg> infinity, linux 3.11.0-2.5 is still lodged in proposed because of the eglibc autotest failure. Could you drop kick it into release ?
<infinity> rtg: Yeah, will do.  I was trying to see if I could reproduce the eglibc failure first, which I seemingly can't.
<rtg> infinity, make a really small disk ?
<xnox> mdeslaur: rbasak: they may have it, but is it build by the source package? Looking at debian/control of the package in sid, it no longer builds the squid binary package.
<infinity> rtg: That's how to make the linux one fail.  The eglibc one seems weirder.
<xnox> it may still be in the debian archive, however. as in debian they postpone removing the package.
<infinity> rtg: Anyhow, given a shove.
<rtg> infinity, thanks
<mdeslaur> xnox: nono, they have a squid _source_ package
<mdeslaur> xnox: which build a squid binary package
<mdeslaur> xnox: they have _both_ squid and squid3
<rbasak> Looks like we introduced a squid transitional package in Precise as an Ubuntu delta.
<rbasak> And that we dropped this inadvertently in the last merge.
<xnox> mdeslaur: oh =(
<xnox> rbasak: i see.
<rbasak>   * Dropped:
<rbasak>     - debian/control: Dropped transitional packages from squid, no
<rbasak>       longer required.
<rbasak> Maybe more intentional than inadvertent!
<rbasak> I'll file a bug.
<rbasak> jamespage, yolanda: ^^
<rbasak> I filed bug 1211942
<ubot2`> Launchpad bug 1211942 in squid3 (Ubuntu Saucy) "Dropped squid transitional package blocks -proposed migration" [High,New] https://launchpad.net/bugs/1211942
<infinity> rbasak: Was the transitional package introduced for lucid->precise?  If so, it's surely not needed anymore.
<infinity> rbasak: And the right answer would be to make things stop depending on it.
<infinity> (Not that keeping it would be wrong either)
<rbasak> infinity: Debian do seem to be keeping it.
<rbasak> infinity: it seems that we dropped it. But I suppose we could reintroduce it now that users have switched when they upgraded from lucid->precise? Is that what you're saying?
<rbasak> (ie. reintroduce into universe)
 * adconrad wonders where his co-lo server has disappeared to for the last half hour.
<adconrad> rbasak: I wasn't suggesting we reintroduce squid2.  That would be confusing as heck if "apt-get install squid" got you an older version on saucy than it does on precise.
<adconrad> rbasak: Our two options, IMO, are to carry the transitional package (so, reintroduce that), or make everything that depends on "squid" depend on squid3 instead.
<rbasak> adconrad: right
<adconrad> rbasak: Reinstroducing the transitional package seems the path of least resistance.
<rbasak> Agreed. I'm just not sure what the logic was to drop the transitional package in the first place, which is why I filed the bug (as both yolanda and jamespage are EOD right now)
<adconrad> rbasak: The logic was likely "people have done the LTS->LTS upgrade, and now we expect them to install squid3 directly", as is the case with most transitional packages.
<adconrad> But in the case where things still *depend* on the transitional package, dropping it is probably less sane.
<adconrad> rbasak: If I were you, I'd just upload to fix the bug, and not worry too much about the rationale.  :P
<jbicha> you could just have squid3 Provides: squid now, right?
<adconrad> You could do that instead, yes.
<rbasak> As long as dependent packages don't make their Depends: versioned in the future.
<cyphermox> ^ this replaces brcm-patchram-plus, which you should feel free to remove
<jamespage> rbasak, that is whats commonly know as a mistake
<jamespage> rbasak, lets get back in sync with Debian
<rbasak> jamespage: by reintroducing squid 2?
<jamespage> rbasak, oh - I see - Debian still has a squid source package
<jamespage> rbasak, how odd
<rbasak> Right
<jamespage> rbasak, I'd re-introduce the squid binary package in squid3
<rbasak> Sounds good
<jamespage> rbasak, as we are skewed from Debian anyway
<jamespage> rbasak, needs a merge as well
<jamespage> ah - I see why mdeslaur was asking now!
#ubuntu-release 2013-08-14
<psivaa> cjwatson: infinity: i reported bug #1212239 for print server installation failures with today's saucy images, tkamppeter says it's an image building issue and not one with the cups-filters
<ubot2`> Launchpad bug 1212239 in cups-filters (Ubuntu) "cups-filters is reported to have unmet dependencies with the latest saucy server installations" [Undecided,New] https://launchpad.net/bugs/1212239
<psivaa> shall i reassign the bug to d-i?
<seb128> psivaa, not sure if it's a *bug/issue* with d-i, but we need help from somebody who understand how the image building is working to debug it
<seb128> we fixed the rdepends to depends on "cups-filters (>= ...) | oldname" and things install/upgrade fine
<seb128> not sure how to debug those sort of issues :/
<seb128> psivaa, cjwatson is at debconf though, not sure how often he looks at IRC
<psivaa> seb128: ahh ok, thanks. dint realise that it's so complex :). could wait.
<seb128> psivaa, it's probably not "so complex" but most of us are not really familiar with the image build details
<psivaa> seb128: ack
<rtg> infinity, bah! please reject fglrx-installer so that I can re-upload it with the proper version diff
#ubuntu-release 2013-08-15
<tkamppeter> I have uploaded ghostscript 9.06rc1 to saucy-proposed and it did not pass on to saucy. As I chose a bad version number (9.08~rc1~dfsg is considered newer than 9.08~dfsg) can this package get removed and I upload the final instead?
<tkamppeter> s/9.06/9.08/
<xnox> Can saucy-adt-beets be re-run please? it's not reproducible here with run-autopackage-test.
<xnox> tumbleweed: ^
<tumbleweed> xnox: thanks
<cjwatson> tkamppeter: Surely you could just upload the final as 9.08+dfsg, which would be more conventional anyway
<tkamppeter> cjwatson, OK.
<Laney> cjwatson: updating your firefox force-badtest version
<tkamppeter> cjwatson, new ghostscript uploaded.
<cjwatson> Laney: thanks
<Laney> sure
<Laney> the failure there is weird btw; stgraber is investigating it
<Laney> (so that it can then fail for real...)
<stgraber> ;)
<cjwatson> Can somebody accept grub2 in saucy unapproved?
<stgraber> the current failure looks like a ENOSPACE on jenkins and a ENOINODE (well, ENOSPACE but caused by not enough inodes) on my machine
<stgraber> cjwatson: I'll do it
<cjwatson> ta
<stgraber> cjwatson: didn't feel like passing -v to debuild? :)
 * cjwatson -> idiot
<cjwatson> or even <-
<cjwatson> er, wait, no I'm not.  I did
<cjwatson> but that's a binary .changes and it probably doesn't preserve that
<stgraber> ah, that'd explain that. Not really a problem as I've got the bzr branch on my machine anyway :)
<stgraber> cjwatson: there you go ^
<cjwatson> thanks
<plars> cjohnston, infinity: When would we expect to start seeing release candidates for 12.04.3?
<plars> cjwatson: ^ :)
<plars> cjohnston probably thinks (and he may be right) that I do that on purpose just to annoy him now
<cjwatson> plars: -> infinity - I'm not running it and am at DebConf this week and vacation next week
<stgraber> plars: slangasek is running it (https://wiki.ubuntu.com/SaucySalamander/ReleaseTaskSignup). Usually the first ones appear on Monday or Tuesday of the milestone week.
<plars> stgraber: ah, I lost that link, thanks
<plars> slangasek: I figured probably on monday, but just wanted to double-check as I think in the past we usually shoot for end of previous week
<plars> slangasek: just trying to plan for the next week or so worth of priorities :)
<knome> umh... *cougs* i know we're a bit late, but we have bug 1207493
<ubot2`> Launchpad bug 1207493 in xubuntu-docs (Ubuntu) "[SRU] Documentation does not match shipped system version (11.10 shipped with 12.04)" [High,Confirmed] https://launchpad.net/bugs/1207493
<knome> is there any possibility to make sure it's in 12.04.3 if we uploaded it today?
<smartboyhw> stgraber, knome (or Release Team Member): Can you add upgrade tests for UbuntuKylin?
<tkamppeter> Someone knows why the ghostscript package is still in -proposed?
<ogra_> tkamppeter, Missing build dependencies: libopenjpeg-dev
<ogra_> https://launchpad.net/ubuntu/+source/ghostscript/9.08+dfsg-0ubuntu1/+build/4880097
<ogra_> and according to http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html on all arches
<tkamppeter> ogra_, so a MIR for openjpeg is needed?
<ogra_> yeah, looks like
<tkamppeter> ogra_, the MIR is already there: bug 711061.
<ubot2`> Launchpad bug 711061 in openjpeg (Ubuntu) "[MIR] libopenjpeg2" [Wishlist,Confirmed] https://launchpad.net/bugs/711061
<ogra_> so someone from the MIR team needs to approve and an archive admin needs to promote it
<infinity> That old MIR didn't go well the last couple of times people looked at it.  You'll want to bounce that back to jdstrand and see if his concerns were addressed.
<infinity> jdstrand: ^^
<jdstrand> ack
<tkamppeter> jdstrand, the CVEs mentioned in the last comments seem to be fixed in our package, as there are patches with that names.
<mdeslaur> can someone explain to me what this means:
<mdeslaur> skipped: libav (36 <- 51)
<mdeslaur>     got: 92+0: i-92
<infinity> It's the next line that's important.
<mdeslaur> * i386: devede, dvd-slideshow, ffdiaporama, kmediafactory, mythexport, ubuntustudio-video
<infinity> Which is telling you that if libav were updated, those packages become uninstallable.
<infinity> That said, we should start the libav 9.x transition, IMO.
<mdeslaur> ah! ok, libav-extra never got uploaded
<mdeslaur> I see
<mdeslaur> infinity: thanks for the explanation...I got hung up on the magic numbers
<mdeslaur> infinity: just for kicks...what do they mean?
<mdeslaur> I assumed "36" was the number of days since infinity slept
<mdeslaur> but I couldn't figure out the others
<infinity> They're just internal counters.  Likely not meaningful unless you're hacking on britney.
<infinity> Arguably have no place in user-facing output.
<mdeslaur> infinity: ah, ok
<flugxu> hi! There's an inconsistency for the release date of 12.04.3 - on this page it says August 22nd (https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule) and on this page it says today (https://launchpad.net/ubuntu/+milestone/ubuntu-12.04.3)
<infinity> flugxu: The LP milestone one is wrong, thanks for pointing it out.
<flugxu> infinity, no problem - pity, I was hoping for some sweet loving today
<infinity> flugxu: Fixed.
<infinity> flugxu: To be fair, unless you really need an ISO, most of what will be 12.04.3 is in precise already.  Milestone releases are pretty uneventful things. :)
<flugxu> infinity, I was under the impression that we'd get a huge compiz update (pulled from 13.04), while right now 0.9.7 is in precise's repos
<flugxu> and compiz is something that could use an update, having previously spent a lot of time on it before
<flugxu> https://wiki.ubuntu.com/Kernel/LTSEnablementStack
<tumbleweed> win 14
<tumbleweed> bleh
<infinity> flugxu: I'm not sure where you got the impression that compiz was getting a "huge" update...
<flugxu> infinity, if it's using the raring stack, that is a huge update
<infinity> flugxu: The "HWE stack" is just hardware support, it's not a new compiz, unity, etc.
<infinity> flugxu: Just a new libdrm, mesa, X11, and kernel.
<flugxu> infinity, hm, you're right, dunno where I got that into my head.
<infinity> flugxu: And you can get that today on precise with "apt-get install linux-generic-lts-raring xserver-xorg-lts-raring"
<flugxu> infinity, ah, thanks! This is the first LTS I've actually stayed on for this long (since 8.04 was really awful and 10.10 was better than 10.04), so I wasn't aware of those metapackages
#ubuntu-release 2013-08-16
<xnox> i've synced db6.0 twice now. so the older one can be dropped. but i'd like the ^ one to be accepted please =)
<cjwatson> xnox: done
<jamespage> Daviey, how would the SRU team feel about backporting the 1.9.0 openvswitch from raring to 12.04 to support the lts-raring enablement kernel?
<xnox> cjwatson: cheers!
<jamespage> it supports 3.8 natively and I feel its actually much lower risk and trying to backport the multitude of cherry-picks that don't apply cleanly to the 1.4.x codebase we have in 12.04
<Daviey> jamespage: Hmm, a dedicated NEW versioned package name (like linux), or bumping the version?
<jamespage> Daviey, hmm
<jamespage> Daviey, I was thinking a straight backport to updates
<Daviey> jamespage: Dual supporting both is more favourable IMO, but lack of dynamic dependencies makes this kinda hellish..  I can't think of a good user experience fix for handling this gracefully
<jamespage> Daviey, the other option which is not ideal is to provide 1.9.0 via precise-backports
<jamespage> so that 1.4.0 continues to exist for those that want to stick with 3.2
<jamespage> but lts-raring users have to use the backports version....
<jamespage> I'd need to run that past the backports team obviously
<Daviey> jamespage: Probably a good idea to bring this to the TB mailing list, outlining the issue and possible solutions
<jamespage> actually that might work better - I suspect that for the saucy enablement kernel I'll need to backport 1.10 which drops the brcompat module
<jamespage> Daviey, OK - I'll send something this morning
<Daviey> jamespage: Well, straight backports cannot really solve this, can it?  Unless you still do the compat work in the current openvswitch package?
<jamespage> Daviey, ?
<jamespage> its already backwards compatible
<jamespage> i.e. 1.10 works on the 3.2 kernel
<Daviey> jamespage: Current ovs in precise works with current lts kernel, but not raring backport?
<Daviey> Oh!
<jamespage> Daviey, yes
<jamespage> The version we have in precise is good up to the quantal hwe kernel
<jamespage> but that was painful and we have to carry a large number of patches
<jamespage> (and I got it wrong first go)
<Daviey> jamespage: Right.. and you want to avoid that again... and I agree the regression potential of trying to cherry pick that much is a problem.
<Daviey> So what i am saying is, making use of backports will mean that  -updates doesn't work with the most recent HWE kernel.
<Daviey> jamespage: AND, we ned to move quite quickly... 12.04.3, scheduled for next Thursday (is that still correct?).. will not work with openvswitch as it has the raring kernel, right?
<jamespage> Daviey, no
<Daviey> I'm wrong?
<Daviey> jamespage: Am i wrong?
<jamespage> Daviey, the version of openvswitch in 12.04 will not work with the raring HWE kernel
<jamespage> well the user space tools might with the native kernel module
<jamespage> but the openvswitch-datapath-dkms module which is the one everyting uses will not
<Daviey> jamespage: Right.. the native support doesn't have GRE support, right?
<jamespage> Daviey, thats correct
<jamespage> Daviey, hmm - I wonder whether we can skew the userspace tools against the dkms module version
<jamespage> Daviey, that way we could provide a versioned openvswitch-datapath-dkms-lts-raring package only
<Daviey> Yeah, I think that is what I was thinking earlier.. but create a good user experience as we cannot do dynamic depends
<Daviey> err, creates a poor*
<jamespage> Daviey, well we have todo an explicit install of the dkms package anyway
<jamespage> Daviey, so its not that much different
<Daviey> jamespage: true.. Yeah, I think that is the best balance
<jamespage> Daviey, just testing that now
<Daviey> We get raring-hwe compatibility, with no risk of current users.
<Daviey> I'd also say that it is a manageable workflow in the future
<Mirv> could an archive admin add "poppler-qml-plugin" to the whitelist of source packages coming from cu2d? maybe cjwatson? both didrocks and seb128 are away today.
<Daviey> Mirv: Sorry, I would help.. but I do not know how cu2d works, and I have been unable to find any docs.
<jamespage> Daviey, userspace tools for 12.04 appear to be functional with newer dkms versions!
<Mirv> Daviey: yeah the slight problem here is that I don't know where/what the whitelist didrocks touches is, but cyphermox told it's on the archive machines and not part of cu2d system (https://wiki.ubuntu.com/DailyRelease) as such
<Daviey> jamespage: Super, that is good news.  I'd be happy processing this approach myself, unless anyone else objects.
<jamespage> Daviey, great - I'll not bother emailing the TB as we have a low risk approach now
<jamespage> marvellous
 * jamespage thinks its good to talk these things through!
<Daviey> Mirv: Yeah, I'm not even sure I can do that.. I'd rather not poke around, and risk getting it wrong.  Sorry. :(
<Mirv> Daviey: I totally understand, that's why the idea of getting that Thing documented is a good one :)
<Laney> It's something that gets committed to bzr and then pulled on lillypilly
 * Laney waves hands and flails
<sil2100> Daviey: hi! Maybe you could help us in some other way! Do you have a minute? :)
<sil2100> Daviey: in the daily-release process, we have a requirement that whenever there is a packaging change in a package that is ready for releasing, we need and archive-admin-or-similar to ACK the change - so that no 'risky' packaging change gets released into Ubuntu
<sil2100> Daviey: normally didrocks or seb128 do those, but now they're both gone
<sil2100> Daviey: we have one thing like this now, it's really a one-liner that we already acknowledged, but we still need some core-dev to ACK it as well
<sil2100> Daviey: I know it's hard to ACK something when you don't know the code, but it's just to make sure nothing unwanted gets into the archive
<sil2100> Daviey: https://jenkins.qa.ubuntu.com/view/cu2d/view/Head/view/Indicators/job/cu2d-indicators-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_libusermetrics_1.1.1+13.10.20130816-0ubuntu1.diff
<sil2100> Could you take a look? ;)
<jamespage> Daviey, I've emailed upstream just to validate the approach we discussed
<jamespage> I might be missing something re userspace/kernel module compatibility
<Daviey> sil2100: Well, reviewing the packaging diff represented there - it looks like something i'd be happy sponsoring.
<sil2100> Daviey: !
<sil2100> Daviey: thank you!
<sil2100> Mirv: puublish!
<Daviey> jamespage: well.. this base approach gives us some known compatibility.. in the worsed case, we'd need to also add a raring-hwe user space tools - right?
 * sil2100 goes into slow-motion
<jamespage> Daviey, yes
<sil2100> Mirv: noooooow~!
<sil2100> Daviey: thanks!
<Mirv> sil2100: oh, you were shouting here :)
<sil2100> ;)
<cjwatson> Mirv: I'm at DebConf and I don't know much about cu2d anyway, sorry.
<cjwatson> sil2100: This process should involve verification by somebody with upload privileges, not by an archive admin (a much smaller and much more contended set of individuals)
<cjwatson> For the record
<Daviey> cjwatson: Yeah, i almost said that - but i think sil2100 knew that, as he quantified with "need some core-dev to ACK it" .. I assume it's not in a pkg set.
<Mirv> cjwatson: ok thanks anyway, and happy debconfing. and yes, the thing sil2100 asked for requires just core-dev.
<Mirv> it's good that didrocks is away for a small while before real vacation, so that we notice these beforehand :)
<sil2100> Indeed :)
<sil2100> Actually, once again we need a core-dev to ACK another packaging change
<sil2100> A quick one again
<Laney> core-devs> #ubuntu-devel
<sil2100> ogra_: hi! Are you still around?
<sil2100> ogra_: we have another near-deadline packaging ACK that needs ACKing, maybe you could help this time as well ;) ?
<sil2100> ogra_: https://jenkins.qa.ubuntu.com/view/cu2d/view/Head/view/Unity/job/cu2d-unity-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_libunity_7.0.11+13.10.20130816.2-0ubuntu1.diff
<ogra_> sil2100, i assume this has been tested (cant really judge the sed lines so i need to truset a testrun you did )
<ogra_> *trust
<sil2100> ogra_: it passed our testing (failures in the acceptance threshold)
<ogra_> sil2100, fine, then, go ahead
<sil2100> ogra_: thanks! You're a life saver
<jamespage> Daviey, ^^ updated iscsitarget for lts raring hwe kernel
<Daviey> jamespage: reviewed and ^
<jamespage> Daviey, thanks muchly!
<tkamppeter> jdstrand, hi
<jdstrand> tkamppeter: hey
<cyphermox> sil2100: Mirv: when you need a core-dev to review things before upload, that I or kenvandine can do
<cyphermox> so, for the cu2d magic that apparently is needed on lillypilly
<sil2100> \o/
<cyphermox> seems like that would be just a matter of a bzr pull for the cupstream2distro-config branch somewhere on the machine
<sil2100> cyphermox: first of all, do you have a moment for a quick pkg ACK? See #ubuntu-desktop ;)
<sil2100> cyphermox: awesome
<cyphermox> cron should be able to say exactly where, but I don't know how didrocks did it, and I don't have that kind of god powers
<Laney> needs documenting for bus factor reasons
<sil2100> Ok
<sil2100> Laney, cyphermox: https://wiki.ubuntu.com/DailyRelease/FAQ#Adding.2BAC8-removing_components_to_a_stack this documents some parts probably
<cyphermox> right
<cyphermox> it is documented, just in a non-obvious way
<cyphermox> I totally read over that without noticing >.<
<sil2100> hehe
<sil2100> Right, it's not being explicitly mentioned anywhere
<tkamppeter> jdstrand, did you have a look into the openjpeg MIR, bug 711061?
<ubot2`> Launchpad bug 711061 in openjpeg (Ubuntu) "[MIR] libopenjpeg2" [High,Confirmed] https://launchpad.net/bugs/711061
<cyphermox> Laney: so, is that wiki page enough information?
<Laney> dunno
<Laney> I don't even know what is being requested. :P
<jdstrand> tkamppeter: no. let me see if I can get someone else to do it
<Laney> cyphermox: that branch is on 608 but trunk is 655
<tkamppeter> jdstrand, OK.
<cyphermox> Laney: if you could bzr pull on that branch I suspect it will be enough
<Laney> I don't know what it means and so I'm reluctant to do so
<Sarvatt> anyone know whats up with x11-utils migration? autopkgtest for gvfs 1.17.2-0ubuntu6: RUNNING but it looks like it succeeded in jenkins unless i'm misunderstanding it
#ubuntu-release 2013-08-17
<infinity> slangasek: ^-- New base-files for your point release.
<phillw> infinity: do you know if linux-ppc [powerpc] (saucy-proposed) [3.11.0-0.1] is the kernel that will get ppc desktops back working?
<infinity> phillw: Should do, yes.
<infinity> phillw: I just smoketested it on my G3 and G5, and both work.
<phillw> great, so the cron build tomorrow should put the ppc-lubuntu testers back in the chase?
<infinity> phillw: Depending on how quickly I get it migrated, but probably yes.
<phillw> infinity: scheduled to start at 16:29 (UTC)Â  is that enough time for you?
<phillw> or would you prefer an extra 24 hours?
<infinity> Oh, indeed, it's almost a day until the next build.  Yeah, that one should be fine.
<phillw> infinity: okies, if you are sure, I will email the testers, obviously they are chomping on the bit to get back to work!
<infinity> I make no guarantees that various DRM/KMS drivers are working (I don't run consoles on any of my PPC machines, they're all servers), but these kernels at least boot on all my kit, which is a step up from the previous version. :P
<phillw> there's one sure fire way to check :P
<infinity> 3.11 includes a pretty massive changeset to the radeon driver, so that could cut both ways.  Maybe it's drastically improved, or maybe it has a ton of new bugs that break it on !x86... We'll see.
<phillw> as always, we rely on the testers to let us know :) That the promise to have a kernel that at least stood a chance of working has been kept, they will be happy and do not 'rant' over bugs.
<infinity> Well, I can nearly guarantee that it should boot on pretty much any hardware we've supported before.  Between Ben and I, we have a pretty wide array of stuff to boot and stress test on.
<infinity> It's just that he and I both only run headless servers.
<infinity> So, we'll see. :)
<phillw> the graphics cards that apple used were and are always an issue... they have gotten used to workarounds, only by letting it into the wild can these issues with the graphics cards be started to be investigated :)
<phillw> infinity: many thanks to you and ben for this work, I do know ppc for desktops is a low priority :)
<infinity> It's not the cards, per se, it's that the radeon driver has become very x86-centric, and very few people care about fixing the PPC bugs with it.
<infinity> nouveau seems to suffer fewer of those issues (for whatever reason), so the nvidia cards that Apple shipped with later G5s seem to be in better shape.
<phillw> we're still working with G3's and g4's... as long as the darn thing will boot, the graphics cards could be seen as nearly a seperate branch of their own.
<infinity> Yeah, I haven't tried running X on the ATi Rage128 in my G3 for, like, a decade.
<infinity> I assume it probably sort of works.  But I have no idea, and don't care, as it's a headless router/firewall in my house. :P
<infinity> Though, the offb driver would work for boring old 2D X.  You'd just get zero acceleration.
<phillw> Well, we should have some results in ~ 24 hours.
<phillw> oh, is it still one kernel? i.e. will the ISO still be CD sized? this is important for some of them. Julien has held back awaiting for a working kernel to be released.
#ubuntu-release 2013-08-18
<phillw> infinity: 1st report back for PPC reports as good. "The usual boot parameter was needed to get the correct color depth", excellent work guys!
<Noskcaj> phillw, YAY!
<Noskcaj> I'll try and get my mac mini going this weekend
#ubuntu-release 2014-08-11
<Noskcaj> Could someone please explain why anjuta hasn't migrated?
<cjwatson>     * i386: anjuta-extras, gnome-devel
<Laney> The following packages have unmet dependencies. anjuta-extras : Depends: anjuta (< 2:3.11) but 2:3.12.0-1 is to be installed
<cjwatson> Or in plain English, anjuta-extras needs to be rebuilt against the new anjuta; no idea if that requires source changes or not
<Noskcaj> thanks cjwatson
<Noskcaj> I think it reeds RM, i'll ask the pkg-gnome guys
<Noskcaj> *needs
<shadeslayer> could someone move kde SC 4.13.3 from trusty-proposed to trusty-updates?
<shadeslayer> https://bugs.launchpad.net/ubuntu/+source/kde4libs/+bug/1349296
<ubot93> Launchpad bug 1349296 in kubuntu-meta "SRU tracking bug for KDE SC 4.13.3" [Undecided,Fix committed]
<mlankhorst> https://launchpad.net/ubuntu/+source/xorg-server-lts-trusty/2%3A1.15.1-0ubuntu2~precise2/+publishinghistory
<mlankhorst> seems the copy in -proposed still exists?
<cjwatson> Normal
<cjwatson> Shows up for cleanup on http://people.canonical.com/~ubuntu-archive/pending-sru.html
<mlankhorst> ah
<cjwatson> Will be fixed if I ever get round to finishing my move-package LP branch
<cjwatson> Removed now
<cjwatson> shadeslayer: seems to still be at only 6 days aged per pending-sru
<shadeslayer> oh ok
 * shadeslayer thought it was at the 7th day today
<cjwatson> might roll over later today I guess, haven't checked
<rtg> can an AA please approve the Utopic linux binaries ?
<cjwatson> rtg: doing
<rtg> cjwatson, thanks
<apw> i assume the reason that publishing seems sluggish is it has been haskeld
<cjwatson> I wouldn't expect so; that's only in -proposed
<apw> britney looks to be running much less often than i was expecting, if i am reading the logs right, i thought it was per publisher run
<cjwatson> the most recent one apparently took a while to publish a libav security update
<apw> ahh, where is my instant gratification, where; /me goes find some patience
<cjwatson> apw: there is some slowness but it actually appears to be due to libass
<cjwatson> guess I should chase that down ...
<apw> :) that brightened my day
 * cjwatson adds a transition tracker config for it
<bdmurray> infinity: its monday so I'm going to flip the lts upgrade switch okay?
<doko> ScottK, are you the one to overwrite the cantor autopkg test?
<infinity> bdmurray: If you're aware of no new reasons not to (I'm not), let's do it!
<infinity> bdmurray: I'm sure we'll get a nice crash spike and new bugs once you flip the switch, but we'll cross that bridge when we get there. :P
<jamespage> arges, if you have some time all of 2014.1.2 is now in the trusty proposed review queue - bug 1354159
<ubot93> bug 1354159 in nova "[SRU] icehouse 2014.1.2 point release" [Undecided,New] https://launchpad.net/bugs/1354159
<bdmurray> infinity: there is this version of the release upgrader still in -proposed for trusty ... https://launchpad.net/ubuntu/+source/ubuntu-release-upgrader/1:0.220.3
<infinity> bdmurray: Do we need that?  103 days without verification isn't comforting.
<bdmurray> infinity: well, the problems it fixes in the error tracker, but a couple look like people would encounter them
<infinity> bdmurray: Well, if you want to dig deeper into all those bugs and why they're unverified and/or failed, be my guest. :/
<ScottK> doko: Yes.  Want me to drop it?
<ScottK> Actually, I did already.
<bdmurray> infinity: I've looked around some more at that version of the release upgrader and think they are mostly corner cases
<infinity> bdmurray: Mmkay.  Would still be good to get mvo on looking at the verification failures and helping decide what to do with it, since it's not doing us any good in proposed, but I don't think we should block on it.
<doko> ScottK, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html  I want you to fix the autopkg test
<ScottK> doko: The problem is that the maxima backend test has never worked.
<doko> ScottK, well, then re-add the unblock
<ScottK> OK.
<doko> or remove the autopkg test
<ScottK> doko: Done.
#ubuntu-release 2014-08-12
<slangasek> bdmurray, infinity, stgraber: ^^ urgent-ish fix for a precise->trusty upgrade issue
<RAOF> slangasek: Want me to take a look?
<slangasek> RAOF: sure :)
<RAOF> Yeah, that looks urgentish :)
 * stgraber was just about to look at it
<slangasek> ta
<arges> jamespage: i can take a look today
<arges> re: openstack packages
<jamespage> arges, ++ thanks
<michagogo> arges: fyi, the bitcoin SRU should hit 7 days in about 3 hours
<arges> michagogo: ok i'll take a look this afternoon then
<michagogo> And it has a second bug mentioned on http://people.canonical.com/~ubuntu-archive/pending-sru.html, apparently from a previous SRU that was dropped because it never got verified
<michagogo> Since this SRU is to remove the package, it's safe to ignore the second bu
<michagogo> g
<arges> michagogo: yea i adjusted that already
<michagogo> arges: Ah, great. Thanks!
<arges> jamespage: re: cinder upload. I noticed that the changelog versions have been re-written, wondering why that was. but it may be more of a question for coreycb
<jamespage> arges, that's a mistake if so - I though we had that resolved - let me look
<jamespage> arges, please reject that - well resolve
<arges> jamespage: danke
<arges> jamespage: also look at the ChangeLog file looks like that got edited a bit
<arges> jamespage:ok rejected
<arges> jamespage: neutron appears to be suffering from the same changelog issues
<arges> i'll let you take alook before i reject it
<jamespage> arges, revised cinder uploaded
<jamespage> arges, reject neutron pls - have a fixed changelog version
<arges> jamespage: will do
<michagogo> arges: looks like it changed over
<arges> michagogo: ok done
<michagogo> arges: TYVM!
<arges> jamespage: coreycb : please re-upload neutron. there were some odd changelog issues
<coreycb> arges, ok, I think james is going to have to do that
<arges> coreycb: also for nova why is nova-2014.1.1/debian/patches/Fixes-rdb-backend-image-size.patch dropped, but its not explained in the changelog?
<coreycb> arges, that's a mistake in the changelog.  the patch was dropped because it's fixed upstream.  we can re-upload nova to fix that.
<jamespage> arges, coreycb: neutron re-uploaded with corrected changelog
<coreycb> jamespage, thanks.  see the nova issue?
<jamespage> coreycb, want to update the changelog and propose? I'll review later or tomorrow AM
<coreycb> jamespage, sure, will do
<coreycb> jamespage, here's the nova mp -- https://code.launchpad.net/~corey.bryant/nova/2014.1.2/+merge/230538
#ubuntu-release 2014-08-13
<rtg> infinity, would mind rejecting linux-firmware-free for precise and trusty ? I didn't get the whole job done right.
<rtg> would you*
<infinity> rtg: -nonfree, you mean?
<rtg> infinity, yup. I've since uploaded a newer version with FTBS fixes.
<infinity> rtg: CHeck.  Rejected the old ones.
<rtg> infinity, thanks
<Riddell> how come there's no trusty daily builds? http://cdimage.ubuntu.com/kubuntu/trusty/daily-live/ same for ubuntu.  I need to verify an SRU
<infinity> Riddell: Because I didn't turn them back on after the point release to avoid clashing with the precise one, should probably turn them all back on now.
<infinity> Riddell: Thanks for the nudge.
<infinity> Riddell: Installer SRU, or is there some reason it needs an ISO to validate?
<Riddell> infinity: yeah installer
<Riddell> ubiquity-dm too, not easy to run on an installed system
<infinity> Riddell: precise and trusty re-cronned.
<Riddell> thanks
<asac> 22:05 < asac> infinity: hey, i see https://launchpad.net/ubuntu/+source/llvm-toolchain-snapshot failed to upload on i386
<asac> 22:05 < asac> do we need to give that back? can you do?
<asac> anyone else from -release knows?
<asac> stgraber: ^
<mlankhorst> can someone force through mesa? it will probably fail to build on that arch that doesn't have llvm 3.4
<mlankhorst> then again, not seeing anything wrong atm
<infinity> mlankhorst: Why would we expect it to fail?  It built on all arches in trusty.
<mlankhorst> no idea tbh, i just assumed it would because someone wanted me to flip to 3.5
#ubuntu-release 2014-08-14
<doko> can somebody please overwrite the libncursesada check? it's not in the release pocket anymore, and blocks ncurses
<doko> stgraber, ^^^
<stgraber> doko: done
<doko> thanks
#ubuntu-release 2014-08-15
<ari-tczew> can someone take a look on package https://launchpad.net/ubuntu/+source/bijiben/3.12.2-1 what's going on with that one? will be deleted, or try to build?
<doko> ScottK, Riddell: please could somebody fix the kstars and kactivities autopkg tests? seems to be unrelated to gcc-4.9, but rather the new kde upstream
<Riddell> doko: gotcha, will investigate
<jamespage> thanks arges!
<arges> jamespage: np
<xnox> doko: may i drop zsh from main? or can yodl be MIRed please?
<infinity> xnox: Dropping zsh from main will likely make some people grumpy.
<xnox> infinity: it will also make people happy, cause it would be non-broken, with correctly generated docs and updated more often =)
<xnox> infinity: i only see shutil2 having a build-dep-indep on zsh to run tests (can be converted to dep-8 if really needed) & seed in development-common seed...... but it's a fetish to promote zsh to developers =)
<infinity> xnox: It's been in main pretty much since the dawn of time as it's a lot of people's default shell.
<infinity> xnox: Just because I don't use it doesn't make that any less true.
<xnox> infinity: yeah, and it would be sad when someones shell drops off from updates cause they happen to have a main only install.
<xnox> infinity: ok, so how about promoting yodl to main?
<infinity> xnox: If you feel strongly about it, file an MIR and argue the case?
<xnox> infinity: 2012 called, and wants it's mir processed =) https://bugs.launchpad.net/ubuntu/+source/yodl/+bug/920436
<ubot93> Launchpad bug 920436 in yodl (Ubuntu) "[MIR] yodl" [Undecided,New]
<infinity> xnox: And for icmake
<infinity> Oh, look, that's there too.
<xnox> cm-super-minimal is in main in utopic.
#ubuntu-release 2014-08-16
<Saviq> can anyone please re-run the qtcreator-plugin-ubuntu adt http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity8 ?
<Saviq> Mirv, I saw you around, so will harass you â can you restart adt jobs? or know someone who can?
<Saviq> jibel, thank you! (for unblocking u8)
<Mirv> Saviq: I already mentioned on #ubuntu-devel that unity8 is stuck and whether someone is able to restart those, but no I do no thave access to kick those jobs for a rerun
<Mirv> (right, fixed)
#ubuntu-release 2015-08-10
<darkxst> can we get Ubuntu GNOME ISO size limits bumped up to 1.5GB?
<slangasek> infinity: well, I pulled in your changes from trusty but that's insufficient, because it goes on to install the ubuntu-live task which also includes various other conflicted libraries
 * didrocks wonders when slangasek isn't working
<slangasek> didrocks: weekends when we're not in the critical path of a terrible g++ transition
<didrocks> slangasek: good luck! if you need any new hands, this week should be better for meâ¦
<slangasek> didrocks: the transition tracker has huge piles of libraries that we haven't started the rebuilds for yet, dig in :)
<didrocks> slangasek: will do! :)
<arges> infinity: would you be terribly inconvienced if I reviwed the openstack uploads in vivid today
<infinity> arges: Why would I be inconvenienced if you did my job for me? :P
<arges> infinity: : )
<Laney> slangasek: Had a go at implementing de-duping for the tracker
<slangasek> Laney: de-duping?  you mean for the new-binary-package-name case?
<Laney> Yep
<slangasek> Laney: ok.  tdaitx was also looking at this on Friday (and this morning), if you want to compare notes
<tdaitx> Laney, http://paste.ubuntu.com/12047242/ and http://paste.ubuntu.com/12047866/
<tdaitx> in short: if a source package (in Source file) appears more than once, all binaries ("Binary:" field) it declares are removed from Package_arch file except for the ones in the latest (ie. highest version) source package
<infinity> tdaitx: You can't (reliably) map in that direction, though.  Some source packages lie aboutt he binaries they produce and we don't enforce consistency.
<tdaitx> Laney, slangasek said "I can see that this approach will mask per-architecture build failures, for instance, which I suspect is not what the release team wants"
<infinity> tdaitx: The only reliable mapping is the Packages file.
<tdaitx> oh
<infinity> tdaitx: It might be good enough for a hack today, mind you.  JUst saying that it's not accurate for all source->binary mappings, since we're trusting the source package not to lie.
<tdaitx> indeed
<infinity> tdaitx: The inverse (checking the Source: field on binaries in Packages) is always correct.
<Laney> I grabbed the source packages from -proposed's Packages file and then ripped those out of release's
<infinity> tdaitx: With the hilarious caveat that binaries whose name matches their source don't have a Source field, so you have to check for Source not being set and assume Source==Package
<infinity> tdaitx: All that said, Laney's solution is probably simpler. :P
<infinity> tdaitx: But, y'know, consider the above a lesson in apt source parsing in general.
<tdaitx> Laney, I tried that, but ben does look at the binaries in Packages_arch
<tdaitx> I mean, it does what infinity suggested: grab the Source from the binary
<Laney> Yep
<Laney> I only look at Packages
<Laney> (and write to)
<Laney> anyway, sorry for duplicating your work - I wasn't aware :(
<tdaitx> np
<tdaitx> Laney, in short: you grab all Source fields from -proposed Packages and proceed to remove the binaries in release Package that have the same Source?
<Laney> Right, and fall back to Package if Source isn't there
<Laney> Then spit proposed and release out as Packages_arch
<Laney> Tool of choice was grep-dctrl
<slangasek> Laney: are you doing it on a per-arch basis?
<tdaitx> nice, Laney can you send me the script? I would like to compare what they are (not) ripping out
<infinity> You'd have to, to get it right.
<Laney> Yep
<Laney> tdaitx: It's in go on snakefruit, if you have access
<tdaitx> not sure I do
<Laney> I would bet it has some bugs :)
<Laney> ok
<infinity> tdaitx: You'll probably find Laney's approach and your approach tearing out the same packages (hopefully), because there aren't many source->binary liars in the archive.  If the kernel is in proposed, though, I know it lies. :)
 * Laney VPNs it up
<infinity> (Which is a bug, but it's also a bug that we have no lie detection, so it's allowed to)
<infinity> Laney: He doesn't have snakefruit, no, I've tried to impress upon IS the importance of not randomly handing out sensitive groups/hosts to people without asking, so I'd be miffed if he did. :P
<Laney> tdaitx: http://paste.ubuntu.com/12048720/
 * tdaitx wishes to had known about grep-dctrl
<infinity> tdaitx: By the way, grep-dctrl.  HTH.
<tdaitx> yeah
<tdaitx> that =)
<Laney> There's certainly some golfing to be done there. :P
<Laney> zcatting the same thing twice, oh my
<infinity> Laney: The second one will be near instant, probably, but yeah, a bit eww.
<infinity> Laney: And, of course, at that point, output == proposed (doesn't it?), so you could do your filter on output instead.  Which will be in cache.
<infinity> Yeah, that's the first write to output.
<Laney> Feel free to go shrink it. ;)
<infinity> Laney: I don't much care, it'd save half a second, at best.  Was just engaging in your optimisation thought exercise. :P
<infinity> (Also, what have I become where I don't think saving half a second is huge?  I hate modern computing...)
<slangasek> infinity: well when you get old and your reaction time slows to 5 seconds for anything...
<infinity> slangasek: Touche.
<tdaitx> Laney, infinity, slangasek: packages kept only by Laney's script *or* mine for amd64, ppc64le, and all archs @ http://paste.ubuntu.com/12049566/
<tdaitx> hopefully this can tell if either script is removing something that it shouldn't
<infinity> tdaitx: Well, you can spot-check that with "rmadison <package>" on a few and see what reality says about the situation.
<infinity> tdaitx: If it exists in both suites and one of you is removing it, you have a bug.
<tdaitx> infinity, thanks, that's a good tip
<slangasek> tdaitx: or, for example, if I look at the first package in that list, ruby-gdk3-dbg: ruby-gdk3-dbg comes from ruby-gnome2 source package, ruby-gnome2 source exists in wily-proposed but is not built on any arch; so this should not be removed, laney's script is correct for this one
<slangasek> tdaitx: and then you get down to line 13, libsigc++-2.0-0c2a built from libsigc++-2.0 source, which exists in wily-proposed, is built for all architectures, and no longer includes this binary package - so your script is the correct one ;)
<tdaitx> slangasek, I have also confirmed that my script is removing binaries that exist in both series (wily and -proposed), but so far there is another package available from the same source, example: removing libcdr-0.1-1 (wily and -proposed) but keeping libcdr-0.1-1v5 (-proposed)
 * doko looks for gcc-5 5.2.1 in -release ...
<slangasek> tdaitx: in that case, there are two versions of the source package in wily-proposed, and the latest version has dropped the libcdr-0.1-1 binary (in favor of libcdr-0.1-1v5).  So it's correct to remove
<infinity> slangasek: If there are two versions in -proposed with differing binaries, that confuses britney until someone processes the NBS manually (I'll do that).
<infinity> WOuldn't be shocked if it confused other things too.
<slangasek> infinity: sure, but "something gets confused" is different from "it should be on the transition tracker"
<infinity> slangasek: Yeahp, just saying it's harder to sort out those cases correctly sometimes. :)
 * infinity finds libcoverartcc1 in the same state and fixes.
 * infinity hunts for more.
<tdaitx> slangasek, ruby-gdk3-dbg is on wily's Sources Binary: field, but not on -proposed's Source Binary: field, is this one case where the Binary: field from -proposed is lying/wrong?
<slangasek> tdaitx: no, my point is that the package has not been built in wily-proposed yet so it shouldn't be taken off the transition tracker because it's not "done"
<tdaitx> oh
<slangasek> this is different than infinity's point that the Sources may lie, but leads to the same conclusion
<tdaitx> is that the reason it does not show in -proposed's ruby-gnome2 Binary: ? because it was not build yet?
<infinity> This whole "sync first, then rename" caused quite a mess...
<infinity> Okay, I think I got all the NBS in proposed.
<infinity> At least, all the rename-related NBS.
<infinity> slangasek: http://paste.ubuntu.com/12049946/ cleaning up that might help a bit.
<infinity> Hopefully we don't see too many more "try to build, then rename later" shenanigans.
<infinity> s/build/rebuild/
<doko> infinity, did you see my gdb ping?
<infinity> doko: I did, yeah.  Rebuilding it and will ask a WeBop to babysit when it stalls again.
<infinity> doko: Not exactly an ideal workflow going forward, mind you.
<doko> sure, I can disable the testsuite, which isn't ideal either.
<infinity> doko: Quite.  Disabling the one test might be okay.  Finding out why it explodes might also be nice.  gdb still tries pretty hard to kill my ppc builders too.
<infinity> Not that any of that is gdb's fault, it's clearly kernel bugs.
<infinity> doko: Anyhow, we'll do the hackish thing for today.
<doko> is oftc irc down? can't connect
<teward> doko: up for me
<ScottK> doko: Working here.
<doko> hmm, nslookup irc.debian.org fails for me from germany, brazil,
<teward> doko: nslookup on irc6.geo.oftc.net
<teward> (irc.debian.org is a CNAME to that)
<teward> ooop
<teward> doko: actually, looks like OFTC's dns is possibly blown up
<doko> no, doesn't work either
<teward> yeah it shouldn't
<doko> ok, will wait
<teward> http://paste.ubuntu.com/12050243/
<teward> SERVFAIL
<teward> doko: i could give you the v6 addr for one of their servers now if you want.  don't have v4 because it's connected to my bouncer, but..
<teward> until they fix DNS anyways
<doko> getting food first =)
<teward> mmkay
<infinity> doko: Curious.  The testsuite didn't hang on armhf this time.
<slangasek> ok, that's strange, I just reloaded http://people.canonical.com/~ubuntu-archive/transitions/html/icu.html and mediawiki2latex has dropped off of there when it shouldn't have
<slangasek> has someone deployed changes to snakefruit?
<slangasek> (Laney?)
<slangasek> oh, no, I see, someone actually fixed mediawiki2latex
<slangasek> tricky
<teward> doko: apologies for discussion derailments.  But, in the interim: i've made a note to OFTC that their DNS is explodified.  sarnold poked that up to people there.  beauty.oftc.net is 2604:a880:800:10::870:a001 port +6697 and is up, although DNS won't resolve because i think their DNS exploded.
<slangasek> and that was Laney too, right attribution wrong change ;)
<teward> in case anyone else here with v6 who needs to get to OFTC needs to get there... :P
<slangasek> ok, now this one is *not* due to a fix... mrtrix is broken and FTBFS on armhf, but no longer shows up on http://people.canonical.com/~ubuntu-archive/transitions/html/gtkmm2.4-g++5.html
<Laney> My thing totally broke for packages which contain "+" :)
<Laney> I avoided using regex now...
<slangasek> heh
<slangasek> Laney: did you deploy any changes to snakefruit, though?  I'm trying to figure out why mrtrix is gone from the tracker
 * Laney looks
<Laney> it's showing as unknown
<slangasek> hrm
<Laney> for armhf
<Laney> but why?
<Laney> oh, because I made it remove the old binaries from Packages - this seems suboptimal
<slangasek> ok; so the filter is wrong, 5 good + 1 unknown should still show when 'unknown' is checked, surely
<slangasek> and looking at the package in the archive, it doesn't look 'unknown' to me
<slangasek> ah, so you did deploy a change :P
<slangasek> Laney: are you reverting this?
<Laney> Thinking
<slangasek> Laney: please revert this ;)
<doko> slangasek, xnox: any news about the boost1.58 rebuilds?
<doko> teward, oftc works again
<slangasek> doko: I haven't been tracking boost, I assumed xnox was doing something with it and that I'd just get in the way if I tried to trigger rebuilds
<teward> doko: their DNS just came back up yes
<teward> doko: in any case if it breaks in the future https://pbin.dark-net.net/view/raw/0411bee5 is a 'good server' for now
<teward> (that'll be there for a week, that pastebin)
<slangasek> xnox: the scripts I have on hand for batch-uploading don't map to boost, should I hack up a new one or do you have something scripted to go on your side?
<tdaitx> slangasek, please try to rebuild notmuch, I tried a local build and it went ok
<tdaitx> robru, ^ in case you can also trigger a rebuild for notmuch
<robru> tdaitx: so far I trigger rebuilds by asking slangasek to do it ;-)
<tdaitx> robru, alright then, I will keep pestering him about it
<tdaitx> robru, slangasek, as for the ceph issue, here is the bug (with fix): http://tracker.ceph.com/issues/11576
<robru> cool
<slangasek> tdaitx: any idea what changed that would make notmuch work again?  FWIW I did previously reproduce the build failure locally against wily-proposed
<tdaitx> slangasek, nope, I tried to reproduce it locally and it build ok
<slangasek> ok. I'll retry it in launchpad
<tdaitx> I saw that my env had newer packages and that's it
<robru> tdaitx: slangasek: https://github.com/ceph/ceph/pull/5122/files so I guess we need to distropatch this fix onto our existing package?
<robru> or pull a newer upstream?
<slangasek> robru, tdaitx: the ceph package is owned by the server team and in main, we shouldn't take it upon ourselves to pull a new upstream version without coordinating with them.
<slangasek> tdaitx: if you have a patch for ceph, you might want to throw it in the direction of smoser
<slangasek> (e.g. on #ubuntu-devel)
<doko> tdaitx, LP: #1483403
<ubot93> Launchpad bug 1483403 in ceph (Ubuntu) "ceph FTBFS with boost1.58" [Critical,Confirmed] https://launchpad.net/bugs/1483403
<slangasek> ah yes, so posting the patch there and letting the server team pick it up seems like a good approach
<doko> tdaitx, not much luck
<doko> slangasek, why didn't you mark clementine and notmuch as removal candidates?
<slangasek> doko: notmuch because it has revdeps and is popular so I wasn't considering it a removal candidate, but that doesn't mean it can't be removed. clementine, I don't know why ;)
<slangasek> doko: oh, because the clementine issue is a trivial fix, that's why
<slangasek> doko: #ifndef Q_MOC_RUN // #include <boost/thingy.hpp> // #endif
<doko> slangasek, yeah, was talking with sitter about that for kdepim as well
<doko> slangasek, debian seems to close many transitions as not needed. with their next sourceful uploads, these will appear again in -proposed (because the old binary is still there). how could we avoid this?
<slangasek> doko: track the ones that are closed as not-needed, we should revert the package name transitions and add a Provides: libfooNv5 for compatibility
<slangasek> possibly even a Provides: libfooNv5 (= $version), since I hear that works now with apt/dpkg in vivid and wily
<slangasek> then we rebuild the revdeps (again) if necessary, but it can be a soft transition
<slangasek> strange, why did numexpr just get into wily? (python3.5 no-change rebuild uploaded 19 days ago)
<slangasek> because p-m+autopkgtest went wrong
<tdaitx> notmuch rebuild failed... hmm, I wonder what is "wrong" with my local sbuild
<slangasek> tdaitx: is your local sbuild configured to build against wily-proposed, or only against wily?
<tdaitx> I had a wily that had proposed disabled, but I installed/made a new one that includes proposed
<tdaitx> or at least I thought I did, will check that... again
<slangasek> ok
<tdaitx> slangasek, apologies, how can I be sure my schroot is indeed running -proposed? it does show in apt sources.list and I can see gcc5 5.2.1 (instead of 5.1..1)
<slangasek> tdaitx: well, those are the things I would check also so it sounds like you're there
<slangasek> tdaitx: are you running the build under sbuild?
<tdaitx> right
<tdaitx> yes, I am
<tdaitx> I will try another build after ceph is done
<tdaitx> meanwhile I will compare the build logs
<slangasek> doko: is openvdb on your radar?  your last upload went from 4 archs failing with .symbols mismatch, to 6 archs failing with .symbols mismatch
<doko> slangasek, ok, I'll look
<tdaitx> slangasek, what's the right way to fetch the package? I'm using  pull-lp-source <pkg> wily-proposed
<infinity> tdaitx: You just need "wily", it'll magically pick the latest version from wily{-updates,-security,-proposed}
<infinity> tdaitx: Or indeed, no argument, which defaults to the dev release, which is wily.
<tdaitx> the version matches, but I can see a few differences in the build logs that made me wonder if I actually have the same thing
<infinity> tdaitx: Such as?
<infinity> tdaitx: Could be as simple as you comparing a -A build with not. (ie: amd64 on LP builds -A, while all other arches don't, and the sbuild default is withuot, IIRC)
<doko> infinity, tdaitx: so notmuch succeeds locally here in fresh sid and wily-proposed chroots, with the wily-proposed kernel running
<tdaitx> meh, not such meaningful changes actually... setup.py running files in a different order (might be ok actually), a few different packages being installed...
<tdaitx> doko, succeeds locally here as well, 3.19.0-25-generic
<infinity> doko: Yeah, confirmed here too.  So we might just need to disable that one test when run on << 3.19
<infinity> Except... That's still sketchy.  Cause it built BEFORE all these rebuilds.
<infinity> And the kernels weren't downgraded. :P
<infinity> Oh, not in this version, though.  Maybe that test is new.
<infinity> Yeah, okay, same test was failing before the transition too.
<tdaitx> infinity, any chance we can get a set -x in that test/T160-json.sh script? at least to see where exactly it is failing?
<infinity> tdaitx: Not easily.
<infinity> tdaitx: Not without uploading to a PPA with said hack in place.
<infinity> So, that's kinda suspicious.  It was working with 0.17-3, started failing with 0.17-5 ...
<infinity> It's possible the packaging broke, but seems more likely that coincides with a dependency breaking.
<infinity> Especially since the packaging didn't change meaningfully between those versions.
<tdaitx> infinity, sorry, how did you tell it started failing with 0.17-5?
<infinity> tdaitx: Drilled back through publishing history until I found the earliest one with failures.
<infinity> tdaitx: https://launchpad.net/ubuntu/+source/notmuch/0.17-5
<infinity> And there are zero changes between -3 and -5 to account for it, so it has to be something else than changed (a dep, toolchain, etc)
<infinity> Same kernel on both builds too.
<doko> the toolchain doesn't have bugs, it only exposes some
<infinity> doko: Uh huh. :)
<doko> well, at least until now I didn't see one for GCC 5
<infinity> doko: This isn't gcc-5, this has been breaking since trusty.
<infinity> Or, utopic rather.
<doko> yeah, some people are behind with merges ...
<infinity> doko: This has nothing to do with merges.  It's a package without a delta whose autosyncs have been failing for two years.
<infinity> tdaitx: Your sh -x request: https://launchpad.net/~adconrad/+archive/ubuntu/ppa/+build/7782298
<robru> infinity: any low-hanging fruit you can throw my way? I just got a succesful build of clementine and mailed the debdiff to slangasek
<infinity> robru: No idea, I'm not on top of the transition stuff, since I wasn't involved last week.
<robru> heh, he told me you'd know since he's afk briefly
<infinity> robru: He lied. :)
<robru> well, anybody else know any easy transition bits for a noob to poke at?
<slangasek> infinity: I said that you would be able to guide, which I have every confidence in even if you don't already know ;)
<robru> he's back!
<slangasek> robru: try libktorrent, same basic issue as clementine
<robru> thanks
<tdaitx> infinity, bummer, I was setting up my ppa =P
<tdaitx> infinity, anyway, it is stuck in a loop... it seems to be missing at least one dependency
<infinity> Oh, maybe the reason it works locally is because my local schroot is a tiny bit fatter than the lp-buildd chroot tarballs.
<infinity> Bah, we still don't have "apt-get build-dep foo.dsc"
<infinity> Must be in apt 1.1
<tdaitx> I am not sure, mine is supposedly very slim
<tdaitx> and it still passes
<infinity> tdaitx: Testing a theory on the one thing I guarantee is different.  Sec.
 * tdaitx still waiting for ceph to finish... doh, forgot parallel build! to kill or not to kill?
<infinity> tdaitx: My .bashrc has this at the end, so I never have to think about it:
<infinity> export DEB_BUILD_OPTIONS="parallel=$(nproc)"
<tdaitx> indeed
<infinity> Hrm, purging locales didn't break it.  That was my one good guess.
 * infinity compares an entire dpkg -l with the build log.
<tdaitx> so... after uploading to my ppa, how long does it usually take for the builders to grab it?
<infinity> Bah.  Literally identical set of packages installed, still no failure.  Not we're in the realm of the bizarre.
<infinity> tdaitx: Depends on queue depth.
<infinity> tdaitx: Though, generally, you have to actually upload something first.
<infinity> (I see nothing in your PPA)
<ScottK> Now you're getting demanding.
<infinity> ScottK: I know, I'm a stickler.
<tdaitx> infinity, but I did run dput and it said the world was good and peaceful
<tdaitx> did it lie?
<infinity> tdaitx: dput just fires and forgets.
<infinity> tdaitx: You either (a) have a REJECT email, if your upload was unacceptable, or you (b) have zero feedback at all if you forgot to sign your upload.
<infinity> I'm betting on B.
<tdaitx> I did sign it, dput checked that
<infinity> Then check your email. :)
<infinity> (I'm going to assume you signed it with the same key LP knows...)
<tdaitx> infinity, indeed, it was rejected
<tdaitx> oh yeah, from the command line it seemed like dput checked even that
<infinity> dput just checks that it's signed, period, not who it's signed by.  Though, if you got a reject, it was the right key.
<infinity> And something else was wrong.
<tdaitx> right, I cant submit to wily-proposed
<infinity> Yeah, get out of that habit anyway.
<infinity> The correct thing to upload to is always just "$release".
<infinity> For PPAs without pockets, that works, and for the primary archive, we map $release to $release-proposed on the server side.
<tdaitx> nice
<tdaitx> infinity, ha! I was able to reproduce the issue locally
<infinity> tdaitx: !
<tdaitx> infinity, TERM="unknown" sbuild
<infinity> Ahh!
<tdaitx> dtach does not like an unknown term
<infinity> Also, balls.  That means our term setup is different from Debian's, where it succeeded on all buildds.
<tdaitx> I have been bitten by that I don't remember how long ago
<tdaitx> yes
<tdaitx> mine was rxvt-unicode, from my own term
<infinity> Looks like Debian isn't explcitly setting TERM at all, so hard to say what setting is leaking through.
<infinity> I guess whatever the buildd pid has.
<infinity> Man, and we tried to hard to be 100% compatible. :P
<infinity> I even remember when we made this change (which coincides with when this build started failing).
<infinity> For now, though, a delta to call the testsuite with TERM=vt100 or something will probably work.
 * infinity tries.
<tdaitx> infinity, yeah, that should do it... vt100 or even xterm (I can see it installed on my failed build session)
<infinity> Already testing vt100, so if that works, that wins.
<tdaitx> or linux
 * tdaitx is somewhat happy to have battled against dtach on the past
<robru> hey release peeps, I've analyzed http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gcc-5 and found that kservice, libktoblzcheck, kdeclarative, autopilot-gtk, step regresions are more recent than the gcc5 upload (eg, those autopkgtests passed with the initial gcc5 upload then failed later for other reasons)
<robru> infinity: ^
<infinity> tdaitx: Okay, confirmed that this works: http://paste.ubuntu.com/12052461/
<infinity> tdaitx: Will upload after making the changelog more manager friendly.
<tdaitx> infinity, great =)
<tdaitx> oh yeah, be "nice" on the changelog
<infinity> tdaitx: Thanks for the analysis!
<infinity> robru: Your analysis, I'm less sure what to do with.  If those are new failures, we kinda still need to know why.
<robru> infinity: yeah I'm not really sure either. slangasek asked me to look into that. apparently the ones I listed shouldn't block the gcc5 transition
<tdaitx> infinity, you are welcome =)
<slangasek> infinity: yes, this is for unblocking gcc-5, not for ignoring the failures wholesale
<tdaitx> ceph just passed locally
<tdaitx> one, two down... one, two to go...
<infinity> slangasek: Check.
<infinity> robru: So, are those the only regressions britney's hating on?
 * infinity looks.
<robru> infinity: no there's other regressions
<infinity> Right, in that case, not much I can do about it yet.
#ubuntu-release 2015-08-11
<robru> infinity: do you want the list of regressions that actually correspond with the gcc5 upload?
<infinity> Since the way we give gcc-5 a pass is to tell britney to ignore all gcc-5 related tests.
<infinity> Which I won't do until we're sure all the ones we care about are good.
<robru> ah
<infinity> (The other way is to ignore tests for specific packages, but that gives those regressions a pass, which we don't want)
<infinity> Some of these might be flappy weirdness.
 * infinity retries a few.
<infinity> ... after I read pitti's mail about how to retry.
<slangasek> is there a hand gesture to go with "flappy weirdness"?
<infinity> slangasek: Imagine Kermit flailing.
<tdaitx> doko, should we create a bug report for LP: #1483403 in Debian as well?
<ubot93> Launchpad bug 1483403 in ceph (Ubuntu) "ceph FTBFS with boost1.58" [Critical,Confirmed] https://launchpad.net/bugs/1483403
<cyphermox> so, where should I start to help with gcc5? I have the pad open but I'm not quite sure where to begin
<tdaitx> cyphermox, still looking where to help on gcc5?
<tdaitx> cyphermox, anyway, the stuff at the bottom is more recent, so you can start there
<tjaalton> I wonder if xcb-util could be dropped from NEW before we have a unwarranted diff against debian
<tjaalton> an
<RAOF> tjaalton: Pretty sure the answer is âyes, but I'm not meant to press that buttonâ
<tjaalton> riight
<tjaalton> ok
<tjaalton> I'll wait for a reply first..
<tjaalton> from the uploader :)
<tjaalton> before doing anything myself
<tjaalton> the only thing being reverting the change from the debian branch
<infinity> tjaalton: What diff do we not want?
<tjaalton> infinity: renaming libxcb-util
<tjaalton> well, pkg-xorg doesn't wan't the transition on debian, because it's pointless
<infinity> tjaalton: It's not renamed because the SOVER changed?
<tjaalton> the sover has been like that for ages
<infinity> I mean, 0 -> 1 seems pretty clear.
<tjaalton> hmm
<tjaalton> or I'm completely wrong
 * infinity looks at actual contents.
<tjaalton> meh
<infinity> Yeah, it really did bump SOVER.
 * tjaalton woke up at 4am
<infinity> Not renaming would be very wrong. :P
<infinity> Hah.  That's something you don't see every day.  kwayland-integration was FTBFS on everything except arm64.
<flexiondotorg> Laney, who can help promote deja-dup-caja out of the NEW queue for wily/
<flexiondotorg> ?
<Laney> ~ubuntu-archive
<darkxst> Laney, how often do the packageset scripts run?
<darkxst> (for seeded stuff)
<Laney> manually, I run it once a week or so
<darkxst> Laney, manually automatic ;) can you run it this week some time ? to pick up gnome-getting-started-docs
<Laney> it means that the sets aren't managed by hand
<Laney> will run it now if you want
<darkxst> Laney, that would be good, images took a 120MB hit from seeding it
<darkxst> though that in itself its not a huge problem, at this point, but want to be able test langpacks are getting installed correctly before B1 hits
<Laney> need to fix this script to not rsync ALL the dists/wily-*
<lamont> I want to get bcache-tools into trusty/precise...  I'm guessing that I probably did wrong in 1429857 and actually just want to upgrade 1449099 from wishlist? or progress it anyway...
<lamont> what's the next step for me here, really, oh mighty release gods?
<infinity> lamont: precise seems a bit much.
<infinity> lamont: But if it builds cleanly on a straight backport, meh.
<infinity> lamont: If so, then we just need SRUs of said backports from vivid (versioned as 1.0.7-1~14.04 and 1.0.7-1~12.04)
<infinity> lamont: Given that the package didn't exist before, there's no regression chance, so the backport is not really problematic, but do put a test plan in the SRU bug for how you intend to validate that it's working on both releases.
<lamont> infinity: lts kernel on precise... :(
<lamont> infinity: ack
<lamont> ta
<tseliot> infinity: any updates on nvidia-352{-updates} ?
<slangasek> sigh; jackd2 has a wrong symbols file (seemingly generated out of nowhere), so all the jackd2 rebuilds have to be redone
<slangasek> oh, d-shlibs again.  thanks Jonas
<slangasek> except... d-shlibs isn't used in the build either
<slangasek> Laney: it looks like the go script has been updated again, considering some of the things dropping out of the list.  How confident are we that this is correct, before I start culling the list of in-progress transitions?
<Laney> slangasek: Indeed, I deployed a new version --- moderately confident? :)
<slangasek> heh
<Laney> I fixed the problems I knew about and have verified some transitions today
<slangasek> ok so no symbols file in libjack-jackd2-0v5 at all, just a shlibs file and the shlibs file looks correct.  Brilliant
<Laney> Got an example of a bad package? Second pair of eyes might be helpful?
<slangasek> Laney: every darn thing on http://people.canonical.com/~ubuntu-archive/transitions/html/jackd2-g++5.html
<slangasek> I'm starting from the zynjacku end
<slangasek> oh of course
<slangasek> it pulled in libjack-dev instead of libjack-jackd2-dev at build time
<slangasek> a) why do we still have two of those things, b) that obviously won't work if the ABI has changed so either there's no ABI transition or libjack is now bustificated
<slangasek> doko: how did you determine that jackd needed an ABI transition?
<doko> slangasek, https://people.debian.org/~doko/logs/gcc5-20150701/jackd2_1.9.10+20140719git3eb0ae6a~dfsg-2_unstable_gcc5.log
 * Laney cries at the libbpp stack
<slangasek> doko: ok so on jack.  jackd provides two libraries; libjack and libjacknet.  libjack has a C-only ABI.  the shlibs point to libjack-jackd2-0v5 (>= 1.9.5~dfsg-14) | libjack-0.116.  libjacknet has a C++ ABI; its shlibs also point to libjack-jackd2-0v5 (>= 1.9.5~dfsg-14) | libjack-0.116.  However, libjack-0.116 is a virtual package provided by both libjack-jackd2-0v5 and by libjack0, and libjack0 do
<slangasek> esn't include libjacknet at all
<slangasek> if nothing has noticed this, it's possible libjacknet is completely unused and we shouldn't do a package name change
<Laney> Should we start to see stuff migrating once it's ready?
<Laney> modulo gcc-5 itself
<slangasek> Laney: probably small clusters only
<Laney> in theory though
<slangasek> yes
<Laney> I like attacking things from the proposed-migration direction too
<Laney> pick a package and drill down on it until it goes in
<slangasek> doko: confirmed that libjacknet is an internal library only with no header files, it shouldn't even be part of the libjack package AFAICS but it certainly shouldn't have the shlibs it currently has.  I'll back out the transition
<slangasek> Laney: yes, you should be able to do that soon
<Laney> nod, thanks
<cyphermox> doko: are you aware of some change in our gcc5 that would affect floating point precision on i386?
<doko> cyphermox, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323  -> almost always bad code
<ubot93> gcc.gnu.org bug 323 in middle-end "optimized code gives strange floating point results" [Normal,Suspended]
<cyphermox> figured that's what you'd link me ;)
<doko> glad you found it on your own =)
<cyphermox> hehe
<cyphermox> doko: danke.
<slangasek> I've seen some no-change rebuilds for boost today; is anyone working on systematically rebuilding for http://people.canonical.com/~ubuntu-archive/transitions/html/boost1.58.html ?
<doko> not me
<flocculant> afternoon - could someone point balloons and I at what we need to report against for wily live sessions in Ubuntu and Xubuntu falling to login screen rather than starting the desktop
<doko> slangasek, ocaml packages could need some attention (e.g. liblastfm-ocaml-dev not installable) who did those in the past?
<slangasek> doko: I don't know
<Laney> cjw I think did some
<Laney> it's the same as haskell - rebuild them in level order
<cyphermox> flocculant: I saw something like that related to compiz perhaps, but it depends
<cyphermox> flocculant: wily daily for xubuntu and ubuntu?
<flocculant> both
<flocculant> cyphermox: so not compiz I would have to assume
<cyphermox> flocculant: if both try to log in and fail, falling back to the login prompt, then something is broken
<flocculant> cyphermox: want some logs?
<cyphermox> I'd watch .xsession-errors carefully (or whatever gets written), to see where it breaks
<cyphermox> flocculant: check .xsession-errors and the logs in .cache/upstart/, like gnome-session.log or unity7.log
<cyphermox> I'll check in a bit
<flocculant> cyphermox: logs http://pastebin.com/MnV18Csc
<robru> anybody have any easy gcc5 stuff for a noob like me to poke at?
<doko> robru, https://launchpad.net/ubuntu/+source/openvdb/3.0.0-3ubuntu3
<robru> doko: thanks
<doko> robru, there's also tbb ftbfs on arm64
<doko> would suggest to contact debian and/or upstream
<doko> or looking for patches upstream
<robru> doko: I don't see any new versions for tbb or openvdb either upstream or in debian
<robru> doko: do you want me to just file bugs in debian?
<doko> robru, no, I meant upstream trunk
<robru> doko: what? I went to the upstream homepages and they had nothing new?
<doko> robru, ohh, np VCS?
<robru> doko: not that I could see...
<doko> robru, yes, debian forwards would be ok, but you probably can't reproduce on these architectures
<doko> tbb and openvpn without VCS? can't believe that
<robru> doko: well I didn't look into openvdb that closely but tbb was definitely just tarballs on a website. no VCS I could find
<robru> doko: ah, openvdb does have a github
<robru> doko: actually wait, https://launchpadlibrarian.net/214176471/buildlog_ubuntu-wily-arm64.tbb_4.3~20150611-1~exp3_BUILDING.txt.gz this just says "build killed after 150 minutes of inactivity", could that not be a transient issue? retry the build maybe?
<doko> robru, could you check on the developer box first?
<robru> doko: sure
<robru> doko: ok, arm64 build started, apparently it takes 4 hours if successful though
<robru> doko: also for openvpn, v3.0.0 has never built on powerpc. last successful powerpc build was 2.3.0-2
<doko> slangasek, time to force gcc-5 and gcc-defaults to -release?
<slangasek> doko: where did we get to with the analysis of the failures?
<doko> see the pad. it's kde only, one ada issue, nothing important
<slangasek> ok
<slangasek> then yes, let's
<doko> the ftbfs for main are fixed
<slangasek> doko: hint added
<infinity> slangasek: Oh, good, "force" didn't mean what I feared it did. :)
<slangasek> infinity: acceleratin' that mass
<infinity> slangasek: AKA, American sexy fun times?
<slangasek> infinity: you have a dirty mind
<infinity> slangasek: Little bit.
<slangasek> doko, infinity: robru is looking at openvdb, which ftbfs on powerpc because it uses tbb which appears to be reinventing the wheel on atomics.  What's the right way to do atomics in C++?
<infinity> slangasek: Lemme see the failure?
<slangasek> infinity: https://launchpadlibrarian.net/214175949/buildlog_ubuntu-wily-powerpc.openvdb_3.0.0-3ubuntu3_BUILDING.txt.gz
<infinity> slangasek: If it's *only* on ppc, they might be doing atomics correctly, but missing -latomic.
<slangasek> "incomplete type" suggests otherwise
<slangasek> /usr/include/tbb/atomic.h:220:34: error: 'tbb::internal::atomic_impl<T>::my_storage' has incomplete type
<tdaitx> slangasek, infinity: this? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787084
<ubot93> Debian bug 787084 in src:tbb "error: 'tbb::internal::atomic_impl<T>::my_storage' has incomplete type" [Serious,Open]
<infinity> Yeahp.  With a patch, no less.
<slangasek> oh hey
<slangasek> "Here is a patch whic huse the gcc libatomic instead of [...]" there we go
<slangasek> oh, except that the maintainer claims it's applied in experimental
<slangasek> and that's the version we have synced, I think?
<infinity> No.
<infinity> We have unstable.
<infinity> Oh, tbb.
<slangasek>  tbb          | 4.3~20150611-1~exp3   | wily-proposed/universe | source
<slangasek> yes
<infinity> I'm looking at ... Yeah.
<slangasek> oh, hangon
<infinity> So, there may still be a missing -latomic on top of this.
<slangasek> robru: what version of libtbb-dev was openvdb building /against/ ?
<slangasek> infinity: it's not a linker error
<infinity> Get:161 http://ftpmaster.internal/ubuntu/ wily-proposed/universe libtbb-dev powerpc 4.3~20150611-1~exp3 [208 kB]
<infinity> From the build log.
<slangasek> well phooey
<robru> slangasek: yeah, that
<robru> slangasek: I had that idea too, maybe it was an older version or something
<robru> but no
<infinity> Oh.
<infinity> This was definitely applied... Differently.
<slangasek> (said in a raiders of the lost ark voice)
<infinity> Hrm.
<slangasek> oops, no, not that movie the other one
<infinity>     #if (TBB_USE_GCC_BUILTINS && __TBB_GCC_BUILTIN_ATOMICS_PRESENT)
<infinity>         #include "machine/gcc_generic.h"
<infinity> So, maybe that's not actually working.
<slangasek> Last Crusade, that's what it's called
<slangasek> so, gcc regression?
<infinity> Ah-ha.
<infinity> No, stupid patch.
<infinity> See debian/patches/ppc32_atomics.patch
<infinity> Which should be dropped.  And libtbb should just be linked with -latomic.
<infinity> Maybe.
<infinity> Yeah.
<infinity> The atomic-rework patch explicitly fixes things to work with -latomic (ie: new style intrinsics), then the ppc patch disables it. :P
<infinity> slangasek: Gimme a few minutes to play on a porter, and I'll have a fix on the way.
<slangasek> hah
<slangasek> infinity: or do you want to hand it off to robru?
<robru> infinity: but wait though. the latest changelog specifically says "restoring this patch because it never should have been dropped"
<infinity> robru: Yes, because his atomic-rework failed on ppc32 because he didn't link with -latomic, and he misread that as "oh, this doesn't work on ppc, then"
<robru> infinity: alright, want me to make a debdiff with the patch dropped?
<infinity> robru: If you want to figure out how to make it link correctly (and drop that patch) as learning exercise, go nuts.
<infinity> robru: The linking bit is important, not just dropping the patch. :)
<robru> oh, well
<robru> slangasek: how hard is that? for somebody who's never written any C++ and would just be stabbing in the dark ^
<slangasek> robru: library linkage is unrelated to writing C++
<slangasek> so it should be a piece of cake ;)
<slangasek> Good: .depends ~ /libassimp3v5/
<slangasek> Bad: .depends ~ /libassimp3/
<robru> slangasek: ok well I'm also completely unfamliar with library linkage.
<slangasek> also bad: someone's regexp handling at 3 in the morning?
<slangasek> robru: now's a great time to learn :)
<robru> slangasek: ok can you point me at some documentation to get me started
<robru> ?
<infinity> Documentation won't help you here, these are custom Makefiles, not something pleasant(?) like autoconf.
<slangasek> robru: 1) drop the patch that's identified as bad 2) test-build on powerpc 3) see where it's failing to build because underlinked 4) fix the necessary makefile
<doko> slangasek, gcc-5 in -release, plus 7 libs
<doko> \o/
<slangasek> and so it begins
<robru> infinity: autoconf? pleasant? uh-huh.
<doko> wondering if we can force boost1.58 and icu as well
<robru> doko: so the tbb rebuild on arm64 is stuck in the same spot, darn
<infinity> robru: Just adding -latomic to LIBS in build/linux.gcc.inc will probably do the trick.  Maybe.
<robru> infinity: thanks
<infinity> robru: If you have access to the ppc porter, that will help a bit.
<slangasek> doko: I think we want to wait and see what p-m returns for those libraries
<doko> sure
<robru> infinity: yeah, just looking now
<doko> but boost1.58 is all new, and icu changed the soname, so the old lib isn't removed
<infinity> robru: Not that that was much of a learning exercise, since I can't leave well enough alone, but I got there by backtracking from the Makefile generating the library through to the Makefiles in build/ and then to the include bits.
<robru> k
<slangasek> doko: yes; but if that was all there was, p-m should have figured it out already on its own so I want to see why it refused before we use a hammer
<infinity> robru: All untested.  So please test a full build with testsuite.
<infinity> robru: And then if you fix it, forward to Debian with a "well, actually..." explanation.
<robru> infinity: yep, just firing it up now
<slangasek> hmm, only 7 libraries? I just got 38 wily install notification mails
 * infinity goes to fix North Korea.
<slangasek> infinity: now for that, you'll want a hammer
<slangasek> cyphermox: ignition-math2, I just noticed was never built on i386 so not a regression; did you see the same?
<infinity> slangasek: Or just a tzdata update.  That'll fix ALL their problems, right?
<cyphermox> slangasek: I had not noticed
<cyphermox> slangasek: in any case, I'm sending a patch to debian now
<slangasek> infinity: as long as their clocks match the reality and declare that they're in the stone age, all is good
<cyphermox> it's not perfect, but it allows it to build on i386
<slangasek> cyphermox: ok.  taking it off the pad anyway
<infinity> slangasek: Setting all their clocks back to 1950 would be a great idea.  I wonder if we're popular enough there to cause an international incident.
<doko> slangasek, where do you get these emails? I only get those for my own uploads
<slangasek> doko: who do you think uploaded the libraries
<slangasek> :P
<doko> heh
<slangasek> and 38 was just the first batch, p-m appears to still be running
<infinity> ... and firefox has developed an -latomic issue suddenly too.
<infinity> Weird.
<robru> doko: oh, actually, so there was a pause but tbb build succeded on arm64. not sure if you want to retry the arm64 build or just wait for the new upload that fixes powerpc anyway
<doko> robru, given back. please check tomorrow
<robru> doko: thanks
<doko> infinity, could you update the buildd images? get gcc-4.9 removed, and 5 wouldn't need updates, speeding up the builds a bit
<infinity> doko: Yup, I was waiting for it to migrate before I mangled them.
<infinity> doko: Are you happy (enough) with this version of GCC until the transition is done?
<infinity> I mean, barring critical bugs you didn't know about, of course.
<infinity> Cause not updating it until post-transition would be a big help for speed.
<doko> yes, at least we didn't find any GCC issue, after the transition started
<infinity> Alright, I'll do some refreshes shortly here.
<infinity> robru: I'm guessing from this slow build that no one ever taught you about export DEB_BUILD_OPTIONS="parallel=$(nproc)"
<infinity> robru: Shiny, looks like that worked.  Score one for me for (educated-)random sed?
<robru> infinity: yeah lots of stuff nobody ever told me about ;-)
<robru> was also eating lunch
<robru> infinity: ok, want the debdiff? or did you grab it since you're snooping in my home dir anyway? ;-)
<infinity> robru: Well, depends on who wants credit for the upload and who's forwarding the fix to Debian. ;)
<robru> infinity: seeing as I have no upload rights...
<infinity> robru: Though, for paranoia's sake, I think I'll stage it in my devirt PPA and try rebuilding whatsit against it first.
<robru> infinity: fair enough
<infinity> WHatever whatsit was.  I already forgot.
<infinity> open... something.
<robru> infinity: openvdb
<robru> infinity: anyway, tbb.debdiff is there for you
<infinity> robru: Sure.  If I was sponsoring this for you (and I can, if you want credit), I'd ask you to flesh out the headers on that patch to explain it a bit better.
<robru> infinity: I'm not particularly bothered about credit for something that you directly told me to do that I didn't really understand.
<infinity> "Since gcc-4.9, the atomic intrinsics on some architectures (like powerpc) are split off into -latomic, so always attempt to link it."
<infinity> robru: Hah.  Well, maybe you undestand it a bit better with my above edit. :)
<infinity> robru: I'll take this one from here, though, thanks for the test run.
<robru> infinity: thanks for the instructions ;-)
<slangasek> doko: update_output is updated, and shows that icu has tentacles into a lot of other stuff; doesn't look like the old and new are coinstallable
<doko> well, the library is, probably not the -dev package
<slangasek> the -dev package isn't causing 11000 binary packages to be uninstallable
<slangasek> infinity: can you refresh my memory on what's expected to happen here?  Should p-m calculate installability assuming the NBS binaries stick around?
<infinity> robru: Also, your debdiff missed running "update-maintainer"
<infinity> slangasek: It calculates assuming they're removed.
<robru> infinity: probably because I don't know what that is
<infinity> robru: It needs running whenever we introduce a delta on top of Debian.
<robru> infinity: k, thanks
<doko> first nbs removals ...
<infinity> robru: And found another bug while I was in there.  Whee.
<robru> infinity: good thing you're on it then
<slangasek> infinity: so; if it assumes the NBS removals, there's no way to get p-m to show us the results of a partial upgrade?
<slangasek> (like it does in Debian these days)
<robru> NBS?
<doko> not built from source (anymore)
<infinity> slangasek: I'm not entirely sure what you mean by "show results of a partial upgrade".
<infinity> slangasek: But, indeed, our britney carries a patch to do things the inverse of how Debian does them, because we're dealing with a partial suite, and they have a full suite.
<slangasek> infinity: doko has requested, and it makes sense, to have icu transition into wily and unblock a bunch of stuff because it *should* be a soft migration - the old library binary should be coinstallable
<slangasek> infinity: er, I don't see why partial suiteness implies forcing hard transitions
<slangasek> that is, forcing transitions to be hard
<infinity> slangasek: So they require NBS removal in sid before something can migrate, which gives them a wholistic view, we have to pretend to do NBS removal in "testing" to get a similar consistent view.
<slangasek> hmm
<slangasek> right, so it's because we don't have the old binary packages in the partial suite, so can't just look at -proposed to decide whether a package is ready to migrate
<infinity> Is it desperately difficult to just finish the icu transition?
<slangasek> infinity: 11,000 binary packages
<slangasek> the icu transition underlies half the other C++ libraries in the archive
<infinity> Ahh, a drop in the bucket!
<infinity> Yeah, icu is always large, I've done it before.
<infinity> Though, it's rarely problematic on its own.
<infinity> Tied up with a new g++, though.  Ick.
<slangasek> so if we tried to force icu in via p-m, it would remove libicu42 from wily?
<infinity> slangasek: So, if we're sure it's not problematic on its own, we can force icu through the pipe manually.
<infinity> slangasek: No, it won't *actually* remove it.  britney does no removals.  The inst checker just *pretends* it's removing it.
<slangasek> infinity: I checked, libicu52 and libicu55 are coinstallable (at least on amd64, should be same for all archs)
<infinity> slangasek: So, if we're sure it's good, we can manually copy it, and let it unwind itself on the next run.
<slangasek> infinity: ok, I think we ought to. can you poke that in this afternoon?
<infinity> I can.
<slangasek> ta
<infinity> It does mean that list of broken packages migrates from update_output to the NBS report instead, but as long as there's a commitment to follow up sooner rather than later, I don't think it's an actual problem.
<infinity> Oh.
<infinity> It might also make the uninstall count go up?
<infinity> Depends on how stupid britney is.
<infinity> Hopefully stupid enough that it doesn't.
<infinity> If it counts NBS binaries in testing as still being available, we're fine.
<infinity> If not, we'll break the whole world.
<infinity> Perhaps I'll copy it and do a no-commit britney run afterward to make sure the world didn't explode.
<infinity> But I think it's sufficiently unclever enough to not break.
<robru> how do you tell if something is a regression on an arch vs if something was never supported on that arch?
<infinity> robru: rmadison, see if binaries exist on the arch in question.
<infinity> robru: Or check the previous version on LP for successful/failed builds.
<infinity> Holy crap on a stick, tbb takes forever to build on arm64.
<robru> infinity: so if the latest version in the release pocket is failed, that's authoritative that the arch isn't supported?
<infinity> I wonder what's up with that.
<infinity> robru: Well, it's authoritative that it's not a regression against the release pocket. :P
<robru> heh
<infinity> robru: When I'm touching a package for unrelated reasons, I tend to look at the arch FTBFSes anyway to see if it's trivial to fix in passing.
<infinity> robru: But if it's not trivial, as long as it's not a regression, the status quo is fine.
<robru> infinity: just curious about this pymia/mia thing mentioned on the pad. it suggests to rebuild mia against vtk5 on armhf except as far as i can tell armhf was never supported so I have no idea why this is blocking anything
<infinity> robru: Where is this magic pad people are working from?  I'm out of touch with the transition so far.
<robru> infinity: http://pad.ubuntu.com/gcc-5-transition has a bunch of TODOs, I'm finding it hard to follow though
<infinity> robru: Right, I see no pymia/mia on armhf at all, in any release, so that line can likely be deleted.
<robru> infinity: well I started a build with the suggested change, maybe let's see how it turns out first ;-)
<infinity> robru: Having it have different deps on different arches sounds like more trouble than it's worth, IMO.
<infinity> robru: And the fact that it's never built in the past makes it a bit of a "who cares".  If we leave it as-is, it'll magically work if/when someone fixes vtk6.
<robru> fair point
<robru> I don't  know who put it on the list in the first place
<infinity> Probably someone who just looked at the missing build without checking history.
<infinity> Oh.  And vtk6 on armhf is the usual Glfloat/GLdouble GL/GLES madness.
<infinity> That's fixable, if anyone cares.
<slangasek> yes, please don't make something like mia build-depend vtk5 on armhf
<slangasek> I also don't know why it ended up on the pad; someone must've been working from their build-failure email notifications as a todo list, instead of the trackers
<infinity> Are we not yet at a point where we have a new enough OpenGL that we can just use GLES everywhere as a pure subset of GL and stop this insanity with different standards on different arches?
<slangasek> not sure what you mean by that
<infinity> slangasek: So, the reason one used to have to choose A or B was that GLES was, annoyingly, not a pure subset of GL.  It was mostly a subset, but also included some features GL didn't have.
<slangasek> I thought the library entry points, not to mention the OpenGL runtime "whoami?" insanity, were different between the two
<infinity> slangasek: Newer versions of the GL/GLES standard have GLES as a pure subset (or GL as a pure superset, however you want to look at it), so one can, in theory, write all their stuff to target GLES, and make it work on both.
<infinity> slangasek: But, yes, that probably still needs fixing in mesa with a hybrid loader or something to fix the final step, now that the standard makes it possible.
<slangasek> right, so that doesn't really help if you're using things like libGLU
<slangasek> I guess in theory you just have everything building against GL headers, and if it's smart it only uses a subset and then you're happy?
<slangasek> but currently the compiler is what you use to enforce the subsetness
<infinity> Right.
<infinity> Oh well.  Maybe next decade.
<infinity> Our (correct) choice to make ARM GLES in Ubuntu (deviating from Debian) has been no end of pain, though.
#ubuntu-release 2015-08-12
<slangasek> infinity: how did your no-commit britney test go?
<slangasek> sigh; why does libmecab-java not show up on http://people.canonical.com/~ubuntu-archive/transitions/html/mecab-g++5.html ? (libmecab-jni, depends libmecab2 (>= 0.996-1))
<doko> infinity, slangasek: any update on icu?
<infinity> doko: I'm going to play with it in a bit.  Was trying not to lose context on other things before I did.
<infinity> Since I also need to hack around and remind myself how to make britney not promote things.
<infinity> Ahh, I can just no-op lp_import
<infinity> doko: Okay, will get to icu shortly.
<infinity> If it breaks the world, I'll have to revert.  We'll see.
<infinity> slangasek: You around?
<slangasek> infinity: hi
<infinity> slangasek: Hey.  I decided it didn't look TOO broken, but if you could spot-check snakefruit:/home/ubuntu-archive/proposed-migration/var/data-b2/output/wily/HeidiResultDelta for sanity?
<infinity> slangasek: Ignore the "reomvals", they're informational, but all the other lines are packages it wants to promote after the manual icu move.
<infinity> slangasek: Most of it looked vaguely reasonable, though I didn't realize this was also unsticking a mess of haskell in the process.  If it's not meant to, we'be broken something. :P
<slangasek> infinity: I don't know the syntax of this file.  bare package+version is new thing promoted?  - is an NBS binary that's dropped?
<slangasek> infinity: haskell getting in is an ok outcome
<slangasek> it was known to be tied up with icu
<infinity> slangasek: Yeah, lines starting with '-' can be ignored.
<infinity> It's what britney would try to remove if it knew how, but we don't let it. :P
<slangasek> ok.  so yeah, that looks reasonable and small
<infinity> Kay.
<infinity> Letting her loose, then.
<infinity> In other news, tbb is a flaming mess.
<slangasek> infinity: btw, what's the convention for expiring off "finished" transitions from the tracker? 'cuz we're accumulating a few
<infinity> slangasek: Moving them to the finished directory, I believe.  Or deleting.  Whatever you prefer.
<slangasek> infinity: right, so 'finished' all is still on the report
<slangasek> which makes that page a bit scrolly :)
<infinity> slangasek: Ahh, I see what you mean.  Yeah, deleting is fine too, when it's actually finished.
<infinity> slangasek: The reason for them being there is the (almost) part, I imagine.
<slangasek> hopefully having them marked 'finished' at least saves processing time
<infinity> Or just the Debian authors who hate deleting things.
<infinity> I suspect finished is still processed.
<infinity> Maybe.
<infinity> This is so not my code. :)
<infinity> Anyhow, when you're sure a transition is actually 100% done, deleting is totally fine, IMO.  History is not even remotely interesting here.
<slangasek> except perhaps for the part where nobody running the tracker remembered that the regexps needed to be explicitly word bounded because they were cargo culting from bad examples? ;)
<slangasek> but yeah
<slangasek> and then we have trackers that are failing to find any packages. http://people.canonical.com/~ubuntu-archive/transitions/html/vpb-driver-g++5.html
<infinity> slangasek: Well, cargo-culting can happen from VCS history, the files don't need to live on for that.
<infinity> slangasek: So, big britney run happening now.  Should be fun.
<tseliot> can an admin please blacklist nvidia-graphics-drivers-legacy-340xx so that we don't sync it from Debian?
<infinity> tseliot: Done.
<infinity> tseliot: And needs removing from -proposed, looks like.
<tseliot> infinity: thanks. Also, please approve 352 when you can
<slangasek> who wrote "jack transition" on http://pad.ubuntu.com/gcc-5-transition for asterisk? pitti?
<slangasek> hmm has anyone been tinkering with the transition tracker scripts again?
<slangasek> (Laney)
<slangasek> I shunted med-fichier off because it was 100% done; now it's less done again
<slangasek> maybe ben is getting confused after things transition to wily, hmm
<darkxst> can I get gnome-online-accounts 3.16 removed from wily-proposed, doesnt look like we can get around webkit2 requirements
#ubuntu-release 2015-08-13
<robru> soooo anybody know anything about opencsg? apparently qmake is bringing in gles on armhf but the source isn't compatible with gles at all.
<darkxst> can I get gnome-online-accounts 3.16 removed from wily-proposed, doesnt look like we can get around webkit2 requirements
<darkxst> bug 1466245
<ubot93> bug 1466245 in gnome-control-center (Ubuntu) "Update to 3.16" [Wishlist,Triaged] https://launchpad.net/bugs/1466245
<darkxst> ah no its bug 1466290
<ubot93> bug 1466290 in gnome-online-accounts (Ubuntu) "Update to 3.16" [Medium,New] https://launchpad.net/bugs/1466290
<darkxst> infinity, didrocks ^
<didrocks> hum, I guess we will need to blacklist it to not get it synced back. I'm unsure what's the procedure to blacklist only for one release? (as we copy the black list to the next release)
<didrocks> I guess infinity already got this case
<darkxst> didrocks, yeh it will need blacklisting
<didrocks> darkxst: I just don't want to blacklist it and forget about it later on (and so, will be blacklisted in next release), so that's why I wonder if there is a special section for this
<darkxst> ok
<darkxst> it would sometimes be nice if the sync-er ignored packages that are just going to depwait!
<didrocks> darkxst: it's slightly more complicated I guess, because the new versionned dep-wait can be into that transaction
<didrocks> doable, but not trivial :)
<didrocks> (especially as we don't know about the dep-wait without having a build running IIRC)
<darkxst> yeh, and its probably only a few packages each cycle that get hit, so not worth the effort
<darkxst> didrocks, also can you look at the gnome-getting-started-docs langpack split in new, would be nice to get the the 120MB monster package, off our dailies for the next build, so I can get people testing it;)
<didrocks> darkxst: will probably after finishing the morning duties (so at my start of afternoon). Opening a tab with it :)
<darkxst> didrocks, ok, thanks!
<didrocks> darkxst: no worry, I just gave a first quick look, sounds good. Quite impressed they are shipping localized webm videos as well, do you know what tool did they use to create those animations?
<didrocks> (as it's a space where we don't have really good tools)
<darkxst> didrocks, no idea, but wonder if its somewhat not automated, since only 5-6 out of 30 locales have them
<darkxst> where as all have localised svg's
<didrocks> oh, so yeah, maybe they are svg with placeholders
<didrocks> not sure, you can't rely on this
<didrocks> so yeah, ok, I'll maybe poke upstream at some point
<darkxst> didrocks, yeh, Ive not looked into the details at how they are generated, but they seem to have a bunch of python scripts that generate them, https://git.gnome.org/browse/gnome-getting-started-docs/tree/animation?id=8ad76711dbc4b895efa1cdea62fc06c1cff68fea
<didrocks> darkxst: ok, seems they match that with some blender magic and spits out the webm, interestingâ¦
<didrocks> darkxst: while I was at it, I finished the review, NEWed
<darkxst> didrocks, thanks
<didrocks> yw
<slangasek> Laney: so there are a lot of autohints in update_output right now that are all failing.  Do you have the big picture view of what needs to happen to unblock the big mass?
<cyphermox> slangasek: should we do a respin of one image once syslinux lands?
<slangasek> cyphermox: yes
<cyphermox> slangasek: I'm saying this because I don't think I have access to trigger that :)
<cyphermox> it's still going to be a bit though, it's building right now
<Laney> slangasek: No, I occasionally have a small view into it though
<slangasek> cyphermox: maybe you do via the iso tracker, I'm not sure?  but yes, when it's built let us know and we'll get it respun
<Laney> Give me two minutes and I'll share my script so you can all be as clueful as me
<cyphermox> slangasek: I only have access to trigger touch builds, I'm not in the cdimage team or whichever is used to respin isos
<slangasek> Laney: well I've at least managed to find the two 700+ package easy hints; I wonder how much overlap there is between those
<slangasek> in fact the two 700+ package easy hints differ by 16 packages
<Laney> slangasek: https://code.launchpad.net/~laney/ubuntu-archive-tools/update-output-helper/+merge/267970
<slangasek> Laney: ok
<slangasek> fwiw I've just looked at double-conversion, which was notable in the list because one of the autohints tried it and one didn't; looks like qtdeclarative-opensource-src is the blocker there
<Laney> I tried to fix kdeclarative
<Laney> ah man, one of the upstream tests is failing too
<slangasek> what's the nature of the kdeclarative failure?
<slangasek> the autopkgtest log isn't very scannable :/
<Laney> look for "FAIL non-zero exit status"
<slangasek> thank
<slangasek> s
<Laney> hopefully just a missing dep
<slangasek> claims QtQuick is not installed, but qml-module-qtquick2 is in the log
<Laney> it's not in the test-deps of "testsuite"
 * Laney ponders on @ vs. qml-module-qtquick2
 * Laney starts documenting blockers for this transition
<Laney> too much k and q
<jdstrand> slangasek: hey, it seems today's wily i386 livecd doesn't get past ISOLINUX in kvm. is this known? if so, do you know when the last usable wily i386 was?
<slangasek> jdstrand: yesterday's was usable; syslinux built with gcc5 is broken, we're working on getting a new image built with a gcc-4.9 syslinux
<jdstrand> ok, great. thanks!
 * jdstrand confirms that http://cdimage.ubuntu.com/daily-live/20150812/wily-desktop-amd64.iso appears to work
<jdstrand> slangasek: thanks again
<slangasek> jdstrand: sure thing
<slangasek> and syslinux 3:6.03+dfsg-8ubuntu1 is built/published, so I'll trigger an image respin now ( cyphermox davmor2 )
<slangasek> only triggering for ubuntu at the moment, but if any other flavors are blocked and need a respin let me know (or use that handy dandy iso tracker)
<cyphermox> slangasek: thanks.
<cyphermox> slangasek: apparently not any better sadly :(
<cyphermox> ah, I see, we're still picking up lots from 5.2.1
<slangasek> cyphermox: picking up lots of what?
<slangasek> is it linking in libgcc?
<cyphermox> slangasek: I see a bunch of libraries coming from libgcc 5.2.1
<cyphermox> yes
<slangasek> hmm ok
<cyphermox> I'll just try the patch that's included, despite it not being blessed upstream
<cyphermox> it seems to work for redhat if I read the bug report properly
<robru> anybody know anything about qmake pulling in gles on armhf? I'm working on opencsg and it has seemingly no gles support but it's being pulled in somehow and ftbfs
<infinity> robru: ARM has defaulted to GLES instead of GL pretty much since we did the first armel port.  It's more surprising that that package hasn't tripped over it until now.
<robru> infinity: seems it's a case of new upstream changes? wily release version is 1.3 and built on armhf, proposed has 1.4 and failed. the error message looks a lot like it's trying to mix GL and GLES in bad ways
<robru> infinity: it's using qmake which tries to pull gles in automatically, but it seems like most of the code just has GL hard-coded and has no real support for GLES
<robru> infinity: like, the code has references to "experimental GLES" that's commented out.
<robru> infinity: and uncommenting it doesn't build successfully ;-)
<wxl> hey folks problems with our alternates building today http://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/wily/daily-20150813.log
<wxl> seems like some seed is missing?
<ianorlin> it looks like the import of the packages it should have fails in bzr looking at the log
<wxl> near the bottom gpg issues too
<infinity> wxl: Probably just need to mangle some priorities.  Will fix.
<wxl> thx infinity
<robru> Laney: any thoughts on opencsg gles on armhf issue?
<slangasek> infinity: so the package in question (opencsg) basically bundles glew from what I can see, which isn't going to work with GLESv2 AFAIK
<slangasek> infinity: and the reason it pulls in GLESv2 is that it asks qmake for 'opengl' and this is the answer it gets
<slangasek> so the first offense of course is using qmake
<infinity> slangasek: Right, the second bit is well known, but the bundling of glew seems wrong...
<slangasek> but I wonder how we could fix this
<infinity> slangasek: The old version build-depped on glew, so I assume this bundling is a new offense.
<infinity> The new one build-deps on glew too...
<slangasek> robru: ^^ can you investigate why opencsg is now bundling glew?  (if there's upstream history or Debian bugs that explain)
<slangasek> robru: it's possible that a distro patch to replace the 'CONFIG += opengl' with 'LIBS += -lGLEW -lGL' would be enough to fix this here
<robru> hmm
<slangasek> robru: and if you exhaust those options, I'm fine with punting this one to the corner; there are other higher-priority issues that will need looked at, e.g. the "failing tests that need resolving" listed on the pad as blockers
<robru> ok
<robru> LOL http://opencsg.org/ their latest release is from 2014 but this website is straight outta 1993.
<robru> "The archive contains all required helper libraries, i.e., also RenderTexture and GLEW." I'm not seeing a changelog suggesting that's new though
<robru> v1.3 definitely had glew bundled as well
<infinity> So, the bundling could be a red herring.  Or it could be that we accidentally started using the bundled version when we didn't before.
<robru> infinity: slangasek: clue? http://anonscm.debian.org/cgit/collab-maint/opencsg.git/commit/?id=6f46d2e0f28ed4ffa9b72b5bcfa68e0f643a4264
<infinity> robru: Now if only that changelog entry related to a code change...
<robru> yeah I'm poking around a bit...
<infinity> ---- opencsg-1.3.2.orig/Makefile
<infinity> -+++ opencsg-1.3.2/Makefile
<infinity> -@@ -1,4 +1,4 @@
<infinity> --SUBDIRS = glew src example
<infinity> -+SUBDIRS = src example
<infinity> -
<infinity> Etc.
<infinity> Check the debian-changes patch from the previous version.
<infinity> Entirely possible none of that applied to the new version, hence they dropped it, but it might still be relevant in spirit and someone oopsed.
<infinity> robru: If the above was gibberish, just debdiff 1.3.2 and 1.4.0, search for 'debian-changes', and go "oh, look at that".
<robru> infinity: it took me a bit but I realized you were talking about the distropatch from 1.3, I see it now
<infinity> robru: The maintainer was (a) disabling the bundled glew build, and (b) changing the link line to link slightly different sets of GLish libs.
<robru> infinity: http://paste.ubuntu.com/12074203/ ok here's a diff of the patch. new version looks kinda fluffy (eg almost exclusively patching html files, no meat)
<robru> infinity: so you're saying I should resurrect the old bits and try building with that?
<robru> infinity: this isn't making a lot of sense, the Makefile in the new version no longer references glew at all, no SUBDIRS variable either.
<infinity> robru: Right, the upstream build system no doubt changes substantially, leading the maintainer whose patch no longer applied to believe it was also no longer needed.
<infinity> robru: s/changes/changed/
<infinity> A fine argument for the patch having been written in an upstreamable way, adding a "--no-bundled-glew-you-twits" flag to the build system, so they could wash their hands of it and not mess up on rebase.
<infinity> But oh well.  We're all guilty of not upstreaming as much as we should.
<robru> right
<robru> infinity: I guess what it comes down to is that I don't understand the new build system well enough to be able to identify how to disable building the bundled glew
<robru> infinity: also that debian changelog entry seemed to imply the bundled glew wasn't building...
<infinity> robru: Fair enough.  As our glorious leader pointed out, there are more important things to bang your head on anyway.
<robru> ok
<robru> I'll grab lunch and start fresh on something else then
<slangasek> the list of outstanding transitions is now fairly short and this makes me suspicious
<slangasek> I wonder if there are a bunch of boost revdeps tied up in the transition knot
<infinity> slangasek: You guys have put in a ton of hours on this, maybe you actually just made progress?
<infinity> Look at me and all my optimism.
<slangasek> infinity: it's a shorter list of edge things than I would expect given that the transition hasn't yet gone through :)
<cyphermox> infinity: slangasek: could one of you please respin Ubuntu desktop wily once more?
 * cyphermox will need to go buy a bunch of new USB keys tonight or so
<infinity> cyphermox: Sure.
<robru> slangasek: alright, thoughts on what  should look at next?
<cyphermox> ah, the livefs got broken because of the bluetooth transition :/
<bdmurray> infinity: could you do some -proposed cleanup?
<robru> sweet, upstream success https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795144
<ubot93> Debian bug 795144 in clementine "clementine: Fix FTBFS with qt4 moc & boost includes." [Important,Fixed]
<infinity> bdmurray: Yup.
<infinity> bdmurray: Done.
<bdmurray> Thanks
<slangasek> robru: anything listed under 'blockers'...
<robru> slangasek: ok so randomly I'm looking at python-launchpadlib. Why does the excuses page say "regression" when clicking through to the log doesn't show any ever passing?
<robru> slangasek: eg here: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#simplejson
<infinity> robru: Because this new infrastructure didn't import logs of old jenkins runs, but it did import state.
<robru> ah
<infinity> I suppose faking up old runs and importing logs might not be the worst idea, but scraping that all from jenkins would suck.
<doko> slangasek, infinity: unrelated: what's holding up valgrind for trusty?
<doko> and I'm unsure about the state of python3.4
<infinity> doko: See the bug, arges commented on it.
<infinity> doko: Short story, backporting from the devel series for SRUs is generally frowned upon, but if that's the best option, please also update vivid to match.
<doko> infinity, bug number?
<infinity> doko: I'll go a bit further though, and say is there a test plan to validate this?  Some things build-dep on valgrind for testsuites and such.  A 5MB diff is, obviously impossible to audit.
<infinity> doko: https://bugs.launchpad.net/ubuntu/trusty/+source/valgrind/+bug/1386524
<ubot93> Launchpad bug 1386524 in valgrind (Ubuntu Trusty) "Update Ubuntu 14.04 with full Valgrind LE support." [Medium,Confirmed]
<doko> ta
<doko> infinity, honestly, I think valgrind isn't good enough for these things. we should find out how to use the sanitizers for that
<infinity> doko: Perhaps, but that's not an answer for SRUs. :)
<infinity> doko: At least, a PPA test of $(reverse-depends -r trusty -b src:valgrind) should be done, and we also need some what to know that $(reverse-depends -r trusty src:valgrind) don't break.
<doko> infinity, I thought you were supposed to care about the ppc64el issues ...
<infinity> doko: I care about ppc64el, but oddly enough, not at the expense of other arches.
<infinity> doko: "valgrind sucks on ppc64el" is no excuse to shove in a new version without testing it doesn't break everything else.
<infinity> Anyhow, commented on the bug.
<infinity> doko: The upshot here is that this isn't a mass rebuild or something, it's dumping 20ish sources in a PPA and seeing how they do.
<infinity> doko: The downside is testing the runtime rdeps, which aren't many, but I'm not sure how best to make sure they "don't break".
<doko> infinity, can you do that?
<infinity> doko: I can certainly do the "dump some stuff in a PPA" bit, sure.
<infinity> doko: I'm less likely to agree to take ownership of it if any of them break. ;)
<doko> thanks
<doko> well, show me the results, and we'll see
<infinity> doko: Give us a vivid upload to match (or backport the vivid one instead, if the wily one isn't actually needed), and I can set up the test PPAs.  I'll do it under toolchain-r, so you have access to them too.
<doko> toolchain-r/test please
<doko> infinity, please take the one proposed for trusty and rebuild it
<infinity> doko: I was going to just create a new PPA, they're cheap.
<doko> or that
<robru> hey xnox, when you get a chance can you do a release for lp:launchpadlib? looks like trunk has a fix for the latest autopkgtest failures that are blocking some things in proposed.
#ubuntu-release 2015-08-14
<robru> infinity: hey if you have a sec (ha), the lplib autopkgtest has a fix in trunk and just needs to be released to unblock simplejson.
<infinity> wgrant: ^-- Hey, core-dev, release your own software.
<wgrant> infinity: adt image downloading thing is still downloading images
<wgrant> slow internet is slow
<wgrant> I didn't realise it was actually blocking things.
<infinity> Ahh, so you're already on it?  Awesome.
<infinity> wgrant: I think someone was whining in another channel about it being out-of-date on pypi too, if you feel like killing multiple birds whilst in a software release context.
<slangasek> gee, a whole lot of my uploads that I don't care about sure are making it into wily
<infinity> slangasek: That's the good kind of spam, no?  I always feel some small bit of undeserved pride every time I see an ACCEPTED email from a queue.
<slangasek> heh
<slangasek> these are the p-m ones
<slangasek> for libraries I never heard of before Monday
<infinity> slangasek: Also, thanks for helping utlemming with that xe-utils thing.  After my second (and third) round of reviews, I think it's almost not icky.
<slangasek> infinity: you may be a packaging hypochondriac
<infinity> slangasek: I'm... Not sure what that means.
<slangasek> anyone looked at marble yet?
<slangasek> ok, looks like a symbol symbols ftbfs
<slangasek> infinity: could you take a look at apt 1.0.10? python-apt dep-waits on it, which blocks language-selector-common -> kde-runtime
<infinity> slangasek: Yeah, I was going to try merging it tonight, and if it's too much of a pain, just drop the python-apt versioned dep a bit, since it's only got it for the transition.
<slangasek> infinity: changelog says it was bumped for a new interface
<slangasek> ("Files2")
<infinity> slangasek: Which changelog...?
<slangasek> infinity: python-apt
<slangasek> infinity: oops no, that says 1.0.9.4
<infinity> slangasek: I don't see the string "Files2" anywhere in http://launchpadlibrarian.net/213586903/python-apt_1.0.0~beta3ubuntu1_1.0.0~beta3.1.diff.gz
<slangasek> sorry
<slangasek> infinity: however I just tried to downgrade the build-dep here and build, and it fails with pep8 test failures
<infinity> Well, that would be entirely unrelated, and due to the new pep8. ;)
<infinity> But I can look at that too.
<slangasek> yeah
<slangasek> it does mean the C built successfully anyway
<slangasek> hmm and the kservice test that fails on i386 via p-m with a complaint about threads succeeds locally in an i386 chroot
<infinity> slangasek: Perhaps needs an i386 kernel to reproduce?
<infinity> Heh, happy to see jak is on the same "screw E402" page with python-apt that I was with unattended-upgrades.
<pitti> heh, I added --ignore=E402 as well -- it's outright impossible to do that for some projects
<pitti> if you have to set sys.path before "import"
<pitti> slangasek: oh nice, http://autopkgtest.ubuntu.com/packages/k/kservice/wily/i386/ succeeds again
<pitti> pytables also had a weird crash which now seems fixed
<pitti> so whatever changed, good :)
<slangasek> oh nice, flaky tests ;)
<pitti> slangasek: nice, marble passed again too, thanks!
<infinity> pitti: Yeah, I looked at "fixing" it in unattende-upgrades, followed the upstream pep8 bug "discussion" (argument), and just came to the conclusion that's it's a pointless error.
<slangasek> pitti: yeah, that one required an actual fix, but done now
<pitti> slangasek: right, hence the "thanks" :)
<slangasek> libsfml had a package name change but there was no transition tracker for it; triggering rebuilds for that now
<pitti> I uploaded the kicad fix now, so that it's easier to retry once apw uploads the fixed boost
<infinity> slangasek: I opted for patching python-apt and letting mvo deal with the apt merge when he's back.  I can never decide if half his apt delta is on purpose or mistakes, but I'd rather let the mistakes be his. :P
<infinity> Maybe I'll use my vacation to rewrite his evil build system; especially the part that mangles all the po files every time I sneeze near my laptop.
<pitti> debuild -S -nc FTW :)
<infinity> pitti: Yeah, that's how I always upload apt.
<infinity> pitti: Well, that's how I always upload most things, but apt pretty much requires it.
<pitti> ah, lots of k* just became "valid candidate", but still some uninstallables in _output
 * pitti grabs wily-proposed schroot and pokes
<pitti> skipped: khtml (6 <- 864)
<pitti>     got: 63+0: a-63
<pitti>     * amd64: libkf5kdelibs4support-dev, libkf5khtml-dev
<pitti> so if I read that right, britney claims that khtml breaks libkf5kdelibs4support-dev ?
<pitti> cause "chdist apt-get wily-armhf install libkf5khtml-dev libkf5kdelibs4support-dev" works fine
<pitti> or is that part of the big "too much for britney's little brain"?
<infinity> pitti: Try that with foo- on the end for the packages that were removed from khtml.
<pitti> oh, because NBS?
<infinity> I'm assuming that packages were removed anyway...
<pitti> nope, no NBS
<pitti> at least not from khtml
 * infinity looks at output.txt
<pitti> same for kdelibs4support
<pitti> ah, "install libkf5khtml-dev kubuntu-desktop" fails, maybe that'll lead to something
<pitti>   Considering libqca2:armhf -1 as a solution to libqca2v5:armhf 15
<pitti>   Added libqca2:armhf to the remove list
<pitti>   Fixing libqca2v5:armhf via keep of libqca2:armhf
<pitti> ok, that's at least something concrete to do
 * pitti stabs http://people.canonical.com/~ubuntu-archive/transitions/html/html/qca2-g++5.html
<pitti> this tracker looks wrong -- several packages like kadu built successfully days ago
<infinity> pitti: kadu only built on 2/6 arches.
<pitti> but even those aren't marked as "done", and https://launchpad.net/ubuntu/+source/psi/0.15-2build1 built everywhere 4 days ago
<pitti> I checked the build log, no stray hardcoded "libqca2" deps
<infinity> Weird.
<pitti> https://launchpad.net/ubuntu/+source/kdeconnect/0.8-0ubuntu3 even already propagated
 * pitti wonders if it's the \b, most other trackers use a different re
<pitti> I'll just adjust that and check in the next run, and until then go through the logs
<pitti> hm, http://people.canonical.com/~ubuntu-archive/transitions/html/html/snappy-g++5.html used the same syntax and was happy
<pitti> ooh, I know!
<pitti> Depends: libqca2-plugins
<pitti> that matches libqca2\b
<infinity> Hahah.  Oops.
<pitti> pushed
<pitti> ok, missing rebuilds uploaded, there are a couple of FTBFS
 * pitti sobs at qmake
<Mirv> could sources qtcreator-plugin-remotelinux and qtcreator-plugin-cmake be removed from wily-proposed? the new Qt Creator 3.5 RC in -proposed pocket has the changes in those packages (which were partial forks of QtC 3.1 sources) after zbenjamin submitted everything upstream. the conflicts/breaks are there so upgrades are smooth.
<pitti> Mirv: you mean from wily? it's not in -proposed
<Mirv> pitti: yes, of course, I was just thinking about proposed migration
<pitti> Mirv: you mean the qtcreator package  itself ships these modules?
<pitti> I see it has Conflicts: to them, but not Replaces:/Provides:
<Mirv> pitti: yes, they are part of the normal QtC but they were removed from Ubuntu's normal QtC so that they could be replaced from elsewhere
<pitti> thus most likely apt will rather hold back the new qtcreator than removing these plugins
<Mirv> pitti: they are in a new path in the new QtC
<Mirv> hmm, it upgraded fine in my wily-proposed chroot
<pitti> well, I wouldn't bet on it with just Conflicts:
<pitti> so yes, fine to remove these from wily, but adding R/P: is still necessary IMHO
<Mirv> ok
<Mirv> doing a new upload of qtcreator
<pitti> Mirv: what about qtcreator-plugin-qnx and qtcreator-plugin-valgrind, as well as all the -dev? these are also built from the old sources, but not by qtcreator
<Mirv> pitti: they are all in the main qtcreator package that has tens of plugins, those were just ripped out of the main qtcreator package earlier. the -dev were not real -dev:s since Qt Creator doesn't officially support these kind of external plugins, so they were sort of hand made by benjamin
<pitti> Mirv: right, but I mean it should C/R/P: those packages too then
<Mirv> pitti: right, ok
<Mirv> so I'm now adding C/R/P for all the old binary packages
<pitti> Mirv: thanks
<pitti> Mirv: http://paste.ubuntu.com/12077489/
<Mirv> thanks!
<infinity> pitti: No need for "provides" if nothing depends on them, only C/R to force them off.
<infinity> (Not that all 3 hurts much either)
<darkxst> infinity, hi, can you remove gnome-online-accounts 3.16 from wily-proposed
<pitti> ah, seems I fixed the regexps at http://people.canonical.com/~ubuntu-archive/transitions/html/qca2-g++5.html hard enough at last
<pitti> argh, hardcoded lib dep
 * pitti uploads kdeconnect, take III
<darkxst> hmm current ubuntu-gnome wily daily images, don't want to boot ;( syslinux seems to be hanging
<infinity> darkxst: Was that gnome-bluetooth upload in -proposed a mistake?  It's got a ~ppa version.
<darkxst> infinity, I think seb copied it from the ppa
<darkxst> https://launchpad.net/~ubuntu-desktop/+archive/ubuntu/transitions
<infinity> Oh, hrm, seems to be a few ~ppa versions in wily.  Ick.
<darkxst> I certainly didnt upload them to the archive
<seb128> I was unsure if I should change them just to avoid the number of just copy
<seb128> so I decided to just copy
<seb128> it's only a version number, doesn't matter much
<infinity> seb128: It's not the end of the world.  As you say, only a version number.
<infinity> seb128: That said, as an end user, I see "ppa" versions, and assume I have a PPA enabled, so I might comb through the archive in a few weeks and rebuild anything with such versions.
<seb128> fair enough
<infinity> (That package isn't the only offender)
<seb128> the package might have an upload before that
<infinity> darkxst: Oh, and removed g-o-a for you.  Sorry about missing that in backscroll.
<seb128> darkxst, btw can you merge your change back to the vcs? I didn't find a branch/mp matching so I didn't do it
<infinity> darkxst: And your syslinux issue is known.  Supposed to be fixed in https://launchpad.net/ubuntu/+source/syslinux/3:6.03+dfsg-8ubuntu2
<infinity> darkxst: Perhaps your daily was built before that hit the release pocket?
<seb128> likely, iso built are buggy because of bluez
<seb128> builds
<seb128> which doesn't migrate for whatever reason (was autopkgtest and boottest but now it's something in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt unsure what, it's listed several times)
<infinity> leading: bluez,gnome-bluetooth,gnome-user-share,bluedevil
<infinity> start: 219+0: a-61:a-40:a-29:i-30:p-31:p-28
<infinity> orig: 219+0: a-61:a-40:a-29:i-30:p-31:p-28
<infinity> easy: 262+0: a-69:a-47:a-36:i-37:p-38:p-35
<infinity>     * amd64: bluedevil, gnome, gnome-control-center, gnome-core, gnome-desktop-environment, gnome-phone-manager, ubuntu-gnome-desktop, ubuntu-mate-core
<seb128> yeah, that doesn't speak to me
<seb128> like half of those should be valid candidates and the other half not care
<seb128> Laney helped
<seb128> going to fix gnome-phone-manager
<seb128> I've no clue about ubuntu-mate and what they have that depends for and what they want to use instead
<darkxst> infinity, thanks
<infinity>  gnome-control-center : Depends: libgnome-bluetooth11 (>= 3.4.0) but it is not going to be installed
<infinity> seb128: That'd be the root of the problem for the -desktops too, I assume.
<seb128> we don't use g-c-c
<infinity> Who is "we"?
<seb128> -desktop
<infinity> unity doesn't, everyone else does.
<seb128> k, I though you meant ubuntu-desktop
<infinity> Well, that's probably what's breaking ubuntu-gnome-desktop.
<infinity> ubuntu-mate-core is another mystery.
<darkxst> seb128, sure I can push my changes to vcs in the morning, off for the night now
<seb128> k, for some reason that copy didn't work or I missed it
<seb128> darkxst, thanks, good night
<darkxst> infinity, boot is failing way to early for g-c-c to be a problem
<infinity> darkxst: Hrm?  Lots of boost bits are already migrated.
<infinity> The autohinter isn't lying about the result here.
<darkxst> infinity, it doesnt even get to the boot menu
<infinity> Oh.  boot.  I thought you said boost. :P
<infinity> darkxst: See above, where I pointed at the syslinux bug.
<darkxst> infinity, looking now
<infinity> darkxst: We're discussing bluez/g-c-c/etc because all of that it preventing you from getting new ISO builds.
<jibel> darkxst, it's bug 1484571
<ubot93> bug 1484571 in syslinux (Ubuntu) "Latest wily image is not booting" [Critical,Fix released] https://launchpad.net/bugs/1484571
<infinity> darkxst: syslinux is fixed, but you get no new livefses until bluez is unbuggered.
<jibel> darkxst, it should be fixed in next build
<darkxst> right and bluez became a bit messy with stuff migrating before bluez itself
<infinity> I'm amused by the claim that migrating bluedevil breaks bluedevil.
<infinity> Does it make sense for bluedevil to depend on BOTH bluez-obexd and obex-data-server?
<darkxst> gtg, if you see anything specific to ubuntu gnome ping me an I will look in the morning
<darkxst> infinity, I think the latter dep is gone
<infinity> darkxst: Gone from where?
<infinity> It still exists in the archive.
<infinity> But it seems the intent in other packages was to move from obex-data-server to bluez-obexd, but bluedevil is depending on both.
<darkxst> infinity, yeh that, intent is its gone, depending on both makes noe sense
<infinity> darkxst: Does bluez-obexd provide a completely compatible interface?  As in, one can just swap the dep and that's it?
 * infinity would like to "fix" bluedevil, but is probably completely the wrong person to do so, if he has to ask these questions.
<Mirv> I had a vague memory that the following snippet from update_output http://pastebin.ubuntu.com/12079096/ meant uninstallability of the listed packages, but I don't have problem installing those on wily-proposed (all have rebuilt against GCC5)
<darkxst> infinity, i don't know the answer to that, and really have to go, so can
<darkxst> can't check
<infinity> Mirv: It means uninstallability *if* you also assume that promoting the candidate sources removes their NBS binaries.
<infinity> Mirv: Guessing at least one of those renamed a library or something.
<Mirv> hmm
 * darkxst gone
<Mirv> thanks inf
<Mirv> thatÂ botan had the v5 library rename and those packages have all been rebuilt against it, so I don't see where the problem but lie.
<Mirv> s/but/would/
<Mirv> no other reverse deps
<infinity> Mirv: The problem is that block of packages also wants muparser, which isn't in that autohint set.
<Mirv> ahah!
<seb128> k, so I handled gnome-phone-manager and gnome-bluetooth
<seb128> seems like ubuntu-mare should stop pulling in bluez-alsa
<seb128> mate
<seb128> flexiondotorg, ^
<Laney> didn't g-c-c need one too?
<seb128> unsure then about bluedevil
<seb128> Laney, sorry, gnome-bluetooth was a typo for g-c-c
<Laney> haha
<Laney> I see!
<seb128> ;-)
<Laney> what's the problem with bluedevil?
<seb128> <infinity> Does it make sense for bluedevil to depend on BOTH bluez-obexd and obex-data-server?
<seb128>  But it seems the intent in other packages was to move from obex-data-server to bluez-obexd, but bluedevil is depending on both.
<Laney> oh right
<Laney> well I don't see it in the problems for the migration
<seb128> trying: bluedevil
<seb128> skipped: bluedevil (58 <- 823)
<seb128>     got: 62+0: a-62
<seb128>     * amd64: bluedevil
<seb128> unsure if that means it's a problem though
<seb128> infinity mentioned it so he probably thinks it is?
<Laney> there's a later hint involving bluez and bluedevil
<seb128> Trying easy from autohinter: bluez/5.33-0ubuntu2 gnome-bluetooth/3.16.1-1ubuntu1~ppa1 gnome-user-share/3.0.4-0ubuntu2 bluedevil/4:5.1.95-0ubuntu1 has
<seb128>     * amd64: bluedevil, gnome, gnome-control-center, gnome-core, gnome-desktop-environment, gnome-phone-manager, ubuntu-gnome-desktop, ubuntu-mate-core
<seb128> so it's listed in there as wel
<infinity> I'm honestly not sure why bluedevil is in that list, it's confusing me a bit.
<Laney> Trying easy from autohinter: libbluedevil/4:5.2.2-0ubuntu3 bluedevil/4:5.1.95-0ubuntu1 bluez/5.33-0ubuntu2 gnome-bluetooth/3.16.1-1ubuntu1~ppa1 gnome-user-share/3.0.4-0ubuntu2
<infinity> I just noticed the weird double dep when trying to understand it.
<Laney> [â¦]
<Laney>     * amd64: gnome, gnome-control-center, gnome-core, gnome-desktop-environment, gnome-phone-manager, ubuntu-gnome-desktop, ubuntu-mate-core
<infinity> Oh, we have another autohint that I missed?  Or was libbluedevil not there last time I looked?
<infinity> That one looks much more sane.
<infinity> Just g-c-c broken, and ubuntu-mate-core.
<infinity> seb128: I can fix MATE for them.  I take it bluez-alsa is dead/
<seb128> infinity, it is yes
<seb128> infinity, thanks
<Laney> I think it's just that after the ones seb128 also did
<Laney> nice
<infinity> seb128: Is there a replacement for bluez-alsa, or is it just rolled into bluez?
<infinity> And does anything force it off with a Conflicts/Replaces?
<seb128> infinity, afaik it's deprecated by bluez itself, nothing seems to C/R it though
<seb128> cyphermox, ^ maybe you know more about that?
<cyphermox> I don't think it's still needed, pulseaudio knows about bluez's dbus APIs
<cyphermox> so if it's no longer shipped...
 * infinity looks sideways at the MATE seeds not having the string "bluez" in them.
<cyphermox> infinity: does it have blue
<infinity> cyphermox: Right, so bluez should C/R -alsa to force it off cleanly on upgrades.
<cyphermox> infinity: most likely, yes
<cyphermox> let me check what bluez-alsa shipped before
<cyphermox> yeah, they probably dropped this :/
<cyphermox> http://git.kernel.org/cgit/bluetooth/bluez.git/commit/?id=4ff9b99292eca193dc0c149722328cb0b1ab0818
<infinity> Yeahp, fair enough.
<infinity> Just need to make the old package go away, since it clearly won't work with the new bluez, and don't want the cruft lying around.
<cyphermox> seb128: should I do the change?
<seb128> cyphermox, if you want, yes please, maybe check with morphis he was configuring a packaging vcs for bluez under ~bluetooth
<cyphermox> mmkay
<cyphermox> eep
<cyphermox> yeah, it's there, but no history :/
<seb128> did we have some before somewhere?
<cyphermox> seb128: at the very least we have launchpad as a last resort
<seb128> right
<cyphermox> I see Iain has a branch up to some rev of 4.99
<cyphermox> that's still not getting is very far though
<Laney> looks like that was using the UDD branch
<cyphermox> yeah
<cyphermox> I was already thinking of importing the history for the NM branch into a git-dpm tree or something, perhaps we can do the same with bluez?
<seb128> if you have a nice workflow feel free to do it/tell us how it works
<seb128> I suggested the desktop way of debian/ dir only because that's what I know which works best for component non hosted on launchpad
<infinity> Okay, that was confusing.  Found the bluez-alsa dep and wiped it out.
<infinity> It was a recommends from desktop-common, but due to an entirely weird bug, those recommends become depends for ubuntu-mate-core (and only them), while they're recommends for everyone else.
<infinity> Whee.
<davmor2> cyphermox: did you manage to resolve the iso booting issue in the end?
<cyphermox> davmor2: it was broken by related bluetooth issues too ^
<cyphermox> I haven't checked this morning yet
<infinity> cjwatson: germinate bug/misfeature, or is MATE doing something wrong?
<cyphermox> isn't MATE doing something special to their seed anyway
<infinity> cyphermox: no-follow-recommends, but it doesn't follow that that should translate all recommends into deps. ;)
<cyphermox> no, it doesn't :)
<cyphermox> :q
<cyphermox> dah
<infinity> Oh.
<infinity> cjwatson: Nevermind, not a germinate bug, their metapackage is weird.
<infinity> flexiondotorg: Dude.
<infinity> flexiondotorg: You around?
 * infinity decides he's waited long enough for flexiondotorg and fixes his meta without input.
<cyphermox> what was it?
<infinity> cyphermox: ${germinate:Recommends} was on the Depends line for ubuntu-mate-core. :P
<cyphermox> woops ;)
<infinity> seb128: ubuntu-mate-meta uploaded.
<cyphermox> seb128: infinity: could you please get the boottest for bluez to be skipped?
<seb128> cyphermox, I don't know the magic for that
<seb128> unsure what group has the acl for it as well
<seb128> Laney and pitti can is all I know
<cyphermox> seb128: I could maybe have done it but only for touch things :P
<cyphermox> huh, scratch that,  I guess it's probably more "only for RTM"
<slangasek> looks like python-apt is clear, but there are other apt revdeps not rebuild yet.  anyone worked on those or should I give it a go?
<slangasek> apt revdeps uploaded
<robru> anybody around to sponsor an upload for me? infinity?
<cyphermox> robru: I can, I haven't left yet
<robru> cyphermox: ah barry got to me first, but thanks
<cyphermox> ok
<barry> robru: built for me at least on a wily amd64 chroot
<barry> sponsoring
<robru> barry: yeah it should be good, not an arch-specific failure, thanks
<slangasek> oh fail; debian-xcontrol checks its own control file at build time and barfs on XSBC-Original-Maintainer
<slangasek> libmusicbrainz5's transition tracker also didn't cover the bases; more rebuilds needed there, trying to upload now (but at the tail end of battery here)
<doko> why is this still showing up http://people.canonical.com/~ubuntu-archive/transitions/html/libqalculate-g++5.html ? it's the only package
<slangasek> doko: because of a bad matching rule; .depends ~/libqalculate5\b/ also matches Depends: libqalculate5-foo.  It's in the "finished" section anyway, so you can ignore it?
<doko> ok
<slangasek> barry, robru, infinity, cyphermox (or anyone who's around): top priority today should be getting the mega hint unstuck.  Laney has a branch at lp:~laney/ubuntu-archive-tools/update-output-helper with a tool of the same name that helps with analysis of the output.  I'm using it like this: http://paste.ubuntu.com/12081732/
<cyphermox> ack
<slangasek> the interface is a bit janky (and I haven't yet merged that into ubuntu-archive-tools because of that jankiness) but hopefully you can figure it out and make some headway
<slangasek> I've sorted out apt and musicbrainz5, there were missing revdep rebuilds - those are now on the tracker and noted in the pad
<slangasek> 5 minutes battery left here, so signing off.  Good luck :)
<robru> cyphermox: I don't really know what to do
<Laney> slangasek: I thought about making it a straight wrapper with some more smarts
<Laney> but that would have taken extra time
<Laney> can improve it later on
<Laney> it's looking smaller!
<cyphermox> Laney: it's not missing much to be useful in this particular case
<cyphermox> first I picked was tangled in apt too
<Laney> can't parse that, sorry
<Laney> do you mean it's not useful or it is? :)
<cyphermox> robru: so, you get laney's branch. then run update-output-helper -u... as per the paste from slangasek
<cyphermox> Laney: I say it's useful
<barry> pitti: if you're around (or anybody else who has shell on autopkgtest.u.c) could you please retry ipython i386?
<cyphermox> Laney: and I say it's not missing much to wrap the rest of what slangasek was doing
<Laney> cool
<Laney> I just copy and paste the huge list
<Laney> and if you pull it does update for you :P
<cyphermox> robru: you just need to take the huge list beside: Trying easy from autohinter, and copy-paste it when you run update-output-helper again (without -u)
<cyphermox> yep
<cyphermox> robru: and to finish that apt-get install call (with the obvious different dirs so you don't mess up your install), you pick some random package under amd64: or something, those without a /version_number, and try to install it, see where it hangs
<Laney> don't forget --dry-run
 * Laney puts that in
<Laney> done
<cyphermox> why?
<cyphermox> ah, now I pick something and it's installable
<Laney> so that it doesn't try to do anything
<robru> cyphermox: is this meant to be done in a wily chroot?
<Laney> nah
<cyphermox> I thought so but passing dirs to apt makes it unnecessary
<Laney> it's at least offering to install something here
<Laney> don't know what would happen if I say yes :)
 * cyphermox takes src:player
<cyphermox> Laney: it tries to download the files from your aptroot, and fails.
<Laney> can you try a rebuild of visp and see if it gets libogre-1.9.0v5?
<robru> Laney: cyphermox: http://paste.ubuntu.com/12081879/ yeah I have no idea what I'm doing
<Laney> looks like that might be why its test fails
 * Laney is on Frankfurt train station wifi
 * cyphermox is at home waiting for his lift to the airport
 * cyphermox takes geos and player...
<cyphermox> robru: no get update
<robru> cyphermox: the paste said to update :-P
<cyphermox> you also don't need to run the extra update with apt-get -o blah, because it gets run when you run update-output update
<cyphermox> s/ update$/-helper/
<cyphermox> you're just not picking the packages from the right list for the call to install
<cyphermox> under the huge list of hints, you have besides ' * amd64:' a list of uninstallable packages, pick from that :)
<robru> cyphermox: ok now what? http://paste.ubuntu.com/12081911/
 * Laney plays the "will it build before the train arrives or my 30 minutes of wifi runs out?" game
<cyphermox> robru: right, so this means that something is still depending on libgeos-c1 instead of libgeos-c1v5, what I was looking at right now
<cyphermox> so you'd check if what you picked (libqgis) has built properly, and if you got the newest in proposed
<Laney> often stuff is rebuilt but blocked at the excuses stage
<doko> Laney, it's "wily it build ..."
<Laney> the train is delayed by zwanzig minuten
<Laney> but I have 6 minutes of wifi left
<Laney> someone just try a visp rebuild already :)
<doko> somebody should give back libkcddb and cantata when musicbraiz is built
<doko> anway, afk now
<Laney> 10 seconds
 * Laney fail
<Laney> ttyl :P
<cyphermox> robru: back in a bit on my way to the airport
<robru> cyphermox: OK I'm on lunch for a bit & running some errands, we should sync up a bit later
<stokachu> infinity: ^
<cyphermox> robru: well, I had to get to the airport, I'm there now having dinner since my flight still isn't for a few hours
<robru> cyphermox: cool. Can you run me through this update output helper thing? I don't really know how to fix the problems found with it
<cyphermox> sure
<cyphermox> where you at now?
<robru> cyphermox: same place we left off
<cyphermox> ahah ok
<cyphermox> I was just hacking at the script, I don't really like how it brings out things that may already have been rebuilt in proposed
<cyphermox> so, you run the update and all, up to trying to install a package, which will say why it fails to install
<cyphermox> something like http://people.ubuntu.com/~mathieu-tl/output
<cyphermox> (but way shorter)
<cyphermox> say you try pcl-tools
<cyphermox> you'll get a complaint about libvtk5.8  and one about libvtk5.8-qt4,
<cyphermox> what this means is that it's likely that pcl-tools needs to be rebuilt to pick these up, but you still need to verify
<robru> cyphermox: ok let me try pcl-tools and see what happens
<robru> cyphermox: ok so I see the thing about libvtk5.8{,-qt4}, what is it that I need to "verify" and how do I fix this?
<cyphermox> ok so I found that in some cases say, pcl would already be in proposed but not being listed by update-output-helper, so I check on lp for what's there, and look in the build logs to check that it picked up the new build-deps, in this case libvtk5.8v5 and libvtk5.8-qt4v5
<cyphermox> in this particular example, looks like pcl doesn't build
<robru> cyphermox: so it looks like mterry was working on this recently but his FTBFS fix failed? https://launchpad.net/ubuntu/+source/pcl/1.7.2-8ubuntu1
<cyphermox> yup
<robru> cyphermox: oh well that one is just more BOOST_JOIN failures though
<cyphermox> i wouldn't know
<robru> cyphermox: I guess I don't understand what this helper tool is telling me that I can't already see on the update_excuses page
<robru> cyphermox: I'm familiar with the BOOST_JOIN thing, I've done a few patches for that already
<cyphermox> essentially it allows you to walk through the list so you can fix things  that unblock many things
<cyphermox> if you want to look at pcl, I'll finish my burger, pass security, then I'll be 100% able to help :)
<robru> cyphermox: heh, ok
 * cyphermox is on slowww wireless tubes
<robru> cyphermox: lol, so mterry uploaded a new fix while I was fumbling with that
<cyphermox> ok
<cyphermox> well, good I guess, aside from the duplication of work
<cyphermox> robru: look at marsshooter, if you want something new
<robru> cyphermox: yeah figured he was EOD since he's not in the channel
<robru> also it's after 6 in his timezone
<cyphermox> looks like it should be a straight rebuild for the new libsfml; but it's 70Mb source and I'm in an airport
<cyphermox> otoh I guess I could bring it up on a server
<robru> cyphermox: so you want me to pull-lp-source and poke at it? what should I check?
<robru> cyphermox: better if you teach me I think
<cyphermox> well, see if it's uninstallable first, it should tell you about libsfml
<cyphermox> libsmfl has been renamed with the usual XYZv5; so doing a no-change rebuild of marsshooter should pick up these new names and just work
<cyphermox> (but it's worth running it through sbuild first just in case)
<robru> cyphermox: ok will do
<robru> cyphermox: yeah, local build success, you wanna upload a nochange?
<cyphermox> sure
<robru> cool
#ubuntu-release 2015-08-15
<slangasek> so, some octave challenges left I see
<slangasek> giving back a number of packages on armhf now that octave is available there
<darkxst> infinity, any ideas why gnome-control-center is stuck in proposed? update_output, seems to pin it on gnome-user-share from what I can tell, but that was updated for bluez5 transition
<infinity> darkxst: Looks like vorlon hinted it and it's in.
<darkxst> infinity, ok cool, that was a messy transition!
<darkxst> guess its due to general lack of deps for dbus stuff
<infinity> darkxst: That was a tiny transition.  The messy one is still in progress. :P
<darkxst> infinity, messy in the sense that most of it migrated at will
<darkxst> in bits and pieces
<infinity> darkxst: Yeah, true that.  It would have been less bad if it weren't tied up in all the other things ongoing right now, since we could have done it in a block and it would have just worked.
<infinity> But, such is life.
<infinity> Hopefully we won't break C++ ABI for another half decade or more. :/
<darkxst> hope so, thinking there will be a lot of FFe requests this cycle!
<darkxst> and really the only things in the GNOME stack to use c++ are spidermonkey and webkit
<slangasek> infinity, darkxst: yes, the autohinter was insufficiently clever in this case; I don't know why but probably related to gnome-user-share /not/ being listed in p-m as having a dependency on the new gnome-bluetooth
<darkxst> slangasek, I guess that is life, dealing with antique packages, all the bluetooth stuff had moved into gnome-bluetooth itself for 3.16, but we are stuck on 3.0 due to UI changes
<cyphermox> slangasek: confirming the image boots fine now, so syslinux issue is resolved.
<infinity> cyphermox: \o/
<slangasek> cyphermox: good-o, thanks
<Laney> Can someone clean up the NBS libcpprest2.4 in wily-proposed?
<infinity> Laney: Yep.
<infinity> Laney: Except, what NBS is that?
<infinity> Oh, only on one arch, so it looked like a build failure at first.
<infinity> Which is why I didn't get it in my last pass.
<Laney> Cheers duck
<xnox> i am confused why boost-defaults is not migrating.
<xnox> Trying easy from autohinter: boost-defaults/1.58.0.0ubuntu1 libftdi/0.20-3ubuntu1 libftdi1/1.2-4
<xnox> leading: boost-defaults,libftdi,libftdi1
<xnox> somehow fails, yet in -proposed chroot they do install...
<xnox> also
<xnox> https://launchpad.net/ubuntu/+source/libftdi
<xnox> &
<xnox> https://launchpad.net/ubuntu/+source/libftdi1
<xnox> look conflicting to me....
<xnox> slangasek: infinity: why was libftdi forked from libftdi1 package, and why do we have both?
<xnox> i guess i'm missing something...
<infinity> xnox: Confusingly, they generate two different versions of the library.
<infinity> xnox: But the failure to migrate is because of the packages they make uninstallable.
<infinity>     * amd64: ubuntu-sdk, ubuntu-sdk-libs-dev
<infinity> Which, I assume, still depend on the old unnamed sovers.
<infinity> I can fix that up after I get out of this video game. :P
<infinity> (Yay, weekends)
<xnox> infinity: yes, but they generate the same name packages, imho that's wrong.
<xnox> (binaries that is)
<infinity> xnox: No they don't.
<infinity> foo1 and foo1-2
<infinity> (Now foo1v5 and foo1-2v2)
<infinity> s/v2/v5/
<xnox> infinity: am i wrong?! -> http://paste.ubuntu.com/12089667/
<xnox> as in doing it wrong...
<infinity> apt might be lying to you.
<infinity> That's certainly not what I see in LP.
 * xnox fetches source packages, ok.
<xnox> yeap they are different.
<infinity> Try an --only-source on those command lines.  apt might be trying clever reverse mapping.
<infinity> Now, let's see how these sdk packages are generated and what I can do about it.
<xnox> they are a seed.
<infinity> Yeah.
<infinity> Fiddling.
<xnox> anyway, i'm in chroot, now install all of ftdi, will try to install boost and finally see how/why sdk baffles.
<infinity> xnox: Keep in mind that britney assumes removal of NBS.
<infinity> So those apt-get install lines of yours need an explicit libfoo1- libfoo1-2-
<infinity> Etc.
<xnox> ok, checking nbs now.
<infinity> Hrm, this seems to work:
<infinity> apt-get install ubuntu-sdk ubuntu-sdk-libs-dev libftdipp1- libftdipp1-2-
 * infinity scratches his head.
<infinity> I wonder if something else needed for this isn't actually migrating yet.
<xnox> sigh http://paste.ubuntu.com/12089732/
<xnox> no, that's C....
<infinity> YEah, that's fine.
<xnox> could britney be confused about the dual/clashing name libftdi1 thing?
<infinity> Probably not.
<infinity> And ubuntu-sdk doesn't depend on any of those.
<infinity> Not directly, anyway.
<infinity> Did boost-defaults drop any packages?
 * xnox checks
<xnox> i didn't prepare it, doko did.
<infinity> FWIW, there are no package name clashes, you were just victim to apt's binary mapping.
<infinity> Which britney doesn't use.
<xnox> ack.
<xnox> boost build looks weird and has dbgsyms packages, and previously didn't.
<infinity> More realistically, this just needs a couple more packages on the hint to make it work, but given that ubuntu-sdk+ubuntu-sdk-libs-dev pulls in 1103 binaries (!), it's not trivial to unpack.
<xnox> all packages are the same in boost-defaults.
<xnox> (55 vs 58)
<infinity> At the very least, that hint needs libjsoncpp with it, looks like.
<infinity> And jsoncpp is probably tied up in a larger batch.
<xnox> hm.
<infinity> ubuntu-touch-meta depending directly on libraries makes it critical path for a lot of hint combinations.  I wonder if just removing it entirely for a week would upset anyone. :P
<xnox> ok, i'll go poke easer things for now.
<xnox> infinity: i'm sure it has nothing important there. it's not like wily is shipping anywhere.
<xnox> infinity: the more crap migrates, the better from my point of view =)
<xnox> has anything migrated so far?
<infinity> slangasek: Thoughts?
<infinity> xnox: Some things, here and there.  vorlon's been doing a good job of unwinding and by-hand hints.
<infinity> slangasek: I wasn't being facetious about removing ubuntu-touch-meta.  The part where it depends directly on libraries means that it forces all the libraries it depends on to migrate together, which is much harder than doing small transitions.
<infinity> slangasek: Would anyone lose their mind if we just blew it out of the water for a few days?
<xnox> demote it to -proposed.
<xnox> that will also uncover all the random jenkins that use release pocket without proposed =)
<infinity> xnox: Well, it's already in proposed.  But deleting from release is what I meant, yes.
<xnox> right.
<infinity> It means image builds will explode.
<infinity> But by their own admission, the touch guys aren't too focused on wily right now.
<infinity> I don't really want to get yelled at, though, so I'll let slangasek vote.
<xnox> infinity: i wish i was an archive admin, lol.
<xnox> "fixed" octave-communications, was ready to be rebuild for dep-wait.
<xnox> looking into octave-nan
 * xnox giggles at the new changelog.
<xnox> https://launchpad.net/ubuntu/+source/octave-nan/+changelog
<xnox> fixing ubuntu-core-meta for libapt-pkg.
<xnox> how often britney runs?
<tumbleweed> every publisher run, according to Laney
<tumbleweed> also, why aren't yuo here?
<tumbleweed> that applies to both of you
<infinity> tumbleweed: Debconf conflicted with Plumbers.
<infinity> xnox: Define fixing.
<infinity> xnox: If ubuntu-core-meta is refering to libapt-pkg, that's a bug.
<tumbleweed> infinity: pity. next time
<xnox> infinity: it's refering to it, seed is updated, but not the package. cause germinate doesn't look like it looks at -proposed, still.
<infinity> xnox: What seed is this?
<infinity> xnox: Yeah, see, your fix is wrong. :P
<xnox> tumbleweed: i have sprained ankle.
<xnox> infinity: ubuntu-core.wily seed.
<xnox> last modified by slangasek...
<infinity> Well, IMO.  libapt-* shouldn't be hardcoded in core-libs at all.  It's a BS lie, since no one's committing to making that a stable ABI.
<infinity> Oh well.  I'll argue with people about that some other day.
<xnox> ...
<infinity> ...?
<xnox> germinate should be fixed to look into -proposed.
<xnox> hm.
<xnox> edubuntu-desktop, kubuntu-desktop, kubuntu-full uninstallable =/
<xnox> do we need to transition insighttoolkit4 to v5?!
<slangasek> xnox, infinity: yes I was bandwidth-constrained so didn't get ubuntu-core-touch uploaded yet.  I was prepping it now, have I been superseded?
<xnox> slangasek: si, senior.
<slangasek> infinity: ubuntu-touch-meta> yes it is harder but we're almost there; can you give it another day to see where we get?  alternatively if we get the big chunk in now and then resolve ubuntu-touch-meta by Monday it's probably about the same
<xnox> i believe insighttoolkit4 needs v5 treatment.
<slangasek> xnox: what's this about a sprained ankle?  are you with a sprained ankle here or with a sprained ankle somewhere else?
<xnox> slangasek: i'm in LHR.
<xnox> this week.
<xnox> not coming to FRA
<infinity> slangasek: Does the big chunk not require touch-meta?  That was sort of my point.
<infinity> slangasek: The big chunk might be smaller chunks if there wasn't this one crazy package that depends on a ton of libraries.
<xnox> hm, fixed all of octave, but they are not migrating =(
<xnox> hm. failing to see what else to fix. can we hint everything to go together?
<xnox> error: unknown type name 'BOOST_PP_IIF_BOOST_PP_BOOL_BOOST_PP_COMPL_BOOST_PP_NOT_EQUAL_CHECK_BOOST_PP_NOT_EQUAL_'
<xnox> oh my
<xnox> i think clang++ just hangs.
<slangasek> xnox: spending a week in Heathrow!  What crime could possibly fit that punishment?
<slangasek> xnox: too bad, anyway
<slangasek> infinity: ubuntu-touch-meta itself is easier to transition if it's first pulled out; but it's not the only metapackage in the transition
<xnox> slangasek: nah, at home in greenwich. they actually cannot keep me in heathrow,lol.
<xnox> =( gnuradio takes forever to compile.
#ubuntu-release 2015-08-16
<infinity> slangasek: No, but ubuntu-touch-meta and ubuntu-core-meta are the only metas (because of the whole "sdk libraries" thing) that directly depend on libraries, so it makes them much harder to deal with.
<infinity> slangasek: Other metas are mostly a non-issue.  You need to keep them installable, but that can be done by transitioning a few of their deps at a time, rather than ALL of them.
<xnox> infinity: can you please new gunicorn?
<xnox> https://launchpad.net/ubuntu/wily/+queue?queue_state=0&queue_text=gunicorn
<xnox> off to sleep. good night. there is too much things to new.
<xnox> ok thanks.
<doko> xnox, why? https://people.debian.org/~doko/logs/gcc5-20150813/archive-gcc-08-13-2015/gnuradio_3.7.8-1_unstable_gcc5.log you are delaying the transition. we will continue to offload your packages
<doko> infinity, slangasek: all arm64 buildds down. contacted is, but no reply yet
 * Laney screams at gnuradio
<cyphermox> Laney: still looking at gnuradio?
 * slangasek cleans up octave Breaks: to match the actual Ubuntu versions
<slangasek> so what's still wrong with gnuradio?
<Laney> now needs a transition
<slangasek> har, and software-center is rendered uninstallable because debtags in wily-proposed has dropped the python2 support
<slangasek> Laney: a new one?
<slangasek> it was already transitioning from 3.7.5 to 3.7.8
<slangasek> ah
<slangasek> xnox: nack on gnuradio 3.7.8-1ubuntu3, this needs reverted
<slangasek> xnox: for packages that are mixed up in the big transition, it's worth 5 minutes of discussion before upload to save 5 hours of compile time
<slangasek> xnox: also, to summarize the current status: all first-level libraries that are affected by the ABI change have already been transitioned in wily; so unless you run into a package build failure due to a library in the archive still having old symbols (which will basically mean this library didn't get detected in the Debian rebuild because it FTBFS), there shouldn't be any more transitions needed
<slangasek> if anyone cares to look at it, pocl has an interesting build failure - rebuild needed for llvm3.5, but build segfaults with a stack trace pointing into llvm3.5 itself
<slangasek> (not sure why llvm-toolchain-3.5 is still in main in wily, given that mesa has moved to 3.6 - but if mesa's moved I'm not so worried about it that I'll block the 3.5 transition)
<slangasek> removing pcl binaries on ppc64el, the source looks incompatible with current eigen3
<slangasek> so I can't see any reason that the autohinter is including debtags in the hint, considering nothing in update_excuses depends on it and it makes stuff uninstallable.  It may be a mis-hint that the autohinter will figure out when we get closer, or it may be something that'll require a manual hint to avoid
<slangasek> but I am amused that debtags has dropped python2 support before software-center has switched to python3
<Laney> uwsgi FTBFS in some not immediately obvious how to fix way
<Laney> looks like yade needs fixing/removing too
<slangasek> yade was on my list already, I don't know why it didn't make it to removal
<xnox> slangasek: ok.
<slangasek> Laney: you at the venue?
<Laney> yeah
<Laney> the smaller talk room
<Laney> oh actually, yade dropped of the list for this run
<xnox> slangasek: the thing that tripped me up, is that it's still red in boost tracker, yet it clearly has been built against boost 1.58.
 * xnox traces.
<slangasek> xnox: interesting; I would blame the tracker for still getting the wrong answer when there are different binary names between wily and wily-proposed, except gnuradio 3.7.8 did already transition to wily (but has to get rebuilt again and transition again with the group, because uhd)
<slangasek> xnox: maybe it's NBS binaries?  looking now
<slangasek> xnox: it is not NBS binaries
<slangasek> anyway, at a bit of a stopping point so wandering to the debconf venue now
<xnox> ok
<slangasek> Laney: ah I remember why I hadn't gotten around to removing yade yet though, it's because it looked suspiciously like a vtk6 bug rather than a yade bug
<Laney> I'm hoping it got disentangled
<Laney> slangasek: OK to sync new libsidplayfp?
<Laney> looks like upstream bumped SONAME
<Laney> (blocks https://launchpad.net/ubuntu/+source/sidplayfp/1.4.0-1/+build/7793291)
 * Laney does it
<Laney> rebuild plasma-mediacenter
<Laney> +ing
<slangasek> Laney: I have no idea :)
<Laney> I did it anyway :P
 * cyphermox feels audacious
<slangasek> Laney: right, so the answer is that libsidplay has added new uninstallables to the transition (audacious-plugins) which were otherwise ready to go, so you get to fix that :P
<slangasek> and for questions of the general form "can I sync new version of $package_included_in_the_big_autohint that introduces a new ABI transition", the answer is "not until the hint finishes" ;)
<slangasek> Riddell: why does plasma-workspace in wily-proposed conflict against the latest version of kio-extras present in wily-proposed?  plasma-workspace was uploaded 6 days ago, is a new kio-extras coming?
<slangasek> Riddell: note that this is on the short list of < 6 remaining blocking issues for the main g++5 transition, and as this is a versioned breaks it doesn't look like something we can straightforwardly upload a fix to plasma-workspace for; so if we don't have a new kio-extras in -proposed by the time the hint is ready to go in (which I believe will be EOD today), we will probably need to break kubunt
<slangasek> u-meta in wily to let the transition through
<slangasek> Laney: which library transition entangles uwsgi?  I don't see any uploads of it to wily-proposed
<slangasek> Laney: (an upload to wily-proposed would let us all look at the same build failure)
<slangasek> ok, libgloox
<slangasek> (uploading)
<slangasek> right, uwsgi build failure reproduced in the archive now; someone who likes both ruby and GNU make can debug that one
<slangasek> meanwhile, package removed from wily
<slangasek> the next p-m run should start to look interesting
<slangasek> Laney: I've assumed that you are going to do the no-change rebuilds for new libsidplayfp (now that it's past new).  If not please let me know
<slangasek> ok, the debtags problem reveals itself - the old version is in C and depends on libept, the new version drops python2 support
<Laney> slangasek: It blocked some other package, and the transition was small - yes, will rebuild
<Laney> ty
<cyphermox> anyone already looking at wusgi
<Laney> no I am
 * Laney watches him get up and walk out
 * Laney creepy
<cyphermox> Laney: ?
<Laney> Building uwsgi now
<Laney> Only a crappy fix though, if it works
<cyphermox> ok
<Laney> but we have multiple supported ruby versions which it seems breaks this
<cyphermox> doesn't seem to be much else left
<Laney> debtags
<Laney> AFAICS
<Laney> (remove that from proposed?)
<slangasek> debtags needs a fix; I just talked to enrico had he told me mvo has some insight on this
<slangasek> s/had/and/
<Laney> The version in wily-release too?
<slangasek> yes, per above old debtags depends on libept which is an affected C++ lib
<slangasek> and oh btw I think the hint just succeeded
<slangasek> oops
<slangasek> oops because whatever uninstallables someone had left in wily that are now resolved were uninteresting leaf packages, and they've been swapped for um ubuntu-desktop and friends
<slangasek> so I hope this upgrade I've just started succeeds before the mirrors update?
<Laney> I mean that we can reupload a buildX of the last version which had python-debtagshw
<Laney> If that helps
<Laney> don't see that it worked..?
<Laney>     * amd64: audacious, audacious-dbg, audacious-plugins, audacious-plugins-dbg, audtty, autoradio, debtags, goplay, kubuntu-desktop, kubuntu-full, lubuntu-desktop, packagesearch, qmmp-plugin-projectm, remuco-audacious, wmauda
<Laney> sometimes bits get nibbled off though
<slangasek> Laney: oh, I see - right it didn't succeed at all it was an invalid hint because someone changed the version of qtdeclarative-opensource-src!
<slangasek> well I guess I can drop my hint now anyway in favor of the autohint now that we know what's up with debtags
<slangasek> changed the version of> or possibly that bit got in, as you say
<Laney> libsidplayfp has NBS in wily-proposed to clean up
<slangasek> debtags uploaded
<Laney> should be it AFAICS
<Laney> please to delete libsidplayfp3v5
<slangasek> Laney: done
<slangasek> kubuntu-desktop will still be uninstallable, because of the kio-extras issue
<slangasek> what are these new mozc uninstallables in the latest run?
<Laney> new upload, needs to clear excuses
<slangasek> uim-mozc was NBS in wily-proposed, also removed now
<slangasek> if nothing else changes, I guess the next run will be it aside from forcing kubuntu-desktop
<Laney> where is this kio-extras 4:5.3.2+git20150710.0210?
<ianorlin> The lubuntu desktop live build failed
<cyphermox> ianorlin: I can check, maybe there is something I can do
<ianorlin> it looked to fail build the livefs
<cjwatson> we're mid g++ 5 transition, lots of stuff is failing across the board, not just lubuntu
<cjwatson> in this case the specific failure is
<cjwatson>  blueman : Depends: bluez (>= 4.61) but it is not going to be installed
<cjwatson>  bluez-alsa : Depends: bluez but it is not going to be installed
<cjwatson> but it's probably just uncoinstallable for real at the moment ...
<cyphermox> well, these should have been to -release already
<cyphermox> oh
<cjwatson> yeah but that probably means that something else in the install set depends on non-v5 libraries
<infinity> bluez-alsa is dead.
<infinity> I removed it from seeds, but it needs meta updates.
<infinity> Someone needs to upload all the metas that include it.
<infinity> Which is all the desktops except mate, cause I fixed theirs.
<infinity> I can do that.
<infinity> Not sure about the blueman->bluez thing, though.
<cyphermox> lubuntu-core
<infinity> Oh, that'll be the same failure.
<infinity> Because bluez C/R bluez-alsa.
<cyphermox> yes
<infinity> So rebuilding all the metas will fix that.
<infinity> I'll grab 'em all and upload.
<cyphermox> ok
 * cyphermox is still too slow at this debugging race
<ianorlin> ah ok I grabbed an alternate and it is almost done installing
<infinity> cyphermox: Thanks for adding the C/R, BTW.
<cyphermox> infinity: yeah, apparently I'm sure I did it with that previous upload, but someone it didn't get through
<cyphermox> *somehow
<infinity> Heh.
<infinity> Editors are fickle.
<cyphermox> not that much :)
<cyphermox> I see some stuff appeared in that update_output of doom.
<infinity> cjwatson: Does germinate respect apt's proxy configs?
 * infinity guesses no.
<infinity> Would make these updates a tad faster.
 * infinity notes that a number of these haven't been updated since vivid...
<infinity> And mythbuntu, not since utopic.  Awesome.
<infinity> Oh well, I needed something to do while waiting on laundry before my flight.
<ari-tczew> cyphermox: we are not so far to FeatureFreeze, what about Network Manager 1.0 in wily?
<cjwatson> infinity: It uses Python's urllib.request - should respect the proxy environment variables, but not apt's config
<infinity> cjwatson: I probably live in a fantasy world, but I'm of the opinion that anything downloading from Debian archives should respect the system apt proxy configs.
<infinity> cjwatson: (I know, I know, patches welcome)
<cjwatson> It's probably not hopelessly difficult with python-apt.
<cjwatson> I don't immediately have time though
<infinity> cjwatson: I was just going to parse `apt-config dump`, but switching from urllib to python-apt might be a better long-term thing, dunno.
<cyphermox> ari-tczew: NM is no longer my primary responsibility, so it's up to free time. thanks for reminding me, I'll get at least the git migration started right now
<ari-tczew> cyphermox: so who is the next one?
<cyphermox> ari-tczew: unknown, possibly "awe_", or you, if you're interested
<cyphermox> I'd think I would do 1.x and leave the package in a nice enough state for somebody else to take over
<cyphermox> (although the 1.x release shouldn't be very hard to do)
<ari-tczew> cyphermox: would be nice, but I think I haven't enough knowledge
<doko> where are you all now? youth hostel, or the hotel?
<cyphermox> doko: I thought you had left already, I'm back to my room
<cjwatson> infinity: Doesn't need to switch to python-apt for the retrieval, just use apt.Config
<cyphermox> I have no idea where the others are
<cjwatson> or whatever it is
<cyphermox> ari-tczew: knowledge comes from experience, we all start with relatively 0 knowledge about package *p
<ari-tczew> cyphermox: you're right
<cyphermox> ari-tczew: maybe we should move this to #u-devel
<doko> cyphermox, mvo, Laney, and me are at the hotel bar
<cyphermox> ah!
<ari-tczew> cyphermox: +1
<cyphermox> well, I guess I'll have to pass for tonight :)
<infinity> Alright, metas all uploaded, now to finish packing and call a cab...
<doko> cjwatson, infinity: anything to look at for the big migration?
<cjwatson> doko: I've been away for a week, I know nothing
<cyphermox> doko: update-output-helper, unblock the megablob?
<cyphermox> doko: that's the last info I had
<cyphermox> there isn't much left there
#ubuntu-release 2016-08-15
<Mirv> the request from Saturday would still be needed - https://irclogs.ubuntu.com/2016/08/13/%23ubuntu-release.html#t06:03 - at least running the failed unity-scope-click's unity8 tests with --all-proposed, I understand if you don't necessarily want to edit vorlon's hint (visible in update_output.txt)
<flocculant> infinity: seems that xubuntu hasn't built since Saturday - not sure why
<pishuilu> @all   The Ubuntu Kylin daily iso is not created successfully. The question is about python3-aptdaemon.pkcompat package. Kubuntu and Xubuntu have the same question. But Ubuntu and lubuntu daily iso is created susccessfully. What needs to be done to sovle this question? The URL is https://launchpadlibrarian.net/278816938buildlog_ubuntu_yakkety_amd64_ubuntukylin_BUILDING.txt.gz and
<pishuilu> https://launchpadlibrarian.net/278982117/buildlog_ubuntu_yakkety_amd64_xubuntu_BUILDING.txt.gz
<ginggs> hi Laney, ubuntu's libphonenumber needs a fix for gcc6/boost1.61 - you uploaded a newer version to debian a year ago. is there any reason we shouldn't sync from debian?
<Laney> hi ginggs
<Laney> I don't know, the phone people like to patch that package so I would talk to them
<Laney> Maybe it can be merged
<ginggs> Laney: ok, thanks - speaking to the phone people first is a reason not to sync
<Mirv> likewise --all-proposed for these unity8 tests http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#webbrowser-app
<Laney> Mirv: going
<Laney> let's see what is left
<Laney> a lot of things are coming down to graphicsmagick
 * Laney pokes
<Mirv> Laney: I guess you can't update the manual hint from slangasek visible at update_output? it lacks some required newer versions.
<Mirv> oh, not visible anymore, was still in the morning
<Mirv> had these Version mismatch rows
<Mirv> anyway, it looked like a good hint
<Mirv> doh, webbrowser-app needs a no-change rebuild, on it. that was a weeks old silo that landed.
<Laney> what for?
<Mirv> it was compiled before Qt 5.6 landed in proposed and depends on the older private ABI
<Mirv> I realized it thanks to your script, trying some apt commands
<Mirv> ...or not. weird. so click throughing in LP got me to an older deb download, the control.tar.xz of which I examined. I didn't question it since the apt did claim webapp-container depending on qtbase-abi-5-5-1.
<Laney> wait
<Laney> It's fine, it depends on 5-6-1
<Mirv> I know (now)
<Laney> you just have to wait for it to pass excuses
<Laney> update_output.txt is telling you about the webbrowser-app in yakkety-release
<Mirv> oh well proposed seems broken anyway since oxide-qt has failed a build on armhf and arm64 which webbrowser depends on.
<Mirv> armhf specifically, arm64 never worked on yakkety
<Mirv> maybe that hybris dependency could be now filled, trying a rebuild of oxide
<Mirv> hmm, I guess I can workaround that oxide for now, since oxide-qt is not required for the migration since it fortunately nowadays does not depend on the private ABI.
<Mirv> filed a bug about that armhf FTBFS anyway, since it seems the dependencies are still unfilled
<Laney> Mirv:  libhybris-common1 : Depends: libc6 (< 2.24) but 2.24-0ubuntu1 is to be installed
<Mirv> updated bug #1613257
<ubot5> bug 1613257 in libhybris (Ubuntu) "oxide-qt fails to build on yakkety due to missing hybris dependencies" [Critical,New] https://launchpad.net/bugs/1613257
<kdub> Mirv, I can probably spare some cycles if you need any help on https://bugs.launchpad.net/ubuntu/+source/oxide-qt/+bug/1613257, its blocking the mir release too, along with the oxide migration
<ubot5> Launchpad bug 1613257 in libhybris (Ubuntu) "oxide-qt fails to build on yakkety due to missing hybris dependencies" [Critical,Confirmed]
<Mirv> kdub: I don't have an idea how to fix that, it's likely we need morphis or someone else who knows about the hybris internals to know why glibc 2.24 is banned like that, and how big an issue to solve it would be
<morphis> Mirv: is that in yakkety?
<Mirv> morphis: yes
<morphis> Mirv: we don't define that requirement in debian/control for libhybris
<morphis> just for vivid we require gcc 4.7
<kdub> morphis, so maybe a nochange-rebuild would fix?
<morphis> yes
<kdub> cool
<kdub> I think there might be a way to nochange-rebuild without a silo? (but I'm not a debian/ubuntu maintainer, and don't know how to do that)
<Mirv> I don't see thought where Laney got that, as I only see: Depends: libandroid-properties1, libc6 (>> 2.23), libc6 (<< 2.24), libgcc1 (>= 1:3.5), libstdc++6 (>= 5.2) in the latest yakkety armhf binary, but maybe a no-change rebuild could help
<Laney> Then you do see it?
<Mirv> Laney: thank you, now I do, I didn't when copy-pasting :D
<Laney> :)
<Mirv> I'm trying a no-change rebuild in a silo. Meanwhile, I restored the webbrowser-app for now.
<Laney> restored?
<Mirv> I managed to do that no-change upload before noticing the issue. Now I waved another magic wand to keep it possible for the Qt & KDE migration to happen.
<Laney> I see webbrowser-app is building, but I'm not sure why it was necessary to do that
<Mirv> it wasn't, originally, but since ubuntu2 bumped into oxide-qt/hybris glibc issue, ubuntu3 is a "restoration" of ubuntu1 so to speak, but still ok for migrations
 * Mirv keeps alive the dream of Qt & KDE migration
<Laney> Now it's going to re-trigger the unity8 tests
<Mirv> however, this week it's also relevant to ask if that can happen now or if I should bite the bullet and eg upload that newer qtbase that's pending
<Mirv> but I hope update_output.txt will be ready for another slangasek's hint attempt later today
<Laney> I really wish you hadn't done that
<Mirv> Laney: you'd rather like the error be visible, or you'd rather have just stayed with the 2 week old webbrowser-app that got binary copied to the proposed earlier today from silo?
<Laney> what error?
<Mirv> Laney: the ubuntu2 of webbrowser-app that revealed the oxide/libhybris issue
<Mirv> ubuntu1 was the two week old build that was ok, and wouldn't have needed a rebuild (strictly). ubuntu3 is more or less the ubuntu1 again, so working.
<Laney> I have no idea why webbrowser-app has anything to do with that
<Mirv> Laney: it depends on oxide-qt, so can't build on armhf with oxide-qt from proposed
<Laney> it was already built on armhf
<Mirv> yes it was, using the older oxide-qt
<Laney> so?
<Mirv> so, nothing, it'd been better to just stay with ubuntu1 instead of juggling around, but now we at least have more bugs filed.
<Laney> It looks like you made this one build without proposed anyway
<Laney> so I have no idea what this has achieved other than wasting some time
<Mirv> Laney: as said, ubuntu2 shouldn't have been done, so yes it's wasting some time, but it's at least not blocking anymore compared to if I had stayed with the broken ubuntu2
<Laney> that was about to become a candidate for migration
<Mirv> yes, it will be again in an hour or two.
<Laney> Right, in future if I'm helping you then please ask before randomly uploading stuff that's going to change the state of play
<Laney> now I better go run the tests with all-proposed
<Mirv> I will ask, I'm just used to working mostly alone in the last 2.5 weeks, but now it has fortunately changed.
<Laney> seems like the new kernel has to go in with all of this stuff too btw
<Laney> I don't think any manual hinting will be required once that goes green
<Mirv> Laney: ok I will start with double-checking https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-073/+sourcepub/6805016/+listing-archive-extra would look ok to binary copy to archives once the binaries are published. built against proposed, looks now proper >> 2.24, << 2.25
<Laney> looks good, not related to this current migration though
<Laney> it's going to get stuck along with glibc
<Mirv> not related, but a broken oxide blocks touch developers none the less
<Laney> ya
<Laney> just saying, luckily they are separate
<Laney> I wonder why it gets these weird depends on armhf only
<Laney> right, I triggered unity8 with all-proposed again, for the new webbrowser-app ._.
 * Laney goes to find a sandwich
<Mirv> thank you, sorry :(
<Mirv> it seems the previous i386 run failed with random flakiness so not much time actually wasted too either
 * Laney cries, amd64 failed this time
<slangasek> Mirv: my hint was superfluous, the autohinter is already showing the correct hint and output
<Mirv> looks like unity8 amd64 succeeded now (20160815_171244)
<Mirv> this earlier i386 failure may have been overlooked however http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-scope-click - even though unity-scope-click should not be mandatory migrator (existing release pocket version should have no trouble with new Qt and friends)
<slangasek> wxl: so the missing lubuntu-next builds are because for-project isn't recognizing lubuntu-next as a project; I guess something was missed there in the ubuntu-cdimage patch
<jbicha> why does qt think it needs linux 4.6?
<tsimonq2> slangasek: what do you think might be missing? I can send an updated MP your way.
<slangasek> tsimonq2: haven't looked at it, but the error message is certainly suggestive
<slangasek> for-project: error: unrecognised project 'lubuntu-next'
<slangasek> tsimonq2: so, lib/cdimage/project.py project_map
<tsimonq2> ok slangasek
<bdmurray> slangasek: I've uploaded a new update-manager with virtualbox lts packages support
<bdmurray> slangasek: for review in the Trusty SRU queue
<slangasek> bdmurray: got it, thanks
<slangasek> bdmurray: should the existing -proposed package be released first?
<bdmurray> slangasek: I'm not certain what would happen if the virtualbox packages were not in sync w/ X and the kernel.
<tsimonq2> slangasek: https://code.launchpad.net/~tsimonq2/ubuntu-cdimage/lubuntu-next-image/+merge/302964
<slangasek> bdmurray: I think they'd get uninstalled, because e.g. virtualbox-guest-x11-lts-vivid Depends: xserver-xorg-core-lts-vivid
<slangasek> bdmurray: however, as per https://launchpad.net/ubuntu/+source/virtualbox-lts-vivid/+publishinghistory these packages only even landed in -updates this month... so I think the number of users who'll be impacted is fairly small
<slangasek> and we could fix it almost immediately
<slangasek> but if we go that way, we should definitely use a different SRU bug for this issue
<slangasek> LocutusOfBorg: ^^ fwiw
<slangasek> tsimonq2: merged
<bdmurray> slangasek: I don't think the existing one in -proposed needs to be released first.
<slangasek> ok
<tsimonq2> slangasek: thanks
<tsimonq2> slangasek: could you please trigger the build manually (instead of waiting for cron) to see if I need to fix anything else?
<slangasek> tsimonq2: running
<tsimonq2> thank you slangasek
<slangasek> tsimonq2: I see it failed, haven't looked how/why, will let you investigate
<tsimonq2> slangasek: where can I find the logs?
<tsimonq2> slangasek: nvm I think I found it
<tsimonq2> slangasek: nope, where is the build log?
<tsimonq2> argh sorry I *did* find it
<tsimonq2> hmmm "No valid suites to build for"
<slangasek> tsimonq2: etc/default-arches ?
<slangasek> (maybe)
<slangasek> nah, the catch-all at the bottom should dtrt
<tsimonq2> I'll check after lunch
 * infinity fixes the project name.
<infinity> slangasek: FWIW, you need to fix ~cdimage/cdimage/production/livefs-launchpad and the livefs itself also needs to be created in LP.
<infinity> Also fixed the project name to not have a space, which debian-cd would end up barfing on after you fix the above. :P
<tsimonq2> thanks infinity
<infinity> slangasek: And https://launchpad.net/~adconrad/+livefs/ubuntu/yakkety/lubuntu-next created for you.
<slangasek> infinity: hmm livefs-launchpad seems awfully redundant with default-arches, why do we need two of these?
<infinity> slangasek: It's mapping project to lp livefs.  It could perhaps be done more intelligently.
<infinity> (or, indeed, default-arches could perhaps grow a column)
<slangasek> infinity: k. anyway, thanks
<infinity> slangasek: When we were split across old-style builders and lp-buildd builders, production/livefs-* made more sense.
<infinity> Err, pretend I didn't paste what I did above, but rather https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/yakkety/lubuntu-next
 * infinity fixed the owner... Derp.
<slangasek> ;)
<tsimonq2> infinity, slangasek: what now?
<slangasek> tsimonq2: basically, all the missing bits were things the cdimage team needed to do but only some of us know how to ;)
<tsimonq2> ok slangasek :)
<tsimonq2> slangasek: so etc/default-arches doesn't need to be edited I assume?
<slangasek> tsimonq2: it does not
<tsimonq2> slangasek: ok, so I don't need to do anything else?
<infinity> tsimonq2: Not until you hit the next failure. ;)
<infinity> But the current batch of failures was on us.
<tsimonq2> hehehehehe
<tsimonq2> so can we get another respin then so I can mov on to the faliures I have to fix?
<LocutusOfBorg> thanks
<LocutusOfBorg> BTW I'm building only the guest packages, so the users are confined to people running ubuntu inside a virtualbox vm
#ubuntu-release 2016-08-16
<rbasak> Can we blacklist src:mysql-defaults from autosync from Debian please? With feature freeze coming up, I'd like to hold this for Yakkety+1 if possible, as it'll make no difference for Yakkety and could be confusing for users.
<rbasak> infinity: ^
<rbasak> It's already been uploaded to unstable.
<rbasak> Though I don't see it in LP yet.
<mwhudson> can someone process golang-github-coreos-pkg pretty pls :-) (slangasek? infinity?)
<infinity> rbasak: Err, why?
<infinity> rbasak: If it'll "make no difference for yakkety"?
<infinity> rbasak: Seems like a reasonable thing to get in, so our packaging can keep tracking for the rest of yakkety, no?
<infinity> rbasak: Otherwise, you're forking mysql from here.
<infinity> (because of mysql-common)
<rbasak> infinity: because it creates default-mysql-* packages, which make it look like we "default" to MariaDB, but that won't be the case (in Yakkety) because no packages actually will use those metapackages.
<rbasak> I should double check, but mysql-common hasn't actually changed yet.
<infinity> rbasak: And if we don't intend to default to mariadb ever, we should change the defaults.
<infinity> rbasak: That's the point of "defaults" packages.  Makes it easier for derivatives.
<rbasak> Debian is only starting the switch to src:mysql-defaults. I don't think it makes sense to take it now, since we're about to feature freeze.
<rbasak> We can take it next cycle and add a delta or whatever.
<infinity> rbasak: I'm really less inclined to agree, I guess.  universe syncs might start depending on the default stuff, and needing deltas, etc.  Just taking mysql-defaults and fixing it is saner.
<infinity> rbasak: Feature freeze is pretty lax (and/or nonexistent) for unseeded stuff.
<infinity> I think any attempt to avoid work here is likely to create more work than just uploading mysql-defaults with s/maria/mysql/ and be done with it.
<rbasak> I just think that it'd be confusing for Yakkety and doesn't actually give us anything. In the case of a universe package getting synced and having a new dependency on default-* in Debian, it's be trivial to delta that out.
<infinity> Err, yes.  But we can fix one package, or fix potentially many.
<rbasak> src:mysql-defaults will also take over mysql-common, currently generated by src:mysql-5.7 in Ubuntu (and src:mysql-5.6 in Debian, which we will update to src:mysql-5.7 without mysql-common soon)
<infinity> I don't get the "confusing" argument.  At all.  If nothing depends on it, it's not confusing, if something does, it's helpful.
<rbasak> I guess it's not confusing if we do delta it.
<infinity> Right.
<infinity> As we do for default-mta, etc.
<infinity> This is a Good Thing(tm).
<rbasak> I don't disagree. Only with the timing. I'm not convinced it's useful to introduce this right now. But I don't feel strongly about it.
<tedg> Hello, I need an archive admin to delete two binaries in yakkety. url-dispatcher and indicator-datetime for s390
<tedg> They depend on libubuntu-app-launch which depends on Upstart which isn't building on s390.
<slangasek> tedg: binaries removed (and ftr it's not two binaries, it's all the binaries built from url-dispatcher source on s390x)
<tedg> slangasek: Thank you, yes.
<tedg> Sorry to be confusing.
<slangasek> tedg: I'm not sure what that does to other packages that depend on liburl-dispatcher1... looks like there are other indicator packages that will need to be removed from s390x in the next round
<tedg> slangasek: A couple, the biggest one is platform-api, but I think that already doesn't build on s390.
<slangasek> yeah, it's only built on x86 and arm
<tedg> Huh, surprised how big that rdepends list is...
<Mirv> ah so there's another bunch of new packages requiring --all-proposed rerun
<Mirv> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtmir
<Mirv> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-settings-components
<Mirv> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-notifications
<slangasek> Mirv: triggered; but why are these packages finding their way into -proposed while the transition is in progress?
<slangasek> some of these, at least, would seem to be silo landings
<slangasek> if people are forcing in landings on top of other landings, they should maybe not do that considering it will further slow down the transition
<infinity> tedg: The goal being to remove upstart, can we tackle that from the other direction?
<infinity> tedg: Removing all the s390x binaries that are in the rdep chain for a package we want to stop depending on seems counter-productive.
<Mirv> slangasek: those are silo landings yes, OTA-13 is being finalized this week
<Mirv> there would be an option to not release to yakkety for a little while if wanted, only publish to overlay PPA
<Mirv> the transition has been going on for three weeks now
<flocculant> infinity: images (all I looked at) aren't building - looking I assume they're having trouble with dependencies
<handsome_feng> cjwatson, infinity: Good morning!  The Ubuntu Kylin daily iso is not created successfully. The question is about python3-aptdaemon.pkcompat package. Kubuntu and Xubuntu have the same question. But Ubuntu and lubuntu daily iso is created susccessfully.Do you know how to sovle this problem? The URL is https://launchpadlibrarian.net/278816938buildlog_ubuntu_yakkety_amd64_ubuntukylin_BUILDING.txt.gz and https://launchpadlibrarian.net/278982117/build
<handsome_feng> log_ubuntu_yakkety_amd64_xubuntu_BUILDING.txt.gz  Thank you !
<seb128> handsome_feng, python3-aptdaemon.pkcompat has been removed, stop trying to install it
<seb128> see https://launchpad.net/ubuntu/+source/aptdaemon/1.1.1+bzr982-0ubuntu15
<seb128> just use packagekit
<handsome_feng> seb128, I see the ubuntu-desktop package still recommend python3-aptdaemon.pkcompat,but python3-aptdaemon.pkcompat is not installed.
<seb128> right, recommends don't fail build, they just go missing if they can't be insalled
<seb128> but that one should probably be removed indeed
<seb128> thanks for pointing it out
<handsome_feng> seb128,  ubuntukylin-desktop also only recommed python3-aptdaemon.pkcompat package, but build failed
<seb128> handsome_feng, you are sure that you don't have something else that has a depends on it?
<seb128> otherwise I don't know but maybe infinity has some idea when he's around
<handsome_feng> I use command "apt-cache rdepends" only find ubuntukylin-desktop which related us.
<handsome_feng> By the way, ubuntu mate,ubuntu gnome, xubuntu, kubuntu have the same issue.
<infinity> ubuntu.yakkety/desktop: * (python3-aptdaemon.pkcompat) # needed to keep packagekit off the images
<infinity> seb128: So, if the intent was to keep packagekit off images, "just install packagekit" seems like a poor fix.
<seb128> infinity, that comment is years old, from a time where packagekit didn't have a decent apt backend, my understanding with that package1.0 transition is that the packagekit backend is considered better maintained and that we want to use it
<seb128> which is why the pkgcompat layer got dropped from aptdaemon
<infinity> seb128: Mmkay.  Will tear it out of all the seeds, then.
<seb128> thanks
<infinity> seb128: Care to do me a favour and look at all the rdeps for pkcompat on http://people.canonical.com/~ubuntu-archive/nbs.html and make sure they're other OR deps or deps on the virtual package?
<infinity> seb128: So we can remove the binary...
<seb128> infinity, k, let me have a look
<infinity> No, some are definitely real deps.
<infinity> ubuntu-drivers-common and packagekit-tools at least.
<infinity> gnome-packagekit-session and gstreamer1.0-packagekit
<infinity> cyphermox: When you remove a package, it would be nice to check the rdeps. :P
<infinity> Oh, gnome-packagekit-session is itself NBS.
<infinity> But also not removable. :P
<tjaalton> anyone fancy reviewing x-x-v-intel from xenial queue? adds some pciids and apparently fixes #1568604
<tjaalton> bug #156860
<ubot5> bug 156860 in f-spot (Ubuntu) "f-spot crashes on tif file import" [Undecided,Invalid] https://launchpad.net/bugs/156860
<tjaalton> uh
<tjaalton> bug #1568604
<ubot5> bug 1568604 in xserver-xorg-video-intel (Ubuntu Xenial) "Mouse cursor lost when unlocking with Intel graphics" [High,Confirmed] https://launchpad.net/bugs/1568604
<infinity> tjaalton: I can haz matching lts-xenial upload?
<Mirv> Laney: i386 unity8 also passed
<tjaalton> infinity: you will
<tjaalton> infinity: if this works?
<tjaalton> I can't repro the bug
<Mirv> so on next update excuses page should look better
<Mirv> (amd64 Pass already visible there)
<Laney> Mirv: cool
<Laney> that wasn't run with all-proposed, but it worked :-o
<Laney> Hopefully then we just need to get the kernel
<Mirv> Laney: it was, s_langasek did a bunch of them when I asked
<Laney> it wasn't, you can see at the top of the log
<Laney> he picked some packages instead
<infinity> tjaalton: Not being able to reproduce is a bit annoying.
<tjaalton> yep
<Mirv> Laney: aren't those full -proposed archives? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/i386/u/unity8/20160816_083258@/log.gz
<Mirv> Laney: but it still just takes the listed ones I guess?
<Laney> --apt-pocket=proposed=src:systemd,src:gsettings-ubuntu-touch-schemas,src:unity8,src:qtmir,src:ubuntu-settings-components,src:unity-notifications,src:libhybris
<Laney> it uses apt pinning to only use those ones
<Mirv> right, then some luck too
<Laney> Mirv: Just kernel stuff left now, AFAICS
<willcooke> Hi gang - could someone take a look at the NM SRU please? https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=network-manager
<Mirv> update_output indeed seems clearer than ever
<Mirv> "just" the kernel is a bit worrying though
<Laney> why?
<Mirv> well I can imagine releasing a new kernel is not always a matter of hours
<Mirv> and herding these cats to not publish anything new might be challenging :)
<Mirv> most of touch stack fortunately doesn't even affect the migrations, and unity8 and friends were just published last night so it's not going to happen soon again
<Saviq> seb128, willcooke, hey, how do I find out about the state of unity8 dependencies WRT MIR? is there some way I could query the archive or maybe we've already a list of projects + MIR bug#s?
<willcooke> Saviq, well, there's this:  https://trello.com/b/mab4G8UQ/unity-8-in-16-10
<willcooke> Saviq, but that's pretty much manual
<willcooke> and bregma has a script which walked the dependancy tree - that might help
<Saviq> I think I'll wait for that...
<bregma> Saviq, ~bregma/+junk/MIR-tools
<Saviq> bregma, ack
<Saviq> bregma, how do I use that? generate-package-list unity8 just shows me unity8, the other shows all binaries from src:unity8
<bregma> add -k to keep the graphviz file and use xdot to view or sotty to convert to svg or some other format
<Saviq> ack
<Saviq> bregma, still, that only shows me the list of binaries from src:unity8, that correct?
<bregma> nope
<bregma> ewww, I mean dotty, not sotty
<bregma> example of unity8-desktop-session from the week before last: http://i.imgur.com/3e4Yq0f.jpg
<bregma> it shows the recursive depends and recommends not in main for all binaries generated by the source packages
<Saviq> bregma, ok, seems my sources.list caused it, got a graph now, do we have a central place listing the MIR bug#s yet?
<bregma> Saviq, just https://trello.com/b/mab4G8UQ/unity-8-in-16-10
<bregma> I was working on a script to connect trello to the packages, but got sidetracked
<bregma> also https://bugs.launchpad.net/~ubuntu-mir/+subscribedbugs?orderby=-datecreated&start=0
<Saviq> bregma, in the MIR bug, I suppose I should only list direct deps?
<Saviq> oh that looks helpful
<bregma> Saviq, that's what I did (ie. only dependencies, not recommends) because Seb says that's all that's really needed despite what the Wiki page says
<Saviq> ack
<bregma> we'll see what beatings the MIR team give us over not including the recommends
<Saviq> bregma, ah, and green is OK because it's in main?
<Saviq> in the chart I mean?
<bregma> Saviq, yeah, green means the source package is already in main so the binary can just be (auto) promoted
<seb128> Saviq, bregma, recommends in universe are going to show on component mismatch but shouldn't block iso builds/create issue, they are going to need to be eventually to be dealt with but that can come after we start installing the session and we can probably demote things to Suggests if needed
<Saviq> ack
<bregma> unless the MIR team rejects the MIR because all recommends must be in main first, in which case we need to land all the package changes necessary to move the recommends to suggests, and all that will take time to move through the pipeline, and there are looming deadlines for 16.10
<seb128> that's only text
<seb128> we can change the recommends to suggests if that's what they want
<seb128> and I doubt they are going to block on that
<bregma> it's still a change that has to land though ci-train, and that can currently take *weeks*
<seb128> it's everybody's interest to get the feature in so it can get tested earlier
<seb128> it doesn't have to
<seb128> dput still works
<didrocks> as long as the change is in the pipe (please link it/write it in the MIR bug report), that's fine, not a blocker
<seb128> didrocks, thanks for confirming ;-)
<didrocks> yw ;) (that's how *I* deal with it, others might have different opinions)
<bregma> at least it's not as bad a Debian in that regard
<didrocks> Saviq: you can use check-mir btw as a helper to list them if that helps
<Saviq> ack
<Mirv> Laney: any word from the kernel team? is there someone we could ping directly?
<tedg> infinity: The answer is "kinda" the problem is that most of these packages triple land all the way back to vivid.
<tedg> infinity: I think that once UAL supports systemd we can make Upstart an optional build dep there. Which will block off some of the issues.
<tedg> infinity: But today that is its only backend, so we kinda need it as a real build dep.
<infinity> tedg: Right, but with the push to move yakkety to all-systemd-all-the-time, I do hope this is something being worked on.  If I have my way, we'll remove libnih/upstart/mountall from the archive entirely before release.
<tedg> infinity: It is on my todo list, but I don't think that's a goal. AFAIK no one is porting the rest of the U8 session to systemd. It's not a goal.
<infinity> It very much is a goal.  People sprinted for this and everything.
<infinity> If we move U7 entirely to systemd but not U8, that's a bit lolz.
<tedg> *I* sprinted on it, but that was U7 not U8
<infinity> pitti: ^-- tedg's been telling me that while unity7 systemdness was a goal, unity8 (and u-a-l?) isn't a priority for yakkety.
<pitti> none of the touch things have been ported yet indeed
<pitti> we do have WIs for it, but indeed less urgent than for u7
<infinity> pitti: I'd really like to remove nih/upstart/mountall entirely by release if we can manage.  But...
<infinity> Though, most of my pain would also be averted by someone fixing bugs in them.
<infinity> Given that the bugs in upstart in yakkety are entirely valid in xenial too, where we're not removing it.
<infinity> I need to talk to Steve about allocating time for that somehow.
<infinity> And chaining xnox to a desk.
<Laney> Mirv: infinity stabbed some people with a rusty fork and it is being progressed
<caribou> Any reason why LP: #1587988 is held in trusty-proposed ?
<ubot5> Launchpad bug 1587988 in sssd (Ubuntu Trusty) "LDAP ping doesn't prefers site-local DCS" [High,Fix committed] https://launchpad.net/bugs/1587988
<flocculant> infinity: thanks for the intel sru bug comment etc - have asked 'our' people to test that
<infinity> flocculant: You're thanking a script, I don't write those comments by hand. :)
<infinity> flocculant: If I did, they'd be more sarcastic.
<flocculant> :)
<flocculant> I'll thank anyone if it helps :p
<xnox> infinity, there are a couple phone specific things that rely on upstart: click apps launching, android container -> text socket io bridge -> system upstart events -> user session upstart events (for e.g. sms notifications)
<xnox> click apps launching -> tedg's help / guidance is needed to port that to systemd
<xnox> porting socket bridge to systemd is doable, but will need a bit of engineering to start/stop targets properties on systemd side and change things to listen/bindsto those and some such.
<infinity> xnox: The whole upstart-versus-newer-kernels thing should probably be fixed in xenial anyway. :/
<xnox> first one is portable without a working phone.
<xnox> the later one needs a phone to test things on.
<xnox> because i can't run an andorid lxc container on a regular desktop and goldfish emulator is b0rked
<xnox> but do we really want to port clicks to run under systemd? and/or will the phone move to have apps as snaps? Or is .click -> .snap conversion scheduled for some time later on the current generation phones?
<bdmurray> slangasek: update-manager, update-notifier, and xserver-xorg-video-ati-lts-xenial are all verified and ready for an early SRU release.
<flocculant> jbicha: I was just a bit confused how the murrine thing actually happened - and not sure of your tz :)
<jbicha> flocculant: I'm US Eastern
<flocculant> aah ok - not 'too' bad then for me :)
 * infinity wonders why packagekit-plugin-click doesn't show up on the NBS report...
<cjwatson> Because it's still listed in debian/control, but conditionally not built
<infinity> Well, that's derpy.
<cjwatson> Needed to keep it existing in vivid/xenial
<infinity> Kay.
<infinity> cjwatson: rdeps look clean, I'll just remove it blindly.
<cjwatson> kay
<infinity> I wonder how often that happens. :/
<infinity> cjwatson: Wow.  A local build of click in sbuild fails the testsuite miserably.  Am I missing a trick of some sort?
<cjwatson> er, dunno.  any details?
<infinity> test_fields (click.tests.test_framework.TestClickFramework) ... ERROR
<infinity> /usr/lib/python3.5/unittest/case.py:628: ResourceWarning: unclosed file <_io.BufferedReader name=3>
<infinity>   outcome.errors.clear()
<infinity> A lot of stuff like that.
<cjwatson> haven't the foggiest.  it's been a while
<infinity> Kay.  Don't care.  The test build was unnecessary anyway, once I realised the thing I was rebuilding for was NBS. :P
<slangasek> flocculant, jbicha: hi, so what's the path forward on gtk2-engines-murrine?  Is this going to be fixed timely in the dependent theme package, or do we need a revert?
<flocculant> slangasek: I'm not sure tbh tbh, ochosi is the guy to talk with
<slangasek> ok
<ochosi> slangasek: it's only "fixable" in the theme package by not using the text-shadow feature anymore in the theme
<slangasek> for reference, the policy on SRUs is "no regressions allowed"; so whoever uploaded this SRU should take some responsibility for following through
<ochosi> as far as i can see the bug isn't fixed
<flocculant> ochosi: thanks for seeing the ping here :)
<ochosi> (the fixes proposed for other themes simply switched to a different way of drawing text shadows which only works in some specific application contexts)
<ochosi> so basically we either need to 1) bisect murrine to see what went wrong where and fix it or 2) roll back
<ochosi> at least that's my view
<jbicha> is it actually a xfdesktop bug or just a murrine bug?
<ochosi> (in theory there are hundreds of other murrine-based themes out there which use text-shadow and now have breakage)
<slangasek> bdmurray: releasing, thanks!
<ochosi> jbicha: it's murrine. xfdesktop has a built-in function for text-shadow (stemming from the times where themes couldn't do it yet)
<ochosi> that's the workaround
<ochosi> but it only works for the desktop, not in other contexts
<ochosi> also see https://bugs.launchpad.net/ubuntu/+source/gtk2-engines-murrine/+bug/1598316/comments/8 for reference
<ubot5> Launchpad bug 1598316 in gtk2-engines-murrine (Ubuntu) "gtk2-engines-murrine desktop text shadow problem" [High,Triaged]
<flocculant> jbicha: shoulD *that* matter?
<ochosi> sry, gotta go, bbl :/
<flocculant> ochosi: understood that :)
<jbicha> flocculant: I think it matters when deciding which bug is more important, the bug that was fixed or the bug that was triggered
<flocculant> I guess
<flocculant> what we have is brokne desktops
<ochosi> final note: as murrine is longtime unmaintained it shouldn't be terribly hard to find the offending commit
<ochosi> i'm even surprised anyone commits to it at all
 * ochosi would look at cimi with sad puppy eyes if he were in this channel right now
<jbicha> ochosi: the bug was triggered by https://launchpad.net/ubuntu/+source/gtk2-engines-murrine/0.98.2-0ubuntu2.1
<jbicha> which was accepted into multiple other distros
<flocculant> jbicha slangasek I don't code at all - I just try to get testing done, when something breaks when it *was* ok - hands up in surrender
<flocculant> jbicha: so can it not be reverted?
<jbicha> ochosi: I think we're delegating the decision on what to do here to you then
<jbicha> sure, it can be reverted; I guess people using 3rd party themes is more common than people using a bitmap font as their system font
<flocculant> mmm
<flocculant> jbicha: I don't know enough to comment more atm, I'll leave that to others
<flocculant> all I'll say is *we* have to test with foo, if it then changes and a flavour ends up broken - that's not good for anyone :)
<flocculant> what I know is that the update broke things for us
<gb_mks> Hi, IÂ´m looking for some help to fix this bug in Ubuntu 14.04. https://bugs.launchpad.net/ubuntu/+source/schroot/+bug/1398569   is this the right place for it?
<ubot5> Launchpad bug 1398569 in schroot (Ubuntu) "overlayfs: handle v3.18 overlay union type" [Medium,Fix released]
<ochosi> jbicha, flocculant: i'll take a look at that commit and see whether i can fix the fix...
<ochosi> (don't hold your breath though)
<tsimonq2> gb_mks: probably #ubuntu-devel
<gb_mks> tsimonq2: thanks  :) I will try there
<tsimonq2> slangasek, infinity: so lubuntu-next is just not building at all, very weird http://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu-next/yakkety/
 * tsimonq2 double-checks cron
<tsimonq2> (I *thought* it was like 11:something AM my time that it spun up and it's 1:09 PM)
<slangasek> tsimonq2: I see the lubuntu cronjob still running, and the crontab edit you made causes lubuntu-next to be serialized behind lubuntu which is probably still running
<tsimonq2> slangasek: ohh good point
<tsimonq2> slangasek: thanks
<tsimonq2> slangasek: wait a minute... https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/yakkety/lubuntu should be done? look at the log for powerpc
<tsimonq2> I'm no expert but doesn't the PPC log look done already?
<wxl> well desktop hasn't built yet
<tsimonq2> wxl: really?
<tsimonq2> hmmm
<tsimonq2> wait, but I think it's waiting on PPC
<tsimonq2> oh nvm
<tsimonq2> so if the live image is built, why isn't it continuing? http://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/yakkety/daily-live-20160816.log
<cjwatson> tsimonq2: cd-build-logs is only synced periodically, it's not a live log
<tsimonq2> good to know, thanks cjwatson
<cjwatson> */15 * * * *    mirror-image-build-logs
<cjwatson> just finished
<tsimonq2> so in a minute and a half it'll sync?
<cjwatson> tsimonq2: ish
<cjwatson> I don't recall how long the rsync takes
<tsimonq2> there it is! \o/
<tsimonq2> slangasek: what's the deal? http://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu-next/yakkety/daily-live-20160816.log
<wxl> same error from yesterday
<wxl> didn't you guys merge the fix yesterday?
<cjwatson> looks like no livefs-launchpad change, again
<slangasek> infinity: ^^ did you forget to push your livefs-launchpad change?
<wxl> also is "Could not resolve hostname royal.buildd" to be concerned about?
<slangasek> that's because of trying to do a non-launchpad build, which is probably a knock-on effect of the missing merge
<cjwatson> yes
<cjwatson> we should probably kill the fallback to be less confusing, but it would just fail differently :)
<cjwatson> (or at least kill the fallback configuration; the code is still conceivably useful for people doing stuff locally)
<infinity> slangasek: I didn't make a livefs-launchpad change.
<infinity> slangasek: I pointed out to you where to make it. :P
<infinity> slangasek: I guess a slight miscommunication there.
 * infinity goes and makes the change now.
<slangasek> infinity: ah, sorry
<slangasek> and thanks :)
<wxl> infinity: when that's merged, is it possible to trigger the rebuild?
<infinity> wxl: Sure.
<wxl> infinity: thank you kindly, sir.
<infinity> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/yakkety/lubuntu-next
<infinity> livefses are building, at least.
<infinity> Progress.
<wxl> yay you rock!
<infinity> Err, oh.  Crap.
<tsimonq2> ooh what's that mean?
<tsimonq2> what happened? :O
<infinity> I goofed something.  Cancelling and trying again.
<tsimonq2> ok ð
<Ukikie> infinity: Speaking of which, you guys bothered to review the MATE/Xubuntu ones?
<mwhudson> slangasek: can you process golang-github-coreos-go-systemd ^ through NEW?
<mwhudson> slangasek: then i can upload lxd!
<wxl> tsimonq2: bah https://launchpadlibrarian.net/279311792/buildlog_ubuntu_yakkety_powerpc_lubuntu-next_BUILDING.txt.gz
<wxl> lubuntu-default-seetings is the problem
<tsimonq2> oh gawd
<slangasek> mwhudson: done
<mwhudson> slangasek: thanks
<infinity> mwhudson: Will this lxd pass its testsuite? :)
<mwhudson> infinity: i certainly hope so!
<mwhudson> there's not really an easy way to find out apart from uploading to -proposed is there?
<infinity> mwhudson: You can run autopkgtests locally, but every time I need to do so, I find myself forgetting where that's documented. :/
<infinity> doko: Your addition of python3-talloc{,-dev} got removed in a later Debian upload.  Do you want to reintroduce that as an Ubuntu delta, or fix the one rdep (ldb) to not care?
<jbicha> mwhudson: it's also possible to run autopkgtest.u.c from a ppa but it's not a very intuitive process
#ubuntu-release 2016-08-17
<Mirv> morning. how's the transition going, is the kernel landing?
<slangasek> Mirv: according to http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#linux it's still blocked by https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1609913.  Have you spoken with the kernel team about it?
<ubot5> Launchpad bug 1609913 in Kernel Development Workflow "linux: 4.6.0-10.12 -proposed tracker" [Medium,In progress]
<slangasek> (I don't know how long their automated testing takes to finish)
<Mirv> slangasek: no, I just heard that inf_inity was talking about it
<Mirv> asked on #ubuntu-kernel now
<oSoMoN> is this the right place to request feedback on https://launchpad.net/bugs/1600176 ?
<ubot5> Launchpad bug 1600176 in webbrowser-app (Ubuntu) "[SRU] webbrowser-app bug fixes" [High,New]
<doko> infinity, I'd like to restore that for now
<RAOF> oSoMoN: Could be!
<RAOF> oSoMoN: Hm. You probably should check your claims in that bug. Specifically - the first two links I clicked on did *not* have details on how to reproduce, neither did they mention autopilot tests.
<RAOF> :)
<RAOF> (https://bugs.launchpad.net/ubuntu/+source/webbrowser-app/+bug/1572673, for example)
<ubot5> Launchpad bug 1572673 in webbrowser-app (Ubuntu) "[webapp-container] Invalid variable access error 'popupWindowController'" [Medium,Fix released]
<oSoMoN> RAOF, let me check, I filed that SRU a while ago and IÂ need to refresh my memories of it
<oSoMoN> RAOF, I have updated the bug reports, adding test cases where they were missing, and specifying in the SRU bug what kind of tests each bug has
<oSoMoN> let me know if anything is missing, Iâll try to address right away
<RAOF> oSoMoN: Hm. webbrowser-app doesn't actually appear to be in the unapproved queue? https://launchpad.net/ubuntu/xenial/+queue?queue_state=1
<oSoMoN> RAOF, not itâs not, I have a silo containing the packages but I was looking for feedback on the paperwork prior to actually landing it
<oSoMoN> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-051/+packages
<RAOF> Ah. It *should* be fine to land it at the same time as getting the paperwork in order. I *think* the silo will correctly dump things in unapproved rather than directly into -proposed.
<RAOF> oSoMoN: OK, so https://bugs.launchpad.net/ubuntu/+source/webbrowser-app/+bug/1572673 is missing reproduction steps (what is an overlay, and how would I cause webbrowser-app to try to open one)
<ubot5> Launchpad bug 1572673 in webbrowser-app (Ubuntu) "[webapp-container] Invalid variable access error 'popupWindowController'" [Medium,Fix released]
<RAOF> Likewise, I'm not *entirely* clear on https://bugs.launchpad.net/ubuntu/+source/webbrowser-app/+bug/1573017 - I *think* this is about a webapp in a container requiring multi-stage login and opening up the browser for the sso.ubuntu.com step, but I'm unfamiliar with the specific terms used.
<ubot5> Launchpad bug 1573017 in webbrowser-app (Ubuntu) "[webapp-container] SAML detection logic broken" [High,Fix released]
<oSoMoN> RAOF, bug #1572673 has an autopilot test along with the bug fix to verify it, but Iâll clarify the bug description anyway
<ubot5> bug 1572673 in webbrowser-app (Ubuntu) "[webapp-container] Invalid variable access error 'popupWindowController'" [Medium,Fix released] https://launchpad.net/bugs/1572673
<RAOF> Oh, you should probably mention the autopilot test then :)
<oSoMoN> will do
<RAOF> (And how to run it)
<oSoMoN> and same for bug #1573017, Iâll clarify and explain how to run the tests
<ubot5> bug 1573017 in webbrowser-app (Ubuntu) "[webapp-container] SAML detection logic broken" [High,Fix released] https://launchpad.net/bugs/1573017
<RAOF> Finally (before I look at the actual code), it'd be nice if the changelog entry in your .changes file had a brief description of the changes, rather than just a list of bug numbers.
<RAOF> That's a nice-to-have, though.
<oSoMoN> that will require a silo rebuild, but it should be fine
<oSoMoN> Iâll take a quick lunch break and will be right on those afterwards
<oSoMoN> RAOF, Iâve updated the bug reports to indicate when there are autopilot tests, and how to run them
<oSoMoN> RAOF, sil2100 told me that the CI train currently doesnât allow using the entire commit message of a merge request as the changelog entry
<oSoMoN> I could probably add a detailed changelog entry to the branch itself, but not sure how well bileto would deal with itâ¦
<pete-woods> hey all! any archive admins about who could delete a binary package for me from s390x?
<pete-woods> http://paste.ubuntu.com/23064439/
<pete-woods> ^ that's the list of packages that needs to be nuked from s390x on yakkety
<pete-woods> some of the dependencies for that lib have just been removed, so I can't build it on s390x any more
<jbicha> Ubuntu GNOME amd64 yakkety has been stuck at "re-building" in the iso tracker since yesterday
<pete-woods> slangasek: hi! any chance you could take care of the binary package removal I nagged about just above?
<infinity> jbicha: Looking.
<infinity> jbicha: Fixed.
<jbicha> thank you
<slangasek> pete-woods: which is the dependency that's been removed on s390x?
<pete-woods> slangasek: url-dispatcher
<slangasek> pete-woods: ack, removed from yakkety and yakkety-proposed
<pete-woods> slangasek: awesome, thanks!
<flexiondotorg> infinity, I just uploaded mate-media_1.14.1-0ubuntu1~yakkety1.0 to the archive in error. Can you rejected it please.
<flexiondotorg> infinity, And sorry.
<infinity> flexiondotorg: I can't.
<infinity> Well, maybe I can if I'm fast.
<flexiondotorg> Ah.
<flexiondotorg> OK.
<infinity> Nope.  But I can delete it.
<flexiondotorg> That works :)
<infinity> flexiondotorg: Done.
<flexiondotorg> infinity, Thank you. Add it to your next beer tab ;-)
<Mirv> I see "gcc-snapshot" as a newcomer to update_output.txt on arm64
<Mirv> doko uploaded one earlier today
<infinity> Mirv: An upload that hasn't managed to build yet shouldn't affect migration.  Curious why snapshot in the release pocket is going to be broken by that block.
<infinity> Will look once I'm happy with the kernel state.
<jbicha> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/yakkety/ubuntu-gnome/+build/72765 and 72766 appear to have stalled
<infinity> jbicha: Or it's just taking a very long time to push the bits over the ocean.
<infinity> We don't have any visual feedback for "the builder is returning results now".  We probably should.
<infinity> Never mattered when everything was in London. :/
<infinity> Oh.  Wait.  That *is* in London.
<infinity> Well, in Redhill.  Close enough.
<infinity> Hrm.
<jbicha> I don't mind if we wait a bit longer
<jbicha> I'm wondering why empathy still seems to want to be on the UG images, does something else need to be manually updated for a metapackage change like that?
<infinity> jbicha: mcp-account-manager-goa
<infinity> jbicha: http://paste.ubuntu.com/23065193/
<jbicha> infinity: can you update the tasks then? https://launchpad.net/ubuntu/+source/ubuntu-gnome-meta/0.63
<infinity> Tasks are automatically generated from germinate output...
<infinity> So, perhaps something's going wonky.
<jbicha> for a simpler example, germinate is pulling in both gucharmap and gnome-characters but gnome-characters replaced gucharmap in the metapackage today
<bladernr> Hey, when will the ISOs for 16.04 GA be moved to Old Releases, now that 16.04.1 is available?
<bladernr> ^^ old-releases.ubuntu.com
<jbicha> infinity: it took over 3 hr but the UG iso's finally finished :)
<jbicha> I have 3 gnome-games I want to upgrade to new versions but they depend on libgnome-games-support ^
<jbicha> so, release team assuming that new pkg doesn't get accepted in the next 24 hr, would it be better for me to upload those games now and have them be in depwait, or just wait
#ubuntu-release 2016-08-18
<infinity> jbicha: Problem solved by me reviewing and accepting libgnome-games-support.
<jbicha> infinity: thank you
<infinity> jbicha: Minor nitpick, debian/copyright assigns copyright of debian/* to upstream (ie: there's a block for *, but no debian/* block), but if that's standard in the GNOME packaging, I don't really care.
<infinity> And 99% of debian/ isn't copyrightable in most jurisdictions anyway.
<infinity> jbicha: Otherwise, looked good.
<jbicha> yeah, I prefer to let upstream keep the copyright
<infinity> jbicha: Binaries looked good too.  Enjoy.
<oSoMoN> why does `sudo do-release-upgrade -d` say thereâs no new release found when I run it on 16.04.1 ? Shouldnât it offer yakkety for upgrade?
<infinity> oSoMoN: What is Prompt set to in /etc/update-manager/release-upgrades ?
<oSoMoN> itâs set to "lts"
<infinity> oSoMoN: I'm going to assume 'lts'
<infinity> oSoMoN: Right, yakkety isn't an LTS.  So, there you go.
<oSoMoN> infinity, thanks, I didnât know of that option
<infinity> oSoMoN: It's a twiddle in the Software Properties UI (and in the config file, obviously).  If you install with an LTS, it defaults to LTS, to avoid downgrading people's support length surprisingly.
<oSoMoN> that makes sense
<Mirv> infinity: Laney: our machinery of not allowing Publish button to work apparently did not work since there is now a new UITK in proposed. just FYI since either something should be done about it or ok for a new delay from that (mostly running unity8 test and possibly rerunning if flaky, running takes 2-3h)
<infinity> Mirv: S'ok, I had to redo my kernel hack, so we're still waiting on that to clear the pipe.
<infinity> Mirv: Come hell or highwater, this mess will migrate today, or I'm stabbing someone. :)
<infinity> I don't even care who.
<Laney> I'll stab a rebuild of unity8 with all-proposed against it once it's published
<Laney> s/rebuild/restest/
<infinity> Ta.
<Mirv> ok
<sergiusens> bdmurray hi there, can you accept snapcraft 2.15 into xenial-proposed please?
<arges> sergiusens: bdmurray i got it
<sergiusens> oh thanks arges
<arges> done
#ubuntu-release 2016-08-19
 * Mirv recommends people to switch the side of the street if they see infinity walking towards them
 * acheronuk hands out a pile of stab proof vests just in case
<Mirv> not that I'd see any other blocker than the tag in the bug related to kernel 4.6
 * acheronuk glares at pesky tag
<Laney> please could someone remove unity-greeter/s390x from yakkety-proposed?
<Laney> I just uploaded 16.10.2.2 with a build-dep on upstart so it doesn't come back
<xnox> looking at unity8 adt test failure
<xnox> it claims not able to find Lcov or gcovr
<xnox> i guess it's a case of transitive adt test dependencies gone missing?
<xnox> Mirv, is this something you can look into, or who should I ping about src:unity8 ? ^
<xnox> because apperantly my biometryd upload regressed unity8 adt
<Laney> xnox: nah we need to run it with all-proposed
<xnox> ah
<Laney> once this $Â£"$"% gets migrated that won't be necessary any more
<Laney> however...
<Laney> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity8
<Laney> it got promoted without its deps?
<Mirv> xnox: as Laney said
 * xnox slowly backs away
<Mirv> ouch, how did that happen
<Laney> https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1613638
<ubot5> Launchpad bug 1613638 in unity8 (Ubuntu) "[MIR] unity8" [Undecided,Fix released]
<Laney> jumped the gun?
<Laney> I think it should be demoted again
<Laney> doko's offline though
<xnox> Laney, he is sending emails though....
<Laney> xnox: about promoting things?
<xnox> Laney, just 1on1 emails about things i'm uploading (replies to changes mailing list)
<xnox> he is online, just not on irc.
<Laney> ok
 * Laney emailzzzzzzzzzz
<flocculant> afternoon peeps - tested completely with xubuntu, half way through testing with ubuntu daily - seems no network on either daily today
<flocculant> pitti: could the lack of network on the dailies (and the installed version) be something to do withhttp://changelogs.ubuntu.com/changelogs/pool/main/n/network-manager/network-manager_1.2.2-0ubuntu8/changelog ?
<pitti> flocculant: this needs https://launchpad.net/ubuntu/+source/livecd-rootfs/2.427 too
<pitti> flocculant: I noticed that e. g. the last ubuntu desktop dailies were still built with 426, so ethernet wouldn't work via NM indeed
<pitti> flocculant: in theory tomorrow's dailies should be fine again, otherwise I'll investigate on Monday
<Laney> pitti: flocculant: I've kicked a rebuild to verify
<pitti> â oh, nice, thanks Laney: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/yakkety/ubuntu/+build/72979
<pitti> I uploaded both NM and livecd-rootfs yesterday at the same time, but apparently some odd timing somewhere
<pitti> or I messed up the livecd-rootfs change, which is plausible :)
<Laney> erm, hang on
<Laney> https://launchpadlibrarian.net/279800397/buildlog_ubuntu_yakkety_amd64_ubuntu_BUILDING.txt.gz <- 2.427
<pitti> Laney: actually, the one from 5 hours ago was already using 247
<pitti> sorry, I looked this morning, and got the 20 hours old one
 * pitti rsyncs
<Laney> I wonder if I got this one or the previous
<pitti> I should also make this more verbose
<pitti> this == http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/revision/1431
<Laney> I already had that one it seems
<Laney> at least zsync thinks it's 100% complete
<pitti> confirmed, no /etc/netplan/01-network-manager-all.yaml there
<pitti> ogra_, infinity: do you happen to see why http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/revision/1431 would not actually do anything? AFAICS "chroot/" should be the live file system in construction, no?
<pitti> my first guess is that this hook runs before installing ubuntu-desktop
<pitti> I see hooks for ubuntu-core, cpc, desktop-next, and touch, but none for "plain" ubuntu/xubuntu etc.
<ogra_> pitti, we dont build yakkety ubuntu-core
<pitti> ogra_: I want to do that when building desktop images, not -core
<ogra_> (please dont trigger any builds manually, we also stopped using cdimage for that and the publishing folders have placeholders we do not want deleted)
<pitti> l
<ogra_> oops, i got tricked by ~ubuntu-core-dev :P
<Laney> haha
<pitti> â¦â¦â¦â¦â¦â¦â¦â¦ubuntu-touch:*|ubuntu-touch-custom:*|ubuntu-core:system-image|ubuntu-desktop-next:system-image|ubuntu-cpc:*)
<pitti> â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦cp -af /usr/share/livecd-rootfs/live-build/${PROJECT}/* \
<pitti> â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦config/
<pitti> oh, this might be the bit that installs hooks for those projects
<ogra_> pitti, look into adding a hook to live-build/$project/hooks instead
<pitti> so apparently we just don't have any hooks for the desktop flavors (this isn't flavor specific at all)
<ogra_> well, then auto/build is fine but there the place you add it is essential
<pitti> this applies to every kind of image build; so live-build/auto/build runs before installing packages, and there's no script which runs after?
<pitti> ogra_: I added it at the very end, but it seems that auto/build is not actually the thing that installs packages?
<Laney> pitti: I don't know about that - you can see in the log that "Checking size of /usr/share/doc" is in the log after packages are installed
<Laney> but it's earlier in auto/build than your code
<ogra_> live-build/auto/build runs both, before and after
<pitti> oh, so I did that *too* late
<pitti> presumably after the squashfs
<Laney> there's a mksquashfs after this script
<ogra_> it really depends ...
<ogra_> some projects roll their tarballs from within live-build/auto/build ...
<pitti> http://paste.ubuntu.com/23070370/
<ogra_> looking at the current code, you want to add it *before* line 203
<pitti> ogra_: thanks for the hint about "Checking size of doc/, to relate log output with the script
<ogra_> that was Laney :)
<ogra_> but yeah ... there are multipple subshell calls in the live-build/auto/build script
<ogra_> you want to be in the one above 203
<pitti> right, the above patch does that now
<ogra_> yeah,  that should work
<pitti> flocculant, Laney, ogra_: livecd-rootfs_2.428_source.changes uploaded; sorry about messing this up
<pitti> Laney, ogra_: thanks for your help!
<ogra_> no worries
<Laney> ah
<Laney> it's the "lb binary" that you need to be before
<Laney> maketh sense
 * Laney didn't see that sneaky line there
<ogra_> yeah .. the subshell braces make it really hard to read
<infinity> pitti: Are you sure that doesn't belong in casper?
<infinity> pitti: As in, is the plan for desktop systems to be all-nm-all-the-time, or was your intent to just do that for live sessions?
<infinity> pitti: Well, actually, I guess that would be the plan for desktops as a default.  But if server starts preinstalling NM, your hack goes sideways too. :)
<ogra_> well, but servers are supposed to also use the new infra, just not with NM ... at least the "mkdir /etc/netplan" is generic
<ogra_> probably the patch should be split ...
<sil2100> infinity: hey! Any news on our yakkety-proposed issues? ;)
<infinity> sil2100: Every fixed bug pops up another.  Next is fakeroot segfaulting on i386 and armhf. :/
<sil2100> How I hate fakeroot
<infinity> ogra_: I'd be more inclined to say this belongs in installers, where networking has always been.  Which implies casper for the live session.
<infinity> pitti: ^
<infinity> A rootfs can't make a one-size-fits-all choice here, probably.
<ogra_> hmm, indeed
<infinity> sil2100: Not as much as I'm going to hate it by the time this day is over. :/
<infinity> sil2100: It's not exactly fun to debug.
<infinity> sil2100: At least the kernel is sorted?  One step forward, one back...
<slangasek> Mirv: who did you talk to from the kernel team about their update landing in yakkety?
<slangasek> infinity: why do we have both a blocking bug and a block hint for linux?  Shouldn't the blocking bug be sufficient?
<infinity> slangasek: The blocking bug is meant to go away in favour of the hint, I think.  Or something.  Andy, Brad, and I need to sort out the master plan there. :P
<infinity> slangasek: Anyhow, it can be unblocked.  But it won't go in.
<slangasek> infinity: AIUI apw is on vacation currently; and linux is currently holding up the world because linux-tools; so I'd like to know who I'm blaming for things
<Mirv> slangasek: no-one answered but infinity already earlier removed the arm64 problematic 4.6 kernel from proposed, replacing it with a 4.4 rebuild (only which didn't build with gcc6)
<infinity> slangasek: You can blame me, it's my kernel, and I'm happy to release it.  But, like I said, it won't go in anyway.  d-i is FTBFS on two arches due to a fakeroot segv.
<Mirv> slangasek: so the bug blocking tag actually talks about the 4.6 that is no more
<slangasek> infinity: how does a d-i FTBFS block this?
<infinity> slangasek: kernel can't migrate without d-i.
<slangasek> because?
<infinity> Because of dependencies?
<slangasek> ok
<infinity> slangasek: If you love debugging fakeroot, feel free to play along.  I got pointers from Clint, but am just about to dive into it when waking up is complete.
<slangasek> infinity: this is blocking the world.  What's in "your kernel" that needs to go in?  All we need is a rebuild of linux-tools against current binutils; could we bump the current linux aside, do a no-change rebuild of the kernel in yakkety, get that through, and then unpick the fakeroot thing?
<slangasek> this transition has been blocking the world for weeks at this point
<slangasek> and speaking of which, is the autoimporter turned off, so other things stop sneaking in from unstable and delaying us?
<infinity> slangasek: That is a no-change rebuild, but with a new ABI to not clash with xenial.
<slangasek> why does a no-change rebuild get a new ABI?
<infinity> "to not clash with xenial".
<infinity> And because ABI == package name == must be unique if you want signed modules to work.
<pitti> infinity: as far as I understood slangasek back then, we wanted NM to manage all devices for "desktop" installs (where we pre-install NM), but if you apt install n-m on an existing system we don't want it to take over interfaces managed by networkd
<pitti> infinity: so instead of trying to come up with a fuzzy  definition of "what is desktop", I think "n-m is preinstalled" is what we actually want
<slangasek> infinity: I don't follow how there's a clash with xenial
<infinity> The concept of non-abi-bumping kernels went out the window with ephemeral signing keys.
<pitti> infinity: and no, this isn't specific to the live system (thus not in casper)
<slangasek> ugh
<slangasek> infinity: then I think we should accept breaking installability of linux-tools while this wends its way through
<slangasek> however, it seems address-book-app and indicators-client have reset
<infinity> slangasek: Well, we can break linux-tools, or we can break server ISOs.
<Laney> Somebody prematurely promoted unity8
<Laney> well, doko. :P
<infinity> Someone should unpromote it?
<Laney> I emailed him
<Laney> do i
<Laney> t
<infinity> Bug?
<infinity> Found it.
<Laney> 'k
<slangasek> infinity: are you demoting?  I have it here from c-m
<infinity> slangasek: I am.
<slangasek> ok
<slangasek> I'll write up the force hint
<infinity> Err, wat?
<slangasek> to break linux-tools?
<infinity> I'd rather break server ISOs, to be honest.  That has no visible archive impact.
<infinity> ie: force the kernel in.
<slangasek> both require a force hint
<infinity> If you force the kernel, the rest will just flood in without hinting.
<infinity> Am I not awake enough to use change-override correctly, or is LP busted today?
<infinity> Oh, I can't spell universe.
<infinity> Apparently.
<ogra_> Ã¼nivÃ¤rse
<infinity> I'm not Swedish.
<pitti> ogra_: no, junivÃ¤rs clearly
<ogra_> !
<infinity> pitti: Maybe.  I dunno.  Still feels like this belongs to installers, not to filesystem builders.
<infinity> Our filesystems have never shipped a working network config.
<infinity> Well, except for the live session NM case, I guess.
<pitti> infinity: it's not configuring any network devices, just telling NM that it should manage all devices instaead of just wifi+wwan
<infinity> pitti: Right, but if that config doesn't belong in the package, it belongs in the installer, generally.
<pitti> infinity: alternatively we could put this into nm.postinst if there is some robust way for it to see if it installs into an OS image build or onto an actually running syste
<pitti> m
<slangasek> infinity: I've hinted the lot, linux included; this way if something else gets uploaded in the meantime we get to look at it rather than just randomly increasing the uninstallability count further
<infinity> pitti: livecd-rootfs's job (well, before system-image and core came along, ignore their crazy hooks) is to provide a pristine image, not a working preinstalled image.
<slangasek> infinity: and I've dropped the block-proposed tag from the bug
<pitti> infinity: well, I wouldn't like to duplicate this logic into ubiquity, cloud-init, casper, and another handful of installers
<pitti> refining nm.postinst sounds good, if we find a good test there
<infinity> pitti: And, yet, that's what having multiple installers tends to mean. :/
<infinity> pitti: I don't see how it can reliably belong in a postinst either.
<pitti> putting it into image builds seemed both robust and central to me
<pitti> as that's what it is effectively -- policy based on the kind of image we build
<infinity> pitti: Okay, ignore the desktop case for now.  If I install a server ISO, configure a network (which is ifupdown today, but won't be Very Soon, I assume), I also need a netplan config that tells it to DTRT, right?
<infinity> pitti: So, installers already need to know how to write that config.
<infinity> pitti: Or, so I would think.
<pitti> infinity: right, for the actual devices you configure
<slangasek> the server iso doesn't need a netplan config to declare the renderer policy because it uses the default
<pitti> right
<slangasek> it just needs the netplan config for the devices that are configured
<slangasek> and that obviously belongs in the installer
<pitti> and the default NM behaviour is now "manage wifi and wlan, ignore everything else"
<infinity> But... That's going to break upgrades.
<slangasek> the desktop ISO needs something different; it needs the policy saying "NM owns all the devices", which is a policy related to the image you install from rather than the packages you have
<pitti> but for desktops (or, IMHO, more precisely: images that ship NM by default) we want NM to manage everything
<infinity> The "default" needs to be smarter than this.
<infinity> Unless we don't intend to ever migrate people to netplan.
<slangasek> infinity: upgrades won't have any netplan yaml on them so by default things will continue to do what they do
<infinity> Given that probably 99% of our desktop users use NM for all interfaces.
<pitti> also, upgrading NM disables the "restricted" policy
<slangasek> the upgrade path doesn't need to land at the same time as the installer support.
<slangasek> except for that bit that pitti mentions for NM
<slangasek> we have actually worked through this already
<pitti> install xenial NM, upgrade to y â NM manages everything
<pitti> install yakkety NM â NM only manages wifi/wwan
<pitti> and desktop images ship a policy snippet that tell it to again manage everything
<infinity> And if I had an ifupdown config, and NM ignoring it?
<infinity> (as it does)
<pitti> that's how I understood the discussion at the Athens sprint
<infinity> Anyhow.  I didn't mean to go down the upgrade rabbit hole.
<pitti> infinity: NM ignores devices that are configured in ifupdown
<infinity> A config file that says which interfaces are managed by what is an installer config file.  That's all I was arguing.
<pitti> correct
<infinity> If installers configure interfaces, they know which interfaces are configured by what.
<pitti> well, a file that says "ens3 is configured like this"
<infinity> The installer knows the inverse too.
<pitti> the livecd-rootfs bit is generic policy, not particular interface config
<infinity> It knows if you chose no manual configuration and, thus, are all-nm.
<infinity> Or whatever.
<infinity> pitti: What happens in a ubiquity install (hypotetically, I assume this hasn't landed yet) if I manually configure an interface?  Is it going to inject a manual eth0 config into NM, or something netplan/systemdish, or...?
<infinity> If the answer is anything other than "everything will always be network-manager", that config file doesn't belong on a pristing livefs.
<infinity> pristine*
<slangasek> what do you mean by "inject a manual eth0 config"?
<slangasek> sorry
<slangasek> what do you mean by "manually configure an interface"?
<infinity> slangasek: Set up a static IP on my ethernet adapter.
<infinity> slangasek: For instance.
<slangasek> how?
<pitti> right now ubiquity just copies the NM connections
<infinity> Ask nicely?
<pitti> not sure if that should stay or if this should somehow be converted to a netplan config (the former is much simpler obviously)
<infinity> Oh, I guess ubiquity does just use NM for that anyway, doesn't it?  It's not something I've done in a long time.
<pitti> yes
<pitti> d-i, subiquity etc. are different beasts
<pitti> d-i currently writes /e/n/i, and should move to netplan
<slangasek> pitti: yes, the latter is out of scope
<pitti> same for subiquity, cloud-init etc.
<slangasek> you twiddle nm-applet, you get a config in NM
<slangasek> but nm-applet needs to first be told that it's allowed to mess with eth0, which by default in the package it wouldn't be
<slangasek> to ensure the correct experience when installing NM on a non-desktop system
<infinity> I really dislike this desktop/not-desktop split being anywhere but installers.
<infinity> If I netboot d-i and install a desktop, I'll get a different experience.
<pitti> right, then NM wouldn't manage ethernets by default
<pitti> but that's independent of whether it's livecd-rootfs or the installer who writes that policy snippet
<pitti> and you would currently have an /e/n/i for your ethernets, which you don't have with a desktop isntall
<pitti> so in some way it's the same experience
<infinity> Well, yes and no.  I guess it's about mindset.  If we say "this is an installer thing", then we fix the installers to do what we want, instead of saying "this ISO behaves this way".
<slangasek> you will get a different experience anyway when netbooting d-i to install the desktop, because we do not support installing the desktop with d-i netboot.
<Laney> We should turn off auto-sync
<infinity> We should.
<pitti> not just "we will", we already do (cf. getting an /e/n/i or not)
<slangasek> where's the button for turning off autosync?
<infinity> I overworked myself yesterday and forgot to freeze.
<Laney> I think it's adding --dry-run in the crontab
<Laney> Can do that
<infinity> Yeah, snakefruit crontab.
<Laney> And have done
<Laney> happy DIF
<infinity> slangasek: Unless "we don't support doing it that way" becomes "we acitively prohibit doing it that way", it's a pretty lousy argument, IMO.
<infinity> But I'm also cranky.  Obviously.
<slangasek> Laney: thanks :)
<Laney> I'll announce feature freeze too
<Laney> brain isn't feeling up to very much else
<infinity> Laney: My hero.
<Laney> it's that or design a hook interface for the appstream generator
<infinity> Laney: I'm sure it's still Thursday somewhere.
<infinity> Like, in a gravity well or something.
<slangasek> infinity: the argument is "it's more work to do it that way to facilitate this use case that *we do not support*"
<jbicha> I wanted to upload bug 1613291 but I've been waiting this week for qt to migrate first, can I still upload today or do I need to wait until after Beta?
<ubot5> bug 1613291 in evolution-data-server (Ubuntu) "Update evolution stack to 3.22" [Wishlist,In progress] https://launchpad.net/bugs/1613291
<Laney> can you get the transition done over the weekend?
<cjwatson> Oh, excellent, I think that may be the first time !me implemented DIF post-new-auto-sync
<jbicha> yes, there's one CI train package (syncevolution in universe) though
<Laney> Doesn't the train implement proper ACLs now?
<Laney> If not, you can dput it and submit a merge proposal to reconcile trunk
<jbicha> I don't have push rights to https://code.launchpad.net/~phablet-team/syncevolution/ubuntu but yes since it's in universe I can just force it in
<jbicha> and evolution-rss needs to be removed as s_eb128 ack'd on the bug
<Laney> You might be able to use CI train
<Laney> which does have push access
<jbicha> can you point me to where I should look to try that?
<Laney> jbicha: https://wiki.ubuntu.com/citrain/LandingProcess#landing
<Laney> you can get robr_u to look it over
<Laney> infinity: you haz moderation
<infinity> Laney: Looking.
<infinity> Laney: And approved.
* Laney changed the topic of #ubuntu-release to: Released: Trusty 14.04.5, Xenial 16.04.1 | Archive: feature freeze | Yakkety Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis
<flocculant> pitti Laney and anyone else involved - thanks :)
<pitti> flocculant: no guarantee that the next image builds will actually work, but much higher chance now :) I'll keep watching out
<flocculant> pitti: well I'll look tomorrow and see what happens :)
<Laney> looks like Things just went in
<flocculant> okey doke
<flocculant> I'll soon shout out if needed - then wait for Monday :D
<pitti> Laney: ooh -- you mean THINGS really, like half of -proposed
<pitti> yay!
<flocculant> :)
<pitti> Friday evening is the BEST time to break yakkety
<Laney> pitti: the power of the force hint
<infinity> Laney: While you're being captain helpful, what are the odds you'd be willing to be on deck for Beta2?
<infinity> s/Beta2/Beta1/
<infinity> The one next week. :P
<flocculant> I'm so glad we've ignored those this cycle ...
<Laney> infinity: Could do, if someone flavourish is on the other side
<infinity> Laney: I'll leave that between you and the flavours, then. :)
<infinity> Laney: We made it very clear last time that if they don't get their act together, we're not playing.
 * Laney grimaces
<Laney> flexiondotorg: Can you dig someone up to release manage beta 1 please? :)
<jbicha> just to be clear, can I start the evolution transition now?
<Laney> Assuming everything is test built and going to go smoothly, no objection from me
<jbicha> yes, I'll just need an AA to remove evolution-rss
<Mirv> wow, don't wake me up, this is better than my dreams about Qt usually
<Mirv> is now the time when I go file FFe about Qt 5.7? it's about time to get up-to-date Qt release in to archives </funnyness>
<Mirv> sil2100: the transition is happening, I can start cleaning the unfinished issues latest on Monday, but let's see this through now first before immediately publishing the pending stuff
<Laney> Mirv: you can probably turn CI train publishing back on now, I guess
<sil2100> \o/
<Mirv> Laney: we accumulated some manual backlog during the last few days, it's better to clean that up before accepting uncontrolled publications
 * Laney shrugs
<jbicha> Laney: is that a yes on evolution then?
<ginggs> xnox: i'm not sure you are the right person to ask, can we remove boost1.58? i think there are a few things to decruft
<Laney> jbicha: Yeah, just don't break stuff. :)
<ginggs> slangasek: can we remove fpc and rdeps on powerpc? debian bug #834644 has been filed
<ubot5> Debian bug 834644 in ftp.debian.org "RM: fpc reverse dependencies [powerpc] -- ROM; fpc doesn't build anymore on powerpc" [Normal,Open] http://bugs.debian.org/834644
<Mirv> pitti: do you have some special place you use for monitoring "recent things moving from proposed to release pocket"?
<pitti> Mirv: no, just working off excuses.html
<pitti> and for my own uploads I obviously get ACCEPTED mails
 * pitti waves, have a nice weekend everyone!
<Mirv> ok
<Mirv> have a nice weekend, especially infinity for all the efforts in the last few days (even if some of it still continues)
<Mirv> I may do a thing or two during the weekend since there's so much pending that has been waiting, including powerpc GCC6 fix for Qt apps
<Mirv> inbox is reminding me of all the LXQt, KDE autopkgtest, packagekit, seed and other fixes that I needed to do in the past weeks (by giving the release pocket notifications). it was a really long journey.
<slangasek> Newly uninstallable packages in testing:
<slangasek>     * amd64: debian-installer-udebs
<slangasek>     * arm64: debian-installer-udebs, gcc-snapshot
<slangasek>     * armhf: debian-installer-udebs
<slangasek>     * i386: debian-installer-udebs
<slangasek>     * powerpc: debian-installer-udebs
<slangasek>     * ppc64el: debian-installer-udebs
<slangasek>     * s390x: debian-installer-udebs
<slangasek> tada
<slangasek> Mirv, infinity, sil2100: ^^ hint done; linux can take a bit longer to un-pick
<slangasek> ginggs: fpc> if there's an open bug for this, can you remind me the number?
<sil2100> Ooh!
<slangasek> robru: ^^ was that the reason that publishing was disabled?  Can this then be reverted now?
<jbicha> infinity: do you want a tracking bug for the issue where germinate is still pulling in old pkgs that shouldn't be in Ubuntu GNOME's Y seed any more? if so, where would I file that bug?
<ginggs> slangasek: is it 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> ginggs: LGTM, thanks
<Mirv> slangasek: that was the reason, to give infinity the peace of untangling the problems while not getting more packages delaying the transition into yakkety. I've made a short backlog of todo items in the last few days http://pad.ubuntu.com/yakkety-pending-landings but I've handled the really manual stuff now so I think robru can now indeed restore the functionality
<acheronuk> Mirv: http://paste.ubuntu.com/23071193/
<Mirv> acheronuk: :D looking good! nice that even upgrading from a variety of PPAs works
<acheronuk> Mirv: yep, it even unblocked some ppa stuff that had built against proposed :)
<superm1> can an AA please axe that appstream-glib upload ^, it seems to be causing crashes and needs closer looking
<superm1> thanks
<slangasek> superm1: done
<superm1> thanks
<sergiusens> slangasek mind taking a look at that ^ please?
<slangasek> sergiusens: accepted
#ubuntu-release 2016-08-20
<tsimonq2> slangasek: does https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze_for_new_packages apply to source packages only?
<slangasek> tsimonq2: generally yes
<slangasek> tsimonq2: though I don't think that actually documents current practice, which is actually more along the lines of "if it's a completely new package that doesn't touch anything, we require no paperwork, you just have to get an AA to review it"
<jbicha> slangasek: oh, so I can just sync bug 1614894 after a test build?
<ubot5> bug 1614894 in cassbeam (Ubuntu) "Sync cassbeam 1.1-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1614894
<tsimonq2> slangasek: let's say foo is a big package. I want to split foo into foo and foo-bar to separate it and add a few more things to foo-bar (for some complicated reasons)
<tsimonq2> slangasek: it fixes foo when installed under certain conditions, but since it adds new files as well, it might be considered a feature
<tsimonq2> slangasek: (I'm talking about lubuntu-default-settings being split into lubuntu-qt-default-settings and updating the seed to fix the Lubuntu next image)
<tsimonq2> slangasek: do I need to file an FFE when Julien merges my MP into the lubuntu-default-settings repo?
<slangasek> jbicha: cassbeam> yes
<slangasek> tsimonq2: I would call that ba bugfix and not press you for an FFe
<tsimonq2> ok thanks slangasek
<flocculant> pitti: that'll be a no from here re networking :(
<flocculant> also daily gets to the try/install dialogue and then no further to get to desktop without using startx
<flocculant> s/the try option of the dialogue
<jbicha> flocculant: wait a few hours and try a rebuild: https://launchpad.net/ubuntu/+source/livecd-rootfs/2.429
<flocculant> jbicha: ack - ty :)
<jbicha> for networking, I don't know about the other issue
<flocculant> well at least if I get networking I can try and report it with apport :D
<flocculant> not really sure what to report against mind you - tracker suggests syslinux
<jbicha> yeah I had to use a USB stick to get the data out of VirtualBox for bug 1614848
<ubot5> bug 1614848 in Ubuntu GNOME "ubiquity crashed with GLib.GError in configure_icons(): gtk-icon-theme-error-quark: Icon 'gtk-missing-image' not present in theme Adwaita (0)" [Critical,New] https://launchpad.net/bugs/1614848
<jbicha> I guess I was one of the first to be affected by the no-networking bug but since ubiquity was badly broken I didn't realize it wasn't ubiqutiy's fault
<flocculant> ha ha
<flocculant> jbicha: I'm just glad xubuntu is only doing final beta or I'd be :( at the moment
<sakrecoer> flocculant: i ma in here :)
<sakrecoer> where do you announce these discussions as the one held yesterday?
<flocculant> sakrecoer: if you mean what I said in the mail - it wasn't - I just read it in channel
<sakrecoer> flocculant: yes, and like i wrote on the list, i'm not sure i will have that time unfortunately
<sakrecoer> and ross said he hasn't
<flocculant> yea I gathered - not actually anything to do with me, I just thought I'd ask on the list as no-one else had yet :)
<sakrecoer> ok :) thanks.. i will probably be able to, but since i can't garantee it, i feel ackward to commit to it...
<sakrecoer> monday i'm supposed to get confirmation for a job that would start on tuesday..
<sakrecoer> flocculant ^
<flocculant> nice :)
<sergiusens> slangasek or pitti just in case you monitor during the weekend, I don't quite follow the queue status; snapcraft here http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html says "Tests in progress" but it doesn't seem to be true
<roasted> hi friends. I see NM 1.2.2 is listed in the upload queue. Is there any idea when that may land?
<jbicha> Mirv: the only thing left for the evolution 3.22 transition is qtorganizer5-eds's inability to build on s390x (becasue of url-dispatcher)
<jbicha> Laney: hi, evo transition is done but for ^
<Laney> jbicha: nice one, try to get someone to remove the old binaries I guess
<jbicha> oh I see you're not in ~ubuntu-archive yet
 * Laney weeps in the corner
<apw> sergiusens, your tests appear to have run and imploded: "badpkg: rules extract failed with exit code 1
<Mirv> jbicha: right, I guess we'll reach someone latest on Monday morning (as pit_ti is back)
<jbicha> Mirv: do you know exactly what packages need to be removed? because there are AAs that do some things on weekends
<Mirv> jbicha: it's always complicated. the basic problem is upstart not available on s390x, and the problems spread from there on out. the easy answer is just the qtorganizer5-eds's binaries need to be removed, so that it's not stuck on proposed on the principle "it used to have s390x binaries": https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-055/+build/10498649
<Mirv> jbicha: the problem is sometimes the problems can back, since obviously it'd be best if one could continue building the binaries, upstart would build etc instead of this hunting
<Mirv> but the immediate problem should be fixed by removing the organizer's s390x binaries
<jbicha> or alternatively, just kick upstart out! ;) (which I think is happening too)
<slangasek> sergiusens: http://autopkgtest.ubuntu.com/packages/s/snapcraft/xenial/amd64/ actually shows the test failed, but because it was captured with the wrong version, it wasn't recorded :/  running manually now
<slangasek> jbicha: kicking upstart out of the archive doesn't help those pieces of the phone stack that depend on it
<Ukikie> People care about the phone? :o
<sergiusens> slangasek thanks, the log there doesn't make sense to me, we have no packaging changes for it to fail at that level (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/s/snapcraft/20160820_000616@/log.gz)
<slangasek> sergiusens: the re-run succeeded, so the earlier failure is ignorable
<roasted> When is the next sru landing? Crossing fingers for a nm bump...
#ubuntu-release 2016-08-21
<flocculant> pitti: had some fun over weekend with desktop failing on xubuntu and mate, changing exec line for xubuntu.desktop fixes it temporarily here (thanks Ukikie ;)) bug 1615341
<ubot5> bug 1615341 in systemd (Ubuntu) "Yakkety desktop fails to start" [Undecided,New] https://launchpad.net/bugs/1615341
<Rosco2> Can someone with the right foo please trigger a rebuild of Ubuntu Studio live CD?
<Rosco2> I can see other flavours have a successful build today
<Rosco2> I tried from the iso tracker - but no workie
<flocculant> Rosco2: I did - but looking at buildlog it looks like it's got issues with gnupg1 and kactivitymanagerd
<flocculant> https://launchpadlibrarian.net/280052495/buildlog_ubuntu_yakkety_amd64_ubuntustudio_BUILDING.txt.gz
<Rosco2> flocculant, Thankx. It has had that problem for a few days. I was hoping it sorted itself out. Will have to dig deeper
<Rosco2> Atctually https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/yakkety/ubuntustudio does not show a rebuild in the last 17 hours
<flocculant> Rosco2: right - I'd guess it needs more than just asking to rebuild if it's not showing recent attempts
<flocculant> not sure why it built ok on the 19th and also failed to build on the 19th though :)
<flocculant> thanks Laney :)
<Laney> what? what did I do?
<Laney> </fat tony>
<flocculant> :)
<flocculant> Laney: grabbed from -proposed, restored original xubuntu.desktop, booted properly here - thanks again fat tony :p
#ubuntu-release 2017-08-14
<slangasek> xnox: looks like ubuntu-settings-components and revdeps are now the blockers for qtbase-opensource-src; was that a part of the stack you looked at for removal?
-queuebot:#ubuntu-release- Unapproved: lxcfs (trusty-backports/universe) [2.0.6-0ubuntu1~14.04.1 => 2.0.7-0ubuntu1~14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: lxd (trusty-backports/universe) [2.0.9-0ubuntu1~14.04.1 => 2.0.10-0ubuntu1~14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cgroup-lite [source] (trusty-backports) [1.11~ubuntu14.04.3]
-queuebot:#ubuntu-release- Unapproved: lxc (trusty-backports/main) [2.0.7-0ubuntu1~14.04.1 => 2.0.8-0ubuntu1~14.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (trusty-backports) [2.0.8-0ubuntu1~14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (trusty-backports) [2.0.10-0ubuntu1~14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted lxcfs [source] (trusty-backports) [2.0.7-0ubuntu1~14.04.1]
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.26.10~14.04 => 2.27.1~14.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapd (zesty-proposed/main) [2.26.10+17.04 => 2.27.1+17.04] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.26.10 => 2.27.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted libxmlezout [amd64] (artful-proposed) [1.06.1-10]
-queuebot:#ubuntu-release- New: accepted libxmlezout [armhf] (artful-proposed) [1.06.1-10]
-queuebot:#ubuntu-release- New: accepted libxmlezout [ppc64el] (artful-proposed) [1.06.1-10]
-queuebot:#ubuntu-release- New: accepted opentoken [amd64] (artful-proposed) [6.0b-7]
-queuebot:#ubuntu-release- New: accepted opentoken [armhf] (artful-proposed) [6.0b-7]
-queuebot:#ubuntu-release- New: accepted opentoken [ppc64el] (artful-proposed) [6.0b-7]
-queuebot:#ubuntu-release- New: accepted libxmlezout [arm64] (artful-proposed) [1.06.1-10]
-queuebot:#ubuntu-release- New: accepted libxmlezout [s390x] (artful-proposed) [1.06.1-10]
-queuebot:#ubuntu-release- New: accepted opentoken [i386] (artful-proposed) [6.0b-7]
-queuebot:#ubuntu-release- New: accepted libxmlezout [i386] (artful-proposed) [1.06.1-10]
-queuebot:#ubuntu-release- New: accepted opentoken [s390x] (artful-proposed) [6.0b-7]
-queuebot:#ubuntu-release- New: accepted opentoken [arm64] (artful-proposed) [6.0b-7]
-queuebot:#ubuntu-release- New: accepted libtexttools [amd64] (artful-proposed) [2.1.0-10]
-queuebot:#ubuntu-release- New: accepted libtexttools [armhf] (artful-proposed) [2.1.0-10]
-queuebot:#ubuntu-release- New: accepted libtexttools [ppc64el] (artful-proposed) [2.1.0-10]
-queuebot:#ubuntu-release- New: accepted libtexttools [arm64] (artful-proposed) [2.1.0-10]
-queuebot:#ubuntu-release- New: accepted libtexttools [s390x] (artful-proposed) [2.1.0-10]
-queuebot:#ubuntu-release- New: accepted libtexttools [i386] (artful-proposed) [2.1.0-10]
-queuebot:#ubuntu-release- New: accepted libflorist [amd64] (artful-proposed) [2017-3]
-queuebot:#ubuntu-release- New: accepted libflorist [armhf] (artful-proposed) [2017-3]
-queuebot:#ubuntu-release- New: accepted libflorist [ppc64el] (artful-proposed) [2017-3]
-queuebot:#ubuntu-release- New: accepted libflorist [arm64] (artful-proposed) [2017-3]
-queuebot:#ubuntu-release- New: accepted libflorist [s390x] (artful-proposed) [2017-3]
-queuebot:#ubuntu-release- New: accepted libflorist [i386] (artful-proposed) [2017-3]
-queuebot:#ubuntu-release- New: accepted libaunit [amd64] (artful-proposed) [17.2017-2]
-queuebot:#ubuntu-release- New: accepted libaunit [armhf] (artful-proposed) [17.2017-2]
-queuebot:#ubuntu-release- New: accepted libaunit [ppc64el] (artful-proposed) [17.2017-2]
-queuebot:#ubuntu-release- New: accepted libncursesada [amd64] (artful-proposed) [6.0.20170708-2]
-queuebot:#ubuntu-release- New: accepted libncursesada [armhf] (artful-proposed) [6.0.20170708-2]
-queuebot:#ubuntu-release- New: accepted libncursesada [ppc64el] (artful-proposed) [6.0.20170708-2]
-queuebot:#ubuntu-release- New: accepted libaunit [arm64] (artful-proposed) [17.2017-2]
-queuebot:#ubuntu-release- New: accepted libaunit [s390x] (artful-proposed) [17.2017-2]
-queuebot:#ubuntu-release- New: accepted libncursesada [i386] (artful-proposed) [6.0.20170708-2]
-queuebot:#ubuntu-release- New: accepted libaunit [i386] (artful-proposed) [17.2017-2]
-queuebot:#ubuntu-release- New: accepted libncursesada [s390x] (artful-proposed) [6.0.20170708-2]
-queuebot:#ubuntu-release- New: accepted libncursesada [arm64] (artful-proposed) [6.0.20170708-2]
-queuebot:#ubuntu-release- New: accepted libgmpada [amd64] (artful-proposed) [1.1-2]
-queuebot:#ubuntu-release- New: accepted libgmpada [armhf] (artful-proposed) [1.1-2]
-queuebot:#ubuntu-release- New: accepted libgmpada [ppc64el] (artful-proposed) [1.1-2]
-queuebot:#ubuntu-release- New: accepted libgmpada [arm64] (artful-proposed) [1.1-2]
-queuebot:#ubuntu-release- New: accepted libgmpada [s390x] (artful-proposed) [1.1-2]
-queuebot:#ubuntu-release- New: accepted libgmpada [i386] (artful-proposed) [1.1-2]
-queuebot:#ubuntu-release- New: accepted libtemplates-parser [amd64] (artful-proposed) [17.2-2]
-queuebot:#ubuntu-release- New: accepted libtemplates-parser [armhf] (artful-proposed) [17.2-2]
-queuebot:#ubuntu-release- New: accepted libtemplates-parser [ppc64el] (artful-proposed) [17.2-2]
-queuebot:#ubuntu-release- New: accepted sparse [amd64] (artful-proposed) [0.5.0-4]
-queuebot:#ubuntu-release- New: accepted sparse [armhf] (artful-proposed) [0.5.0-4]
-queuebot:#ubuntu-release- New: accepted sparse [ppc64el] (artful-proposed) [0.5.0-4]
-queuebot:#ubuntu-release- New: accepted libtemplates-parser [arm64] (artful-proposed) [17.2-2]
-queuebot:#ubuntu-release- New: accepted libtemplates-parser [s390x] (artful-proposed) [17.2-2]
-queuebot:#ubuntu-release- New: accepted sparse [i386] (artful-proposed) [0.5.0-4]
-queuebot:#ubuntu-release- New: accepted libtemplates-parser [i386] (artful-proposed) [17.2-2]
-queuebot:#ubuntu-release- New: accepted sparse [s390x] (artful-proposed) [0.5.0-4]
-queuebot:#ubuntu-release- New: accepted sparse [arm64] (artful-proposed) [0.5.0-4]
-queuebot:#ubuntu-release- New sync: gmime2.6 (artful-proposed/primary) [2.6.23+dfsg1-1]
<LocutusOfBorg> hello, can anybody please do some little removals of "cruft" (old libraries) for the new gnat-7 packages?
<LocutusOfBorg> opentoken libxmlezout libtexttools libflorist libtemplates-parser libaunit libgmpada libncursesada
<LocutusOfBorg> apw, good morning, gmime2.6 has cleared the new queue in debian two days ago, but didn't get autosync'd because it was part of Ubuntu precise, can you please clear it? this should end the gmime transition
<apw> LocutusOfBorg, as in it was in precise and removed there ?
<apw> LocutusOfBorg, then all it should require is a manual sync, which i assume you can do, to start it syncing again
<LocutusOfBorg>  	2012-03-18 19:10:13 CET 	Deleted 	Precise 	release 	universe 	libs 	2.6.4-0ubuntu2
<LocutusOfBorg>   	2012-01-19 16:35:18 CET 	Superseded 	Precise 	release 	universe 	libs 	2.6.4-0ubuntu1
<LocutusOfBorg> it has been part of precise for two months
<LocutusOfBorg> I already syncd
<apw> ahh ok
<LocutusOfBorg> my plan is: since gmime now points to 3.0, and is already in main, I plan to rebuild every reverse-deps that is in main against the gmime one
<LocutusOfBorg> and keep this one in universe, for the old stuff (in a similar way debian did)
<LocutusOfBorg> hopefully this is already done :p
<LocutusOfBorg> (probably debian will do a transition to kill this 2.6 source, and move everything to 3.0, but they don't know if they will do that in time for buster)
-queuebot:#ubuntu-release- New: accepted gmime2.6 [sync] (artful-proposed) [2.6.23+dfsg1-1]
<apw> LocutusOfBorg, opentoken et al, why do they count as cruft
<apw> or are we talking nbs in proposed
<LocutusOfBorg> that one! yes
<LocutusOfBorg> the binaries have been renamed
<LocutusOfBorg> does anybody with a ppc64el machine understand why britney complains here?
<LocutusOfBorg> trying: gmime2.6
<LocutusOfBorg> skipped: gmime2.6 (0, 34, 11)
<LocutusOfBorg>     got: 55+0: a-9:a-9:a-9:i-9:p-10:s-9
<LocutusOfBorg>     * ppc64el: gmime-bin
<xnox> LocutusOfBorg, you don't need ppc64el machine to check installability. You can use chdist, and setup apt sources to have ppc64el arch from ports.ubuntu.com
<xnox> LocutusOfBorg, also i think it compains about removing gmime2.6 because gmime got upgraded to 3.0.1-3
<xnox> possibly the two need to be hinted together
<xnox> src:gmime src:gmime2.6
<LocutusOfBorg> makes sense thanks
<LocutusOfBorg> I'll try too setup a ppc64el sort of that thing
<LocutusOfBorg> so, somebody has to hint it? apw maybe? <3
<xnox> i did not check if britney already tried the two together
<LocutusOfBorg> no
<xnox> and if the gmime 3.0 transition is ready to go in.
<LocutusOfBorg> considering that the old source is still around I would say yes
<LocutusOfBorg> it is
<xnox> right, indeed.
<LocutusOfBorg> (everything that is in main has the new gmime dependency)
<LocutusOfBorg> and the old 2.6 should satisfy the others
<LocutusOfBorg> (grilo-plugins and notmuch uses gmime-3 now)
<acheronuk> apw: this is triggering tests for ppc64el and s390x, despite the fact that there are no binaries for those archs, and they are not buildable
<acheronuk> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#libkf5incidenceeditor
<apw> acheronuk, have there been so in the past?  britney can be a little dumb
<acheronuk> had this issue on something else, and I seem to recall a fix was pushed or proposed. but seems not to be working there
<apw> that rings a bell indeed, we might have removed the historical results or something
<acheronuk> can they be ignored? or otherwise fixed if not?
<apw> thinking about it now
<acheronuk> ok. thanks
<LocutusOfBorg> slangasek, FWI I syncd libgtkada
<LocutusOfBorg> the tar now is new, and the --exclude keyword seems better
-queuebot:#ubuntu-release- New binary: libgtkada [ppc64el] (artful-proposed/universe) [17.0.2017-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libgtkada [s390x] (artful-proposed/universe) [17.0.2017-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libgtkada [amd64] (artful-proposed/universe) [17.0.2017-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libgtkada [i386] (artful-proposed/universe) [17.0.2017-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libgtkada [arm64] (artful-proposed/universe) [17.0.2017-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libgtkada [armhf] (artful-proposed/universe) [17.0.2017-2] (no packageset)
<LocutusOfBorg> apw, ^^ please, this should unblock 1/3 of gnat-7 packages
-queuebot:#ubuntu-release- New: accepted libgtkada [amd64] (artful-proposed) [17.0.2017-2]
-queuebot:#ubuntu-release- New: accepted libgtkada [armhf] (artful-proposed) [17.0.2017-2]
-queuebot:#ubuntu-release- New: accepted libgtkada [ppc64el] (artful-proposed) [17.0.2017-2]
-queuebot:#ubuntu-release- New: accepted libgtkada [arm64] (artful-proposed) [17.0.2017-2]
-queuebot:#ubuntu-release- New: accepted libgtkada [s390x] (artful-proposed) [17.0.2017-2]
-queuebot:#ubuntu-release- New: accepted libgtkada [i386] (artful-proposed) [17.0.2017-2]
<LocutusOfBorg> ta
<acheronuk> apw: similar for libkf5calendarsupport/4:16.12.3-0ubuntu1 and libkf5eventviews/4:16.12.3-0ubuntu1 failing tests against abi-compliance checker for s390x
<acheronuk> those should never be running
<xnox> removal / disaapearance of adt test is considered to be a regression.
-queuebot:#ubuntu-release- New binary: libgnatcoll [ppc64el] (artful-proposed/universe) [17.0.2017-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libgnatcoll [s390x] (artful-proposed/universe) [17.0.2017-2ubuntu1] (no packageset)
<apw> xnox, in this case though we are running the tests when the package is in dep-wait, even if we wanted to test them we cannot test them yet
<xnox> ah, well, that is fail.
<apw> xnox, i would expect us to not run the test, and britney either be able to migrate it (or not) if it can
-queuebot:#ubuntu-release- New binary: libgnatcoll [amd64] (artful-proposed/universe) [17.0.2017-2ubuntu1] (no packageset)
<acheronuk> yes, we did sort this all with the original uploads, as those packages and their deps are not buildable on those architectures any more. just something has caused the tests to want to run again when they should not
-queuebot:#ubuntu-release- New binary: libgnatcoll [i386] (artful-proposed/universe) [17.0.2017-2ubuntu1] (no packageset)
<acheronuk> this was meant to fix that? https://code.launchpad.net/~cjwatson/britney/+git/britney2-ubuntu/+merge/327610
<LocutusOfBorg> so, can we get a britney hint "please try gmime and gmime2.6 together"? I don't know who can do that...
<LocutusOfBorg> Laney, ^^ :)
<apw> from the comments i suspect that means there is an arch all package which is triggering testing
<acheronuk> if you say so. I've not delved too deep
<apw> hmm but there is not in your initial example
 * acheronuk is confused by britney at the best of times
<acheronuk> it's code, doubly so!
-queuebot:#ubuntu-release- New binary: libgnatcoll [arm64] (artful-proposed/universe) [17.0.2017-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: libgnatcoll [armhf] (artful-proposed/universe) [17.0.2017-2ubuntu1] (no packageset)
<LocutusOfBorg> libgnatcoll is finished ^^ this unblocks src:asis
<LocutusOfBorg> and asis unblocks libaws, that unblocks liblog4ada
-queuebot:#ubuntu-release- Unapproved: sssd (xenial-proposed/main) [1.13.4-1ubuntu1.6 => 1.13.4-1ubuntu1.7] (kubuntu, ubuntu-desktop, ubuntu-server)
<Laney> LocutusOfBorg: away until weds, best try someone else
-queuebot:#ubuntu-release- New source: plymouth-kcm (artful-proposed/primary) [5.10.4-0ubuntu1]
-queuebot:#ubuntu-release- New source: xdg-desktop-portal-kde (artful-proposed/primary) [5.10.4-0ubuntu1]
<shadeslayer> clivejo: ^^
<acheronuk> shadeslayer: ooooh! ty. pinging clive on telegram
<shadeslayer> acheronuk: yeah he ack'd
-queuebot:#ubuntu-release- New source: tracker-miners (artful-proposed/primary) [1.99.2-0ubuntu1]
<tkamppeter> Looking at http://people.canonical.com/~ubuntu-archive/proposed-migration/artful/update_excuses.html it seems that qtbase-opensource-src is blocking most -proposed -> -release migration, especially cups-filters is blocked via Poppler.
<jbicha> tkamppeter: poppler has a few issues of its own: utopia-documents should probably be removed LP: #1710317
<ubot5> Launchpad bug 1710317 in utopia-documents (Ubuntu) "utopia-documents FTBFS in artful" [High,New] https://launchpad.net/bugs/1710317
<jbicha> and poppler is held up by the gdcm transition https://people.canonical.com/~ubuntu-archive/transitions/html/gdcm.html
<tkamppeter> jbicha, thanks. So it will still need some days until the way for cups-filters is clear.
<jbicha> the failing autopkgtests for qtbase are UOA stuff that should maybe be ignored for now if AAs aren't ready to finish working through removing the pieces of that stack
-queuebot:#ubuntu-release- New binary: tracker [amd64] (artful-proposed/main) [1.99.2-0ubuntu1] (desktop-extra, ubuntugnome)
-queuebot:#ubuntu-release- New binary: tracker [ppc64el] (artful-proposed/main) [1.99.2-0ubuntu1] (desktop-extra, ubuntugnome)
-queuebot:#ubuntu-release- New binary: tracker [i386] (artful-proposed/main) [1.99.2-0ubuntu1] (desktop-extra, ubuntugnome)
-queuebot:#ubuntu-release- New binary: tracker [s390x] (artful-proposed/main) [1.99.2-0ubuntu1] (desktop-extra, ubuntugnome)
<tkamppeter> Poppler does not show in https://people.canonical.com/~ubuntu-archive/transitions/html/gdcm.html
<tkamppeter> jbicha, ^^
<jbicha> yes, but gdcm shows up in https://people.canonical.com/~ubuntu-archive/transitions/html/poppler.html
-queuebot:#ubuntu-release- New binary: tracker [arm64] (artful-proposed/main) [1.99.2-0ubuntu1] (desktop-extra, ubuntugnome)
<tkamppeter> jbicha, UOA?? AA??
-queuebot:#ubuntu-release- New binary: tracker [armhf] (artful-proposed/main) [1.99.2-0ubuntu1] (desktop-extra, ubuntugnome)
<jbicha> UOA is Ubuntu Online Accounts, AAs are the Ubuntu Archive Admins who can accept new packages or remove packages we don't want any more LP: #1695928
<ubot5> Launchpad bug 1695928 in gnome-control-center-signon (Ubuntu) "Please remove obsolete UOA packages" [Undecided,New] https://launchpad.net/bugs/1695928
-queuebot:#ubuntu-release- New binary: libbytesize [i386] (artful-proposed/universe) [0.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbytesize [ppc64el] (artful-proposed/universe) [0.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbytesize [amd64] (artful-proposed/universe) [0.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbytesize [s390x] (artful-proposed/universe) [0.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbytesize [arm64] (artful-proposed/universe) [0.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbytesize [armhf] (artful-proposed/universe) [0.10-1] (no packageset)
#ubuntu-release 2017-08-15
-queuebot:#ubuntu-release- New binary: hddemux [amd64] (artful-proposed/universe) [0.3-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: hddemux [ppc64el] (artful-proposed/universe) [0.3-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: hddemux [i386] (artful-proposed/universe) [0.3-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: hddemux [arm64] (artful-proposed/universe) [0.3-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: hddemux [s390x] (artful-proposed/universe) [0.3-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: hddemux [armhf] (artful-proposed/universe) [0.3-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-mattn-go-runewidth [amd64] (artful-proposed/universe) [0.0.2+git20170510.3.97311d9-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-mattn-go-runewidth [ppc64el] (artful-proposed/universe) [0.0.2+git20170510.3.97311d9-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-mattn-go-runewidth [i386] (artful-proposed/universe) [0.0.2+git20170510.3.97311d9-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-mattn-go-runewidth [s390x] (artful-proposed/universe) [0.0.2+git20170510.3.97311d9-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-mattn-go-runewidth [arm64] (artful-proposed/universe) [0.0.2+git20170510.3.97311d9-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-mattn-go-runewidth [armhf] (artful-proposed/universe) [0.0.2+git20170510.3.97311d9-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (zesty-proposed) [2.27.1+17.04]
<apw> ^ rejecting per the uploader, a .2 is expected
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (trusty-proposed) [2.27.1~14.04]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.27.1]
-queuebot:#ubuntu-release- New binary: wget2 [ppc64el] (artful-proposed/none) [0.0.20170806-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wget2 [s390x] (artful-proposed/none) [0.0.20170806-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vim-airline-themes [amd64] (artful-proposed/none) [0+git.20170710.5d75d76-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vim-airline [amd64] (artful-proposed/none) [0.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pycryptodome [ppc64el] (artful-proposed/none) [3.4.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pycryptodome [s390x] (artful-proposed/none) [3.4.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: shimdandy [amd64] (artful-proposed/none) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wget2 [amd64] (artful-proposed/none) [0.0.20170806-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wget2 [i386] (artful-proposed/none) [0.0.20170806-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pycryptodome [amd64] (artful-proposed/none) [3.4.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wget2 [armhf] (artful-proposed/none) [0.0.20170806-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wget2 [arm64] (artful-proposed/none) [0.0.20170806-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pycryptodome [arm64] (artful-proposed/universe) [3.4.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pycryptodome [i386] (artful-proposed/universe) [3.4.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pycryptodome [armhf] (artful-proposed/universe) [3.4.6-1] (no packageset)
<coreycb> hello, can an archive admin please promote python3-oslo.service, python3-oslo.service, and python3-oslo.messaging to main?  the py2 binaries for these packages are already in main.
<infinity> coreycb: component-mismatches sees no reason to promote them.  If they're to be in main, they should be seeded or depended on (I'm assuming the latter is the intent).
<jbicha> infinity: could you look into tracker/tracker-miners in artful/new (tracker-miners is just split from tracker so no new binaries there, the new src:tracker binaries are already in Debian exp.)?
<infinity> jbicha: tracker-miners isn't in Debian?
<coreycb> infinity: right, sorry :)
<jbicha> infinity: not yet, it just got split from tracker a week ago
-queuebot:#ubuntu-release- New: accepted tracker [amd64] (artful-proposed) [1.99.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted tracker [armhf] (artful-proposed) [1.99.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted tracker [ppc64el] (artful-proposed) [1.99.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted tracker [arm64] (artful-proposed) [1.99.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted tracker [s390x] (artful-proposed) [1.99.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted tracker [i386] (artful-proposed) [1.99.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted tracker-miners [source] (artful-proposed) [1.99.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted pycryptodome [arm64] (artful-proposed) [3.4.6-1]
-queuebot:#ubuntu-release- New: accepted pycryptodome [i386] (artful-proposed) [3.4.6-1]
-queuebot:#ubuntu-release- New: accepted pycryptodome [armhf] (artful-proposed) [3.4.6-1]
-queuebot:#ubuntu-release- New: accepted libbytesize [amd64] (artful-proposed) [0.10-1]
-queuebot:#ubuntu-release- New: accepted libbytesize [armhf] (artful-proposed) [0.10-1]
-queuebot:#ubuntu-release- New: accepted libbytesize [ppc64el] (artful-proposed) [0.10-1]
-queuebot:#ubuntu-release- New: accepted pycryptodome [amd64] (artful-proposed) [3.4.6-1]
-queuebot:#ubuntu-release- New: accepted pycryptodome [s390x] (artful-proposed) [3.4.6-1]
-queuebot:#ubuntu-release- New: accepted vim-airline-themes [amd64] (artful-proposed) [0+git.20170710.5d75d76-1]
-queuebot:#ubuntu-release- New: accepted wget2 [amd64] (artful-proposed) [0.0.20170806-1]
-queuebot:#ubuntu-release- New: accepted wget2 [armhf] (artful-proposed) [0.0.20170806-1]
-queuebot:#ubuntu-release- New: accepted wget2 [ppc64el] (artful-proposed) [0.0.20170806-1]
-queuebot:#ubuntu-release- New: accepted libbytesize [arm64] (artful-proposed) [0.10-1]
-queuebot:#ubuntu-release- New: accepted libbytesize [s390x] (artful-proposed) [0.10-1]
-queuebot:#ubuntu-release- New: accepted shimdandy [amd64] (artful-proposed) [1.2.0-1]
-queuebot:#ubuntu-release- New: accepted wget2 [arm64] (artful-proposed) [0.0.20170806-1]
-queuebot:#ubuntu-release- New: accepted wget2 [s390x] (artful-proposed) [0.0.20170806-1]
-queuebot:#ubuntu-release- New: accepted libbytesize [i386] (artful-proposed) [0.10-1]
-queuebot:#ubuntu-release- New: accepted vim-airline [amd64] (artful-proposed) [0.8-1]
-queuebot:#ubuntu-release- New: accepted pycryptodome [ppc64el] (artful-proposed) [3.4.6-1]
-queuebot:#ubuntu-release- New: accepted wget2 [i386] (artful-proposed) [0.0.20170806-1]
<jbicha> thank you :)
<chrisccoulson> hi, can we stop rustc and cargo from being auto-synced from debian please?
<chrisccoulson> this got auto-synced before there was a working 1.17 binary with which to build it on armhf - https://launchpad.net/ubuntu/+source/rustc/1.18.0+dfsg1-4
<chrisccoulson> and now we're in a bit of a mess
<chrisccoulson> errr
<chrisccoulson> actually, that's not entirely true. The last 1.17 build failed (https://launchpad.net/ubuntu/+archive/primary/+sourcepub/8083193/+listing-archive-extra), but there was a successful build before that (https://launchpad.net/ubuntu/+archive/primary/+sourcepub/7936948/+listing-archive-extra) which is still published in artful-proposed
<chrisccoulson> still, I'd like to not auto-sync this because it's too easy to get in a situation where it becomes unbuildable in the archive
<chrisccoulson> (if debian updates rust to 1.19 and it's sync'd to ubuntu now before we have 1.18 working on arm, then we will be in a bit of a mess)
<jbicha> chrisccoulson: the easiest way to block autosyncs is to upload a no-change -ubuntu1 revision :)
<jbicha> or you could use the sync blacklist but that prevents syncpackage from working for that package either
<chrisccoulson> jbicha, yes, but that's not really a long term fix. We have that before, then it got manually sync'd
<infinity> I don't think blacklisting it is sane.
<infinity> We can rebootstrap it if we have to.  Ideally, of course, it should be in shape so that's not required.
<popey> Is Ubuntu (proper) going to participate in beta 1 in a couple of weeks?
<popey> Given we're making significant changes this cycle, seems like it might be prudent for wider testing?
<infinity> popey: There hadn't been plans to do so.
<infinity> popey: But you might ask Will if the desktop team would like to break tradition this cycle, if you feel there's a solid argument.
<infinity> popey: Honestly, I don't think it's the installer and ISOs that need deep testing here, it's upgrade paths.
<infinity> popey: And betas are more about the former.
<jbicha> popey: it's a good idea, are you interested in doing the work to sign off on the iso's that week?
<popey> (sorry, just in a meeting, will come back to this in a moment)
<popey> infinity: ok, I'll ping Will about it.
<popey> jbicha: if I know how much work it is, maybe  ;)
<Laney> We had already thought about doing early milestones, and decided against it.
<Laney> The idea is/was to do QA independently of them.
 * Laney is off, just wanted to say that.
<popey> Ok, thanks
-queuebot:#ubuntu-release- New: accepted hddemux [amd64] (artful-proposed) [0.3-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted hddemux [armhf] (artful-proposed) [0.3-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted hddemux [ppc64el] (artful-proposed) [0.3-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted libgnatcoll [amd64] (artful-proposed) [17.0.2017-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted libgnatcoll [armhf] (artful-proposed) [17.0.2017-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted libgnatcoll [ppc64el] (artful-proposed) [17.0.2017-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted hddemux [arm64] (artful-proposed) [0.3-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted hddemux [s390x] (artful-proposed) [0.3-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted libgnatcoll [i386] (artful-proposed) [17.0.2017-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted hddemux [i386] (artful-proposed) [0.3-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted libgnatcoll [s390x] (artful-proposed) [17.0.2017-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted libgnatcoll [arm64] (artful-proposed) [17.0.2017-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-github-mattn-go-runewidth [amd64] (artful-proposed) [0.0.2+git20170510.3.97311d9-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-github-mattn-go-runewidth [armhf] (artful-proposed) [0.0.2+git20170510.3.97311d9-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-github-mattn-go-runewidth [ppc64el] (artful-proposed) [0.0.2+git20170510.3.97311d9-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-github-mattn-go-runewidth [arm64] (artful-proposed) [0.0.2+git20170510.3.97311d9-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-github-mattn-go-runewidth [s390x] (artful-proposed) [0.0.2+git20170510.3.97311d9-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-github-mattn-go-runewidth [i386] (artful-proposed) [0.0.2+git20170510.3.97311d9-1ubuntu1]
-queuebot:#ubuntu-release- New binary: asis [s390x] (artful-proposed/universe) [2017-1] (no packageset)
-queuebot:#ubuntu-release- New binary: asis [amd64] (artful-proposed/universe) [2017-1] (no packageset)
-queuebot:#ubuntu-release- New binary: asis [i386] (artful-proposed/universe) [2017-1] (no packageset)
-queuebot:#ubuntu-release- New binary: asis [ppc64el] (artful-proposed/universe) [2017-1] (no packageset)
-queuebot:#ubuntu-release- New binary: asis [arm64] (artful-proposed/universe) [2017-1] (no packageset)
-queuebot:#ubuntu-release- New binary: asis [armhf] (artful-proposed/universe) [2017-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted asis [arm64] (artful-proposed) [2017-1]
-queuebot:#ubuntu-release- New: accepted asis [ppc64el] (artful-proposed) [2017-1]
-queuebot:#ubuntu-release- New: accepted asis [armhf] (artful-proposed) [2017-1]
-queuebot:#ubuntu-release- New: accepted asis [amd64] (artful-proposed) [2017-1]
-queuebot:#ubuntu-release- New: accepted asis [s390x] (artful-proposed) [2017-1]
-queuebot:#ubuntu-release- New: accepted asis [i386] (artful-proposed) [2017-1]
<xnox> apw, slangasek, doko: if you have powers, could you please demote _binaries only_ of things that are up for demotions w.r.t. qt4:
<xnox> libavahi-qt4-1 libavahi-qt4-dev	avahi
<xnox> libpoppler-qt4-4 libpoppler-qt4-dev	poppler
<xnox> after that, the only remaining piece would be to somehow resolve fcitx-frontend-qt4 libfcitx-qt0 on-demand-installation / demotion.
<teward> can a release manager / developer please take a quick peek at https://bugs.launchpad.net/ubuntu/+source/pcl/+bug/1704459 please?  (from #ubuntu-bugs)
<ubot5> Launchpad bug 1704459 in pcl (Ubuntu) "rebuild needed because dependency changed location of exported libmpi.so library " [Undecided,Confirmed]
<teward> looks like it'll need looked at, and if you can give guidance to the guy in #ubuntu-bugs that'd be great
<nacc> teward: there's a src:pcl in a-p
<nacc> teward: so i assume it's actually fix committed for artful?
<teward> nacc: not sure, check #u-bugs
<teward> and relay that there :P
<bladernr> hey, who manages the download locations for the current and old ISOs?  IOW, who decides and manages what goes to release.u.c, cdimages.u.c and old-releases.u.c?
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-93.116] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (zesty-proposed/main) [4.10.0-33.37] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (zesty-proposed) [4.10.0-33.37]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-93.116]
<apw> bladernr, that mostly falls to the release team and likely to infinity in the main
<bladernr> apw, thanks!
<slangasek> xnox: yep, demoting a few binaries now
<xnox> bladernr, some of these decisions are IS driven too, w.r.t. mirrors network and what gets masqueraded with CDN.
<xnox> with infinity as a proxy =)
<bladernr> xnox, thanks... infinity is a busy dude :)
<slangasek> bladernr: do you have a request to change something?
<bladernr> slangasek, no. The Cert websites generate urls on the fly for ISO downloads based on the release that was used for testing, so we're trying to improve that process to reduce the number of broken links, and just needed to know who to throw questions at.
<tsimonq2> infinity, mitya57: I really think something similar to this should be done in Ubuntu (maybe next cycle or the one after): https://lists.debian.org/debian-devel-announce/2017/08/msg00006.html - but certainly a first step will be getting the Qt 4 libraries off of the images... Anyways, where should I go to discuss this more with others? (just in here or on a mailing list?)
<xnox> tsimonq2, i've been looking at it. at the moment, everything is gone from main, apart from fcitx-frontend-qt4 which is pulled in, because of providing cjk support out of the box for qt4 apps.
<xnox> tsimonq2, i am not sure what is the state of the art of installing cjk support on-demand, and ideally without shipping the qt4 portion of it by default on cds.
<xnox> tsimonq2, do you recall where the code for cjk langauge support is? if we add fcitx-frontend-qt4 there, we can drop qt4-x11 from main.
<xnox> (qt4-x11 & qt-at-spi)
<tsimonq2> xnox: hm, no but I'm looking :)
<slangasek> bladernr: if you throw the questions at the channel generally, people here can answer (myself or infinity included)
<tsimonq2> xnox: Hmm, not sure, but I've asked in #debian-qt-kde on OFTC to see if they know
<xnox> tsimonq2, they wouldn't... language packs, and language support installer / runtime installation is entirely ubuntu specific.
<xnox> it installs dictionaries, language packs, and input methods specific to a given user chosen locales.
<xnox> maybe bdmurray knows or e.g. setuid
<xnox> unping setuid
<xnox> seb128 i meant, but not in this channel.
<jbicha> xnox: maybe you could do what I'm suggesting in LP: #1585903 and have the qt base library recommend all the addons that used to be included by default like the fcitx support
<ubot5> Launchpad bug 1585903 in Ubuntu GNOME "Make it possible to remove gtk2" [Wishlist,Triaged] https://launchpad.net/bugs/1585903
-queuebot:#ubuntu-release- New binary: libaws [ppc64el] (artful-proposed/universe) [17.2.2017-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libaws [s390x] (artful-proposed/universe) [17.2.2017-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libaws [i386] (artful-proposed/universe) [17.2.2017-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libaws [amd64] (artful-proposed/universe) [17.2.2017-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libaws [arm64] (artful-proposed/universe) [17.2.2017-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libaws [armhf] (artful-proposed/universe) [17.2.2017-1] (no packageset)
<xnox> jbicha, that would introduce circular deps, but it's not like we will have another qt 4.x major release.
<jbicha> but recommends aren't too big of a problem because it's a soft dependency, right?
<tsimonq2> Either way I'm not a fan of introducing an Ubuntu delta, the end goal after we can stop carrying transitional packages is to make qtbase et. al completely syncable.
<jbicha> it looks like the publisher stopped publishing to artful a few hours ago ( see vala-panel-appmenu or meta-gnome3 )
<slangasek> recommends require manual probing for us to decipher for removals (which is a bug in the scripts); and if a package recommends something removed from the archive, that recommended package doesn't get removed on upgrade unless forced out by conflicts
-queuebot:#ubuntu-release- New binary: volume-key [ppc64el] (artful-proposed/universe) [0.3.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: volume-key [s390x] (artful-proposed/universe) [0.3.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: directfb [i386] (artful-proposed/universe) [1.7.7-4] (kubuntu)
-queuebot:#ubuntu-release- New binary: x265 [s390x] (artful-proposed/universe) [2.5-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: directfb [amd64] (artful-proposed/universe) [1.7.7-4] (kubuntu)
-queuebot:#ubuntu-release- New binary: x265 [ppc64el] (artful-proposed/universe) [2.5-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: directfb [ppc64el] (artful-proposed/universe) [1.7.7-4] (kubuntu)
-queuebot:#ubuntu-release- New binary: directfb [s390x] (artful-proposed/universe) [1.7.7-4] (kubuntu)
-queuebot:#ubuntu-release- New binary: volume-key [amd64] (artful-proposed/universe) [0.3.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: x265 [arm64] (artful-proposed/universe) [2.5-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: x265 [i386] (artful-proposed/universe) [2.5-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: volume-key [arm64] (artful-proposed/universe) [0.3.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: x265 [armhf] (artful-proposed/universe) [2.5-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: volume-key [armhf] (artful-proposed/universe) [0.3.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: directfb [arm64] (artful-proposed/universe) [1.7.7-4] (kubuntu)
-queuebot:#ubuntu-release- New binary: directfb [armhf] (artful-proposed/universe) [1.7.7-4] (kubuntu)
-queuebot:#ubuntu-release- New binary: volume-key [i386] (artful-proposed/universe) [0.3.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: x265 [amd64] (artful-proposed/universe) [2.5-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: poco [s390x] (artful-proposed/universe) [1.7.8+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: poco [ppc64el] (artful-proposed/universe) [1.7.8+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: poco [i386] (artful-proposed/universe) [1.7.8+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: poco [amd64] (artful-proposed/universe) [1.7.8+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: poco [arm64] (artful-proposed/universe) [1.7.8+dfsg1-2] (no packageset)
<ahoneybun> anyone know if any of the Ubuntu changes to GNOME can be reverted?
<ahoneybun> other then this vanilla session
<jbicha> ahoneybun: wrong channel?
<ahoneybun> jbicha: not sure
<ahoneybun> not sure where to ask about it
<valorie> ahoneybun: maybe the #ubuntu+1 chan?
<jbicha> ahoneybun: #ubuntu-desktop is where the default Ubuntu desktop is developed, or #ubuntu for support questions
<ahoneybun> jbicha: what sorry IRC died
<hggdh> ahoneybun: #ubuntu-desktop takes care of the default UBuntu desktop, #ubuntu+1 with experience on next Ubuntu
-queuebot:#ubuntu-release- New binary: poco [armhf] (artful-proposed/universe) [1.7.8+dfsg1-2] (no packageset)
#ubuntu-release 2017-08-16
-queuebot:#ubuntu-release- New source: jsonrpc-glib (artful-proposed/primary) [3.25.3-0ubuntu1]
-queuebot:#ubuntu-release- New source: template-glib (artful-proposed/primary) [3.25.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: golang-golang-x-sync [s390x] (artful-proposed/universe) [0.0~git20170317.0.5a06fca-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-golang-x-sync [ppc64el] (artful-proposed/universe) [0.0~git20170317.0.5a06fca-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-golang-x-sync [i386] (artful-proposed/universe) [0.0~git20170317.0.5a06fca-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-golang-x-sync [amd64] (artful-proposed/universe) [0.0~git20170317.0.5a06fca-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-golang-x-sync [armhf] (artful-proposed/universe) [0.0~git20170317.0.5a06fca-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-golang-x-sync [arm64] (artful-proposed/universe) [0.0~git20170317.0.5a06fca-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: debian-multimedia [amd64] (artful-proposed/universe) [0.6ubuntu1] (ubuntustudio)
<tjaalton> is update_excuses.html updates somehow stuck? the timestamp seems old
<acheronuk> might get unstuck soon? http://people.canonical.com/~ubuntu-archive/proposed-migration/log/artful/2017-08-16/
<acheronuk> or at least, seems to have done a recent run now
<tjaalton> ok, cool
<acheronuk> s/done/doing
<apw> tjaalton, yes it was sick over night, it got kicked about 20m ago ... so is grinding now
<tjaalton> great
<apw> it is vomiting tests into the queues as we speak
<tsimonq2> The Qt 5.9.1 transition in Debian Sid started a few hours ago, the autosyncer will pull in 10-15 packages within the next day that could trigger a good amount of autopkgtests...
<apw> oh "good"
<tsimonq2> Well, not qtbase, not unless someone merges from Debian. :P
<tsimonq2> qtbase is the one that triggers the massive amount of tests...
<acheronuk> leave it alone! I nearly got the tests sorted once :P
<tsimonq2> *maybe* once everything migrates from -proposed, but ONLY if it includes useful fixess
<tsimonq2> s/fixess/fixes/
<acheronuk> anyone going to fix the armhf builders so they don't fail installing dbus, and regress with packaname/unknown ?
<acheronuk> sorry. didn't mean that ^^^ to sound moany
<mitya57> tsimonq2, if we are speaking about qt4-x11, it already has a huge delta, so one more recommends won't hurt. So jbicha's suggestion sounds good to me.
<tsimonq2> mitya57: fair
<tsimonq2> mitya57: But I thought we were talking about qtbase-opensource-src
<mitya57> The original question was about dropping qt4-x11 and making sure the CJK support for qt4 is installed when qt4 is in useâ¦
<tsimonq2> Oh ok
<tjaalton> so are failures like https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/amd64/a/akonadi-calendar-tools/20170816_070642_f9d49@/log.gz caused by the ongoing kde uploads?
<tsimonq2> tjaalton: That specifically seems like something is hardcoded for GCC 6...
<tsimonq2> /usr/include/KF5/AkonadiCore/std_exception.h:1:10: fatal error: /usr/include/c++/6/exception: No such file or directory
<tsimonq2>  #include "/usr/include/c++/6/exception"
<tsimonq2>           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<tsimonq2> Soooo idk about that one specifically.
<tjaalton> well there are many of those failing and blocking mesa
<apw> someone really screwed-the-pooch on the c++ header API if you have to use a version in there
<tsimonq2> acheronuk, clivejo: This is something you're aware of, right? ^^^^
<acheronuk> needs tests run against the stuff stuck in -proposed due to Qt etc transition I think, instead of using the akonadi et al. in -release
<acheronuk> I retried similar against those, and they passed
<acheronuk> akonadi is one whole screwed up mess from KDE :(
<tjaalton> agreed :P
<acheronuk> If I could kill it with fire, I would!
 * acheronuk heads to do chores
<tsimonq2> The whole PIM stack is one huge security nightmare and autopkgtest killer!
<tsimonq2> s/PIM/KDE PIM/
-queuebot:#ubuntu-release- New sync: llvm-toolchain-5.0 (artful-proposed/primary) [1:5.0~+rc2-1]
<LocutusOfBorg> hello, I'm really worried, why some stuff isn't autosyncd?
<LocutusOfBorg> e.g. llvm-toolchain-5.0
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-5.0 [sync] (artful-proposed) [1:5.0~+rc2-1]
-queuebot:#ubuntu-release- New: accepted directfb [armhf] (artful-proposed) [1.7.7-4]
-queuebot:#ubuntu-release- New: accepted poco [arm64] (artful-proposed) [1.7.8+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted poco [i386] (artful-proposed) [1.7.8+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted poco [s390x] (artful-proposed) [1.7.8+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted x265 [amd64] (artful-proposed) [2.5-2]
-queuebot:#ubuntu-release- New: accepted poco [amd64] (artful-proposed) [1.7.8+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted poco [ppc64el] (artful-proposed) [1.7.8+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted poco [armhf] (artful-proposed) [1.7.8+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted volume-key [i386] (artful-proposed) [0.3.9-1]
-queuebot:#ubuntu-release- New: accepted directfb [amd64] (artful-proposed) [1.7.7-4]
-queuebot:#ubuntu-release- New: accepted directfb [i386] (artful-proposed) [1.7.7-4]
-queuebot:#ubuntu-release- New: accepted directfb [s390x] (artful-proposed) [1.7.7-4]
-queuebot:#ubuntu-release- New: accepted libaws [arm64] (artful-proposed) [17.2.2017-1]
-queuebot:#ubuntu-release- New: accepted libaws [i386] (artful-proposed) [17.2.2017-1]
-queuebot:#ubuntu-release- New: accepted libaws [s390x] (artful-proposed) [17.2.2017-1]
-queuebot:#ubuntu-release- New: accepted volume-key [arm64] (artful-proposed) [0.3.9-1]
-queuebot:#ubuntu-release- New: accepted volume-key [ppc64el] (artful-proposed) [0.3.9-1]
-queuebot:#ubuntu-release- New: accepted x265 [arm64] (artful-proposed) [2.5-2]
-queuebot:#ubuntu-release- New: accepted x265 [i386] (artful-proposed) [2.5-2]
-queuebot:#ubuntu-release- New: accepted directfb [arm64] (artful-proposed) [1.7.7-4]
-queuebot:#ubuntu-release- New: accepted libaws [amd64] (artful-proposed) [17.2.2017-1]
-queuebot:#ubuntu-release- New: accepted libaws [ppc64el] (artful-proposed) [17.2.2017-1]
-queuebot:#ubuntu-release- New: accepted volume-key [armhf] (artful-proposed) [0.3.9-1]
-queuebot:#ubuntu-release- New: accepted x265 [armhf] (artful-proposed) [2.5-2]
-queuebot:#ubuntu-release- New: accepted x265 [s390x] (artful-proposed) [2.5-2]
-queuebot:#ubuntu-release- New: accepted directfb [ppc64el] (artful-proposed) [1.7.7-4]
-queuebot:#ubuntu-release- New: accepted volume-key [amd64] (artful-proposed) [0.3.9-1]
-queuebot:#ubuntu-release- New: accepted x265 [ppc64el] (artful-proposed) [2.5-2]
-queuebot:#ubuntu-release- New: accepted libaws [armhf] (artful-proposed) [17.2.2017-1]
-queuebot:#ubuntu-release- New: accepted volume-key [s390x] (artful-proposed) [0.3.9-1]
<LocutusOfBorg> apw, do you have any clue for llvm-toolchain-5.0 missed autosync?
<apw> LocutusOfBorg, sorry no, i don't see any history for it in LP so its not that ... i can't say i am very up on the rules autosync applies
<LocutusOfBorg> I'm a little bit worried :)
 * apw adds learning how that works to his long list
<LocutusOfBorg> anyhow, sorted now, I'm worried because I don't know how many packages missed the autosync
<Laney> the latest log is available at http://people.canonical.com/~ubuntu-archive/auto-sync/current.log
<apw>  * Trying to add llvm-toolchain-5.0 ...
<apw> llvm-toolchain-5.0_1:5.0~+rc2-1 is trying to override modified binary clang-5.0_1:5.0~svn305653-1ubuntu1.  OK (y/N)?  n
<LocutusOfBorg> oh
<LocutusOfBorg> thanks!
<LocutusOfBorg> so that old binary was probably in the snapshot package, that won't leave proposed
<LocutusOfBorg> fine to sync, thanks
<LocutusOfBorg> and the proposed one points to llvm 6.0 in new queue
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.10.0-33.37~16.04.1] (kernel)
<Laney> s390x autopkgtesting is off currently for some maintenance
<apw> Laney, off as in queuing i assume ?
<Laney> yeh
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.10.0-33.37~16.04.1]
<Laney> also looking into the big armhf queue
-queuebot:#ubuntu-release- New binary: liblog4ada [ppc64el] (artful-proposed/universe) [1.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (vivid-proposed/main) [3.19.0-92.100] (core, kernel)
-queuebot:#ubuntu-release- New binary: liblog4ada [armhf] (artful-proposed/universe) [1.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-93.116~14.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: liblog4ada [i386] (artful-proposed/universe) [1.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-129.178] (core, kernel)
-queuebot:#ubuntu-release- New binary: liblog4ada [amd64] (artful-proposed/universe) [1.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: liblog4ada [s390x] (artful-proposed/universe) [1.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: liblog4ada [arm64] (artful-proposed/universe) [1.3-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (vivid-proposed) [3.19.0-92.100]
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-93.116~14.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-129.178]
-queuebot:#ubuntu-release- New: accepted liblog4ada [amd64] (artful-proposed) [1.3-2]
-queuebot:#ubuntu-release- New: accepted liblog4ada [armhf] (artful-proposed) [1.3-2]
-queuebot:#ubuntu-release- New: accepted liblog4ada [ppc64el] (artful-proposed) [1.3-2]
-queuebot:#ubuntu-release- New: accepted liblog4ada [arm64] (artful-proposed) [1.3-2]
-queuebot:#ubuntu-release- New: accepted liblog4ada [s390x] (artful-proposed) [1.3-2]
-queuebot:#ubuntu-release- New: accepted liblog4ada [i386] (artful-proposed) [1.3-2]
<Laney> k, armhf should be picking up again
<Laney> ended up with tons of orphaned instances for some reason
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.26.10 => 2.27.2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.26.10~14.04 => 2.27.2~14.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapd (zesty-proposed/main) [2.26.10+17.04 => 2.27.2+17.04] (desktop-core, ubuntu-server)
<slashd> rbasak, good day, if you have some cycle could you please look at releasing "landscape-client" derived binary packages in trusty-updates ? v-t-d has been done with a detailed description including the usual landscape pkging QA testing, it's green in pending sru and has reach the 7 days.
-queuebot:#ubuntu-release- Unapproved: pcl (xenial-proposed/universe) [1.7.2-14build1 => 1.7.2-14ubuntu1.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pcl (zesty-proposed/universe) [1.8.0+dfsg1-4ubuntu4 => 1.8.0+dfsg1-4ubuntu4.17.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (xenial-proposed) [1.157.12]
-queuebot:#ubuntu-release- New source: gnome-shell-extension-ubuntu-dock (artful-proposed/primary) [0.1]
-queuebot:#ubuntu-release- New: accepted gnome-shell-extension-ubuntu-dock [source] (artful-proposed) [0.1]
-queuebot:#ubuntu-release- New binary: gnome-shell-extension-ubuntu-dock [amd64] (artful-proposed/none) [0.1] (no packageset)
<LocutusOfBorg> hello doko I did retry some of the gnat failures against proposed
<LocutusOfBorg> libgnatcoll seems to be a failure, but I don't know how to fix it
<LocutusOfBorg> for others I prefer to wait for results
-queuebot:#ubuntu-release- New: accepted gnome-shell-extension-ubuntu-dock [amd64] (artful-proposed) [0.1]
<LocutusOfBorg> and probably the failure is just uninstallability that is fixed now
 * LocutusOfBorg waits for an hopefully fixed insighttoolkit4 to show up
<LocutusOfBorg> slangasek, ^^
<cpaelzer> polling for an AA to remove sandbox-upgrader and auto-upgrade-testing from artful as described in 1260062
<apw> cpaelzer, hi
<cpaelzer> hi apw
<cpaelzer> power issues today?
<cpaelzer> or about my AA ping?
<apw> cpaelzer, those both appear to be ubuntu only, and maintained by us, and look dead basically ...
<cpaelzer> exactly
<cpaelzer> the bugholds also links to a mailing list thread where I was polling for users
<cpaelzer> but all known ones dropped their usage
<cpaelzer> and "maintained by us"  is a hard exaggeration, it is it more the formal status but not the truth since they were broken so long without notice or fix
<apw> cpaelzer, in thesense "we" aree the arbitors of whether it is, as maintainers
<cpaelzer> yeah, I agree
<apw> cpaelzer, and done
<cpaelzer> thank you
-queuebot:#ubuntu-release- New binary: insighttoolkit4 [s390x] (artful-proposed/universe) [4.12.0-dfsg1-2ubuntu1] (no packageset)
<rbasak> slashd: sorry, out today
<LocutusOfBorg> hello insighttoolki4, welcome back!
-queuebot:#ubuntu-release- New binary: insighttoolkit4 [ppc64el] (artful-proposed/universe) [4.12.0-dfsg1-2ubuntu1] (no packageset)
<slashd> rbasak, no worries thanks
<jbicha> I think the nbs tracker is confused about geany-plugins, the new version of the metapackage does not depend on the removed plugins
<nacc> jbicha: there are two geany-plugins in artful currently?
<nacc> jbicha: (per rmadison)
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (zesty-proposed) [2.27.2+17.04]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.27.2]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.27.2~14.04]
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (zesty-proposed) [1:17.04.6]
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (xenial-proposed) [1:16.04.9]
-queuebot:#ubuntu-release- New binary: insighttoolkit4 [amd64] (artful-proposed/universe) [4.12.0-dfsg1-2ubuntu1] (no packageset)
<slangasek> seb128: it seems someone promoted gmime2.6 source to main without subscribing a team to it.  Is Desktop Team happy to be on the hook for both gmimes?
<slangasek> seb128: sorry, correction, gmime2.6 is only in universe but its /binaries/ were still in main and are now being demoted
<seb128> slangasek, so all good?
<seb128> but yeah otherwise it's fine for us to subscribe to it
<tkamppeter> artful-proposed -> artful transition is still hanging on qtbase-opensource-src failing with Ubuntu Online Accounts tests. Will this get fixed soon?
<tkamppeter> This blocks cups-filters and probably many other packages.
<slangasek> tkamppeter: I have no eta for this being resolved; the packages which regress with new Qt are listed as being owned by the ubuntu-webapps-bugs and unity-ui-team teams, and I'm not sure either of those teams still exists; this probably falls to the Desktop Team to determine what should happen with these packages
<slangasek> xnox, tsimonq2: ^^ have you had any conversations with anyone from the Desktop Team regarding how to unblock qt wrt ubuntu-settings-components and ubuntu-system-settings-online-accounts?
<nacc> some quick digging: qtdeclarative5-gsettings1.0 depends on qtbase-abi-5-7-1 which implies it might need  a rebuild for a new ABI (5-9-1)
 * tsimonq2 defers to mitya57 
<tsimonq2> nacc: 5-9-0 but yeah
<nacc> err, yes, sorry :)
<tsimonq2> Also, we need to look into porting packages off of ubuntu-ui-toolkit
<tsimonq2> We need to remove it one way or another
<nacc> similar abi issues exist for libuntugestures5 and libuntutoolkit5
<tsimonq2> I've tried two times to port it to the new Qt to no avail
<tsimonq2> I think mitya57 has tried too to no success
<tsimonq2> So we can either: a) port packages off of it then remove it; b) remove the whole stack
<tsimonq2> xnox was telling me some people still want some of the rdeps
<tsimonq2> Soooo I guess we have to port things off of it, unless somebody has a working port to the new Qt
<tsimonq2> That's the *real* blocker here.
<slangasek> right, and that porting work should be the responsibility of the folks who want to keep it in the archive
<tsimonq2> Sure
<nacc> why can't src:ubuntu-settings-components be removed?
<nacc> it produces two binary packages, one of which is a dummy and one is a unity8 package
<nacc> or is that the "port off of it" point?
<tsimonq2> nacc: The way I understand it from conversations with mitya57 is that packages that still use ubuntu-ui-toolkit can be ported to use Qt Quick Controls 2
<tsimonq2> But regardless, I'm not really familiar with the packages that people want to keep
<tsimonq2> All I know is that it's just "some of the rdeps"
-queuebot:#ubuntu-release- New binary: insighttoolkit4 [i386] (artful-proposed/universe) [4.12.0-dfsg1-2ubuntu1] (no packageset)
<nacc> tsimonq2: sure, but i mean, at least one part of the blocked stack is removable, afaict? the only rev-dep of src:ubuntu-settings-components is ubuntu-system-settings which seems to be touch-specific (and if src:ubuntu-system-settings was removed that would fall out too)?
<nacc> tsimonq2: altough libertine has a b-d on libsystemsettings-dev
<nacc> geez, how much of this gunk is there because of touch?
<nacc> "sandbox for running deb-packaged X11 apps on Ubuntu Personal"
<nacc> 'Ubuntu "Snappy Personal" system.'
<slangasek> it's all there as part of previous Canonical client stack development.  Not all of it is touch-specific
<tsimonq2> nacc: Lots, it took 1.5 months (I think) for the last Qt transition because it took that long to port all of this...
<tsimonq2> (1 month at least)
<nacc> slangasek: ok, i was just going off the package descriptions :)
<tsimonq2> I'd like to minimize this time to having Qt transitions take a few weeks at best
<slangasek> nacc: "Snappy Personal" != "touch"; but it may be unity8-specific and therefore removable
 * nacc probably isn't helping by poking at that ratking...
<nacc> slangasek: what is "Snappy Personal"?
<nacc> just not familiar with the term
<tsimonq2> nacc: But yeah, I'm not intricately familiar with src:ubuntu-settings-components but that sounds sane. Don't take my word on it though. ;)
<nacc> tsimonq2: :)
<tsimonq2> I'd like to file a removal bug for ubuntu-ui-toolkit with all of the reverse dependencies added on the bug, giving the option to either port off of ubuntu-ui-toolkit or port off of it. Any objections to me filing that bug?
 * tsimonq2 has never filed removal bugs before but it seems fairly straightforward :P
<slangasek> nacc: Snappy Personal was to be a Unity8 client stack (desktop, not primarily phone) packaged as snaps
<nacc> slangasek: ah! thank you
<nacc> tsimonq2: given that, i do think it's reasonable
<tsimonq2> nacc: ok
<tkamppeter> slangasek, thanks. I only want that cups-filters uploads (no relationship at all to Qt) make it quickly into the release so that users test it.
<slangasek> nacc: and fwiw ubuntu-system-settings itself has a revdep tree
<nacc> slangasek: ack, some come from itself, some seem to be |'d with binaries from other pkgs, but yeah, needs a trawl
<slangasek> reverse-depends src:$src excludes self-depends
<slangasek> fwiw
-queuebot:#ubuntu-release- New binary: insighttoolkit4 [armhf] (artful-proposed/universe) [4.12.0-dfsg1-2ubuntu1] (no packageset)
<slangasek> but sadly we still don't have the | info in its output
<nacc> slangasek: oh you're right, sorry, i was glossing ubuntu-system-settings and ubuntu-system-settings-online-accounts into one
<tsimonq2> slangasek, nacc, mitya57, xnox: bug 1711204
<ubot5> bug 1711204 in webbrowser-app (Ubuntu) "Remove ubuntu-ui-toolkit from the archive" [Undecided,New] https://launchpad.net/bugs/1711204
-queuebot:#ubuntu-release- New binary: menhir [amd64] (artful-proposed/universe) [20170712-1] (no packageset)
<acheronuk> slangasek: can the tests for libkf5eventviews/4:16.12.3-0ubuntu1 and libkf5calendarsupport/4:16.12.3-0ubuntu1 on pp64el & s390x be ignored please?
<acheronuk> this is anothjer case of test being run that shouldn't, as there are no binaries now
<acheronuk> part of KDE PIM that is not buildable on those archs now
<acheronuk> I thought that issue had been fixed in britney, but seems still happens in a few cases
<slangasek> acheronuk: I suspect the problem only occurs if for some reason the tests were manually triggered, or were triggered before the britney change; yes, overridden, thanks
<acheronuk> slangasek: thank you
-queuebot:#ubuntu-release- New binary: profitbricks-sdk-python [amd64] (artful-proposed/universe) [4.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fplll [amd64] (artful-proposed/universe) [5.1.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [ppc64el] (artful-proposed/universe) [1.6.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fplll [s390x] (artful-proposed/universe) [5.1.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: fplll [i386] (artful-proposed/universe) [5.1.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: fplll [ppc64el] (artful-proposed/universe) [5.1.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libmysofa [ppc64el] (artful-proposed/universe) [0.6~dfsg0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fplll [arm64] (artful-proposed/universe) [5.1.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: dehydrated-hook-ddns-tsig [amd64] (artful-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gtts [amd64] (artful-proposed/universe) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [amd64] (artful-proposed/universe) [1.6.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fplll [armhf] (artful-proposed/universe) [5.1.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libmysofa [i386] (artful-proposed/universe) [0.6~dfsg0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmysofa [amd64] (artful-proposed/universe) [0.6~dfsg0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [i386] (artful-proposed/universe) [1.6.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [s390x] (artful-proposed/universe) [1.6.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmysofa [s390x] (artful-proposed/universe) [0.6~dfsg0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: postfix (trusty-proposed/main) [2.11.0-1ubuntu1 => 2.11.0-1ubuntu1.1] (core)
-queuebot:#ubuntu-release- New binary: libmysofa [armhf] (artful-proposed/universe) [0.6~dfsg0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [arm64] (artful-proposed/universe) [1.6.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmysofa [arm64] (artful-proposed/universe) [0.6~dfsg0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: radare2 [armhf] (artful-proposed/universe) [1.6.0+dfsg-1] (no packageset)
#ubuntu-release 2017-08-17
-queuebot:#ubuntu-release- New binary: insighttoolkit4 [arm64] (artful-proposed/universe) [4.12.0-dfsg1-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted dehydrated-hook-ddns-tsig [amd64] (artful-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted fplll [arm64] (artful-proposed) [5.1.0-3]
-queuebot:#ubuntu-release- New: accepted fplll [i386] (artful-proposed) [5.1.0-3]
-queuebot:#ubuntu-release- New: accepted fplll [s390x] (artful-proposed) [5.1.0-3]
-queuebot:#ubuntu-release- New: accepted libmysofa [amd64] (artful-proposed) [0.6~dfsg0-1]
-queuebot:#ubuntu-release- New: accepted libmysofa [armhf] (artful-proposed) [0.6~dfsg0-1]
-queuebot:#ubuntu-release- New: accepted libmysofa [ppc64el] (artful-proposed) [0.6~dfsg0-1]
-queuebot:#ubuntu-release- New: accepted menhir [amd64] (artful-proposed) [20170712-1]
-queuebot:#ubuntu-release- New: accepted radare2 [amd64] (artful-proposed) [1.6.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted radare2 [armhf] (artful-proposed) [1.6.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted fplll [amd64] (artful-proposed) [5.1.0-3]
-queuebot:#ubuntu-release- New: accepted fplll [ppc64el] (artful-proposed) [5.1.0-3]
-queuebot:#ubuntu-release- New: accepted libmysofa [arm64] (artful-proposed) [0.6~dfsg0-1]
-queuebot:#ubuntu-release- New: accepted libmysofa [s390x] (artful-proposed) [0.6~dfsg0-1]
-queuebot:#ubuntu-release- New: accepted radare2 [arm64] (artful-proposed) [1.6.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted radare2 [ppc64el] (artful-proposed) [1.6.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted fplll [armhf] (artful-proposed) [5.1.0-3]
-queuebot:#ubuntu-release- New: accepted libmysofa [i386] (artful-proposed) [0.6~dfsg0-1]
-queuebot:#ubuntu-release- New: accepted radare2 [i386] (artful-proposed) [1.6.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted gtts [amd64] (artful-proposed) [1.2.0-1]
-queuebot:#ubuntu-release- New: accepted radare2 [s390x] (artful-proposed) [1.6.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted profitbricks-sdk-python [amd64] (artful-proposed) [4.1.0-1]
-queuebot:#ubuntu-release- New: accepted insighttoolkit4 [s390x] (artful-proposed) [4.12.0-dfsg1-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted insighttoolkit4 [amd64] (artful-proposed) [4.12.0-dfsg1-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted insighttoolkit4 [armhf] (artful-proposed) [4.12.0-dfsg1-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted insighttoolkit4 [ppc64el] (artful-proposed) [4.12.0-dfsg1-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted insighttoolkit4 [arm64] (artful-proposed) [4.12.0-dfsg1-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted insighttoolkit4 [i386] (artful-proposed) [4.12.0-dfsg1-2ubuntu1]
#ubuntu-release 2017-08-18
-queuebot:#ubuntu-release- Unapproved: accepted fwupdate [amd64] (artful-proposed) [9-2]
-queuebot:#ubuntu-release- Unapproved: accepted fwupdate [armhf] (artful-proposed) [9-2]
-queuebot:#ubuntu-release- Unapproved: accepted fwupdate [arm64] (artful-proposed) [9-2]
-queuebot:#ubuntu-release- Unapproved: accepted fwupdate [i386] (artful-proposed) [9-2]
-queuebot:#ubuntu-release- Unapproved: accepted libsdl2 [source] (trusty-proposed) [2.0.2+dfsg1-3ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted pcl [source] (xenial-proposed) [1.7.2-14ubuntu1.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted pcl [source] (zesty-proposed) [1.8.0+dfsg1-4ubuntu4.17.04.1]
-queuebot:#ubuntu-release- New binary: analitza [ppc64el] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: analitza [amd64] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: analitza [s390x] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: baloo-widgets5 [amd64] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: analitza [i386] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: analitza [arm64] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: analitza [armhf] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted deepin-gettext-tools [amd64] (artful-proposed) [1.0.6+git20170811-1]
-queuebot:#ubuntu-release- New: accepted libidn2-0 [armhf] (artful-proposed) [2.0.2-3]
-queuebot:#ubuntu-release- New: accepted pgsphere [arm64] (artful-proposed) [1.1.1+2017.04.11-1]
-queuebot:#ubuntu-release- New: accepted pgsphere [i386] (artful-proposed) [1.1.1+2017.04.11-1]
-queuebot:#ubuntu-release- New: accepted soapyairspy [arm64] (artful-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted soapyairspy [s390x] (artful-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted soapyaudio [arm64] (artful-proposed) [0~git20160607-3]
-queuebot:#ubuntu-release- New: accepted soapyaudio [s390x] (artful-proposed) [0~git20160607-3]
-queuebot:#ubuntu-release- New: accepted soapybladerf [armhf] (artful-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted soapyhackrf [arm64] (artful-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted libidn2-0 [arm64] (artful-proposed) [2.0.2-3]
-queuebot:#ubuntu-release- New: accepted pgsphere [armhf] (artful-proposed) [1.1.1+2017.04.11-1]
-queuebot:#ubuntu-release- New: accepted soapyairspy [armhf] (artful-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted soapyaudio [armhf] (artful-proposed) [0~git20160607-3]
-queuebot:#ubuntu-release- New: accepted soapybladerf [s390x] (artful-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted soapyhackrf [i386] (artful-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted soapyredpitaya [amd64] (artful-proposed) [0.1.0-2]
-queuebot:#ubuntu-release- New: accepted soapyredpitaya [armhf] (artful-proposed) [0.1.0-2]
-queuebot:#ubuntu-release- New: accepted soapyredpitaya [s390x] (artful-proposed) [0.1.0-2]
-queuebot:#ubuntu-release- New: accepted soapyrtlsdr [arm64] (artful-proposed) [0.2.4-1]
-queuebot:#ubuntu-release- New: accepted pgsphere [amd64] (artful-proposed) [1.1.1+2017.04.11-1]
-queuebot:#ubuntu-release- New: accepted soapyaudio [amd64] (artful-proposed) [0~git20160607-3]
-queuebot:#ubuntu-release- New: accepted soapyhackrf [armhf] (artful-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted soapyredpitaya [arm64] (artful-proposed) [0.1.0-2]
-queuebot:#ubuntu-release- New: accepted soapyrtlsdr [amd64] (artful-proposed) [0.2.4-1]
-queuebot:#ubuntu-release- New: accepted soapyrtlsdr [i386] (artful-proposed) [0.2.4-1]
-queuebot:#ubuntu-release- New: accepted soapyuhd [amd64] (artful-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted soapyuhd [armhf] (artful-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted soapyuhd [s390x] (artful-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted wireshark [arm64] (artful-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- New: accepted pgsphere [s390x] (artful-proposed) [1.1.1+2017.04.11-1]
-queuebot:#ubuntu-release- New: accepted soapyhackrf [s390x] (artful-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted soapyrtlsdr [armhf] (artful-proposed) [0.2.4-1]
-queuebot:#ubuntu-release- New: accepted soapyuhd [arm64] (artful-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted wireshark [amd64] (artful-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- New: accepted wireshark [i386] (artful-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- New: accepted wireshark [s390x] (artful-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- New: accepted zimlib [i386] (artful-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New binary: linux [arm64] (artful-proposed/main) [4.12.0-12.13] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (artful-proposed/main) [4.12.0-12.13] (core, kernel)
-queuebot:#ubuntu-release- New: accepted soapybladerf [arm64] (artful-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted soapyrtlsdr [s390x] (artful-proposed) [0.2.4-1]
-queuebot:#ubuntu-release- New: accepted wireshark [armhf] (artful-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- New: accepted zimlib [armhf] (artful-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New binary: linux [i386] (artful-proposed/main) [4.12.0-12.13] (core, kernel)
-queuebot:#ubuntu-release- New binary: xen [arm64] (artful-proposed/main) [4.9.0-0ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server, virt)
-queuebot:#ubuntu-release- New binary: xen [i386] (artful-proposed/main) [4.9.0-0ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server, virt)
-queuebot:#ubuntu-release- New: accepted gocode [amd64] (artful-proposed) [20150303-4]
-queuebot:#ubuntu-release- New: accepted libidn2-0 [i386] (artful-proposed) [2.0.2-3]
-queuebot:#ubuntu-release- New: accepted libidn2-0 [s390x] (artful-proposed) [2.0.2-3]
-queuebot:#ubuntu-release- New: accepted soapyredpitaya [i386] (artful-proposed) [0.1.0-2]
-queuebot:#ubuntu-release- New: accepted wireshark [ppc64el] (artful-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- New binary: linux [s390x] (artful-proposed/main) [4.12.0-12.13] (core, kernel)
-queuebot:#ubuntu-release- New: accepted go-mode.el [amd64] (artful-proposed) [3:1.5.0-1]
-queuebot:#ubuntu-release- New: accepted libidn2-0 [ppc64el] (artful-proposed) [2.0.2-3]
-queuebot:#ubuntu-release- New: accepted soapyairspy [amd64] (artful-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted soapyairspy [ppc64el] (artful-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted soapyaudio [ppc64el] (artful-proposed) [0~git20160607-3]
-queuebot:#ubuntu-release- New: accepted soapybladerf [i386] (artful-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted libidn2-0 [amd64] (artful-proposed) [2.0.2-3]
-queuebot:#ubuntu-release- New: accepted soapyrtlsdr [ppc64el] (artful-proposed) [0.2.4-1]
-queuebot:#ubuntu-release- New: accepted soapybladerf [amd64] (artful-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted debian-games [amd64] (artful-proposed) [2.1ubuntu1]
-queuebot:#ubuntu-release- New: accepted linux [amd64] (artful-proposed) [4.12.0-12.13]
-queuebot:#ubuntu-release- New: accepted linux [armhf] (artful-proposed) [4.12.0-12.13]
-queuebot:#ubuntu-release- New: accepted linux [ppc64el] (artful-proposed) [4.12.0-12.13]
-queuebot:#ubuntu-release- New: accepted linux [arm64] (artful-proposed) [4.12.0-12.13]
-queuebot:#ubuntu-release- New: accepted linux [s390x] (artful-proposed) [4.12.0-12.13]
-queuebot:#ubuntu-release- New: accepted linux [i386] (artful-proposed) [4.12.0-12.13]
-queuebot:#ubuntu-release- New binary: marble [ppc64el] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted xen [amd64] (artful-proposed) [4.9.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted xen [armhf] (artful-proposed) [4.9.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted xen [arm64] (artful-proposed) [4.9.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted xen [i386] (artful-proposed) [4.9.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted baloo-widgets5 [amd64] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: marble [s390x] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkf5kmahjongg [amd64] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkcddb [amd64] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkomparediff2 [amd64] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkcompactdisc [amd64] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkdegames [amd64] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: marble [i386] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkeduvocdocument [amd64] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: konqueror [amd64] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: marble [amd64] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: okteta [amd64] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: marble [armhf] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: marble [arm64] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
<acheronuk> if someone could accept the ongoing new KDE binaries that would be great.
<acheronuk> mostly new data packages now translations are moving back into main sources, and bumped library packages I think
<acheronuk> thanks
-queuebot:#ubuntu-release- New: accepted libkf5kmahjongg [amd64] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkomparediff2 [amd64] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkcddb [amd64] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkcompactdisc [amd64] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkdegames [amd64] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkeduvocdocument [amd64] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted konqueror [amd64] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: kolourpaint [ppc64el] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted okteta [amd64] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: kolourpaint [amd64] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kolourpaint [i386] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (artful-proposed/main) [4.12.0-12.13] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (artful-proposed) [4.12.0-12.13]
-queuebot:#ubuntu-release- New binary: kolourpaint [s390x] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted marble [amd64] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted marble [armhf] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted marble [ppc64el] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted marble [arm64] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted marble [s390x] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted marble [i386] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: kolourpaint [arm64] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kolourpaint [armhf] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
<xnox> slangasek, could you please hint to migrate systemd ? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#systemd
-queuebot:#ubuntu-release- New binary: pluma [ppc64el] (artful-proposed/universe) [1.18.2-1] (ubuntu-mate, ubuntukylin)
-queuebot:#ubuntu-release- New binary: pluma [i386] (artful-proposed/universe) [1.18.2-1] (ubuntu-mate, ubuntukylin)
-queuebot:#ubuntu-release- New binary: pluma [s390x] (artful-proposed/universe) [1.18.2-1] (ubuntu-mate, ubuntukylin)
-queuebot:#ubuntu-release- New binary: pluma [amd64] (artful-proposed/universe) [1.18.2-1] (ubuntu-mate, ubuntukylin)
-queuebot:#ubuntu-release- New binary: pluma [armhf] (artful-proposed/universe) [1.18.2-1] (ubuntu-mate, ubuntukylin)
-queuebot:#ubuntu-release- New binary: pluma [arm64] (artful-proposed/universe) [1.18.2-1] (ubuntu-mate, ubuntukylin)
-queuebot:#ubuntu-release- New: accepted kolourpaint [amd64] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kolourpaint [armhf] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kolourpaint [ppc64el] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kolourpaint [arm64] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kolourpaint [s390x] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kolourpaint [i386] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted pluma [amd64] (artful-proposed) [1.18.2-1]
-queuebot:#ubuntu-release- New: accepted pluma [armhf] (artful-proposed) [1.18.2-1]
-queuebot:#ubuntu-release- New: accepted pluma [ppc64el] (artful-proposed) [1.18.2-1]
-queuebot:#ubuntu-release- New: accepted pluma [arm64] (artful-proposed) [1.18.2-1]
-queuebot:#ubuntu-release- New: accepted pluma [s390x] (artful-proposed) [1.18.2-1]
-queuebot:#ubuntu-release- New: accepted pluma [i386] (artful-proposed) [1.18.2-1]
-queuebot:#ubuntu-release- New source: xchat-gnome (artful-proposed/primary) [1:0.30.0~git20141005.816798-0ubuntu10]
-queuebot:#ubuntu-release- New: accepted debian-multimedia [amd64] (artful-proposed) [0.6ubuntu1]
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.27.2 => 2.27.3] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.27.2 => 2.27.3] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.27.2~14.04 => 2.27.3~14.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapd (zesty-proposed/main) [2.27.2+17.04 => 2.27.3+17.04] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (zesty-proposed) [2.27.3+17.04]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.27.3]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.27.3]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.27.3~14.04]
<didrocks> slangasek: if you get to xnox request, mind doing the same for glib? nplan is the only failing test on x86 (known to be flaky, like what's blocking systemd)
<slangasek> cyphermox: what's the plan for test_mix_vlan_on_bridge_on_bond on i386 in nplan?
<xnox> slangasek, i've rerun nplan with new systemd on i386 and it does not reproduce under qemu runner locally. But my home machine is beefy / less load emulation.
 * xnox can retrigger against canonistack as well, now that i've learned from Laney how to do that.
<xnox> slangasek, it did pass, eventually, for util-linux migration.
<slangasek> xnox: yes, and I've badtested it now
<slangasek> but I want to know when it's going to be fixed :/
<xnox> slangasek, when we drop i386? =)
<ginggs> node-postgres and node-zlib FTBFS with the nodejs-abi-48 rebuild, neither have been in debian testing for some years - can they be removed from -release?
<xnox> ginggs, open a bug against a package "[RM] FTBFS foo", mention details in the description, mark as triaged and subscribe ubuntu-archive team. We document removals.
 * xnox thinks we really really really should be following testing removals, or e.g. stable removals (after testing becomes stable)
<ginggs> xnox: ok, but i don't believe subscribing ubuntu-archive team actually works, launchpad times out retrieving ubuntu-archive team's bugs
<ginggs> but i'll file bugs and bug people here :)
<xnox> ginggs, they have api scripts to process subscribed bugs ;-)
<slangasek> we do? neato
<slangasek> I don't use them; but I still expect a bug report so that there's a public and discoverable audit log for the package removal ;)
<xnox> slangasek, is this the point i say "hand over your ubuntu-archive rights sir and nobody gets hurt"? =)
<xnox> </kidding> i don't want those rights.
<xnox> too much headache.
-queuebot:#ubuntu-release- New binary: pynac [ppc64el] (artful-proposed/universe) [0.7.8-3] (no packageset)
-queuebot:#ubuntu-release- New binary: pynac [s390x] (artful-proposed/universe) [0.7.8-3] (no packageset)
<xnox> slangasek, what about linux/armhf hint and linux-raspi2/armhf hint for systemd? =)
<xnox> rebuild still timed out, but i believe this may be due to our armhf-test-running host is not setup with production recommended lxd settings.
<slangasek> xnox: I still need to look at and evaluate those; I will certainly hint systemd through but will look to see what kind of hint it should be
-queuebot:#ubuntu-release- New binary: pynac [arm64] (artful-proposed/universe) [0.7.8-3] (no packageset)
-queuebot:#ubuntu-release- New binary: pynac [armhf] (artful-proposed/universe) [0.7.8-3] (no packageset)
<xnox> slangasek, rebuild FAIL timed out -> container too small for kernel build =( they did try to fix it, in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1705495 but possibly needs a reopen
<ubot5> Ubuntu bug 1705495 in linux (Ubuntu Zesty) "Adt tests of src:linux time out often on armhf lxc containers" [Undecided,Fix committed]
<slangasek> I am unclear on why a rebuild test is what we're doing in the linux autopkgtests
<apw> xnox, those fixes are only just landing in this cycle i think
<slangasek> it's not like that buys the kernel team anything, since everything builds against -proposed
<apw> slangasek, because the test is in part for things like gcc, which the building part we care about
<slangasek> apw: right, but then maybe we should key it to skip except for certain packages
<apw> slangasek, yeah that would work better than what we do now ...
<apw> which is to skip it for the actual kernel, but doing it only for gcc* and binutils sort of thing makes snese
<xnox> apw, you do get ADT_TRIGGER environment variable, which one can check if the triggered-by package is interesting or not (e.g. gcc/binutils/etc)
<apw> xnox, right and we do that, to avoid doing it when we test linux itself
<xnox> shall i document that in the bug?
<xnox> ah, ok.
<apw> no i know how to do it, will file a card on it
<xnox> so hipster filing cards =)
 * ogra_ is curious to see apw with hipster beard and suspenders at the next sprint 
<ginggs> slangasek: LP: #1711721 and LP:#1711722 please :)
<ubot5> Launchpad bug 1711721 in node-zlib (Ubuntu) "[RM] FTBFS" [Undecided,Triaged] https://launchpad.net/bugs/1711721
<ginggs> LP: #1711722 with a space for the bot
<ubot5> Launchpad bug 1711722 in node-postgres (Ubuntu) "[RM] FTBFS" [Undecided,Triaged] https://launchpad.net/bugs/1711722
<slangasek> ginggs: done
<ginggs> slangasek: thanks!
-queuebot:#ubuntu-release- Unapproved: python3.5 (xenial-proposed/main) [3.5.2-2ubuntu0~16.04.1 => 3.5.2-2ubuntu0~16.04.2] (core)
-queuebot:#ubuntu-release- Unapproved: proj (xenial-proposed/universe) [4.9.2-2 => 4.9.2-2ubuntu1.16.04.1] (no packageset)
<LocutusOfBorg> tjaalton, please approve proj ^^ pcl won't build in plain xenial without that no change rebuild (I remember having to do it for >=xenial)
<LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa/+build/13266936
<LocutusOfBorg> it seems to build fine now
<tjaalton> LocutusOfBorg: too late for me, I'm off
<tjaalton> say hi to Saturday ;)
<LocutusOfBorg> :)
<LocutusOfBorg> I'll be AFK for 3 days probably
<LocutusOfBorg> cheers!
<slangasek> apw: so also, in investigating some autopkgtest timeouts wrt snapd, I now understand that unlike buildds, the 'timeout' in autopkgtest is the total maximum time a test is allowed to run.  And the timeout is hard-coded. So expecting a rebuild test to finish on armhf in 2h47m is bananapants.
<slangasek> xnox: ^^ I now have a satisfactory understanding of *why* these tests fail, so am badtesting linux*/armhf until further notice
-queuebot:#ubuntu-release- New binary: pynac [amd64] (artful-proposed/universe) [0.7.8-3] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-gin-gonic-gin [amd64] (artful-proposed/universe) [1.2+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtk-fontdialog-perl [amd64] (artful-proposed/universe) [0.18-1] (no packageset)
-queuebot:#ubuntu-release- New binary: librt-extension-commandbymail-perl [amd64] (artful-proposed/universe) [3.00-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pynac [i386] (artful-proposed/universe) [0.7.8-3] (no packageset)
<xnox> slangasek, \o/
-queuebot:#ubuntu-release- New binary: libgtk3-webkit2-perl [amd64] (artful-proposed/universe) [0.06-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-genfun [amd64] (artful-proposed/universe) [4.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-imagemagick [amd64] (artful-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-json-schema-traverse [amd64] (artful-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-platform [amd64] (artful-proposed/universe) [1.3.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-read-only-stream [amd64] (artful-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-buffers [amd64] (artful-proposed/universe) [0.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-jed [amd64] (artful-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-promise-inflight [amd64] (artful-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-htmlescape [amd64] (artful-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-path-is-inside [amd64] (artful-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ubiquity-slideshow-ubuntu [amd64] (artful-proposed/main) [128] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: node-parents [amd64] (artful-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-github-gin-gonic-gin [amd64] (artful-proposed) [1.2+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted librt-extension-commandbymail-perl [amd64] (artful-proposed) [3.00-1]
-queuebot:#ubuntu-release- New: accepted node-buffers [amd64] (artful-proposed) [0.1.1-2]
-queuebot:#ubuntu-release- New: accepted node-htmlescape [amd64] (artful-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted node-jed [amd64] (artful-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted node-parents [amd64] (artful-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted node-platform [amd64] (artful-proposed) [1.3.4-1]
-queuebot:#ubuntu-release- New: accepted node-read-only-stream [amd64] (artful-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted pynac [i386] (artful-proposed) [0.7.8-3]
-queuebot:#ubuntu-release- New: accepted libgtk3-webkit2-perl [amd64] (artful-proposed) [0.06-1]
-queuebot:#ubuntu-release- New: accepted node-genfun [amd64] (artful-proposed) [4.0.1-1]
-queuebot:#ubuntu-release- New: accepted node-json-schema-traverse [amd64] (artful-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted node-promise-inflight [amd64] (artful-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted libtk-fontdialog-perl [amd64] (artful-proposed) [0.18-1]
-queuebot:#ubuntu-release- New: accepted node-path-is-inside [amd64] (artful-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted node-imagemagick [amd64] (artful-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted pynac [amd64] (artful-proposed) [0.7.8-3]
-queuebot:#ubuntu-release- New: accepted pynac [arm64] (artful-proposed) [0.7.8-3]
-queuebot:#ubuntu-release- New: accepted pynac [ppc64el] (artful-proposed) [0.7.8-3]
-queuebot:#ubuntu-release- New: accepted pynac [armhf] (artful-proposed) [0.7.8-3]
-queuebot:#ubuntu-release- New: accepted pynac [s390x] (artful-proposed) [0.7.8-3]
<coreycb> hello release team, can you please accept python-mistral-lib and python-glareclient from the new queue?  this will help get some of our openstack packages unblocked.
-queuebot:#ubuntu-release- Unapproved: cups (xenial-proposed/main) [2.1.3-4ubuntu0.2 => 2.1.3-4ubuntu0.3] (core)
#ubuntu-release 2017-08-19
<jbicha> slangasek: good news https://launchpad.net/ubuntu/+source/mongodb/1:3.4.7-1
<jbicha> please delete the i386 artful binaries (no longer supported by mongodb) to allow it to migrate
-queuebot:#ubuntu-release- New binary: polyml [amd64] (artful-proposed/universe) [5.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: polyml [s390x] (artful-proposed/universe) [5.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: polyml [i386] (artful-proposed/universe) [5.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: polyml [ppc64el] (artful-proposed/universe) [5.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: polyml [arm64] (artful-proposed/universe) [5.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: polyml [armhf] (artful-proposed/universe) [5.7-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted polyml [amd64] (artful-proposed) [5.7-1]
-queuebot:#ubuntu-release- New: accepted polyml [armhf] (artful-proposed) [5.7-1]
-queuebot:#ubuntu-release- New: accepted polyml [ppc64el] (artful-proposed) [5.7-1]
-queuebot:#ubuntu-release- New: accepted polyml [arm64] (artful-proposed) [5.7-1]
-queuebot:#ubuntu-release- New: accepted polyml [s390x] (artful-proposed) [5.7-1]
-queuebot:#ubuntu-release- New: accepted polyml [i386] (artful-proposed) [5.7-1]
-queuebot:#ubuntu-release- New: accepted analitza [amd64] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted analitza [armhf] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted analitza [ppc64el] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ubiquity-slideshow-ubuntu [amd64] (artful-proposed) [128]
-queuebot:#ubuntu-release- New: accepted analitza [arm64] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted analitza [s390x] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted analitza [i386] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-golang-x-sync [amd64] (artful-proposed) [0.0~git20170317.0.5a06fca-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-golang-x-sync [armhf] (artful-proposed) [0.0~git20170317.0.5a06fca-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-golang-x-sync [ppc64el] (artful-proposed) [0.0~git20170317.0.5a06fca-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-golang-x-sync [arm64] (artful-proposed) [0.0~git20170317.0.5a06fca-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-golang-x-sync [s390x] (artful-proposed) [0.0~git20170317.0.5a06fca-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-golang-x-sync [i386] (artful-proposed) [0.0~git20170317.0.5a06fca-1ubuntu1]
<doko> coreycb: I have rejected both. Copyright: See individual files for copyright information.
<doko> this is not enough. you have to mention the individual copyright holders in the debian/copyright file
-queuebot:#ubuntu-release- New: rejected python-glareclient [source] (artful-proposed) [0.4.1-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected python-mistral-lib [source] (artful-proposed) [0.2.0-0ubuntu1]
<acheronuk> morning
<acheronuk> would it be possible to badtest for now the test failures on kate4?
<acheronuk> this is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853471
<ubot5> Debian bug 853471 in src:kate4 "kate4: ftbfs with GCC-7" [Serious,Open]
<acheronuk> and not the fault of the packages the tests are being triggered against
-queuebot:#ubuntu-release- New source: python-mistral-lib (artful-proposed/primary) [0.2.0-0ubuntu2]
-queuebot:#ubuntu-release- New source: python-glareclient (artful-proposed/primary) [0.4.1-0ubuntu2]
-queuebot:#ubuntu-release- New source: python-mistral-lib (artful-proposed/primary) [0.2.0-0ubuntu2]
<coreycb> doko: i've updated copyrights and uploaded again. for python-mistral-lib please accept the most recent upload and reject the older one. thank you.
-queuebot:#ubuntu-release- New binary: cantor [ppc64el] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: cantor [amd64] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: cantor [i386] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: cantor [s390x] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: cantor [arm64] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: cantor [armhf] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: eog-plugins [ppc64el] (artful-proposed/universe) [3.16.6-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: eog-plugins [amd64] (artful-proposed/universe) [3.16.6-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: eog-plugins [s390x] (artful-proposed/universe) [3.16.6-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: eog-plugins [arm64] (artful-proposed/universe) [3.16.6-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: eog-plugins [armhf] (artful-proposed/universe) [3.16.6-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: gedit-plugins [amd64] (artful-proposed/universe) [3.22.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: eog-plugins [i386] (artful-proposed/universe) [3.16.6-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: gedit-plugins [ppc64el] (artful-proposed/universe) [3.22.0-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: gedit-plugins [amd64] (artful-proposed/universe) [3.22.0-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: gedit-plugins [s390x] (artful-proposed/universe) [3.22.0-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: gedit-plugins [arm64] (artful-proposed/universe) [3.22.0-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: gedit-plugins [armhf] (artful-proposed/universe) [3.22.0-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: gedit-plugins [i386] (artful-proposed/universe) [3.22.0-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: libemf [amd64] (artful-proposed/none) [1.0.9+git.9.e2f97d9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libemf [ppc64el] (artful-proposed/none) [1.0.9+git.9.e2f97d9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libemf [i386] (artful-proposed/none) [1.0.9+git.9.e2f97d9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libemf [s390x] (artful-proposed/none) [1.0.9+git.9.e2f97d9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libemf [armhf] (artful-proposed/universe) [1.0.9+git.9.e2f97d9-1] (no packageset)
#ubuntu-release 2017-08-20
<slangasek> jbicha: thanks, mongodb binaries nuked.  NB this appears to make uwsgi, libmongodb-perl unbuildable now on i386
<wgrant> slangasek, jbicha: mongodb builds mongodb-clients; does it really make sense to kill the whole thing just because the upstream vendor doesn't like 32-bit servers?
<slangasek> wgrant: it's fine if someone wants to fix it to build on i386, but as things stand i386 is "ANAIS" so with AA/release team hat on it's better to remove than let it block in -proposed indefinitely
<wgrant> Oh they actually broke the build, I see.
-queuebot:#ubuntu-release- New binary: kashmir [amd64] (artful-proposed/none) [0.0~git20150805.0.2f3913f+dfsg1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: guzzle-sphinx-theme [amd64] (artful-proposed/universe) [0.7.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: simgrid [ppc64el] (artful-proposed/universe) [3.16+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: simgrid [s390x] (artful-proposed/universe) [3.16+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: simgrid [amd64] (artful-proposed/universe) [3.16+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: simgrid [i386] (artful-proposed/universe) [3.16+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: simgrid [arm64] (artful-proposed/universe) [3.16+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: simgrid [armhf] (artful-proposed/universe) [3.16+dfsg-1] (no packageset)
<acheronuk> OSError: [Errno 28] No space left on device: on https://autopkgtest.ubuntu.com/running
<acheronuk> tests hanging indefinitely
-queuebot:#ubuntu-release- New source: caja-admin (artful-proposed/primary) [0.0.1-1~git1]
<jbicha> flexiondotorg: caja-admin uploaded ^
-queuebot:#ubuntu-release- New: accepted gedit-plugins [amd64] (artful-proposed) [3.22.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gedit-plugins [arm64] (artful-proposed) [3.22.0-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted gedit-plugins [i386] (artful-proposed) [3.22.0-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted gedit-plugins [s390x] (artful-proposed) [3.22.0-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted kashmir [amd64] (artful-proposed) [0.0~git20150805.0.2f3913f+dfsg1-3]
-queuebot:#ubuntu-release- New: accepted simgrid [arm64] (artful-proposed) [3.16+dfsg-1]
-queuebot:#ubuntu-release- New: accepted simgrid [i386] (artful-proposed) [3.16+dfsg-1]
-queuebot:#ubuntu-release- New: accepted simgrid [s390x] (artful-proposed) [3.16+dfsg-1]
-queuebot:#ubuntu-release- New: accepted gedit-plugins [amd64] (artful-proposed) [3.22.0-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted gedit-plugins [ppc64el] (artful-proposed) [3.22.0-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted simgrid [amd64] (artful-proposed) [3.16+dfsg-1]
-queuebot:#ubuntu-release- New: accepted simgrid [ppc64el] (artful-proposed) [3.16+dfsg-1]
-queuebot:#ubuntu-release- New: accepted gedit-plugins [armhf] (artful-proposed) [3.22.0-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted simgrid [armhf] (artful-proposed) [3.16+dfsg-1]
-queuebot:#ubuntu-release- New: accepted guzzle-sphinx-theme [amd64] (artful-proposed) [0.7.11-1]
-queuebot:#ubuntu-release- New: accepted cantor [amd64] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted cantor [armhf] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted cantor [ppc64el] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted cantor [arm64] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted cantor [s390x] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted cantor [i386] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted eog-plugins [amd64] (artful-proposed) [3.16.6-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted eog-plugins [armhf] (artful-proposed) [3.16.6-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted eog-plugins [ppc64el] (artful-proposed) [3.16.6-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted eog-plugins [arm64] (artful-proposed) [3.16.6-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted eog-plugins [s390x] (artful-proposed) [3.16.6-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted eog-plugins [i386] (artful-proposed) [3.16.6-1ubuntu1]
-queuebot:#ubuntu-release- New: rejected python-mistral-lib [source] (artful-proposed) [0.2.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted libemf [amd64] (artful-proposed) [1.0.9+git.9.e2f97d9-1]
-queuebot:#ubuntu-release- New: accepted libemf [i386] (artful-proposed) [1.0.9+git.9.e2f97d9-1]
-queuebot:#ubuntu-release- New: accepted libemf [s390x] (artful-proposed) [1.0.9+git.9.e2f97d9-1]
-queuebot:#ubuntu-release- New: accepted libemf [armhf] (artful-proposed) [1.0.9+git.9.e2f97d9-1]
-queuebot:#ubuntu-release- New: accepted libemf [ppc64el] (artful-proposed) [1.0.9+git.9.e2f97d9-1]
-queuebot:#ubuntu-release- New: accepted python-glareclient [source] (artful-proposed) [0.4.1-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted python-mistral-lib [source] (artful-proposed) [0.2.0-0ubuntu2]
-queuebot:#ubuntu-release- New binary: python-glareclient [amd64] (artful-proposed/universe) [0.4.1-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-mistral-lib [amd64] (artful-proposed/universe) [0.2.0-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-glareclient [amd64] (artful-proposed) [0.4.1-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted python-mistral-lib [amd64] (artful-proposed) [0.2.0-0ubuntu2]
<jbicha> could gedit-plugins be hinted in to artful? it is now an arch:all metapackage instead of arch:any and it looks like 'gnome' is confused in update_output.txt
<doko> coreycb: in the archive now. if you are aware of any other package with such copyrights, please correct them as well
-queuebot:#ubuntu-release- New binary: mistral [amd64] (artful-proposed/universe) [5.0.0~rc1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted mistral [amd64] (artful-proposed) [5.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- New sync: kexi (artful-proposed/primary) [1:3.0.2-1]
-queuebot:#ubuntu-release- New: accepted kexi [sync] (artful-proposed) [1:3.0.2-1]
-queuebot:#ubuntu-release- New binary: breeze-icons [amd64] (artful-proposed/universe) [4:5.37.0-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- New: accepted breeze-icons [amd64] (artful-proposed) [4:5.37.0-0ubuntu2]
-queuebot:#ubuntu-release- New binary: kexi [i386] (artful-proposed/universe) [1:3.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kexi [ppc64el] (artful-proposed/universe) [1:3.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kexi [amd64] (artful-proposed/universe) [1:3.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted kexi [amd64] (artful-proposed) [1:3.0.2-1]
-queuebot:#ubuntu-release- New: accepted kexi [ppc64el] (artful-proposed) [1:3.0.2-1]
-queuebot:#ubuntu-release- New: accepted kexi [i386] (artful-proposed) [1:3.0.2-1]
-queuebot:#ubuntu-release- New binary: kexi [s390x] (artful-proposed/universe) [1:3.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kexi [arm64] (artful-proposed/universe) [1:3.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kexi [armhf] (artful-proposed/universe) [1:3.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ahven [amd64] (artful-proposed/universe) [2.6-1.2] (no packageset)
-queuebot:#ubuntu-release- New binary: ahven [i386] (artful-proposed/universe) [2.6-1.2] (no packageset)
-queuebot:#ubuntu-release- New binary: importmagic [amd64] (artful-proposed/universe) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ahven [arm64] (artful-proposed/universe) [2.6-1.2] (no packageset)
-queuebot:#ubuntu-release- New binary: ahven [ppc64el] (artful-proposed/universe) [2.6-1.2] (no packageset)
-queuebot:#ubuntu-release- New binary: ahven [armhf] (artful-proposed/universe) [2.6-1.2] (no packageset)
-queuebot:#ubuntu-release- New binary: diceware [amd64] (artful-proposed/universe) [0.9.1-4.1] (no packageset)
-queuebot:#ubuntu-release- New binary: ahven [s390x] (artful-proposed/universe) [2.6-1.2] (no packageset)
#ubuntu-release 2018-08-13
-queuebot:#ubuntu-release- New binary: qtspell [i386] (cosmic-proposed/none) [0.8.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qtspell [s390x] (cosmic-proposed/none) [0.8.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qtspell [arm64] (cosmic-proposed/universe) [0.8.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qtspell [armhf] (cosmic-proposed/universe) [0.8.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qtspell [amd64] (cosmic-proposed/universe) [0.8.4-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted libguestfs [source] (bionic-proposed) [1:1.36.13-1ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: accepted evolution [source] (bionic-proposed) [3.28.5-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New: accepted chafa [arm64] (cosmic-proposed) [0.9.0+git20180731.5ddfe4c-1]
-queuebot:#ubuntu-release- New: accepted chafa [armhf] (cosmic-proposed) [0.9.0+git20180731.5ddfe4c-1]
-queuebot:#ubuntu-release- New: accepted chafa [amd64] (cosmic-proposed) [0.9.0+git20180731.5ddfe4c-1]
-queuebot:#ubuntu-release- New: accepted chafa [s390x] (cosmic-proposed) [0.9.0+git20180731.5ddfe4c-1]
-queuebot:#ubuntu-release- New: accepted chafa [arm64] (cosmic-proposed) [0.9.0+git20180731.5ddfe4c-2]
-queuebot:#ubuntu-release- New: accepted chafa [i386] (cosmic-proposed) [0.9.0+git20180731.5ddfe4c-2]
-queuebot:#ubuntu-release- New: accepted chafa [s390x] (cosmic-proposed) [0.9.0+git20180731.5ddfe4c-2]
-queuebot:#ubuntu-release- New: accepted chafa [ppc64el] (cosmic-proposed) [0.9.0+git20180731.5ddfe4c-1]
-queuebot:#ubuntu-release- New: accepted chafa [armhf] (cosmic-proposed) [0.9.0+git20180731.5ddfe4c-2]
-queuebot:#ubuntu-release- New: accepted yapf [amd64] (cosmic-proposed) [0.22.0-2]
-queuebot:#ubuntu-release- New: accepted chafa [amd64] (cosmic-proposed) [0.9.0+git20180731.5ddfe4c-2]
-queuebot:#ubuntu-release- New: accepted chafa [ppc64el] (cosmic-proposed) [0.9.0+git20180731.5ddfe4c-2]
-queuebot:#ubuntu-release- New: accepted hivelytracker [amd64] (cosmic-proposed) [0+git20180223-1]
-queuebot:#ubuntu-release- New: accepted hivelytracker [amd64] (cosmic-proposed) [0+git20180223-2]
-queuebot:#ubuntu-release- New: accepted hivelytracker [armhf] (cosmic-proposed) [0+git20180223-2]
-queuebot:#ubuntu-release- New: accepted hivelytracker [ppc64el] (cosmic-proposed) [0+git20180223-2]
-queuebot:#ubuntu-release- New: accepted hivelytracker [i386] (cosmic-proposed) [0+git20180223-1]
-queuebot:#ubuntu-release- New: accepted hivelytracker [i386] (cosmic-proposed) [0+git20180223-2]
-queuebot:#ubuntu-release- New: accepted hivelytracker [arm64] (cosmic-proposed) [0+git20180223-2]
-queuebot:#ubuntu-release- New: accepted hivelytracker [s390x] (cosmic-proposed) [0+git20180223-2]
-queuebot:#ubuntu-release- Unapproved: freshplayerplugin (bionic-proposed/multiverse) [0.3.5-1ubuntu7 => 0.3.9-0ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected freshplayerplugin [source] (bionic-proposed) [0.3.9-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted freshplayerplugin [source] (bionic-proposed) [0.3.9-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected nautilus [source] (bionic-proposed) [1:3.26.4-0~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected amd64-microcode [source] (trusty-proposed) [3.20180524.1~ubuntu0.14.04.2+really20130710.1ubuntu1]
-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)
-queuebot:#ubuntu-release- Unapproved: accepted amd64-microcode [source] (trusty-proposed) [3.20180524.1~ubuntu0.14.04.2+really20130710.1ubuntu1]
<sil2100> tseliot: hey! I'm looking at your prime power saving mode SRUs to bionic - in the queue I see uploads for u-d-c and the nvidia-* packages but not for gdm3
<sil2100> tseliot: will that still be coming?
<sil2100> tseliot: or is it not needed for bionic?
<tseliot> sil2100: hi, gdm is need, but, as I understand it, dgadomski_ is going to SRU gdm with another fix, and hopefully include my fix too. slashd should sponsor the upload. That's why I didn't upload myself
-queuebot:#ubuntu-release- Unapproved: accepted open-vm-tools [source] (bionic-proposed) [2:10.3.0-0ubuntu1~18.04.1]
<sil2100> tseliot: does it make sense to accept the others without gdm? Since the test case mentions upgrading all of them, not sure if it wouldn't be confusing when we should consider the bug to be verified
-queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (bionic-proposed) [12.2.7-0ubuntu0.18.04.1]
<tseliot> sil2100: not really, as things might not work as designed
<sil2100> tseliot: ok then, I'll wait for the gdm then - thanks!
-queuebot:#ubuntu-release- Unapproved: grub2-signed (bionic-proposed/main) [1.93.3 => 1.93.4] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.2 => 2.02-2ubuntu8.3] (core)
-queuebot:#ubuntu-release- New binary: e-wrapper [amd64] (cosmic-proposed/universe) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hibiscus [amd64] (cosmic-proposed/universe) [2.8.1+dfsg-1] (no packageset)
<cpaelzer> dpdk SRU in bionic waits on new queue
<cpaelzer> so I can't really test/verify anything yet
<cpaelzer> apw: we talked about very similar on sunday for dovecot
<cpaelzer> is new queue on old release SRU-Team or Release-Team or ??
 * cpaelzer doesn't even know who exactly to ping on this :-/
<ddstreet> slangasek yep i'll look at why it FTBFS
<apw> cpaelzer, nominally speaking New source is always AAs as there are never any new sources in old releases (in theory)
<cpaelzer> ok thanks
<cpaelzer> theory sometimes is wrong in this case
<cpaelzer> but I agree, in general it would not
<apw> cpaelzer, so all i am saying is the process does not cover that ... so you really want someone who is SRU and AA
 * rbasak looks at apw
<rbasak> Although
<rbasak> https://launchpad.net/~apw
<rbasak> "Andy Whitcroft is not an active member of any Launchpad teams."
<cpaelzer> rbasak: https://launchpad.net/~apw/+participation looks quite crowded to me :-)
<acheronuk> weird. cjwatson is that ^^^ an artifact of latest LP changes?
<cjwatson> acheronuk: file a bug
<cjwatson> acheronuk: it's not due to a recent change.  FWIW from a brief skim I think it's a long-standing bug in the event that the last five teams that a person joined are all private from whoever's looking at the page
<cjwatson> (i.e. it grabs the last five approved memberships, then filters by visibility)
<acheronuk> cjwatson: right. makes sense
<sil2100> cpaelzer: I guess I could take a look at it
<Trevinho> sil2100: can you please check SRU queue for gnome-shell-extension-ubuntu-dock and mutter?
<sil2100> Trevinho: ok!
<sil2100> wow, I see dpdk also uses the ~ubuntu0.18.04 versioning scheme, looks like that's some new standard I didn't hear about ;p
 * sil2100 feels stupid now about being so picky with the version numbers
<sil2100> Especially that I only recently started actually being picky about that
<cpaelzer> sil2100: there are reasons for it to use that
<cpaelzer> I even chimed in on a thread about version numbers on ubuntu-devel
<cpaelzer> but there was no further reply :-/
<cpaelzer> most likely case is that you upload exactly what the following -dev release has
<cpaelzer> then the version can't be https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation style
<Trevinho> sil2100: well, I've just followed what was done in previous releases too, so...
<cpaelzer> 2.0-2ubuntu0.11.10.1
<cpaelzer> as 2.0-2 would be in the latter release and break upgrades if extended by ubuntu0
<Trevinho> sil2100: It wasn't mentioned on that wiki, but in previous SRUs that was accepted, and then I sometimes kept using it
<cpaelzer> only the ~ saves the upgrade path in backports
<Trevinho> although I'd generally prefer to be consistent on this
-queuebot:#ubuntu-release- New: accepted dpdk [amd64] (bionic-proposed) [17.11.3-3~ubuntu0.18.04]
-queuebot:#ubuntu-release- New: accepted dpdk [i386] (bionic-proposed) [17.11.3-3~ubuntu0.18.04]
-queuebot:#ubuntu-release- New: accepted dpdk [arm64] (bionic-proposed) [17.11.3-3~ubuntu0.18.04]
<cpaelzer> sil2100: if there is anything bad on this scheme of version numbers (for exactly that case) could you please reply to https://lists.ubuntu.com/archives/ubuntu-devel/2018-July/040406.html ?
-queuebot:#ubuntu-release- New: accepted dpdk [ppc64el] (bionic-proposed) [17.11.3-3~ubuntu0.18.04]
<sil2100> Trevinho: I'm all +1 on consistency, actually that's the usual thing I propose and require
<cpaelzer> I really discussed with a lot of people
<sil2100> Trevinho: so for instance for mutter I'm all good
<cpaelzer> and found no better scheme for the case
<cpaelzer> and I asked if we should add it to the wiki, but no reply on that
<cpaelzer> so if you are -1 on the version let me know, and if you are +1 on it and all in for consitence you might just reply that you'd like if it was added to the wiki page
<cpaelzer> sil2100: ^^
<sil2100> cpaelzer: well, for direct backports of what is in the devel or some other series we usually just recommend adding ~18.04.1 or something
<sil2100> So just the series number
<Laney> Following the backport scheme when the SRU is a backport makes sense IMO - that's when I've used it before.
<Laney> The backport scheme is ~ubuntuXX.YY.<incrementing number>
<Trevinho> yeah, I agree in that case too
<sil2100> Adding ~ubuntu<series> to me personally is confusing, as it seems to apply there are ubuntu changes
<cpaelzer> which is what I used @Laney
<cpaelzer> all I want is consitency and agreement
<cpaelzer> I'd be fine to follow any
<Laney> It's already codified in the backportpackage tool too.
<cpaelzer> but without a clear "that is it" I (as everyone else) just try to make it good
<Trevinho> also in nautilus for example we're going to use the same base version, so using ~ubuntu is better imho
<Laney> So. I prefer this one.
<sil2100> If that is the official backport scheme, then I guess I wasn't educated well enough
<cpaelzer> ok we seem to have local qorum ack :-)
<Laney> If it's not a backport then probably the SecurityTeam page examples should be used
<cpaelzer> feel free to reply to that mail if you want :-)
<cpaelzer> As I said, I'd wish to extend that page
<sil2100> Laney: I guess we'd need to have all those things packed up in one place
<cpaelzer> for the backport'y case
<sil2100> Laney: like, all the 'recommended' version schemes
<Laney> Makes sense
<cpaelzer> but would need some buy in on the mail thread to do so
<Laney> That page seems to be the one people refer to
<cpaelzer> yep
<cpaelzer> most referenced in this case
<sil2100> Laney: since not being part of the backport team I didn't know ~ubuntu<series_number>.<rev> was  the official way, I thought it's ~<series_number>.<rev>
<Laney> nahhhhh, go ahead and do it and ask for complaints after
<sil2100> Laney: since that's what the cloud team was doing for all their cloud backports ;p
<sil2100> Anyway, guess it's all bikesheding more or less
<sil2100> For me first thing is always consistency with other stable series and SRUs for the package, if that's the first time then I can be picky since I don't want a package to start some strange unofficial versioning scheme that'll have to be duplicated by all future series
<sil2100> That's why I, wrongly of course, rejected nautilus
<sil2100> My wrong
<Laney> I dunno if it's a backport in the nautilus case, haven't checked that one
-queuebot:#ubuntu-release- Unapproved: accepted mutter [source] (bionic-proposed) [3.28.3-2~ubuntu18.04.1]
<bdmurray> sil2100: I'm planning on releasing ubuntu-release-upgrader early. Any objections?
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-ubuntu-dock [sync] (bionic-proposed) [0.9.1ubuntu18.04.1]
<sil2100> bdmurray: no objections from my side, especially since it's bad without it anyway
<Trevinho> sil2100: thanks for SRUs
<Trevinho> sil2100: as for nautilus I can reupload it though a bileto sync, or wait seb to redo it..
<sil2100> Trevinho: yw! I'd also review and accept nautilus if I saw it in the queue again ;p
<Trevinho> sil2100: eh, I can't push that directly...
<sil2100> Trevinho: I could re-upload that, but not sure if that wouldn't get in the way of some tooling?
<sil2100> Trevinho: do you know if someone from the desktop team has to be the sponsor?
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (bionic-proposed) [2.02-2ubuntu8.3]
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (bionic-proposed) [1.93.4]
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.3 => 2.02-2ubuntu8.3] (core)
-queuebot:#ubuntu-release- New binary: cjson [amd64] (cosmic-proposed/universe) [1.7.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cjson [s390x] (cosmic-proposed/universe) [1.7.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fclib [s390x] (cosmic-proposed/universe) [3.0.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcdio-paranoia [ppc64el] (cosmic-proposed/main) [10.2+0.94+2-3] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libfprint [amd64] (cosmic-proposed/universe) [1:0.8.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cjson [ppc64el] (cosmic-proposed/universe) [1.7.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcdio-paranoia [i386] (cosmic-proposed/main) [10.2+0.94+2-3] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: fclib [ppc64el] (cosmic-proposed/universe) [3.0.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcdio-paranoia [s390x] (cosmic-proposed/main) [10.2+0.94+2-3] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: cjson [i386] (cosmic-proposed/universe) [1.7.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcdio-paranoia [arm64] (cosmic-proposed/main) [10.2+0.94+2-3] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: pyqt-qwt [s390x] (cosmic-proposed/universe) [1.00.00-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fclib [i386] (cosmic-proposed/universe) [3.0.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-diptest [amd64] (cosmic-proposed/universe) [0.75-7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcdio-paranoia [armhf] (cosmic-proposed/main) [10.2+0.94+2-3] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: fclib [amd64] (cosmic-proposed/universe) [3.0.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyqt5chart [s390x] (cosmic-proposed/universe) [5.10.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-base64url [amd64] (cosmic-proposed/universe) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyqt-qwt [ppc64el] (cosmic-proposed/universe) [1.00.00-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcdio-paranoia [amd64] (cosmic-proposed/main) [10.2+0.94+2-3] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: r-cran-base64url [ppc64el] (cosmic-proposed/universe) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-bridgesampling [amd64] (cosmic-proposed/universe) [0.4-0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-diptest [ppc64el] (cosmic-proposed/universe) [0.75-7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-webshot [amd64] (cosmic-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-zip [i386] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-zip [s390x] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyqt5chart [ppc64el] (cosmic-proposed/universe) [5.10.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-base64url [s390x] (cosmic-proposed/universe) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-diptest [s390x] (cosmic-proposed/universe) [0.75-7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-zip [ppc64el] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-base64url [i386] (cosmic-proposed/universe) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-zip [amd64] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-diptest [i386] (cosmic-proposed/universe) [0.75-7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mariadb-connector-java [amd64] (cosmic-proposed/universe) [2.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyqt5chart [i386] (cosmic-proposed/universe) [5.10.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyqt-qwt [amd64] (cosmic-proposed/universe) [1.00.00-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mckoisqldb [amd64] (cosmic-proposed/universe) [1.0.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: refmac-dictionary [amd64] (cosmic-proposed/universe) [5.41-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyqt-qwt [i386] (cosmic-proposed/universe) [1.00.00-1] (no packageset)
-queuebot:#ubuntu-release- New binary: toulbar2 [amd64] (cosmic-proposed/universe) [1.0.0+dfsg3-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.3 => 2.02-2ubuntu8.3] (core)
-queuebot:#ubuntu-release- New binary: pyqt5chart [amd64] (cosmic-proposed/universe) [5.10.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: toulbar2 [ppc64el] (cosmic-proposed/universe) [1.0.0+dfsg3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: toulbar2 [s390x] (cosmic-proposed/universe) [1.0.0+dfsg3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: toulbar2 [i386] (cosmic-proposed/universe) [1.0.0+dfsg3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cjson [arm64] (cosmic-proposed/universe) [1.7.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fclib [arm64] (cosmic-proposed/universe) [3.0.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cjson [armhf] (cosmic-proposed/universe) [1.7.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fclib [armhf] (cosmic-proposed/universe) [3.0.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-base64url [arm64] (cosmic-proposed/universe) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-base64url [armhf] (cosmic-proposed/universe) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyqt-qwt [arm64] (cosmic-proposed/universe) [1.00.00-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-diptest [armhf] (cosmic-proposed/universe) [0.75-7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-zip [armhf] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-diptest [arm64] (cosmic-proposed/universe) [0.75-7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-zip [arm64] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyqt-qwt [armhf] (cosmic-proposed/universe) [1.00.00-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyqt5chart [armhf] (cosmic-proposed/universe) [5.10.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyqt5chart [arm64] (cosmic-proposed/universe) [5.10.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: toulbar2 [armhf] (cosmic-proposed/universe) [1.0.0+dfsg3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: toulbar2 [arm64] (cosmic-proposed/universe) [1.0.0+dfsg3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted cjson [amd64] (cosmic-proposed) [1.7.5-1]
-queuebot:#ubuntu-release- New: accepted cjson [armhf] (cosmic-proposed) [1.7.5-1]
-queuebot:#ubuntu-release- New: accepted cjson [ppc64el] (cosmic-proposed) [1.7.5-1]
-queuebot:#ubuntu-release- New: accepted e-wrapper [amd64] (cosmic-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted fclib [arm64] (cosmic-proposed) [3.0.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted fclib [i386] (cosmic-proposed) [3.0.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted fclib [s390x] (cosmic-proposed) [3.0.0+dfsg-1]
-queuebot:#ubuntu-release- New binary: breezy [i386] (cosmic-proposed/universe) [3.0.0~bzr7065-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-dhcp4r [i386] (cosmic-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted cjson [arm64] (cosmic-proposed) [1.7.5-1]
-queuebot:#ubuntu-release- New: accepted cjson [s390x] (cosmic-proposed) [1.7.5-1]
-queuebot:#ubuntu-release- New: accepted fclib [armhf] (cosmic-proposed) [3.0.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted hibiscus [amd64] (cosmic-proposed) [2.8.1+dfsg-1]
-queuebot:#ubuntu-release- New binary: rust-dhcp4r [armhf] (cosmic-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted cjson [i386] (cosmic-proposed) [1.7.5-1]
-queuebot:#ubuntu-release- New: accepted fclib [ppc64el] (cosmic-proposed) [3.0.0+dfsg-1]
-queuebot:#ubuntu-release- New source: zvmcloudconnector (cosmic-proposed/primary) [1.2.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted fclib [amd64] (cosmic-proposed) [3.0.0+dfsg-1]
-queuebot:#ubuntu-release- New binary: heat [amd64] (cosmic-proposed/main) [1:11.0.0~rc1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted libcdio-paranoia [amd64] (cosmic-proposed) [10.2+0.94+2-3]
-queuebot:#ubuntu-release- New: accepted libcdio-paranoia [armhf] (cosmic-proposed) [10.2+0.94+2-3]
-queuebot:#ubuntu-release- New: accepted libcdio-paranoia [ppc64el] (cosmic-proposed) [10.2+0.94+2-3]
-queuebot:#ubuntu-release- New: accepted libfprint [amd64] (cosmic-proposed) [1:0.8.2-1]
-queuebot:#ubuntu-release- New: accepted mckoisqldb [amd64] (cosmic-proposed) [1.0.6-2]
-queuebot:#ubuntu-release- New: accepted pyqt-qwt [arm64] (cosmic-proposed) [1.00.00-1]
-queuebot:#ubuntu-release- New: accepted pyqt-qwt [i386] (cosmic-proposed) [1.00.00-1]
-queuebot:#ubuntu-release- New: accepted pyqt-qwt [s390x] (cosmic-proposed) [1.00.00-1]
-queuebot:#ubuntu-release- New: accepted libcdio-paranoia [arm64] (cosmic-proposed) [10.2+0.94+2-3]
-queuebot:#ubuntu-release- New: accepted libcdio-paranoia [s390x] (cosmic-proposed) [10.2+0.94+2-3]
-queuebot:#ubuntu-release- New: accepted pyqt-qwt [amd64] (cosmic-proposed) [1.00.00-1]
-queuebot:#ubuntu-release- New: accepted pyqt-qwt [ppc64el] (cosmic-proposed) [1.00.00-1]
-queuebot:#ubuntu-release- New: accepted pyqt5chart [arm64] (cosmic-proposed) [5.10.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-base64url [arm64] (cosmic-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted libcdio-paranoia [i386] (cosmic-proposed) [10.2+0.94+2-3]
-queuebot:#ubuntu-release- New: accepted pyqt-qwt [armhf] (cosmic-proposed) [1.00.00-1]
-queuebot:#ubuntu-release- New: accepted pyqt5chart [armhf] (cosmic-proposed) [5.10.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted pyqt5chart [ppc64el] (cosmic-proposed) [5.10.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-base64url [amd64] (cosmic-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted r-cran-base64url [i386] (cosmic-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted r-cran-base64url [s390x] (cosmic-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted mariadb-connector-java [amd64] (cosmic-proposed) [2.2.5-1]
-queuebot:#ubuntu-release- New: accepted pyqt5chart [i386] (cosmic-proposed) [5.10.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-base64url [armhf] (cosmic-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted pyqt5chart [amd64] (cosmic-proposed) [5.10.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-base64url [ppc64el] (cosmic-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted pyqt5chart [s390x] (cosmic-proposed) [5.10.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-bridgesampling [amd64] (cosmic-proposed) [0.4-0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-diptest [armhf] (cosmic-proposed) [0.75-7-1]
-queuebot:#ubuntu-release- New: accepted r-cran-diptest [arm64] (cosmic-proposed) [0.75-7-1]
-queuebot:#ubuntu-release- New: accepted r-cran-diptest [amd64] (cosmic-proposed) [0.75-7-1]
-queuebot:#ubuntu-release- New: accepted r-cran-diptest [ppc64el] (cosmic-proposed) [0.75-7-1]
-queuebot:#ubuntu-release- New: accepted r-cran-webshot [amd64] (cosmic-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-zip [arm64] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-zip [i386] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-zip [s390x] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-diptest [i386] (cosmic-proposed) [0.75-7-1]
-queuebot:#ubuntu-release- New: accepted r-cran-zip [amd64] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-zip [ppc64el] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-diptest [s390x] (cosmic-proposed) [0.75-7-1]
-queuebot:#ubuntu-release- New: accepted r-cran-zip [armhf] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted refmac-dictionary [amd64] (cosmic-proposed) [5.41-1]
-queuebot:#ubuntu-release- New binary: r-cran-batchtools [ppc64el] (cosmic-proposed/universe) [0.9.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-batchtools [s390x] (cosmic-proposed/universe) [0.9.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-batchtools [armhf] (cosmic-proposed/universe) [0.9.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-fpc [amd64] (cosmic-proposed/universe) [2.1-11.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-batchtools [i386] (cosmic-proposed/universe) [0.9.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-batchtools [amd64] (cosmic-proposed/universe) [0.9.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-batchtools [arm64] (cosmic-proposed/universe) [0.9.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libgenome [ppc64el] (cosmic-proposed/universe) [1.3.11+svn20110227.4616-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libgenome [s390x] (cosmic-proposed/universe) [1.3.11+svn20110227.4616-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libgenome [i386] (cosmic-proposed/universe) [1.3.11+svn20110227.4616-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libgenome [arm64] (cosmic-proposed/universe) [1.3.11+svn20110227.4616-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fwupd (cosmic-proposed/main) [1.1.0-7 => 1.1.1-1] (desktop-core)
-queuebot:#ubuntu-release- New binary: libgenome [amd64] (cosmic-proposed/universe) [1.3.11+svn20110227.4616-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libncl [s390x] (cosmic-proposed/universe) [2.1.21+git20171002.4becff7-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libgenome [armhf] (cosmic-proposed/universe) [1.3.11+svn20110227.4616-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fwupd (cosmic-proposed/main) [1.1.0-7 => 1.1.1-1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: fwupd (cosmic-proposed/main) [1.1.0-7 => 1.1.1-1] (desktop-core)
-queuebot:#ubuntu-release- New binary: libncl [ppc64el] (cosmic-proposed/universe) [2.1.21+git20171002.4becff7-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fwupd (cosmic-proposed/main) [1.1.0-7 => 1.1.1-1] (desktop-core)
-queuebot:#ubuntu-release- New binary: libncl [amd64] (cosmic-proposed/universe) [2.1.21+git20171002.4becff7-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libncl [i386] (cosmic-proposed/universe) [2.1.21+git20171002.4becff7-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libncl [armhf] (cosmic-proposed/universe) [2.1.21+git20171002.4becff7-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libncl [arm64] (cosmic-proposed/universe) [2.1.21+git20171002.4becff7-2] (no packageset)
#ubuntu-release 2018-08-14
-queuebot:#ubuntu-release- New: accepted libgenome [amd64] (cosmic-proposed) [1.3.11+svn20110227.4616-2]
-queuebot:#ubuntu-release- New: accepted libgenome [armhf] (cosmic-proposed) [1.3.11+svn20110227.4616-2]
-queuebot:#ubuntu-release- New: accepted libgenome [ppc64el] (cosmic-proposed) [1.3.11+svn20110227.4616-2]
-queuebot:#ubuntu-release- New: accepted libncl [amd64] (cosmic-proposed) [2.1.21+git20171002.4becff7-2]
-queuebot:#ubuntu-release- New: accepted libncl [armhf] (cosmic-proposed) [2.1.21+git20171002.4becff7-2]
-queuebot:#ubuntu-release- New: accepted libncl [ppc64el] (cosmic-proposed) [2.1.21+git20171002.4becff7-2]
-queuebot:#ubuntu-release- New: accepted libgenome [arm64] (cosmic-proposed) [1.3.11+svn20110227.4616-2]
-queuebot:#ubuntu-release- New: accepted libgenome [s390x] (cosmic-proposed) [1.3.11+svn20110227.4616-2]
-queuebot:#ubuntu-release- New: accepted libncl [i386] (cosmic-proposed) [2.1.21+git20171002.4becff7-2]
-queuebot:#ubuntu-release- New: accepted libgenome [i386] (cosmic-proposed) [1.3.11+svn20110227.4616-2]
-queuebot:#ubuntu-release- New: accepted libncl [s390x] (cosmic-proposed) [2.1.21+git20171002.4becff7-2]
-queuebot:#ubuntu-release- New: accepted libncl [arm64] (cosmic-proposed) [2.1.21+git20171002.4becff7-2]
-queuebot:#ubuntu-release- New: accepted r-cran-batchtools [amd64] (cosmic-proposed) [0.9.8-1]
-queuebot:#ubuntu-release- New: accepted r-cran-batchtools [armhf] (cosmic-proposed) [0.9.8-1]
-queuebot:#ubuntu-release- New: accepted r-cran-batchtools [ppc64el] (cosmic-proposed) [0.9.8-1]
-queuebot:#ubuntu-release- New: accepted toulbar2 [amd64] (cosmic-proposed) [1.0.0+dfsg3-1]
-queuebot:#ubuntu-release- New: accepted toulbar2 [armhf] (cosmic-proposed) [1.0.0+dfsg3-1]
-queuebot:#ubuntu-release- New: accepted toulbar2 [ppc64el] (cosmic-proposed) [1.0.0+dfsg3-1]
-queuebot:#ubuntu-release- New: accepted r-cran-batchtools [arm64] (cosmic-proposed) [0.9.8-1]
-queuebot:#ubuntu-release- New: accepted r-cran-batchtools [s390x] (cosmic-proposed) [0.9.8-1]
-queuebot:#ubuntu-release- New: accepted toulbar2 [i386] (cosmic-proposed) [1.0.0+dfsg3-1]
-queuebot:#ubuntu-release- New: accepted r-cran-batchtools [i386] (cosmic-proposed) [0.9.8-1]
-queuebot:#ubuntu-release- New: accepted toulbar2 [s390x] (cosmic-proposed) [1.0.0+dfsg3-1]
-queuebot:#ubuntu-release- New: accepted toulbar2 [arm64] (cosmic-proposed) [1.0.0+dfsg3-1]
-queuebot:#ubuntu-release- New: accepted qtspell [amd64] (cosmic-proposed) [0.8.4-1]
-queuebot:#ubuntu-release- New: accepted qtspell [armhf] (cosmic-proposed) [0.8.4-1]
-queuebot:#ubuntu-release- New: accepted qtspell [s390x] (cosmic-proposed) [0.8.4-1]
-queuebot:#ubuntu-release- New: accepted qtspell [arm64] (cosmic-proposed) [0.8.4-1]
-queuebot:#ubuntu-release- New: accepted qtspell [i386] (cosmic-proposed) [0.8.4-1]
-queuebot:#ubuntu-release- New: accepted breezy [amd64] (cosmic-proposed) [3.0.0~bzr7065-1]
-queuebot:#ubuntu-release- New: accepted breezy [armhf] (cosmic-proposed) [3.0.0~bzr7065-1]
-queuebot:#ubuntu-release- New: accepted dolfin [amd64] (cosmic-proposed) [2018.1.0.post1-7]
-queuebot:#ubuntu-release- New: accepted dolfin [i386] (cosmic-proposed) [2018.1.0.post1-7]
-queuebot:#ubuntu-release- New: accepted dolfin [s390x] (cosmic-proposed) [2018.1.0.post1-7]
-queuebot:#ubuntu-release- New: accepted breezy [arm64] (cosmic-proposed) [3.0.0~bzr7065-1]
-queuebot:#ubuntu-release- New: accepted dolfin [arm64] (cosmic-proposed) [2018.1.0.post1-7]
-queuebot:#ubuntu-release- New: accepted breezy [i386] (cosmic-proposed) [3.0.0~bzr7065-1]
-queuebot:#ubuntu-release- New: accepted dolfin [ppc64el] (cosmic-proposed) [2018.1.0.post1-7]
-queuebot:#ubuntu-release- New: accepted heat [amd64] (cosmic-proposed) [1:11.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted rust-dhcp4r [amd64] (cosmic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-dhcp4r [i386] (cosmic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-fpc [amd64] (cosmic-proposed) [2.1-11.1-1]
-queuebot:#ubuntu-release- New: accepted rust-dhcp4r [armhf] (cosmic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New binary: r-cran-dendextend [amd64] (cosmic-proposed/universe) [1.8.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cvc4 [i386] (cosmic-proposed/universe) [1.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: cvc4 [amd64] (cosmic-proposed/universe) [1.6-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted cvc4 [amd64] (cosmic-proposed) [1.6-2]
-queuebot:#ubuntu-release- New: accepted r-cran-dendextend [amd64] (cosmic-proposed) [1.8.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted cvc4 [i386] (cosmic-proposed) [1.6-2]
-queuebot:#ubuntu-release- New binary: libmems [s390x] (cosmic-proposed/universe) [1.6.0+4725-7] (no packageset)
-queuebot:#ubuntu-release- New binary: libmems [ppc64el] (cosmic-proposed/universe) [1.6.0+4725-7] (no packageset)
-queuebot:#ubuntu-release- New binary: libmems [amd64] (cosmic-proposed/universe) [1.6.0+4725-7] (no packageset)
-queuebot:#ubuntu-release- New binary: libmems [armhf] (cosmic-proposed/universe) [1.6.0+4725-7] (no packageset)
-queuebot:#ubuntu-release- New binary: libmems [i386] (cosmic-proposed/universe) [1.6.0+4725-7] (no packageset)
-queuebot:#ubuntu-release- New binary: libmems [arm64] (cosmic-proposed/universe) [1.6.0+4725-7] (no packageset)
<ginggs> would someone accept libmems binaries ^ please?
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (bionic-proposed) [2.02-2ubuntu8.3]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (bionic-proposed) [2.02-2ubuntu8.3]
-queuebot:#ubuntu-release- New: accepted libmems [amd64] (cosmic-proposed) [1.6.0+4725-7]
-queuebot:#ubuntu-release- New: accepted libmems [armhf] (cosmic-proposed) [1.6.0+4725-7]
-queuebot:#ubuntu-release- New: accepted libmems [ppc64el] (cosmic-proposed) [1.6.0+4725-7]
-queuebot:#ubuntu-release- New: accepted libmems [arm64] (cosmic-proposed) [1.6.0+4725-7]
-queuebot:#ubuntu-release- New: accepted libmems [s390x] (cosmic-proposed) [1.6.0+4725-7]
-queuebot:#ubuntu-release- New: accepted libmems [i386] (cosmic-proposed) [1.6.0+4725-7]
<ginggs> ta!
<apw> np
-queuebot:#ubuntu-release- New binary: r-cran-seriation [ppc64el] (cosmic-proposed/universe) [1.2-3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-seriation [s390x] (cosmic-proposed/universe) [1.2-3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-seriation [amd64] (cosmic-proposed/universe) [1.2-3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-seriation [arm64] (cosmic-proposed/universe) [1.2-3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-seriation [armhf] (cosmic-proposed/universe) [1.2-3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-seriation [i386] (cosmic-proposed/universe) [1.2-3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted r-cran-seriation [amd64] (cosmic-proposed) [1.2-3-1]
-queuebot:#ubuntu-release- New: accepted r-cran-seriation [armhf] (cosmic-proposed) [1.2-3-1]
-queuebot:#ubuntu-release- New: accepted r-cran-seriation [ppc64el] (cosmic-proposed) [1.2-3-1]
-queuebot:#ubuntu-release- New: accepted r-cran-seriation [arm64] (cosmic-proposed) [1.2-3-1]
-queuebot:#ubuntu-release- New: accepted r-cran-seriation [s390x] (cosmic-proposed) [1.2-3-1]
-queuebot:#ubuntu-release- New: accepted r-cran-seriation [i386] (cosmic-proposed) [1.2-3-1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [amd64] (cosmic-proposed) [1.1.0-7]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [armhf] (cosmic-proposed) [1.1.0-7]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [arm64] (cosmic-proposed) [1.1.0-7]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [i386] (cosmic-proposed) [1.1.0-7]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [amd64] (cosmic-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [armhf] (cosmic-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupdate [amd64] (cosmic-proposed) [12-3]
-queuebot:#ubuntu-release- Unapproved: accepted fwupdate [i386] (cosmic-proposed) [12-3]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [arm64] (cosmic-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupdate [arm64] (cosmic-proposed) [12-3]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [i386] (cosmic-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New binary: r-cran-units [amd64] (cosmic-proposed/universe) [0.6-0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-units [s390x] (cosmic-proposed/universe) [0.6-0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-units [ppc64el] (cosmic-proposed/universe) [0.6-0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-units [arm64] (cosmic-proposed/universe) [0.6-0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-units [armhf] (cosmic-proposed/universe) [0.6-0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-units [i386] (cosmic-proposed/universe) [0.6-0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted r-cran-units [amd64] (cosmic-proposed) [0.6-0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-units [armhf] (cosmic-proposed) [0.6-0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-units [ppc64el] (cosmic-proposed) [0.6-0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-units [arm64] (cosmic-proposed) [0.6-0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-units [s390x] (cosmic-proposed) [0.6-0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-units [i386] (cosmic-proposed) [0.6-0-1]
-queuebot:#ubuntu-release- New binary: r-cran-heatmaply [amd64] (cosmic-proposed/universe) [0.15.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted r-cran-heatmaply [amd64] (cosmic-proposed) [0.15.2+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: gdm3 (bionic-proposed/main) [3.28.2-0ubuntu1.4 => 3.28.2-0ubuntu1.5] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gpgme1.0 (bionic-proposed/main) [1.10.0-1ubuntu1 => 1.10.0-1ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: ayatana-ido [i386] (cosmic-proposed/universe) [0.4.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ayatana-ido [s390x] (cosmic-proposed/universe) [0.4.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ayatana-ido [ppc64el] (cosmic-proposed/universe) [0.4.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ayatana-ido [amd64] (cosmic-proposed/universe) [0.4.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ayatana-ido [arm64] (cosmic-proposed/universe) [0.4.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ayatana-ido [armhf] (cosmic-proposed/universe) [0.4.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mfcuk [ppc64el] (cosmic-proposed/universe) [0.3.8+git20180720-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mfoc [ppc64el] (cosmic-proposed/universe) [0.10.7+git20180724-1] (no packageset)
-queuebot:#ubuntu-release- New binary: skypat [s390x] (cosmic-proposed/universe) [3.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mfcuk [s390x] (cosmic-proposed/universe) [0.3.8+git20180720-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mfoc [s390x] (cosmic-proposed/universe) [0.10.7+git20180724-1] (no packageset)
-queuebot:#ubuntu-release- New binary: erlang-cf [ppc64el] (cosmic-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mfcuk [amd64] (cosmic-proposed/universe) [0.3.8+git20180720-1] (no packageset)
-queuebot:#ubuntu-release- New binary: umoci [s390x] (cosmic-proposed/universe) [0.4.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: usbtop [s390x] (cosmic-proposed/universe) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wmmisc [s390x] (cosmic-proposed/universe) [1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: erlang-cf [s390x] (cosmic-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: usbtop [ppc64el] (cosmic-proposed/universe) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: umoci [ppc64el] (cosmic-proposed/universe) [0.4.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wmmisc [ppc64el] (cosmic-proposed/universe) [1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: driverctl [amd64] (cosmic-proposed/universe) [0.95-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mfoc [amd64] (cosmic-proposed/universe) [0.10.7+git20180724-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-lzstring [amd64] (cosmic-proposed/universe) [1.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mfcuk [armhf] (cosmic-proposed/universe) [0.3.8+git20180720-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mfoc [i386] (cosmic-proposed/universe) [0.10.7+git20180724-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mfcuk [arm64] (cosmic-proposed/universe) [0.3.8+git20180720-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mfoc [arm64] (cosmic-proposed/universe) [0.10.7+git20180724-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-colormath [amd64] (cosmic-proposed/universe) [3.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: setuptools-scm-git-archive [amd64] (cosmic-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: usbtop [i386] (cosmic-proposed/universe) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mfcuk [i386] (cosmic-proposed/universe) [0.3.8+git20180720-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-openidc-client [amd64] (cosmic-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wmmisc [amd64] (cosmic-proposed/universe) [1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mfoc [armhf] (cosmic-proposed/universe) [0.10.7+git20180724-1] (no packageset)
-queuebot:#ubuntu-release- New binary: skypat [amd64] (cosmic-proposed/universe) [3.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: erlang-cf [amd64] (cosmic-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-crcelk [amd64] (cosmic-proposed/universe) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: skypat [arm64] (cosmic-proposed/universe) [3.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: umoci [armhf] (cosmic-proposed/universe) [0.4.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: usbtop [armhf] (cosmic-proposed/universe) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wmmisc [armhf] (cosmic-proposed/universe) [1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: erlang-cf [i386] (cosmic-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: umoci [amd64] (cosmic-proposed/universe) [0.4.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wmmisc [arm64] (cosmic-proposed/universe) [1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-motor [amd64] (cosmic-proposed/universe) [1.2.3-1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: usbtop [arm64] (cosmic-proposed/universe) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-tinycss2 [amd64] (cosmic-proposed/universe) [0.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: usbtop [amd64] (cosmic-proposed/universe) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: virtio-forwarder [i386] (cosmic-proposed/universe) [1.1.99.13-1~unstable] (no packageset)
-queuebot:#ubuntu-release- New binary: umoci [arm64] (cosmic-proposed/universe) [0.4.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: virtio-forwarder [amd64] (cosmic-proposed/universe) [1.1.99.13-1~unstable] (no packageset)
-queuebot:#ubuntu-release- New binary: wmmisc [i386] (cosmic-proposed/universe) [1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: erlang-cf [arm64] (cosmic-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: umoci [i386] (cosmic-proposed/universe) [0.4.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: erlang-cf [armhf] (cosmic-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-32.35] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [4.15.0-1021.21] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-32.35] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1015.18] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-32.35]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-32.35]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [4.15.0-1021.21]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1015.18]
-queuebot:#ubuntu-release- New: accepted erlang-cf [amd64] (cosmic-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted erlang-cf [armhf] (cosmic-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted erlang-cf [arm64] (cosmic-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted erlang-cf [i386] (cosmic-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted ayatana-ido [amd64] (cosmic-proposed) [0.4.4-1]
-queuebot:#ubuntu-release- New: accepted ayatana-ido [armhf] (cosmic-proposed) [0.4.4-1]
-queuebot:#ubuntu-release- New: accepted ayatana-ido [ppc64el] (cosmic-proposed) [0.4.4-1]
-queuebot:#ubuntu-release- New: accepted erlang-cf [ppc64el] (cosmic-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted ayatana-ido [arm64] (cosmic-proposed) [0.4.4-1]
-queuebot:#ubuntu-release- New: accepted ayatana-ido [s390x] (cosmic-proposed) [0.4.4-1]
-queuebot:#ubuntu-release- New: accepted ayatana-ido [i386] (cosmic-proposed) [0.4.4-1]
-queuebot:#ubuntu-release- New: accepted erlang-cf [s390x] (cosmic-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted python-colormath [amd64] (cosmic-proposed) [3.0.0-1]
-queuebot:#ubuntu-release- New: accepted python-lzstring [amd64] (cosmic-proposed) [1.0.4-1]
-queuebot:#ubuntu-release- New: accepted python-openidc-client [amd64] (cosmic-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted setuptools-scm-git-archive [amd64] (cosmic-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted python-crcelk [amd64] (cosmic-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted python-tinycss2 [amd64] (cosmic-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted python-motor [amd64] (cosmic-proposed) [1.2.3-1.1]
-queuebot:#ubuntu-release- New: accepted wmmisc [amd64] (cosmic-proposed) [1.2-1]
-queuebot:#ubuntu-release- New: accepted wmmisc [armhf] (cosmic-proposed) [1.2-1]
-queuebot:#ubuntu-release- New: accepted wmmisc [ppc64el] (cosmic-proposed) [1.2-1]
-queuebot:#ubuntu-release- New: accepted wmmisc [arm64] (cosmic-proposed) [1.2-1]
-queuebot:#ubuntu-release- New: accepted wmmisc [s390x] (cosmic-proposed) [1.2-1]
-queuebot:#ubuntu-release- New: accepted wmmisc [i386] (cosmic-proposed) [1.2-1]
-queuebot:#ubuntu-release- New: accepted umoci [amd64] (cosmic-proposed) [0.4.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted umoci [armhf] (cosmic-proposed) [0.4.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted umoci [ppc64el] (cosmic-proposed) [0.4.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted umoci [arm64] (cosmic-proposed) [0.4.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted umoci [s390x] (cosmic-proposed) [0.4.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted umoci [i386] (cosmic-proposed) [0.4.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted usbtop [amd64] (cosmic-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted usbtop [armhf] (cosmic-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted usbtop [ppc64el] (cosmic-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted usbtop [arm64] (cosmic-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted usbtop [s390x] (cosmic-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted usbtop [i386] (cosmic-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted skypat [amd64] (cosmic-proposed) [3.1.1-1]
-queuebot:#ubuntu-release- New: accepted skypat [s390x] (cosmic-proposed) [3.1.1-1]
-queuebot:#ubuntu-release- New: accepted skypat [arm64] (cosmic-proposed) [3.1.1-1]
-queuebot:#ubuntu-release- New: accepted mfcuk [amd64] (cosmic-proposed) [0.3.8+git20180720-1]
-queuebot:#ubuntu-release- New: accepted mfcuk [armhf] (cosmic-proposed) [0.3.8+git20180720-1]
-queuebot:#ubuntu-release- New: accepted mfcuk [ppc64el] (cosmic-proposed) [0.3.8+git20180720-1]
-queuebot:#ubuntu-release- New: accepted mfoc [amd64] (cosmic-proposed) [0.10.7+git20180724-1]
-queuebot:#ubuntu-release- New: accepted mfoc [armhf] (cosmic-proposed) [0.10.7+git20180724-1]
-queuebot:#ubuntu-release- New: accepted mfoc [ppc64el] (cosmic-proposed) [0.10.7+git20180724-1]
-queuebot:#ubuntu-release- New: accepted mfcuk [arm64] (cosmic-proposed) [0.3.8+git20180720-1]
-queuebot:#ubuntu-release- New: accepted mfcuk [s390x] (cosmic-proposed) [0.3.8+git20180720-1]
-queuebot:#ubuntu-release- New: accepted mfoc [i386] (cosmic-proposed) [0.10.7+git20180724-1]
-queuebot:#ubuntu-release- New: accepted mfcuk [i386] (cosmic-proposed) [0.3.8+git20180720-1]
-queuebot:#ubuntu-release- New: accepted mfoc [s390x] (cosmic-proposed) [0.10.7+git20180724-1]
-queuebot:#ubuntu-release- New: accepted mfoc [arm64] (cosmic-proposed) [0.10.7+git20180724-1]
-queuebot:#ubuntu-release- New: accepted driverctl [amd64] (cosmic-proposed) [0.95-1]
-queuebot:#ubuntu-release- New: accepted virtio-forwarder [i386] (cosmic-proposed) [1.1.99.13-1~unstable]
-queuebot:#ubuntu-release- New: accepted virtio-forwarder [amd64] (cosmic-proposed) [1.1.99.13-1~unstable]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-155.205] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-32.35~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1021.21~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-32.35~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-155.205]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-133.159] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-133.159]
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-133.159~14.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1021.21~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-32.35~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-32.35~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-133.159~14.04.1]
-queuebot:#ubuntu-release- New binary: python-cheroot [amd64] (cosmic-proposed/universe) [6.4.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-spectra [amd64] (cosmic-proposed/universe) [0.0.11-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected gnome-shell-extension-system-monitor [source] (bionic-proposed) [35-1ubuntu1~jdstrand1]
-queuebot:#ubuntu-release- New: accepted python-cheroot [amd64] (cosmic-proposed) [6.4.0+ds-1]
-queuebot:#ubuntu-release- New: accepted python-spectra [amd64] (cosmic-proposed) [0.0.11-1]
-queuebot:#ubuntu-release- New binary: python-httpsig [amd64] (cosmic-proposed/universe) [1.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: smrtanalysis [amd64] (cosmic-proposed/none) [0~20180814] (no packageset)
-queuebot:#ubuntu-release- New binary: libglvnd [ppc64el] (cosmic-proposed/main) [1.1.0-1] (core)
-queuebot:#ubuntu-release- New binary: libglvnd [s390x] (cosmic-proposed/main) [1.1.0-1] (core)
-queuebot:#ubuntu-release- New binary: libglvnd [amd64] (cosmic-proposed/main) [1.1.0-1] (core)
-queuebot:#ubuntu-release- New binary: libglvnd [i386] (cosmic-proposed/main) [1.1.0-1] (core)
-queuebot:#ubuntu-release- New binary: libglvnd [arm64] (cosmic-proposed/main) [1.1.0-1] (core)
-queuebot:#ubuntu-release- New binary: libglvnd [armhf] (cosmic-proposed/main) [1.1.0-1] (core)
#ubuntu-release 2018-08-15
-queuebot:#ubuntu-release- Unapproved: grub2 (trusty-proposed/main) [2.02~beta2-9ubuntu1.15 => 2.02~beta2-9ubuntu1.15] (core)
-queuebot:#ubuntu-release- Unapproved: nodejs (bionic-proposed/universe) [8.10.0~dfsg-2ubuntu0.2 => 8.10.0~dfsg-2ubuntu0.3] (kubuntu)
-queuebot:#ubuntu-release- New: accepted libglvnd [amd64] (cosmic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted libglvnd [armhf] (cosmic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted libglvnd [ppc64el] (cosmic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted python-httpsig [amd64] (cosmic-proposed) [1.2.0-2]
-queuebot:#ubuntu-release- New: accepted libglvnd [arm64] (cosmic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted libglvnd [s390x] (cosmic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted libglvnd [i386] (cosmic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted smrtanalysis [amd64] (cosmic-proposed) [0~20180814]
-queuebot:#ubuntu-release- New: rejected zvmcloudconnector [source] (cosmic-proposed) [1.2.3-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected vaultlocker [source] (cosmic-proposed) [1.0.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted fwupd-signed [source] (cosmic-proposed) [1.0]
-queuebot:#ubuntu-release- New: rejected jboss-annotations-1.2-api [source] (cosmic-proposed) [1.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: jboss-annotations-1.2-api [amd64] (cosmic-proposed/none) [1.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted jboss-annotations-1.2-api [amd64] (cosmic-proposed) [1.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libglvnd (bionic-proposed/main) [1.0.0-2ubuntu2.1 => 1.0.0-2ubuntu2.2] (core)
-queuebot:#ubuntu-release- New source: vaultlocker (cosmic-proposed/primary) [1.0.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: tkblt (bionic-proposed/universe) [3.2.7-1 => 3.2.7-1ubuntu1] (no packageset)
<tkamppeter> gutenprint is stuck in cosmic-proposed but it has already passed all the tests more than 24 hours ago. See http://people.canonical.com/~ubuntu-archive/proposed-migration/cosmic/update_excuses.html#gutenprint
<acheronuk> tkamppeter: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<acheronuk> trying: gutenprint
<acheronuk> skipped: gutenprint (21, 0, 12)
<acheronuk>     got: 16+0: a-3:a-2:a-4:i-3:p-2:s-2
<acheronuk>     * i386: photoprint
<acheronuk> so that is saying that migrating gutenprint to -release would break photoprint
<acheronuk> photoprint depends libgutenprint2 (>= 5.2.13), whereas in gutenprint in -proposed libgutenprint2 lib package no longer exists. so I guess you need to rebuild photoprint against new gutenprint
<tkamppeter> acheronuk thank you very much.
<acheronuk> tkamppeter: sadly looks like current photoprint will FTBFS on a rebuild: https://launchpad.net/~rikmills/+archive/ubuntu/cosmic/+sourcepub/9332953/+listing-archive-extra
<Laney> doko: any thoughts on removing transcode and the things which depend on it?
<Laney> none of them in debian, not maintained in ubuntu apart from people patching transcode when it breaks with new ffmpeg like it is doing now
<tkamppeter> acheronuk, I have found out this, too. For me it looks like that we should better remove it altogether, as its last release is from 2010, and I do not want to fix a stone-old package to unblock the progress on other packages.
<tkamppeter> acheronuk, can we simply remove this obsolete package?
<acheronuk> tkamppeter: up to archive admin (which I am not even close to). I would usually file a bug against the package as per: https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Removing_Packages
<acheronuk> maybe ping AAs in here if it needs sorting quickly
<tkamppeter> acheronuk, it needs to get fixed before Feature Freeze so that the new Gutenprint gets in.
<acheronuk> tkamppeter: for the purposes of Feature Freeze, being in -proposed counts as 'in', so you would not need a freeze exception for current version in proposed or bugfix updates to it
<tkamppeter> acheronuk, on https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Removing_Packages the paragraph "There is checkrdepends in ubuntu-archive-tools, but it needs a mirror to work with." can be removed, this utility and package do not exist any more.
<acheronuk> tkamppeter: never used that. usually I just do something like https://paste.ubuntu.com/p/K6HWkM2GxM/
<acheronuk> tkamppeter: checkrdepends is still in https://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/files , but as said not very easy to use for normal people!
<tkamppeter> acheronuk: https://bugs.launchpad.net/ubuntu/+source/photoprint/+bug/1787146
<ubot5> Ubuntu bug 1787146 in photoprint (Ubuntu) "[PLEASE REMOVE] PhotoPrint is not maintained any more and blocks Gutenprint update" [High,New]
<tkamppeter> acheronuk, did I do this correctly or is there still anything missing?
<acheronuk> tkamppeter: seems ok to me. since it's not removed in debian yet, AAs might conceivably want to demote to proposed rather than remove completely, but that would still let gutenprint though. would be flogging a dead horse IMO though
<acheronuk> apw Laney: if you have a sec, does that look reasonable?
<tkamppeter> Yes.
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.6 => 2.525.7] (desktop-core)
<apw> tkamppeter, i've demoted it to -proposed in the first instance; your reasons for removal seem reaosnable but just don't have time to think on it properly
<Laney> Probably a block-proposed tag on that bug would be a good idea
 * Laney added
-queuebot:#ubuntu-release- Unapproved: accepted appstream-glib [source] (xenial-proposed) [0.5.13-1ubuntu6]
-queuebot:#ubuntu-release- New binary: verbiste [s390x] (cosmic-proposed/universe) [0.1.45-3] (no packageset)
-queuebot:#ubuntu-release- New binary: verbiste [ppc64el] (cosmic-proposed/universe) [0.1.45-3] (no packageset)
-queuebot:#ubuntu-release- New binary: verbiste [amd64] (cosmic-proposed/universe) [0.1.45-3] (no packageset)
-queuebot:#ubuntu-release- New binary: verbiste [armhf] (cosmic-proposed/universe) [0.1.45-3] (no packageset)
-queuebot:#ubuntu-release- New binary: verbiste [arm64] (cosmic-proposed/universe) [0.1.45-3] (no packageset)
-queuebot:#ubuntu-release- New binary: verbiste [i386] (cosmic-proposed/universe) [0.1.45-3] (no packageset)
<Laney> ah, emacs25 is replaced with emacs, that explains the upload failures
<Laney> and of course emacs is blocked :<
<tkamppeter> acheronuk, apw, Laney: Thank you very much. Gutenprint has advanced to the release now.
<acheronuk> tkamppeter: :) your are welcome
<acheronuk> *you
-queuebot:#ubuntu-release- Unapproved: evince (bionic-proposed/main) [3.28.2-1 => 3.29.91-1ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rejected samba [source] (trusty-proposed) [2:4.3.11+dfsg-0ubuntu0.14.04.15]
-queuebot:#ubuntu-release- Unapproved: rejected samba [source] (xenial-proposed) [2:4.3.11+dfsg-0ubuntu0.16.04.14]
<jbicha> please reject evince
-queuebot:#ubuntu-release- Unapproved: rejected evince [source] (bionic-proposed) [3.29.91-1ubuntu2]
<apw> jbicha, ^ ... wrong series ?
<jbicha> yes, thanks :)
<jbicha> I installed cosmic's devscripts now so "dch -r" does what I expect
-queuebot:#ubuntu-release- New binary: fwupd-signed [amd64] (cosmic-proposed/universe) [1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: fwupd-signed [armhf] (cosmic-proposed/universe) [1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: fwupd-signed [arm64] (cosmic-proposed/universe) [1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: fwupd-signed [i386] (cosmic-proposed/universe) [1.1] (no packageset)
<doko> Laney: could you have a look at gcc-6 triggered by binutils? still marked as running ...
<Laney> doko: ok, swap you for my earlier question?
<doko> and just ignore it
<doko> Laney: what to dou want to swap for the brotli fix?
<doko> yes, I'll look
-queuebot:#ubuntu-release- New: accepted fwupd-signed [amd64] (cosmic-proposed) [1.1]
-queuebot:#ubuntu-release- New: accepted fwupd-signed [armhf] (cosmic-proposed) [1.1]
-queuebot:#ubuntu-release- New: accepted vaultlocker [source] (cosmic-proposed) [1.0.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted verbiste [arm64] (cosmic-proposed) [0.1.45-3]
-queuebot:#ubuntu-release- New: accepted verbiste [i386] (cosmic-proposed) [0.1.45-3]
-queuebot:#ubuntu-release- New: accepted verbiste [s390x] (cosmic-proposed) [0.1.45-3]
-queuebot:#ubuntu-release- New: accepted fwupd-signed [arm64] (cosmic-proposed) [1.1]
-queuebot:#ubuntu-release- New: accepted verbiste [amd64] (cosmic-proposed) [0.1.45-3]
-queuebot:#ubuntu-release- New: accepted verbiste [ppc64el] (cosmic-proposed) [0.1.45-3]
-queuebot:#ubuntu-release- New: accepted fwupd-signed [i386] (cosmic-proposed) [1.1]
-queuebot:#ubuntu-release- New: accepted verbiste [armhf] (cosmic-proposed) [0.1.45-3]
<doko> Laney: transcode, needs a bug report, subscribing ubuntu-archive, and checking for all rdepends
<doko> I'm all for removing non-maintained stuff
<Laney> ok, I wanted to know if it was an option
<Laney> thx
 * doko looks around for other archive admins ...
<doko> ok, agreed =)
 * apw looks up
<Laney> it's a trap
 * apw runs for the hills in his 7 league boots
-queuebot:#ubuntu-release- New binary: vaultlocker [amd64] (cosmic-proposed/none) [1.0.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted vaultlocker [amd64] (cosmic-proposed) [1.0.3-0ubuntu1]
<doko> Laney: emacs was a trap too, needs two MIRs =)
<doko> isn't emacs25 obsolete by now?
-queuebot:#ubuntu-release- Unapproved: samba (trusty-proposed/main) [2:4.3.11+dfsg-0ubuntu0.14.04.16 => 2:4.3.11+dfsg-0ubuntu0.14.04.17] (core)
-queuebot:#ubuntu-release- Unapproved: samba (xenial-proposed/main) [2:4.3.11+dfsg-0ubuntu0.16.04.15 => 2:4.3.11+dfsg-0ubuntu0.16.04.16] (core)
<Laney> should be once emacs can migrate
-queuebot:#ubuntu-release- Unapproved: maas (bionic-proposed/main) [2.4.0-6981-g011e51b7a-0ubuntu1~18.04.1 => 2.4.1-7032-g11e4fa330-0ubuntu1~18.04.1] (ubuntu-server)
<Laney> this is weird, I don't see the request for gcc-6/amd64
 * Laney checks britney log
<Laney> no error there...
<Laney> ...
<Laney> resubmitted
<Laney> doko: https://bugs.launchpad.net/ubuntu/+source/subtitleripper/+bug/1787222
<ubot5> Ubuntu bug 1787222 in transcode (Ubuntu) "Remove transcode and friends from cosmic" [Undecided,Confirmed]
<Laney> going to upload to drop those recommends now
<Laney> laney@bionic (master|â)> head -1 debian/changelog                                                      ~/temp/k3b
<Laney> k3b (2.0.2-6ubuntu1) raring-proposed; urgency=low
<Laney> ...
<Laney> guess they're not using that vcs :-)
<Laney> although xjadeo has that in Debian too: should I add a delta to drop it or file a bug there and leave it?
<Laney> doko: what are the MIRs you are after for emacs?
<Laney> I can see that nox and gtk are in universe but they're built from the emacs source
<acheronuk> Laney: thanks for doing k3b.
<Laney> Nae bother
<Laney> This transition is edging along but there's still a fair bit of work to do
<acheronuk> Laney: I have KDEPIM and KDE framework uploads that I have basically been sitting on waiting for the Qt transition, since some packages depend on Qtbase/Qtdeclarative ABI. I assume that heaven forbid, should we cross over to feature freeze without this done, those uploads will be treated kindly for a FFE (they are well tested).
<acheronuk> I assume they would. I guess this is more of a FYI that they are sitting there waiting, than anything else :)
<Laney> We usually give flavours a decent degree of freedom over their own packages anyway
<acheronuk> Laney: thanks. I guess I'm just seeking reassurance, as this release seem like I've done not much apart from waiting on Qt, and uploads I have done recently have all got wedged in proposed
<apw> juliank, you appear to have disabled libnewt0.52-udeb in src:newt ... what was that about ?
<apw> that seems to have broken debian-installer
<juliank> apw: Did not want to introduce a new udeb we don't need
<juliank> There was some transition in d-i upstream
<apw> hmmm, it seems that d-i needs it already
<juliank> Well, it was not there before, so I did not turn it on
<apw> u wi
<apw> i wonder why d-i suddenly knows about it ...
<juliank> If it's needed now, feel free to enable it
<apw> juliank, will do, thanks
<Laney> apw: do you fancy looking at https://bugs.launchpad.net/ubuntu/+source/gmerlin-encoders/+bug/1787239 ?
<ubot5> Ubuntu bug 1787239 in gmerlin-encoders (Ubuntu) "Kick gmerlin-encoders out to proposed" [Undecided,Confirmed]
 * Laney isn't up for fixing all this broken sort of unmaintained stuff
<apw> cirtainly that sounds like -proposed material to me
<Laney> thx
<Laney> so many broken things
<Laney> sometimes you find one fix which makes a load of stuff go installable
<Laney> but I didn't manage to do that sofar
<apw> Laney, done
<Laney> mwah
<doko> Laney: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg xaw3d xutils-dev
-queuebot:#ubuntu-release- Unapproved: rejected catfish [source] (bionic-proposed) [1.4.6-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New binary: newt [s390x] (cosmic-proposed/main) [0.52.20-4ubuntu3] (core)
<superman1> I just upgraded from 16.04 to 18.04 and I was seeing lightdm fail to load and purple screen hang. I went to ctrl+alt+f2 and did a reinstall of lightdm. This brought me to login screen. But now I have no "network". ifconfig only returns the loopback interface.
<superman1> Any suggestions?
-queuebot:#ubuntu-release- New binary: newt [amd64] (cosmic-proposed/main) [0.52.20-4ubuntu3] (core)
-queuebot:#ubuntu-release- New binary: newt [ppc64el] (cosmic-proposed/main) [0.52.20-4ubuntu3] (core)
<superman1> I am also stuck at login loop on the Alt-f1
<superman1> I upgraded using do-release-upgrade.
<Laney> superman1: This isn't a support channel - try #ubuntu please
<Laney> doko: oh ://////////
<superman1> Laney: okies. thanks.
-queuebot:#ubuntu-release- New binary: newt [armhf] (cosmic-proposed/main) [0.52.20-4ubuntu3] (core)
-queuebot:#ubuntu-release- New binary: newt [i386] (cosmic-proposed/main) [0.52.20-4ubuntu3] (core)
-queuebot:#ubuntu-release- New: accepted newt [amd64] (cosmic-proposed) [0.52.20-4ubuntu3]
-queuebot:#ubuntu-release- New: accepted newt [i386] (cosmic-proposed) [0.52.20-4ubuntu3]
-queuebot:#ubuntu-release- New: accepted newt [s390x] (cosmic-proposed) [0.52.20-4ubuntu3]
-queuebot:#ubuntu-release- New: accepted newt [armhf] (cosmic-proposed) [0.52.20-4ubuntu3]
-queuebot:#ubuntu-release- New binary: newt [arm64] (cosmic-proposed/main) [0.52.20-4ubuntu3] (core)
-queuebot:#ubuntu-release- New: accepted newt [ppc64el] (cosmic-proposed) [0.52.20-4ubuntu3]
-queuebot:#ubuntu-release- New: accepted newt [arm64] (cosmic-proposed) [0.52.20-4ubuntu3]
<Laney> doko: wait, is that because it chose emacs-lucid to satisfy the alternate dep?
<superm1> hi can an AA remove and block these from syncing https://launchpad.net/ubuntu/+source/fwupdate-amd64-signed https://launchpad.net/ubuntu/+source/fwupdate-arm64-signed https://launchpad.net/ubuntu/+source/fwupdate-i386-signed ? They're causing problems with https://launchpad.net/ubuntu/+source/fwupdate-signed/1.20
<slangasek> superm1: hi!  I had noticed things going on there and wanted to ask why both fwupd and fwupdate are now producing artifacts for EFI signing
<slangasek> maybe that's all resolved now and we only need to handle the -signed packages now
<superm1> slangasek, i sent some mail to sil2100 to explain it all
<superm1> but i guess that didn't float around to everyone that needs to know
<slangasek> yes, emailing an individual has that effect :)
<superm1> heh. so basically starting with fwupd 1.1.0 the library and EFI binaries were subsumed into the fwupd project
<superm1> they are installed dynamically at runtime now
<superm1> lots of various reasons for this, but the general expectation is that due to this change less bugs, better control on the process, easier to support problems
<superm1> the fwupdate project still exists and can be treated as a simple reference implementation of EFI firmware updates if you don't care about all the other stuff
<superm1> in my mind fwupdate and fwupdate-signed should move to universe in cosmic
<slangasek> superm1: http://archive.ubuntu.com/ubuntu/dists/cosmic-proposed/main/uefi/fwupdate-amd64/current/fwupx64.efi.signed http://archive.ubuntu.com/ubuntu/dists/cosmic-proposed/main/uefi/fwupd-amd64/1.1.1-1/fwupdx64.efi.signed why are there two of these?
<superm1> see above two comments
<slangasek> so
<superm1> I unseeded fwupdate for this purpose on the next meta upload: https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/commit/?id=e44246ad2a65dacc3e816715d0df7bd86cd9a2ac
<slangasek> we shouldn't be signing two streams of EFI binaries
<slangasek> we shouldn't be signing something that's just a "reference implementation"
<cyphermox> moo?
<superm1> Moo
<slangasek> and it's regrettable if sil2100 accepted these for signing on the basis of your conversation
<slangasek> we should instead drop the signing request bits from the package
<superm1> Debian is still going to sign both of them
<slangasek> I'm not responsible for Debian's EFI keys :)
<superm1> and let folks decide if they want to use one or the other
<cyphermox> oh my
<superm1> Sledge told me that infinity and cjwatson had interest in Debian's EFI signing system as well and are going to look into it.  If Ubuntu adopts something akin to it it will be more difficult to drop the signed bits only from Ubuntu for fwupdate
<slangasek> sorry, if Ubuntu adopts something akin to what?
<superm1> the signing process for EFI binaries
<slangasek> ok
<superm1> right now what happens in Debian is that template packages are created and go itno the archive as binary packages
<slangasek> so, regardless, my expectation is that the set of objects signed with the EFI key will be gated on archive admin signoff
<superm1> a signing service runs and installs these template packages and produces new source packages "with the signed" binary
<superm1> and those source packages are uploaded to the archive
<superm1> so yes I would expect the gate to be on accepting "those" source packages
-queuebot:#ubuntu-release- New binary: docker [amd64] (cosmic-proposed/universe) [1.5-1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: duktape [s390x] (cosmic-proposed/universe) [2.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: duktape [amd64] (cosmic-proposed/universe) [2.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: duktape [ppc64el] (cosmic-proposed/universe) [2.3.0-1] (no packageset)
<superm1> slangasek, the other thing i'm worried about with demoting fwupdate to universe and dropping fwupdate-signed is I have no idea what that does to ubuntu core guys
<superm1> if they still use it for generating images or what
<superm1> it's in the "system-image" seed and I suspect they have an expectation that they get the EFI binary installed as part of "core" and not at runtime
-queuebot:#ubuntu-release- New binary: duktape [arm64] (cosmic-proposed/universe) [2.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: duktape [i386] (cosmic-proposed/universe) [2.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: duktape [armhf] (cosmic-proposed/universe) [2.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: git-sizer [s390x] (cosmic-proposed/universe) [1.2.0+dfsg-1] (no packageset)
<cjwatson> superm1: It's not likely to happen any time soon
-queuebot:#ubuntu-release- New binary: eclipse-debian-helper [amd64] (cosmic-proposed/universe) [1.0] (no packageset)
-queuebot:#ubuntu-release- New binary: minetest-mod-lucky-block [amd64] (cosmic-proposed/universe) [0.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: git-sizer [ppc64el] (cosmic-proposed/universe) [1.2.0+dfsg-1] (no packageset)
<cjwatson> Any such change would be distinctly non-trivial
-queuebot:#ubuntu-release- New binary: git-sizer [amd64] (cosmic-proposed/universe) [1.2.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: minetest-mod-unified-inventory [amd64] (cosmic-proposed/universe) [20180704-1] (no packageset)
-queuebot:#ubuntu-release- New binary: minetest-mod-protector [amd64] (cosmic-proposed/universe) [2.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: drms [amd64] (cosmic-proposed/universe) [0.5.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-numpysane [amd64] (cosmic-proposed/universe) [0.15-1] (no packageset)
-queuebot:#ubuntu-release- New binary: git-sizer [i386] (cosmic-proposed/universe) [1.2.0+dfsg-1] (no packageset)
<superm1> cjwatson, OK thanks, I sorta expected that
<cjwatson> There are pros and cons; it may be worth it for the sake of being in sync, and I can see the advantages
<cjwatson> Particularly reducing the number of round-trips for updates
-queuebot:#ubuntu-release- New binary: iraf-mscred [ppc64el] (cosmic-proposed/universe) [5.05+2018.07.09-1] (no packageset)
-queuebot:#ubuntu-release- New binary: iraf-sptable [i386] (cosmic-proposed/universe) [1.0~pre20180612-1] (no packageset)
-queuebot:#ubuntu-release- New binary: iraf-sptable [amd64] (cosmic-proposed/universe) [1.0~pre20180612-1] (no packageset)
-queuebot:#ubuntu-release- New binary: iraf-sptable [ppc64el] (cosmic-proposed/universe) [1.0~pre20180612-1] (no packageset)
<cjwatson> But it doesn't make it an easy change to implement :)
<superm1> yeah from a package maintainer perspective it's nice to not have to update a separate signed -source package
<cjwatson> And it's hard to justify spending time on it when it just streamlines things a bit rather than enabling new functionality
-queuebot:#ubuntu-release- New binary: iraf-mscred [amd64] (cosmic-proposed/universe) [5.05+2018.07.09-1] (no packageset)
<superm1> I think Debian is still working out kinks with their system anyway, it doesn't run automatically just yet
<cjwatson> Indeed
-queuebot:#ubuntu-release- New binary: git-sizer [arm64] (cosmic-proposed/universe) [1.2.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: iraf-mscred [i386] (cosmic-proposed/universe) [5.05+2018.07.09-1] (no packageset)
<cjwatson> In a Launchpad context it would involve dispatching subsidiary builds, I think
<cjwatson> Which is ... complex
<superm1> I see
<cjwatson> I kind of know what sort of general shape I'd like it to be but haven't worked out the data model
<cjwatson> What we definitely *can't* do is construct debs somewhere other than on builders
<superm1> I think even in their model the debs would be constructed on builders
<cjwatson> Yeah, I haven't seen how the dispatch works there ...
-queuebot:#ubuntu-release- New binary: git-sizer [armhf] (cosmic-proposed/universe) [1.2.0+dfsg-1] (no packageset)
<superm1> their model generates source packages that get uploaded
<cjwatson> Right, what I haven't worked out is how those get injected
<cjwatson> And whether there's any DB link between those and the unsigned versions
<cjwatson> I'd kind of rather construct the source packages on builders too
<cjwatson> Like recipes
<cjwatson> That means we get to use tools appropriate to the target series to build the source package, rather than having to either do it by hand or have interesting dependencies on the Ubuntu release that Launchpad happens to run on
<cjwatson> (ICBW but I suspect that Debian is taking something equivalent to the latter approach)
<cjwatson> Recipes have some pretty weird DB modelling though
-queuebot:#ubuntu-release- New binary: iraf-sptable [arm64] (cosmic-proposed/universe) [1.0~pre20180612-1] (no packageset)
<cjwatson> Anyway, that's as far as I've got
<superm1> building the source package outside of a builder is actually quite challenging from the debian side today
<superm1> if it fails to build you have no idea why
-queuebot:#ubuntu-release- New binary: iraf-mscred [armhf] (cosmic-proposed/universe) [5.05+2018.07.09-1] (no packageset)
<superm1> so if you deviated from the "template" used by another signed package a little bit or have a minor typographical error you can't really debug
-queuebot:#ubuntu-release- New binary: iraf-mscred [arm64] (cosmic-proposed/universe) [5.05+2018.07.09-1] (no packageset)
-queuebot:#ubuntu-release- New binary: iraf-sptable [armhf] (cosmic-proposed/universe) [1.0~pre20180612-1] (no packageset)
<superm1> so back on the initial question around fwupdate/fwupdate-signed and what to do with them.  I'll file a bug with this conversation and subscribe ubuntu-archive and whoever is the right person from ubuntu-core that can commment what ripping fwupdate and fwupdate-signed out of system-image does.  slangasek any idea who from core can speak to that?
<cjwatson> https://salsa.debian.org/ftp-team/code-signing/blob/master/secure-boot-code-sign.py is the relevant thing in Debian; definitely looks like that's just going to run with (I assume) stable's dpkg-dev
<cjwatson> which I guess isn't awful since dpkg-dev is pretty stable, but I'd hope not to have to install it on LP systems
<cjwatson> we'd need an isolated signing service in the same way
<superm1> the other dimension I didn't mention is that there may be a need for backporting either fwupdate 12 or fwupd 1.1.1 back to bionic due to https://bugs.launchpad.net/ubuntu/+source/fwupdate/+bug/1785165  I guess i'll add that to the bug for discussion too
<ubot5> Ubuntu bug 1785165 in fwupdate-signed (Ubuntu) "firmware update on fwupdate version 10-3 not work on some AMI's firmwares" [Undecided,New]
<slangasek> superm1: I would have to check what's done with fwupdate in Ubuntu Core, but snaps are not necessarily built from the devel series and core snaps in particular are only built from LTSes.  So any change that's appropriate to make here in terms of preferred EFI implementation for Ubuntu classic should also be tracked by Ubuntu Core in the next major series, and would not affect builds of the
<slangasek> current series.
<superm1> I guess this is now a bigger problem then for them that snaps probably can't put binaries into the ESP directly
<superm1> and they'll have to sort that in snapd by the next LTS?
<slangasek> quite possibly
<slangasek> do the two executables (fwupx64.efi, fwupdx64.efi) provide the same interface?  Do they get installed to the same well known location on the ESP?
<superm1> they purposefully use a different EFI NVRAM variable to communicate information
<superm1> and both get installed into respective binary names (fwupx64.efi or fwupdx64.efi)
<superm1> to allow both implementations to be installed side by side
<slangasek> well, that does make a transition more complicated
<superm1> depends on which lens you look at it from.  it allows the contents of the NVRAM interface variable to change in incompatible ways in the future
<slangasek> fwiw I can't find anything in snapd source code that installs fwupx64.efi to the ESP, and I know I haven't seen this in the gadget snaps
<slangasek> superm1: anyway, when you file that bug, please subscribe me directly as well, and for the ubuntu-core side I think I'd start with ~chipaca
<superm1> OK thanks, will do
<superm1> OK bug 1787254
<ubot5> bug 1787254 in fwupdate-signed (Ubuntu) "Possibly demote fwupdate to universe?" [Undecided,New] https://launchpad.net/bugs/1787254
<slangasek> superm1: ah, and wrt your original request to remove+blacklist fwupdate-{amd64,i386,arm64}-signed, please file a bug for this as well so there's an audit trail
-queuebot:#ubuntu-release- New: accepted drms [amd64] (cosmic-proposed) [0.5.5-1]
-queuebot:#ubuntu-release- New: accepted git-sizer [armhf] (cosmic-proposed) [1.2.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted iraf-mscred [amd64] (cosmic-proposed) [5.05+2018.07.09-1]
-queuebot:#ubuntu-release- New: accepted iraf-mscred [armhf] (cosmic-proposed) [5.05+2018.07.09-1]
-queuebot:#ubuntu-release- New: accepted iraf-mscred [ppc64el] (cosmic-proposed) [5.05+2018.07.09-1]
-queuebot:#ubuntu-release- New: accepted iraf-sptable [arm64] (cosmic-proposed) [1.0~pre20180612-1]
-queuebot:#ubuntu-release- New: accepted iraf-sptable [i386] (cosmic-proposed) [1.0~pre20180612-1]
-queuebot:#ubuntu-release- New: accepted minetest-mod-protector [amd64] (cosmic-proposed) [2.6-1]
-queuebot:#ubuntu-release- New: accepted python-numpysane [amd64] (cosmic-proposed) [0.15-1]
-queuebot:#ubuntu-release- New: accepted git-sizer [arm64] (cosmic-proposed) [1.2.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted iraf-mscred [arm64] (cosmic-proposed) [5.05+2018.07.09-1]
-queuebot:#ubuntu-release- New: accepted iraf-sptable [amd64] (cosmic-proposed) [1.0~pre20180612-1]
-queuebot:#ubuntu-release- New: accepted iraf-sptable [ppc64el] (cosmic-proposed) [1.0~pre20180612-1]
-queuebot:#ubuntu-release- New: accepted git-sizer [i386] (cosmic-proposed) [1.2.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted iraf-sptable [armhf] (cosmic-proposed) [1.0~pre20180612-1]
-queuebot:#ubuntu-release- New: accepted iraf-mscred [i386] (cosmic-proposed) [5.05+2018.07.09-1]
-queuebot:#ubuntu-release- New: accepted minetest-mod-unified-inventory [amd64] (cosmic-proposed) [20180704-1]
-queuebot:#ubuntu-release- New: accepted docker [amd64] (cosmic-proposed) [1.5-1.1]
-queuebot:#ubuntu-release- New: accepted duktape [arm64] (cosmic-proposed) [2.3.0-1]
-queuebot:#ubuntu-release- New: accepted duktape [i386] (cosmic-proposed) [2.3.0-1]
-queuebot:#ubuntu-release- New: accepted duktape [s390x] (cosmic-proposed) [2.3.0-1]
-queuebot:#ubuntu-release- New: accepted git-sizer [amd64] (cosmic-proposed) [1.2.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted git-sizer [s390x] (cosmic-proposed) [1.2.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted duktape [amd64] (cosmic-proposed) [2.3.0-1]
-queuebot:#ubuntu-release- New: accepted duktape [ppc64el] (cosmic-proposed) [2.3.0-1]
-queuebot:#ubuntu-release- New: accepted git-sizer [ppc64el] (cosmic-proposed) [1.2.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted duktape [armhf] (cosmic-proposed) [2.3.0-1]
-queuebot:#ubuntu-release- New: accepted minetest-mod-lucky-block [amd64] (cosmic-proposed) [0.8-1]
-queuebot:#ubuntu-release- New: accepted eclipse-debian-helper [amd64] (cosmic-proposed) [1.0]
-queuebot:#ubuntu-release- New binary: rustc [s390x] (cosmic-proposed/universe) [1.28.0+dfsg1+llvm-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [ppc64el] (cosmic-proposed/universe) [1.28.0+dfsg1+llvm-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: equinox-bundles [amd64] (cosmic-proposed/universe) [4.7.3-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-drivers-common [source] (bionic-proposed) [1:0.5.2.1]
-queuebot:#ubuntu-release- New binary: rustc [arm64] (cosmic-proposed/universe) [1.28.0+dfsg1+llvm-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [armhf] (cosmic-proposed/universe) [1.28.0+dfsg1+llvm-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [amd64] (cosmic-proposed/universe) [1.28.0+dfsg1+llvm-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: iraf-fitsutil [amd64] (cosmic-proposed/universe) [2018.07.06-2] (no packageset)
-queuebot:#ubuntu-release- New binary: iraf-fitsutil [ppc64el] (cosmic-proposed/universe) [2018.07.06-2] (no packageset)
-queuebot:#ubuntu-release- New binary: iraf-fitsutil [i386] (cosmic-proposed/universe) [2018.07.06-2] (no packageset)
-queuebot:#ubuntu-release- New binary: iraf-fitsutil [arm64] (cosmic-proposed/universe) [2018.07.06-2] (no packageset)
-queuebot:#ubuntu-release- New binary: iraf-fitsutil [armhf] (cosmic-proposed/universe) [2018.07.06-2] (no packageset)
#ubuntu-release 2018-08-16
-queuebot:#ubuntu-release- New binary: rustc [i386] (cosmic-proposed/universe) [1.28.0+dfsg1+llvm-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New source: zvmcloudconnector (cosmic-proposed/primary) [1.2.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted equinox-bundles [amd64] (cosmic-proposed) [4.7.3-1]
-queuebot:#ubuntu-release- New: accepted iraf-fitsutil [amd64] (cosmic-proposed) [2018.07.06-2]
-queuebot:#ubuntu-release- New: accepted iraf-fitsutil [armhf] (cosmic-proposed) [2018.07.06-2]
-queuebot:#ubuntu-release- New: accepted iraf-fitsutil [ppc64el] (cosmic-proposed) [2018.07.06-2]
-queuebot:#ubuntu-release- New: accepted iraf-fitsutil [arm64] (cosmic-proposed) [2018.07.06-2]
-queuebot:#ubuntu-release- New: accepted iraf-fitsutil [i386] (cosmic-proposed) [2018.07.06-2]
-queuebot:#ubuntu-release- New: accepted rustc [amd64] (cosmic-proposed) [1.28.0+dfsg1+llvm-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [armhf] (cosmic-proposed) [1.28.0+dfsg1+llvm-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [ppc64el] (cosmic-proposed) [1.28.0+dfsg1+llvm-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [arm64] (cosmic-proposed) [1.28.0+dfsg1+llvm-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [s390x] (cosmic-proposed) [1.28.0+dfsg1+llvm-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [i386] (cosmic-proposed) [1.28.0+dfsg1+llvm-0ubuntu1]
-queuebot:#ubuntu-release- New sync: dconf (cosmic-proposed/primary) [0.28.0-2]
-queuebot:#ubuntu-release- New: accepted dconf [sync] (cosmic-proposed) [0.28.0-2]
-queuebot:#ubuntu-release- New: accepted zvmcloudconnector [source] (cosmic-proposed) [1.2.3-0ubuntu1]
<LocutusOfBorg> since we are approaching a new "big one" transition, what about disabling autosync?
-queuebot:#ubuntu-release- New binary: zvmcloudconnector [amd64] (cosmic-proposed/universe) [1.2.3-0ubuntu1] (no packageset)
<Ukikie> Which transition?
<LocutusOfBorg> qt+everything
<LocutusOfBorg> I mean, we are closing to make it migrate
<LocutusOfBorg> "getting closer"
<LocutusOfBorg> e.g. sndio is getting autosyncd, involving "only 10 packages", but maybe it might be better to entangle more stuff
-queuebot:#ubuntu-release- New: accepted zvmcloudconnector [amd64] (cosmic-proposed) [1.2.3-0ubuntu1]
<LocutusOfBorg> please turn DOWN autosync!
<LocutusOfBorg> cjwatson, ^^ :D
<LocutusOfBorg> we are getting near to see it migrate
<cjwatson> somebody else please
<Laney> I did it
* Laney changed the topic of #ubuntu-release to: Released: Xenial 16.04.5, Bionic 18.04.1 | Archive: open, auto-sync disabled temporarily | Cosmic Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melius malum quod cognoscis
<Laney> if I copy and paste the hint from update_output.txt it crashes tilix
<Laney> /o\
<apw> quality
<LocutusOfBorg> lol
<LocutusOfBorg> Laney, apw emacs25 is now called emacs, so can you please do the "move to main and the other to universe" thing?
<LocutusOfBorg> emacs/amd64 unsatisfiable Depends: emacs-gtk | emacs-lucid | emacs-nox
<LocutusOfBorg> emacs25/amd64 unsatisfiable Depends: emacs-gtk
<LocutusOfBorg> emacs25-nox/amd64 unsatisfiable Depends: emacs-nox
<LocutusOfBorg> (it is a sad thing, I know)
<LocutusOfBorg> 3 RC bugs :/
<Laney> LocutusOfBorg: no
<Laney> I can't do that
<Laney> hhvm and openjfx need something too
<LocutusOfBorg> Laney, openjfx is uploading in some second
<LocutusOfBorg> hhvm on todo
<LocutusOfBorg> problem is ffmpeg and what needs porting/fixes...
<LocutusOfBorg> /Note: this function must return int, despite the fact it doesn't conform to XIMProc type.
<LocutusOfBorg> / This is required in documentation of XIM
<LocutusOfBorg> static int im_preedit_start(XIM im_xim, XPointer client, XPointer call) {
<LocutusOfBorg> this is the openjfx failure... I'm going to do "-Wno-error=cast-function-type"
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (bionic-proposed/partner) [1:20180710.1-0ubuntu0.18.04.1 => 1:20180814.1-0ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20180710.1-0ubuntu0.16.04.1 => 1:20180814.1-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (trusty-proposed/partner) [1:20180710.1-0ubuntu0.14.04.1 => 1:20180814.1-0ubuntu0.14.04.1] (no packageset)
<Laney> performous tupi vcmi
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (bionic-proposed) [1:20180814.1-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (trusty-proposed) [1:20180814.1-0ubuntu0.14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20180814.1-0ubuntu0.16.04.1]
<Laney> that'll do, IMHO everything left apart from emacs should be booted out
<acheronuk> LP: #1772588
<ubot5> Launchpad bug 1772588 in xserver-xorg-video-trident (Ubuntu) "Remove obsolete X11 drivers from the archive" [Undecided,New] https://launchpad.net/bugs/1772588
<acheronuk> not sure if that needs to be actioned instead of rebuilds? tjaalton?
<Laney> yes very good, but I can't do anything about that
<Laney> what I can do is rebuild things so that they don't block this transition
<acheronuk> fair enough. just wasn't sure
<Laney> paraview is failing too
<Laney> and those two octave-* regressions are maybe just things to punt out
<Laney> would be nice if someone could file all those removal / demotions in a bug unless they really want to fix them
<Laney> strigi is probably good to remove completely if amarok is temporarily demoted (IIRC)
<Laney> night
<acheronuk> yes, the amarok in proposed has been rebuilt without strigi. so the amarok in release could be deleted to allow strigi to be removed
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (cosmic-proposed/main) [4.17.0-8.9] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (cosmic-proposed/main) [4.17.0-8.9] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (trusty-proposed/partner) [1:20180710.1-0ubuntu0.14.04.1 => 1:20180814.1-0ubuntu0.14.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20180710.1-0ubuntu0.16.04.1 => 1:20180814.1-0ubuntu0.16.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (bionic-proposed/partner) [1:20180710.1-0ubuntu0.18.04.1 => 1:20180814.1-0ubuntu0.18.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (trusty-proposed) [1:20180814.1-0ubuntu0.14.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20180814.1-0ubuntu0.16.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (bionic-proposed) [1:20180814.1-0ubuntu0.18.04.2]
<LocutusOfBorg> Laney, what about merging the mariadb-10.1 hint request?
<LocutusOfBorg> this one https://code.launchpad.net/~costamagnagianfranco/britney/hints-ubuntu/+merge/352783
-queuebot:#ubuntu-release- Unapproved: fwupd (xenial-proposed/main) [0.8.3-0ubuntu3 => 0.8.3-0ubuntu4] (desktop-core)
<tjaalton> acheronuk: it needs an archive admin to remove the drivers already
<tsimonq2> Oh thank god, finally.
<tsimonq2> LocutusOfBorg: <43
<tsimonq2> *<3
<tsimonq2> And Laney too
<tsimonq2> slangasek: Could bug 1772588 be dealt with please? If I understand correctly it's blocking the megatransition.
<ubot5> bug 1772588 in xserver-xorg-video-trident (Ubuntu) "Remove obsolete X11 drivers from the archive" [Undecided,New] https://launchpad.net/bugs/1772588
<slangasek> tsimonq2: I'm not sure I see the relationship between that bug and the transition being blocked; e.g. xorg-server is listed as one of the uninstallables resulting from the hint, and that's certainly not an obsolete X11 driver
<tsimonq2> slangasek: I see a lot of uninstallables; regardless, could you do the removing if it looks sane? :)
<slangasek> tsimonq2: I am currently processing kernel SRUs, after that I will take a look.  In the meantime, my above is an "are you sure?" since maybe it won't fix the root cause and you want to investigate more
<tsimonq2> slangasek: I know it won't fix the root cause but it's likely to clear things up just a little more.
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-33.36~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1022.22~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-33.36~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1022.22~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-33.36~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-33.36~16.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-134.160] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: rejected maas [source] (bionic-proposed) [2.4.1-7032-g11e4fa330-0ubuntu1~18.04.1]
<slangasek> tsimonq2: well I'm looking at LP: #1772588 and now I don't understand why tjaalton is asking for packages which are in sync from Debian to be removed from Ubuntu only
<ubot5> Launchpad bug 1772588 in xserver-xorg-video-trident (Ubuntu) "Remove obsolete X11 drivers from the archive" [Undecided,New] https://launchpad.net/bugs/1772588
<tsimonq2> Â¯\_(ã)_/Â¯
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-33.36] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-33.36] (core, kernel)
<tjaalton> slangasek: being in sync isn't the point. and yes maybe some of them have been updated there since 2+ months ago
<slangasek> tjaalton: but why go to the effort of removing them from Ubuntu and blacklisting them here, but not remove them from Debian?
<slangasek> tjaalton: (they also aren't causing any transition problems)
<tjaalton> slangasek: ok, what is, at this point? the transitional pkg should've cleared some, right?
<slangasek> there's a smattering of packages now blocking, none of them X-ish
<tjaalton> huh, ok
<slangasek> emacs needed a binary promotion (because emacs stole emacs25 source)
<slangasek>     * amd64: dvdrip, emacs25, emacs25-lucid, hhvm, hhvm-dbg, libopenjfx-java, libopenjfx-jni, libsearchclient-dev, libstreamanalyzer-dev, libstreamanalyzer0v5, libstrigihtmlgui-dev, libstrigihtmlgui0v5, mediathekview, openjfx, paraview, paraview-dev, paraview-python, pdfsam, performous, pfsglview, pfstools, pfsview, rbdoom3bfg, ring, ring-daemon, ripmake, strigi-client, strigi-daemon,
<slangasek> strigi-dbg, strigi-utils, subtitleripper, transcode, transcode-dbg, tupi, vcmi, vdr-plugin-softhddevice
<slangasek> short list
<slangasek> hhvm is probably a disaster but I haven't looked yet
<cyphermox> slangasek: I think I'm looking at the same list, and if I didn't mess up too much the only thing catching was emacs25?
<cyphermox> but I suspect I must have messed up somewhere anyway
<slangasek> cyphermox: what do you mean "catching"?
<tjaalton> from update_output.txt?
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-134.160]
<cyphermox> slangasek: same as you mentioned, emacs stealing emacs25; which I saw when I try to script doing the same thing britney does
<mwhudson> slangasek: hhvm does look "fun"
<slangasek> the other packages listed don't depend on emacs
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-33.36]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-33.36]
<cyphermox> https://paste.ubuntu.com/p/dxDp39XtCC/
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [4.15.0-1022.23] (kernel)
#ubuntu-release 2018-08-17
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [4.15.0-1022.23]
<slangasek> new emacs regresses racket-mode autopkgtest
<mwhudson> upstream seems pretty active
<mwhudson> so maybe it's fixed?
<mwhudson> actually they are so active it's hard to tell :-p
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1016.19] (kernel)
-queuebot:#ubuntu-release- Unapproved: gnome-user-docs (trusty-proposed/main) [3.8.2-1 => 3.8.2-1ubuntu0.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: apturl (bionic-proposed/main) [0.5.2ubuntu14 => 0.5.2ubuntu14.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: apturl (xenial-proposed/main) [0.5.2ubuntu11.1 => 0.5.2ubuntu11.2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: apturl (trusty-proposed/main) [0.5.2ubuntu4 => 0.5.2ubuntu4.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1016.19]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (cosmic-proposed) [4.17.0-8.9]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (cosmic-proposed) [4.17.0-8.9]
-queuebot:#ubuntu-release- Unapproved: accepted apturl [source] (bionic-proposed) [0.5.2ubuntu14.1]
-queuebot:#ubuntu-release- Unapproved: accepted apturl [source] (xenial-proposed) [0.5.2ubuntu11.2]
-queuebot:#ubuntu-release- Unapproved: accepted apturl [source] (trusty-proposed) [0.5.2ubuntu4.1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [source] (xenial-proposed) [0.8.3-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: gdm3 (xenial-proposed/universe) [3.18.3-0ubuntu2.1 => 3.18.3-0ubuntu2.2] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: accepted samba [source] (trusty-proposed) [2:4.3.11+dfsg-0ubuntu0.14.04.17]
-queuebot:#ubuntu-release- Unapproved: accepted samba [source] (xenial-proposed) [2:4.3.11+dfsg-0ubuntu0.16.04.16]
<rbasak> ahasenack: ^
<ahasenack> rbasak: oh, goodie
<Laney> can someone reject gdm3/bionic unapproved please? I'm going to upload the .3 point release instead. (cc slashd dgadomski)
<slashd> Laney, ack tks
-queuebot:#ubuntu-release- Unapproved: gdm3 (bionic-proposed/main) [3.28.2-0ubuntu1.4 => 3.28.3-0ubuntu18.04.1] (ubuntu-desktop)
<Laney> there it is
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1017.20] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1017.20]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-156.206] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-156.206]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-user-docs [source] (trusty-proposed) [3.8.2-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted fwts [source] (xenial-proposed) [16.03.00-0ubuntu1.2]
#ubuntu-release 2018-08-18
-queuebot:#ubuntu-release- Unapproved: qpdf (bionic-proposed/main) [8.0.2-3 => 8.1.0-1] (desktop-core, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: qpdf (bionic-proposed/main) [8.0.2-3 => 8.1.0-1] (desktop-core, ubuntu-server) (sync)
<LocutusOfBorg> hello AA, how do you feel about removing openjfx binaries on armhf arm64 and ppc64el?
<LocutusOfBorg> the reverse-deps are all arch:all, so nobody should care about what is not amd64 and i386...
<LocutusOfBorg> at least until debian fixes the failures, so we can move forward with the transition
<slangasek> LocutusOfBorg: openjfx> sounds like a pragmatic approach.  Looking
<slangasek> LocutusOfBorg: done
<slangasek> anyone working on transcode?  It's two years removed from Debian, I would just remove it from Ubuntu as well but it has revdeps
<slangasek> looks like doko fixed transcode last
<slangasek> also looks like demoting/removing dvdrip,ripmake,subtitleripper,transcode is enough to resolve, so will probably just do that if unresolved when the other blockers are sorted
<slangasek> tsimonq2: anyone after the strigi build failure?
<slangasek> was already ftbfs in bionic release apparently
<acheronuk> slangasek: strigi is dead and removed in debian. amarok in -proposed is built without it, which was the last thing that wanted it
<slangasek> ok
<slangasek> acheronuk: in fact, it appears amarok in cosmic has only an unused build-dep on it, so I can go ahead and remove strigi from cosmic now, thanks
<acheronuk> :)
<slangasek> strigi gone
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-134.160~14.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-134.160~14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (trusty-proposed) [2.02~beta2-9ubuntu1.15]
<LocutusOfBorg> slangasek, https://bugs.launchpad.net/ubuntu/+source/dvdrip/+bug/1787222
<ubot5> Ubuntu bug 1787222 in transcode (Ubuntu) "Remove transcode and friends from cosmic" [Undecided,Confirmed]
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/transcode/+bug/1784612
<ubot5> Ubuntu bug 1784612 in transcode (Ubuntu) "FTBFS against ffmpeg 4" [Undecided,New]
<LocutusOfBorg> I would prefer to follow with removals
<LocutusOfBorg> slangasek, I fixed transcode, because I want to see less stuff in update_output. but *please* remove it anyway, it is not maintainable anymore
<LocutusOfBorg> and I'm really sure the patches we have now are making the program not behaving correctly
<tsimonq2> slangasek: If I needed to sed a single line in the Lubuntu squashfs that shouldn't be in the package, can I add a one-liner to livecd-rootfs?
<tsimonq2> It's pending an upstream solution but it just neans sedding one line.
<tsimonq2> (I know it's hacky... heh)
<LocutusOfBorg> can we please have nodejs hinted so curl can migrate?
<LocutusOfBorg> it is regressed with new libuv, but the test doesn't really run against release (because of transition or other meh)
-queuebot:#ubuntu-release- New binary: budgie-extras [s390x] (cosmic-proposed/universe) [0.6.0-0ubuntu1] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: budgie-extras [ppc64el] (cosmic-proposed/universe) [0.6.0-0ubuntu1] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: budgie-extras [amd64] (cosmic-proposed/universe) [0.6.0-0ubuntu1] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: budgie-extras [i386] (cosmic-proposed/universe) [0.6.0-0ubuntu1] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: budgie-extras [armhf] (cosmic-proposed/universe) [0.6.0-0ubuntu1] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: budgie-extras [arm64] (cosmic-proposed/universe) [0.6.0-0ubuntu1] (personal-fossfreedom, ubuntu-budgie)
<slangasek> LocutusOfBorg: well, not sure it was worth your time to fix transcode when I was already talking about removing it.  I'll take care of these now
<slangasek> tsimonq2: you mean that the line you're sedding out shouldn't be in the package? livecd-rootfs is not a place to hack contents of packages
<tsimonq2> slangasek: Is there a place other than livecd-rootfs for temporary hacks?
#ubuntu-release 2018-08-19
<mwhudson> tsimonq2: debian/patches?
-queuebot:#ubuntu-release- Unapproved: network-manager-openconnect (bionic-proposed/universe) [1.2.4-1 => 1.2.4-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: cpdb-libs [amd64] (cosmic-proposed/universe) [1.2.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: cpdb-libs [s390x] (cosmic-proposed/universe) [1.2.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: cpdb-libs [ppc64el] (cosmic-proposed/universe) [1.2.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: cpdb-libs [armhf] (cosmic-proposed/universe) [1.2.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: cpdb-libs [arm64] (cosmic-proposed/universe) [1.2.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: cpdb-libs [i386] (cosmic-proposed/universe) [1.2.0-0ubuntu1] (no packageset)
<tsimonq2> mwhudson: I need a config variable set in a native package via /etc/xdg/xdg-Lubuntu/lxqt/panel.conf
<tsimonq2> It should be on the live system only.
<tsimonq2> wxl: Heya.
<wxl> o/
<tsimonq2> wxl: You've read through https://wiki.ubuntu.com/ProposedMigration or at least skimmed it?
<wxl> yep
<tsimonq2> Cool.
<tsimonq2> So, with transitions as big as ours, there's gotta be something failing an autopkgtest.
<tsimonq2> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html has a full list, and you can access specific packages via http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src
<wxl> well there's only one of 5 possibilites so you've got a 20% chance of being right :)
<tsimonq2> hahahaha
<tsimonq2> wxl: We want it to say "Valid candidate" at the bottom.
<tsimonq2> From there, that part of the testing has passed, and then it goes to http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<wxl> @tsimonq2: ignore the ignored failures i assume?
<tsimonq2> wxl: Right.
<tsimonq2> All of the "hints", or known failures, are available here: https://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/files
<tsimonq2> We
<tsimonq2> grr
<tsimonq2> We're trying to move it over to team files, such as "ubuntu-release" instead of e.g. "vorlon"
<wxl> looks like there's a handful of always failed. shouldn't be too difficult
<tsimonq2> wxl: So, if you know an autopkgtest is bad, you can either make an MP there or ask someone here.
<tsimonq2> But right.
<tsimonq2> *Usually* it's annotated with a comment.
<tsimonq2> wxl: What isn't documented though, is there's an update_output.txt that's *before* all the tests are passed.
<tsimonq2> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output_notest.txt
<tsimonq2> So what I typically do, for e.g. Qt to migrate, is search for the first entry in the file for qtbase-opensource-src where it's grouped in with a bunch of other packages.
<tsimonq2> From then on, it tries to separate it into different migratable chunks.
<wxl> like the one that begins with qtserialport-opensource-src and ends with khangman?
<tsimonq2> Right.
<tsimonq2> So, with these, you can sometimes diff the listing in update_output.txt with the listing in update_output_notest.txt.
<tsimonq2> Because the latter is with tests *not* considered.
<tsimonq2> Either way, if you're in update_output.txt and the "got" stanza does not contain any other -proposed packages in it, you might want to try looking at Ben: https://people.canonical.com/~ubuntu-archive/transitions/
<tsimonq2> Ben is a graphical representation of some of these transitions; I would encourage you to look into it.
<tsimonq2> The trick is to try to make A) Ben happy for a transition. B) All autopkgtests passable. C) Make everything installable.
<wxl> ok so let's work on an example. walk me through it step by step.
<tsimonq2> So, that big one you mentioned before starting with qtserialport and ending with khangman.
<wxl> ok
<tsimonq2> The only reason why it can't all migrate now is because of these lines:
<tsimonq2>     got: 32+0: a-3:a-2:a-4:i-2:p-19:s-2
<tsimonq2>     * ppc64el: emacs25, emacs25-lucid, libsbml5-octave, octave-lhapdf, octave-ocs, octave-odepkg, octave-plplot, paraview, paraview-dev, paraview-python, performous, rbdoom3bfg, ring, ring-daemon, tupi, vcmi, vdr-plugin-softhddevice
<tsimonq2> So, when these packages are installed, upgrading that whole stack shown in "trying" breaks all of these *somehow*.
-queuebot:#ubuntu-release- New source: cpdb-backend-file (cosmic-proposed/primary) [1.0.0-0ubuntu1]
<wxl> and it's only affecting ppc64el?
<tsimonq2> It cycles through all of the architectures in every run.
<tsimonq2> So this run it'll be ppc64el, next run should be s390x, etc.
<wxl> oic
<tsimonq2> In Ubuntu, unlike Debian, we don't split arch:all and amd64, so amd64 could(!) yield more results.
<wxl> we need a vim plugin with custom folding
<tsimonq2> Oh? :)
<tsimonq2> I don't catch your drife.
<tsimonq2> *drift
<wxl> so you could fold away the lines that are irrelevant and focus only on the important bits
<wxl> anyways carry on
<tsimonq2> So, that's what is uninstallable. Often times within that you can find a dep tree.
<tsimonq2> I personally scan Ben next to see if there's something that corresponds to any of these packages.
<tsimonq2> https://people.canonical.com/~ubuntu-archive/transitions/
<tsimonq2> I see Octave.
<wxl> i'm with you
<tsimonq2> Indeed: https://launchpad.net/ubuntu/+source/emacs25/25.2+1-6build2
<tsimonq2> So the goal with all of these is to find source packages and what's wrong with them.
<tsimonq2> That's a bit of a unique error, so I'll look into it.
<tsimonq2> INFO Upload was rejected:
<tsimonq2> INFO 	emacs25-lucid_25.2+1-6build2_amd64.deb: Version older than that in the archive. 25.2+1-6build2 <= 1:25.2+1-10
<tsimonq2> INFO 	emacs25-nox_25.2+1-6build2_amd64.deb: Version older than that in the archive. 25.2+1-6build2 <= 1:25.2+1-10
<tsimonq2> INFO 	emacs25_25.2+1-6build2_amd64.deb: Version older than that in the archive. 25.2+1-6build2 <= 1:25.2+1-10
<wxl> what about octave?
<tsimonq2> INFO Committing the transaction and any mails associated with this upload.
<tsimonq2> Fun.
<tsimonq2> wxl: Well, Ben needs to be looked at for that it seems.
<acheronuk> emacs took over emacs25 package + friends
<tsimonq2> acheronuk: Got it, so that probably needs AA processing if I'm not wrong?
<acheronuk> [23:44] <slangasek> emacs needed a binary promotion (because emacs stole emacs25 source)
<tsimonq2> Bingo.
<tsimonq2> wxl: So, that's part of what's blocking it; an Archive Admin such as slangasek (there's a few more victims^Mpeople you can poke) needs to press buttons.
<tsimonq2> Otherwise, I'll look at Octave.
<wxl> let's find an "easy" one for me and i'll leave the hard ones for you
<acheronuk> octave is not on the last update_output for i386
<acheronuk> * i386: emacs25, emacs25-lucid, paraview, paraview-dev, paraview-python, performous, pfsglview, pfstools, pfsview, rbdoom3bfg, ring, ring-daemon, tupi, vcmi, vdr-plugin-softhddevice
<tsimonq2> Hmm.
<tsimonq2> Oh, I was looking at notest, hah.
<tsimonq2> wxl: So, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#octave is an example of a package with failing tests.
<tsimonq2> Since Debian started testing for those, you can usually(!) find a corresponding Debian bug.
<tsimonq2> Looks like octave-ocs is not in Testing, so it might need a demotion: https://tracker.debian.org/pkg/octave-ocs
<tsimonq2> (Demotion to -proposed.)
<tsimonq2> wxl: This demonstrates the general point that this is a rabbit hole. :P
<wxl> yes
<wxl> and at this point i'm starting to wonder how i'm going to be helpful because it's going to take half the time to explain to me what it is i'm even looking at
<tsimonq2> Once you learn what you're looking at, it's easy enough to understand what you're dealing with.
<tsimonq2> wxl: If you want, I can continue to hunt the transition on my own, but it'd be cool if you could continue to stick around for the ride. :)
<acheronuk> don't think we need octave for Qt though. normal output where it's not grouped due to the failing tests would migrate Qt without it
<wxl> i'm here to help
<tsimonq2> acheronuk: Right.
<tsimonq2> Fixing https://launchpad.net/ubuntu/+source/ring/20180712.2.f3b87a6~ds1-1build1 is needed it seems.
 * tsimonq2 hunts for upstream patches...
-queuebot:#ubuntu-release- New source: cpdb-backend-file (cosmic-proposed/primary) [1.0.1-0ubuntu1]
<wxl> so going back to octave.. it's passing in excuses, so i guess that's what you mean about the tests before the tests?
<tsimonq2> Yeah, kinda.
<tsimonq2> What our real concern right now is is ring.
<tsimonq2> https://launchpad.net/ubuntu/+source/ring/20180712.2.f3b87a6~ds1-1build1
<tsimonq2> The build passes in Debian but not in Ubuntu. I'm trying a fresh build locally.
<tsimonq2> If it FTBFS in a fresh Sid chroot, I'll file a bug there and it'll be their problem. ;)
<acheronuk> that may be so, but it's still OUR problem as it's blocking OUR transition
<tsimonq2> You're not *wrong*. :P
<acheronuk> I just mean more may be required from us than just 'passing the ball'
<acheronuk> if we want our transition through this year!
<tsimonq2> Oh, that's probably why.
<tsimonq2> It's FTBFS with the new boost!
<tsimonq2> grr
 * tsimonq2 wonders why doko switched our default Boost to 1.67 while Debian's is still at 1.62...
<tsimonq2> For these FTBFS packages, I'm going to switch the build dep to explicitly pull in 1.62 (even though it's in Universe, it's still default in Debian) and file bugs there that it FTBFS with 1.67... eventually once those are solved we should be able to sync.
<tsimonq2> Because some of these don't even have patches upstream yet.
<ginggs> tsimonq2: boost 1.65 was default for bionic, and debian didn't have that either
<tsimonq2> ginggs: Ah, got it.
<tsimonq2> ginggs: Where's the source package for 1.65? I can't seem to find it under the normal naming scheme.
<ginggs> https://launchpad.net/ubuntu/+source/boost1.65.1
<tsimonq2> ack
<ginggs> apparently ftp-master weren't happy with debian/copyright in boost
<tsimonq2> With which one?
<ginggs> all of them
<tsimonq2> Oh. :P
<tsimonq2> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906690
<ubot5> Debian bug 906690 in ring "ring: FTBFS with Boost 1.67" [Important,Open]
<tsimonq2> doko, xnox: Since Boost 1.67 was something you both were involved in, could you please solve the ring FTBFS? I don't know enough about Boost.
<tsimonq2> Trying a new version of yaml-cpp from Debian's Git repo.
<acheronuk> tsimonq2: missing include?
<tsimonq2> acheronuk: New yaml-cpp drops depends on boost ð
<tsimonq2> acheronuk: So if this works, I call it a workaround. :P
<tsimonq2> It doesn't help that the maintainer is MIA though.
<wxl> can we easily get a list of all the ones that require boost?
<tsimonq2> What do you mean?
<wxl> well we have could generate a list of potentially problematic packages, then iterate through them checking to see if they have depends on boost
<tsimonq2> wxl: Right, that's just grepping excuses :)
<tsimonq2> Aww, yaml-cpp is FTBFS :(
<tsimonq2> There, I'm thinking that yaml-cpp upload will fix it.
<tsimonq2> We shall see......
<tsimonq2> slangasek: Could you please demote vdr-plugin-softhddevice to cosmic-proposed? There's been an open bug in Debian since January about fixing support with ffmpeg, which hasn't been solved. Debian bug 888331.
<ubot5> Debian bug 888331 in src:vdr-plugin-softhddevice "vdr-plugin-softhddevice: FTBFS with FFmpeg 4.0" [Serious,Open] http://bugs.debian.org/888331
<tsimonq2> NICE, yaml-cpp does fix it.
<LocutusOfBorg> slangasek, it turned out to be relatively simple to do, and fixing a build failure gave me 12 hours of "good work" in fixing what was left to do, instead of seeing aways the same useless stuff in update_output... so not entirely a waste of time
<LocutusOfBorg> :)
<tsimonq2> wxl: A good challenge is to find yaml-cpp rdeps with `reverse-depends [-b]` and give me a list to retry :)
<LocutusOfBorg> paraview... anybody has hints?
<LocutusOfBorg> I rebuilt the last two xorg packages
<tsimonq2> I was looking at that and couldn't quite figure it out.
<LocutusOfBorg> we probably missed them because they are arch:arm* only
<LocutusOfBorg> I even tried a build with no-parallel...
<tsimonq2> LocutusOfBorg: Tag team you in? :) I will be mostly AFK for the next 6 hours.
<LocutusOfBorg> nothing changes
<LocutusOfBorg> tsimonq2, paraview FTBFS in debian too
<LocutusOfBorg> so you can open an RC bug there
<tsimonq2> ack
<tsimonq2> I can do that later unless you want to now.
<LocutusOfBorg> I can give you a link to build log
<tsimonq2> Please do, pastebin?
<LocutusOfBorg> http://debomatic-amd64.debian.net/distribution#unstable/paraview/5.4.1+dfsg4-3/buildlog
<LocutusOfBorg> there
<LocutusOfBorg> various MB of logs...
<wxl> @teward: doesn't look like it. you're it.
<teward> heh, was merely curious, since nginx is now tracking Mainline at least for 18.10 and 19.04
<teward> ... and I may have implemented something to stop the "Can't start nginx, something's already on port 80" "not-a-bug" bug reports that keep getting filed
<teward> not going to start the release notes yet though :p
<wxl> an apport-hook that looks for "80" in the report and rejects it? :)
<teward> wxl: preemots even that
<teward> preempts*
<teward> https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1782226
<ubot5> Ubuntu bug 1782226 in nginx (Ubuntu Bionic) "Allow NGINX to install but not start during postinst if another process is bound to port 80" [Wishlist,Triaged]
<wxl> oh my
<teward> mhm
<teward> wxl: preempts those issues by addressing the problem in the postinst
<teward> if it's a new install but something else is bound to port 80 it doesn't attempt to start nginx at all, but spits a note out into the logs
<teward> Not my favorite approach, but...
<teward> i'm tired of 20+ "I just installed nginx and it won't start idk why" bugs which are really "Something else is bound to Port 80, go find it and shut it off" Invalid NotABugs.
<teward> to be honest i think everyone is :P
-queuebot:#ubuntu-release- New binary: budgie-wallpapers [amd64] (cosmic-proposed/universe) [18.10] (personal-fossfreedom, ubuntu-budgie)
<mwhudson> tsimonq2: oh, live system only hacks might be more appropriate in livecd-rootfs i guess
-queuebot:#ubuntu-release- Unapproved: ubiquity (bionic-proposed/main) [18.04.14.6 => 18.04.14.7] (core)
-queuebot:#ubuntu-release- Unapproved: base-files (bionic-proposed/main) [10.1ubuntu2.1 => 10.1ubuntu2.2] (core)
#ubuntu-release 2019-08-12
-queuebot:#ubuntu-release- New binary: ocaml-qcheck [s390x] (eoan-proposed/universe) [0.9-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-qcheck [i386] (eoan-proposed/universe) [0.9-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-qcheck [ppc64el] (eoan-proposed/universe) [0.9-2] (no packageset)
-queuebot:#ubuntu-release- New binary: croaring [amd64] (eoan-proposed/universe) [0.2.63+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-qcheck [amd64] (eoan-proposed/universe) [0.9-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-shell-pomodoro [amd64] (eoan-proposed/universe) [0.15.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-shell-pomodoro [s390x] (eoan-proposed/universe) [0.15.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-shell-pomodoro [i386] (eoan-proposed/universe) [0.15.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: phpmyadmin-motranslator [amd64] (eoan-proposed/universe) [4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-qcheck [arm64] (eoan-proposed/universe) [0.9-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-qcheck [armhf] (eoan-proposed/universe) [0.9-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-shell-pomodoro [ppc64el] (eoan-proposed/universe) [0.15.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-shell-pomodoro [arm64] (eoan-proposed/universe) [0.15.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-shell-pomodoro [armhf] (eoan-proposed/universe) [0.15.1-1] (no packageset)
<ginggs> Morning! 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
<ginggs> ^ this should unconstipate r-base
<vorlon> ginggs: done
<ginggs> vorlon: thanks!
<Locutusofborg> now rbase is entangled with everything else, sigh
<Locutusofborg> vorlon, I don't know the deal.ii arm64 failure, I tried old gcc, old fortran, old foo old bar, no idea how to fix it
<Locutusofborg> ./obj-aarch64-linux-gnu/source/non_matching/./source/non_matching/coupling.cc:178:(.text._ZN6dealii11NonMatching32create_coupling_sparsity_patternILi2ELi1ELi2ENS_16TrilinosWrappers20BlockSparsityPatternEfEEvRKNS_9GridTools5CacheIXT_EXT1_EEERKNS_10DoFHandlerIXT_EXT1_EEERKNS9_IXT0_EXT1_EEERKNS_10QuadratureIXT0_EEERT2_RKNS_17AffineConstraintsIT3_EERKNS_13ComponentMaskEST_RKNS_7MappingIXT0_EXT1_EEE[_ZN6dealii11NonMatching32create
<Locutusofborg> _coupling_sparsity_patternILi2ELi1ELi2ENS_16TrilinosWrappers20BlockSparsityPatternEfEEvRKNS_9GridTools5CacheIXT_EXT1_EEERKNS_10DoFHandlerIXT_EXT1_EEERKNS9_IXT0_EXT1_EEERKNS_10QuadratureIXT0_EEERT2_RKNS_17AffineConstraintsIT3_EERKNS_13ComponentMaskEST_RKNS_7MappingIXT0_EXT1_EEE]+0x5c): additional relocation overflows omitted from the output
<Locutusofborg> looks like a binutils regression to me
<Locutusofborg> I would kick it out from arm64 to let something progress
<Locutusofborg> it is blocking a lot of stuff
<ginggs> would someone please kick the scipy can along?  'force-badtest python-scipy/1.2.2-4/amd64 python-scipy/1.2.2-4/i386'
-queuebot:#ubuntu-release- New: accepted gnome-shell-pomodoro [arm64] (eoan-proposed) [0.15.1-1]
-queuebot:#ubuntu-release- New: accepted gnome-shell-pomodoro [armhf] (eoan-proposed) [0.15.1-1]
-queuebot:#ubuntu-release- New: accepted gnome-shell-pomodoro [amd64] (eoan-proposed) [0.15.1-1]
-queuebot:#ubuntu-release- New: accepted gnome-shell-pomodoro [ppc64el] (eoan-proposed) [0.15.1-1]
-queuebot:#ubuntu-release- New: accepted ocaml-qcheck [amd64] (eoan-proposed) [0.9-2]
-queuebot:#ubuntu-release- New: accepted ocaml-qcheck [armhf] (eoan-proposed) [0.9-2]
-queuebot:#ubuntu-release- New: accepted ocaml-qcheck [ppc64el] (eoan-proposed) [0.9-2]
-queuebot:#ubuntu-release- New: accepted gnome-shell-pomodoro [i386] (eoan-proposed) [0.15.1-1]
-queuebot:#ubuntu-release- New: accepted ocaml-qcheck [arm64] (eoan-proposed) [0.9-2]
-queuebot:#ubuntu-release- New: accepted gnome-shell-pomodoro [s390x] (eoan-proposed) [0.15.1-1]
-queuebot:#ubuntu-release- New: accepted ocaml-qcheck [i386] (eoan-proposed) [0.9-2]
-queuebot:#ubuntu-release- New: accepted ocaml-qcheck [s390x] (eoan-proposed) [0.9-2]
-queuebot:#ubuntu-release- New: accepted phpmyadmin-motranslator [amd64] (eoan-proposed) [4.0-2]
-queuebot:#ubuntu-release- Unapproved: gpgme1.0 (bionic-proposed/main) [1.10.0-1ubuntu2 => 1.10.0-1ubuntu2.1] (core)
<ginggs> r-base migrated \o/
<Locutusofborg> ginggs, great success!
<Locutusofborg> Hello, general question: is it possible to know all the Ubuntu delta I own?
 * Locutusofborg moves to #-devel
<ginggs> in soviet russia, ubuntu delta own you
-queuebot:#ubuntu-release- New binary: m2crypto [amd64] (eoan-proposed/universe) [0.31.0-5] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-backtrace [i386] (eoan-proposed/universe) [0.3.34-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-phf [amd64] (eoan-proposed/universe) [0.7.24-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-core [amd64] (eoan-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-backtrace [s390x] (eoan-proposed/universe) [0.3.34-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-string [amd64] (eoan-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-phf [i386] (eoan-proposed/universe) [0.7.24-1] (no packageset)
-queuebot:#ubuntu-release- New binary: m2crypto [s390x] (eoan-proposed/universe) [0.31.0-5] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-string [i386] (eoan-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-wild [i386] (eoan-proposed/none) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-backtrace [amd64] (eoan-proposed/universe) [0.3.34-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-wild [amd64] (eoan-proposed/none) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pango [amd64] (eoan-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-phf [s390x] (eoan-proposed/universe) [0.7.24-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pango [i386] (eoan-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-core [i386] (eoan-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-backtrace [armhf] (eoan-proposed/universe) [0.3.34-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-phf-macros [amd64] (eoan-proposed/none) [0.7.24-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pango [s390x] (eoan-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-phf [armhf] (eoan-proposed/universe) [0.7.24-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-phf [arm64] (eoan-proposed/universe) [0.7.24-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-core [s390x] (eoan-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: m2crypto [ppc64el] (eoan-proposed/universe) [0.31.0-5] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-phf-macros [i386] (eoan-proposed/none) [0.7.24-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-core [armhf] (eoan-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-string [s390x] (eoan-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-backtrace [arm64] (eoan-proposed/universe) [0.3.34-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-string [arm64] (eoan-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-phf-macros [s390x] (eoan-proposed/none) [0.7.24-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-wild [s390x] (eoan-proposed/none) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pango [armhf] (eoan-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-string [armhf] (eoan-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pango [arm64] (eoan-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: m2crypto [arm64] (eoan-proposed/universe) [0.31.0-5] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-phf-macros [arm64] (eoan-proposed/universe) [0.7.24-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-core [arm64] (eoan-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-backtrace [ppc64el] (eoan-proposed/universe) [0.3.34-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-phf [ppc64el] (eoan-proposed/universe) [0.7.24-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pango [ppc64el] (eoan-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-core [ppc64el] (eoan-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-phf-macros [armhf] (eoan-proposed/universe) [0.7.24-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-string [ppc64el] (eoan-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: m2crypto [armhf] (eoan-proposed/universe) [0.31.0-5] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-wild [armhf] (eoan-proposed/universe) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-wild [arm64] (eoan-proposed/universe) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-phf-macros [ppc64el] (eoan-proposed/universe) [0.7.24-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-wild [ppc64el] (eoan-proposed/universe) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-phf-macros [ppc64el] (eoan-proposed) [0.7.24-1]
-queuebot:#ubuntu-release- New: accepted rust-wild [ppc64el] (eoan-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted m2crypto [armhf] (eoan-proposed) [0.31.0-5]
-queuebot:#ubuntu-release- New: accepted rust-phf-macros [armhf] (eoan-proposed) [0.7.24-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-core [arm64] (eoan-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-string [ppc64el] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-wild [armhf] (eoan-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted rust-pango [ppc64el] (eoan-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-core [ppc64el] (eoan-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-phf [ppc64el] (eoan-proposed) [0.7.24-1]
-queuebot:#ubuntu-release- New: accepted rust-wild [arm64] (eoan-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted m2crypto [arm64] (eoan-proposed) [0.31.0-5]
-queuebot:#ubuntu-release- New: accepted rust-backtrace [ppc64el] (eoan-proposed) [0.3.34-1]
-queuebot:#ubuntu-release- New: accepted rust-pango [armhf] (eoan-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-phf-macros [s390x] (eoan-proposed) [0.7.24-1]
-queuebot:#ubuntu-release- New: accepted m2crypto [ppc64el] (eoan-proposed) [0.31.0-5]
-queuebot:#ubuntu-release- New: accepted rust-phf-macros [arm64] (eoan-proposed) [0.7.24-1]
-queuebot:#ubuntu-release- New: accepted rust-pango [arm64] (eoan-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-string [armhf] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-backtrace [arm64] (eoan-proposed) [0.3.34-1]
-queuebot:#ubuntu-release- New: accepted rust-phf [arm64] (eoan-proposed) [0.7.24-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-core [armhf] (eoan-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-string [arm64] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-wild [s390x] (eoan-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted rust-phf-macros [i386] (eoan-proposed) [0.7.24-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-core [s390x] (eoan-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-phf [armhf] (eoan-proposed) [0.7.24-1]
-queuebot:#ubuntu-release- New: accepted rust-string [s390x] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-backtrace [armhf] (eoan-proposed) [0.3.34-1]
-queuebot:#ubuntu-release- New: accepted rust-pango [i386] (eoan-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-phf-macros [amd64] (eoan-proposed) [0.7.24-1]
-queuebot:#ubuntu-release- New: accepted rust-pango [amd64] (eoan-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-core [i386] (eoan-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-pango [s390x] (eoan-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted m2crypto [s390x] (eoan-proposed) [0.31.0-5]
-queuebot:#ubuntu-release- New: accepted rust-phf [s390x] (eoan-proposed) [0.7.24-1]
-queuebot:#ubuntu-release- New: accepted rust-wild [amd64] (eoan-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted rust-backtrace [amd64] (eoan-proposed) [0.3.34-1]
-queuebot:#ubuntu-release- New: accepted rust-wild [i386] (eoan-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted rust-string [i386] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted m2crypto [amd64] (eoan-proposed) [0.31.0-5]
-queuebot:#ubuntu-release- New: accepted rust-backtrace [s390x] (eoan-proposed) [0.3.34-1]
-queuebot:#ubuntu-release- New: accepted rust-phf [i386] (eoan-proposed) [0.7.24-1]
-queuebot:#ubuntu-release- New: accepted rust-string [amd64] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-backtrace [i386] (eoan-proposed) [0.3.34-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-core [amd64] (eoan-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-phf [amd64] (eoan-proposed) [0.7.24-1]
-queuebot:#ubuntu-release- New: accepted croaring [amd64] (eoan-proposed) [0.2.63+ds-2]
-queuebot:#ubuntu-release- New: accepted safeclib [armhf] (eoan-proposed) [3.5-1]
-queuebot:#ubuntu-release- New: accepted safeclib [ppc64el] (eoan-proposed) [3.5-1]
-queuebot:#ubuntu-release- New: accepted safeclib [amd64] (eoan-proposed) [3.5-1]
-queuebot:#ubuntu-release- New: accepted safeclib [i386] (eoan-proposed) [3.5-1]
-queuebot:#ubuntu-release- New binary: okteta [s390x] (eoan-proposed/universe) [5:0.26.2-2ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: okteta [amd64] (eoan-proposed/universe) [5:0.26.2-2ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: okteta [i386] (eoan-proposed/universe) [5:0.26.2-2ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: okteta [ppc64el] (eoan-proposed/universe) [5:0.26.2-2ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: okteta [arm64] (eoan-proposed/universe) [5:0.26.2-2ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: okteta [armhf] (eoan-proposed/universe) [5:0.26.2-2ubuntu1] (kubuntu)
<tjaalton> xrdp-hwe-18.04 is still in binary NEW, any AA availabe to give it a nudge?
<vorlon> looking
-queuebot:#ubuntu-release- New: accepted xrdp-hwe-18.04 [amd64] (bionic-proposed) [0.9.5-2~18.04.1]
-queuebot:#ubuntu-release- New: accepted xrdp-hwe-18.04 [armhf] (bionic-proposed) [0.9.5-2~18.04.1]
-queuebot:#ubuntu-release- New: accepted xrdp-hwe-18.04 [ppc64el] (bionic-proposed) [0.9.5-2~18.04.1]
-queuebot:#ubuntu-release- New: accepted xrdp-hwe-18.04 [arm64] (bionic-proposed) [0.9.5-2~18.04.1]
-queuebot:#ubuntu-release- New: accepted xrdp-hwe-18.04 [s390x] (bionic-proposed) [0.9.5-2~18.04.1]
-queuebot:#ubuntu-release- New: accepted xrdp-hwe-18.04 [i386] (bionic-proposed) [0.9.5-2~18.04.1]
<tjaalton> vorlon: great, thanks!
<ginggs> would someone please kick the scipy can along?  'force-badtest python-scipy/1.2.2-4/amd64 python-scipy/1.2.2-4/i386'
-queuebot:#ubuntu-release- New binary: ipmctl [amd64] (eoan-proposed/universe) [02.00.00.3474+ds-1] (no packageset)
<tumbleweed> ginggs: sure. Kicking...
<vorlon> ginggs: I had resisted doing so up to now because the test failures in the new upstream version are different from those in the old, and I am not confident they don't point to a serious problem with the new package.  any insight there?
<tumbleweed> ah, I saw a screenful of red, and didn't dig deeper
-queuebot:#ubuntu-release- New: accepted ipmctl [amd64] (eoan-proposed) [02.00.00.3474+ds-1]
<tumbleweed> vorlon: wanna revert that?
<ginggs> vorlon: the tests run fine for me locally, and in debian
<vorlon> tumbleweed: no, I was going to add the hint anyway because I also don't like blocking packages based on test failures that are not regressions :)
<vorlon> ginggs: do you think the tests need more memory?
<tumbleweed> I see they got killed, so that's a possibility
<ginggs> vorlon: quite possibly, iirc they are already running on the huge instances
<vorlon> ginggs: I don't find python-scipy mentioned in autopkgtest-cloud
<ginggs> vorlon: ok, do you think that's worth trying first?
-queuebot:#ubuntu-release- Unapproved: grub2 (eoan-proposed/main) [2.04-1ubuntu5 => 2.04-1ubuntu5] (core)
<vorlon> ginggs: yes
-queuebot:#ubuntu-release- Unapproved: grub2 (eoan-proposed/main) [2.04-1ubuntu5 => 2.04-1ubuntu5] (core)
#ubuntu-release 2019-08-13
-queuebot:#ubuntu-release- New binary: faultstat [amd64] (eoan-proposed/universe) [0.01.01-1] (no packageset)
-queuebot:#ubuntu-release- New binary: faultstat [armhf] (eoan-proposed/universe) [0.01.01-1] (no packageset)
-queuebot:#ubuntu-release- New binary: uacme [amd64] (eoan-proposed/universe) [1.0.17-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vectorgraphics2d [amd64] (eoan-proposed/universe) [0.13-1] (no packageset)
-queuebot:#ubuntu-release- New binary: zip4j [amd64] (eoan-proposed/universe) [1.3.3+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: faultstat [arm64] (eoan-proposed/universe) [0.01.01-1] (no packageset)
-queuebot:#ubuntu-release- New binary: uacme [i386] (eoan-proposed/universe) [1.0.17-1] (no packageset)
-queuebot:#ubuntu-release- New binary: faultstat [i386] (eoan-proposed/universe) [0.01.01-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ytcc [amd64] (eoan-proposed/universe) [1.8.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libreoffice [amd64] (eoan-proposed/main) [1:6.3.0-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: uacme [arm64] (eoan-proposed/universe) [1.0.17-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jarchivelib [amd64] (eoan-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: uacme [armhf] (eoan-proposed/universe) [1.0.17-1] (no packageset)
-queuebot:#ubuntu-release- New binary: classmate [amd64] (eoan-proposed/universe) [1.3.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: faultstat [s390x] (eoan-proposed/universe) [0.01.01-1] (no packageset)
-queuebot:#ubuntu-release- New binary: uacme [s390x] (eoan-proposed/universe) [1.0.17-1] (no packageset)
-queuebot:#ubuntu-release- New binary: faultstat [ppc64el] (eoan-proposed/universe) [0.01.01-1] (no packageset)
-queuebot:#ubuntu-release- New binary: uacme [ppc64el] (eoan-proposed/universe) [1.0.17-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dogtail [amd64] (eoan-proposed/universe) [0.9.11-2] (no packageset)
-queuebot:#ubuntu-release- New binary: duktape [i386] (eoan-proposed/universe) [2.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: duktape [amd64] (eoan-proposed/universe) [2.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pyflow [s390x] (eoan-proposed/universe) [1.1.20-2] (no packageset)
-queuebot:#ubuntu-release- New binary: duktape [s390x] (eoan-proposed/universe) [2.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pyflow [amd64] (eoan-proposed/universe) [1.1.20-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pyflow [i386] (eoan-proposed/universe) [1.1.20-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-cluster [amd64] (eoan-proposed/universe) [1.3.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: rename-flac [amd64] (eoan-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pyflow [arm64] (eoan-proposed/universe) [1.1.20-2] (no packageset)
-queuebot:#ubuntu-release- New binary: duktape [armhf] (eoan-proposed/universe) [2.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: duktape [arm64] (eoan-proposed/universe) [2.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vavr0 [amd64] (eoan-proposed/universe) [0.10.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pyflow [armhf] (eoan-proposed/universe) [1.1.20-2] (no packageset)
-queuebot:#ubuntu-release- New binary: duktape [ppc64el] (eoan-proposed/universe) [2.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pyflow [ppc64el] (eoan-proposed/universe) [1.1.20-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted classmate [amd64] (eoan-proposed) [1.3.4-1]
-queuebot:#ubuntu-release- New: accepted duktape [amd64] (eoan-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- New: accepted duktape [armhf] (eoan-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- New: accepted duktape [ppc64el] (eoan-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- New: accepted dogtail [amd64] (eoan-proposed) [0.9.11-2]
-queuebot:#ubuntu-release- New: accepted duktape [i386] (eoan-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- New: accepted duktape [arm64] (eoan-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- New: accepted duktape [s390x] (eoan-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- New: accepted faultstat [amd64] (eoan-proposed) [0.01.01-1]
-queuebot:#ubuntu-release- New: accepted faultstat [armhf] (eoan-proposed) [0.01.01-1]
-queuebot:#ubuntu-release- New: accepted faultstat [ppc64el] (eoan-proposed) [0.01.01-1]
-queuebot:#ubuntu-release- New: accepted jarchivelib [amd64] (eoan-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted faultstat [arm64] (eoan-proposed) [0.01.01-1]
-queuebot:#ubuntu-release- New: accepted faultstat [s390x] (eoan-proposed) [0.01.01-1]
-queuebot:#ubuntu-release- New: accepted faultstat [i386] (eoan-proposed) [0.01.01-1]
-queuebot:#ubuntu-release- New: accepted libreoffice [amd64] (eoan-proposed) [1:6.3.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted python-cluster [amd64] (eoan-proposed) [1.3.3-3]
-queuebot:#ubuntu-release- New: accepted python-pyflow [arm64] (eoan-proposed) [1.1.20-2]
-queuebot:#ubuntu-release- New: accepted python-pyflow [i386] (eoan-proposed) [1.1.20-2]
-queuebot:#ubuntu-release- New: accepted python-pyflow [s390x] (eoan-proposed) [1.1.20-2]
-queuebot:#ubuntu-release- New: accepted uacme [amd64] (eoan-proposed) [1.0.17-1]
-queuebot:#ubuntu-release- New: accepted uacme [armhf] (eoan-proposed) [1.0.17-1]
-queuebot:#ubuntu-release- New: accepted uacme [ppc64el] (eoan-proposed) [1.0.17-1]
-queuebot:#ubuntu-release- New: accepted python-pyflow [amd64] (eoan-proposed) [1.1.20-2]
-queuebot:#ubuntu-release- New: accepted python-pyflow [ppc64el] (eoan-proposed) [1.1.20-2]
-queuebot:#ubuntu-release- New: accepted uacme [arm64] (eoan-proposed) [1.0.17-1]
-queuebot:#ubuntu-release- New: accepted uacme [s390x] (eoan-proposed) [1.0.17-1]
-queuebot:#ubuntu-release- New: accepted python-pyflow [armhf] (eoan-proposed) [1.1.20-2]
-queuebot:#ubuntu-release- New: accepted uacme [i386] (eoan-proposed) [1.0.17-1]
-queuebot:#ubuntu-release- New: accepted rename-flac [amd64] (eoan-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted vavr0 [amd64] (eoan-proposed) [0.10.0-1]
-queuebot:#ubuntu-release- New: accepted ytcc [amd64] (eoan-proposed) [1.8.1-1]
-queuebot:#ubuntu-release- New: accepted vectorgraphics2d [amd64] (eoan-proposed) [0.13-1]
-queuebot:#ubuntu-release- New: accepted zip4j [amd64] (eoan-proposed) [1.3.3+ds-1]
-queuebot:#ubuntu-release- New binary: poco [s390x] (eoan-proposed/universe) [1.9.2-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: poco [amd64] (eoan-proposed/universe) [1.9.2-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: poco [i386] (eoan-proposed/universe) [1.9.2-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: poco [ppc64el] (eoan-proposed/universe) [1.9.2-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: poco [armhf] (eoan-proposed/universe) [1.9.2-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: poco [arm64] (eoan-proposed/universe) [1.9.2-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (bionic-proposed/partner) [1:20190709.1-0ubuntu0.18.04.1 => 1:20190813.1-0ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20190709.1-0ubuntu0.16.04.1 => 1:20190813.1-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (disco-proposed/partner) [1:20190709.1-0ubuntu0.19.04.1 => 1:20190813.1-0ubuntu0.19.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: nova (bionic-proposed/main) [2:17.0.10-0ubuntu2 => 2:17.0.11-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (disco-proposed) [1:20190813.1-0ubuntu0.19.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (bionic-proposed) [1:20190813.1-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20190813.1-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: aodh (bionic-proposed/main) [6.0.1-0ubuntu1.1 => 6.0.1-0ubuntu1.2] (openstack, ubuntu-server)
<bdmurray> coreycb: Has the manual testing of horizon been done? Bug 1830341
<ubot5> bug 1830341 in horizon (Ubuntu Bionic) "[SRU] queens stable releases" [High,Fix committed] https://launchpad.net/bugs/1830341
<coreycb> bdmurray: that's not done yet. SOMEBODY who was going to test it spilled coffee on their keyboard.
<coreycb> bdmurray: thanks for checking
<bdmurray> mmm, coffee keyboard
-queuebot:#ubuntu-release- Unapproved: accepted samba [source] (disco-proposed) [2:4.10.0+dfsg-0ubuntu2.3]
-queuebot:#ubuntu-release- Unapproved: accepted partman-base [source] (disco-proposed) [206ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted partman-base [source] (bionic-proposed) [192ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted nautilus [source] (disco-proposed) [1:3.32.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: libtext-bibtex-perl [amd64] (eoan-proposed/universe) [0.88-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: libtext-bibtex-perl [s390x] (eoan-proposed/universe) [0.88-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: conmon [amd64] (eoan-proposed/none) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-timeline [amd64] (eoan-proposed/none) [0.0.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ecbuild [amd64] (eoan-proposed/none) [3.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: conmon [i386] (eoan-proposed/none) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtext-bibtex-perl [armhf] (eoan-proposed/universe) [0.88-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: libtext-bibtex-perl [ppc64el] (eoan-proposed/universe) [0.88-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: libtext-bibtex-perl [arm64] (eoan-proposed/universe) [0.88-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: libtext-bibtex-perl [i386] (eoan-proposed/universe) [0.88-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: conmon [arm64] (eoan-proposed/none) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: conmon [s390x] (eoan-proposed/none) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: conmon [armhf] (eoan-proposed/none) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (bionic-proposed) [2:12.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: conmon [ppc64el] (eoan-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted thermald [source] (bionic-proposed) [1.7.0-5ubuntu3]
<bryce> vorlon, you had advised us to gate the php transition on the mysql8 transition, but we're feeling it will be a pinch getting mysql8 done by feature freeze.  We're thinking it may be worth requesting FFe for the PHP batch.  If we did that would we need to have separate FFes for each package (54 total) or one single one listing all of them?
-queuebot:#ubuntu-release- Unapproved: accepted bind9 [source] (bionic-proposed) [1:9.11.3+dfsg-1ubuntu1.9]
-queuebot:#ubuntu-release- Unapproved: accepted bind9 [source] (xenial-proposed) [1:9.10.3.dfsg.P4-8ubuntu1.15]
-queuebot:#ubuntu-release- Unapproved: accepted gpgme1.0 [source] (bionic-proposed) [1.10.0-1ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted aodh [source] (bionic-proposed) [6.0.1-0ubuntu1.2]
<vorlon> bryce: +1 on filing a ffe, +1 on the actual ffe, and I think you should file a single bug with a single 'php' task and detail the list of packages you expect to update together
-queuebot:#ubuntu-release- Unapproved: rejected nova [source] (bionic-proposed) [2:17.0.11-0ubuntu1]
<bryce> vorlon, thanks that sounds great
-queuebot:#ubuntu-release- New source: ibus-avro (bionic-proposed/primary) [1.1-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New source: ibus-avro (xenial-proposed/primary) [1.1-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- New source: ibus-avro (disco-proposed/primary) [1.1-0ubuntu0.19.04.1]
<mapreri> meh.   I just uploaded 3 ibus-avro to xenial, bionic and disco, however those should all have been for *-backports
<mapreri> these â
<mapreri> can somebody please reject them, while I re-upload to the right distribution?
-queuebot:#ubuntu-release- New source: ibus-avro (xenial-backports/primary) [1.1-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- New source: ibus-avro (bionic-backports/primary) [1.1-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New source: ibus-avro (disco-backports/primary) [1.1-0ubuntu0.19.04.1]
<mapreri> these are the good ones :)
<mapreri> Laney: â
-queuebot:#ubuntu-release- New: rejected ibus-avro [source] (xenial-backports) [1.1-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- New: rejected ibus-avro [source] (xenial-proposed) [1.1-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- New: rejected ibus-avro [source] (bionic-backports) [1.1-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New: rejected ibus-avro [source] (bionic-proposed) [1.1-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New: rejected ibus-avro [source] (disco-backports) [1.1-0ubuntu0.19.04.1]
-queuebot:#ubuntu-release- New: rejected ibus-avro [source] (disco-proposed) [1.1-0ubuntu0.19.04.1]
-queuebot:#ubuntu-release- New source: ibus-avro (bionic-backports/primary) [1.1-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New source: ibus-avro (xenial-backports/primary) [1.1-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- New source: ibus-avro (disco-backports/primary) [1.1-0ubuntu0.19.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted btrfs-tools [source] (xenial-proposed) [4.4-1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (xenial-proposed) [0.6.5.6-0ubuntu28]
-queuebot:#ubuntu-release- Unapproved: accepted landscape-client [source] (xenial-proposed) [16.03-0ubuntu2.16.04.7]
-queuebot:#ubuntu-release- New: accepted conmon [arm64] (eoan-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted conmon [ppc64el] (eoan-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted libtext-bibtex-perl [armhf] (eoan-proposed) [0.88-3]
-queuebot:#ubuntu-release- New: accepted conmon [armhf] (eoan-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted conmon [s390x] (eoan-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted conmon [amd64] (eoan-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted ecbuild [amd64] (eoan-proposed) [3.0.3-1]
-queuebot:#ubuntu-release- New: accepted libtext-bibtex-perl [arm64] (eoan-proposed) [0.88-3]
-queuebot:#ubuntu-release- New: accepted libtext-bibtex-perl [ppc64el] (eoan-proposed) [0.88-3]
-queuebot:#ubuntu-release- New: accepted conmon [i386] (eoan-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted libtext-bibtex-perl [i386] (eoan-proposed) [0.88-3]
-queuebot:#ubuntu-release- New: accepted libtext-bibtex-perl [amd64] (eoan-proposed) [0.88-3]
-queuebot:#ubuntu-release- New: accepted python-timeline [amd64] (eoan-proposed) [0.0.6-1]
-queuebot:#ubuntu-release- New: accepted libtext-bibtex-perl [s390x] (eoan-proposed) [0.88-3]
<vorlon> well that's fun, 2 of the 3 oldest packages stuck in -proposed were misbuilt binaries that were blocked by autopkgtests and are fixed with a no-change rebuild.  How many other binaries do we have in the archive built at that time which don't have autopkgtests?
<vorlon> (2018-11-08)
-queuebot:#ubuntu-release- New binary: gulkan [i386] (eoan-proposed/universe) [0.12.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: skalibs [i386] (eoan-proposed/universe) [2.8.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: skalibs [amd64] (eoan-proposed/universe) [2.8.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: skalibs [s390x] (eoan-proposed/universe) [2.8.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gulkan [amd64] (eoan-proposed/universe) [0.12.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gulkan [armhf] (eoan-proposed/universe) [0.12.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: skalibs [arm64] (eoan-proposed/universe) [2.8.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gulkan [arm64] (eoan-proposed/universe) [0.12.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gulkan [s390x] (eoan-proposed/universe) [0.12.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: skalibs [armhf] (eoan-proposed/universe) [2.8.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted gulkan [arm64] (eoan-proposed) [0.12.1-1]
-queuebot:#ubuntu-release- New: accepted gulkan [s390x] (eoan-proposed) [0.12.1-1]
-queuebot:#ubuntu-release- New: accepted gulkan [amd64] (eoan-proposed) [0.12.1-1]
-queuebot:#ubuntu-release- New: accepted gulkan [i386] (eoan-proposed) [0.12.1-1]
-queuebot:#ubuntu-release- New: accepted gulkan [armhf] (eoan-proposed) [0.12.1-1]
-queuebot:#ubuntu-release- New binary: skalibs [ppc64el] (eoan-proposed/universe) [2.8.1.0-2] (no packageset)
<teward> vorlon: heads up, I checked the latest iteration of raysession that Eickmeyer has asked for a review, it *looks* like the copyright bits are fixed as are the overrides, since you reviewed it last time I'd like you to review it this time when you get time.  it's in the process of being put in the queue now
<teward> though there's a couple of cases where we COULD get away with gpl-2.0+ because of that specific file(s) licensing.
<teward> and a few wishlist/minor bits, including where lintian seems to think the dep5 for the jacklib.py isn't actually used, if i'm blind then I missed it because it looks proper-syntax to me.
-queuebot:#ubuntu-release- New source: raysession (eoan-proposed/primary) [0.7.2-0ubuntu1]
<teward> ^ that one
#ubuntu-release 2019-08-14
-queuebot:#ubuntu-release- New binary: lua-lxc [amd64] (eoan-proposed/universe) [1:3.0.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: lua-lxc [s390x] (eoan-proposed/universe) [1:3.0.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: lua-lxc [i386] (eoan-proposed/universe) [1:3.0.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: lua-lxc [arm64] (eoan-proposed/universe) [1:3.0.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: lua-lxc [ppc64el] (eoan-proposed/universe) [1:3.0.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: lua-lxc [armhf] (eoan-proposed/universe) [1:3.0.2-1ubuntu1] (no packageset)
<doko> apw, sforshee: linux has autopkg test regressions. please could you have a look?
<apw> doko, will do
-queuebot:#ubuntu-release- Unapproved: openldap (xenial-proposed/main) [2.4.42+dfsg-2ubuntu3.6 => 2.4.42+dfsg-2ubuntu3.7] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: openldap (bionic-proposed/main) [2.4.45+dfsg-1ubuntu1.3 => 2.4.45+dfsg-1ubuntu1.4] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: openldap (disco-proposed/main) [2.4.47+dfsg-3ubuntu2.1 => 2.4.47+dfsg-3ubuntu2.2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: psmisc (xenial-proposed/main) [22.21-2.1build1 => 22.21-2.1ubuntu0.1] (core)
<RikMills> if someone has time, could they accept the okteta new binaries? new kdevelop is dep waiting on that. thanks
-queuebot:#ubuntu-release- New: accepted okteta [amd64] (eoan-proposed) [5:0.26.2-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted okteta [armhf] (eoan-proposed) [5:0.26.2-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted okteta [ppc64el] (eoan-proposed) [5:0.26.2-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted okteta [arm64] (eoan-proposed) [5:0.26.2-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted okteta [s390x] (eoan-proposed) [5:0.26.2-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted okteta [i386] (eoan-proposed) [5:0.26.2-2ubuntu1]
<RikMills> ty ^
-queuebot:#ubuntu-release- New binary: kdevelop [s390x] (eoan-proposed/universe) [4:5.4.0-2ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kdevelop [i386] (eoan-proposed/universe) [4:5.4.0-2ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kdevelop [amd64] (eoan-proposed/universe) [4:5.4.0-2ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kdevelop [ppc64el] (eoan-proposed/universe) [4:5.4.0-2ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kdevelop [arm64] (eoan-proposed/universe) [4:5.4.0-2ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kdevelop [armhf] (eoan-proposed/universe) [4:5.4.0-2ubuntu1] (kubuntu)
<juliank> rbasak: Hey, I've got a dpkg SRU (trigger fixes) in bionic that needs releasing. It's been released on disco and xenial already, only bionic's missing
<seb128> hum, does anyone understand what are the problem for the new libvpx to migrate?
-queuebot:#ubuntu-release- New: accepted lua-lxc [amd64] (eoan-proposed) [1:3.0.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted lua-lxc [armhf] (eoan-proposed) [1:3.0.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted lua-lxc [ppc64el] (eoan-proposed) [1:3.0.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted lua-lxc [arm64] (eoan-proposed) [1:3.0.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted lua-lxc [s390x] (eoan-proposed) [1:3.0.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted lua-lxc [i386] (eoan-proposed) [1:3.0.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted poco [amd64] (eoan-proposed) [1.9.2-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted poco [armhf] (eoan-proposed) [1.9.2-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted poco [ppc64el] (eoan-proposed) [1.9.2-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted poco [arm64] (eoan-proposed) [1.9.2-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted poco [s390x] (eoan-proposed) [1.9.2-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted poco [i386] (eoan-proposed) [1.9.2-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted nut [amd64] (eoan-proposed) [2.7.4-9ubuntu1]
-queuebot:#ubuntu-release- New: accepted nut [armhf] (eoan-proposed) [2.7.4-9ubuntu1]
-queuebot:#ubuntu-release- New: accepted nut [ppc64el] (eoan-proposed) [2.7.4-9ubuntu1]
-queuebot:#ubuntu-release- New: accepted nut [arm64] (eoan-proposed) [2.7.4-9ubuntu1]
-queuebot:#ubuntu-release- New: accepted nut [s390x] (eoan-proposed) [2.7.4-9ubuntu1]
-queuebot:#ubuntu-release- New: accepted nut [i386] (eoan-proposed) [2.7.4-9ubuntu1]
-queuebot:#ubuntu-release- New: accepted budgie-wallpapers [amd64] (eoan-proposed) [19.10]
<ginggs> would someone please kick the mercurial can along? 'force-badtest mercurial/4.8.2-1ubuntu4/arm64'
-queuebot:#ubuntu-release- New: accepted rust-quick-xml [amd64] (eoan-proposed) [0.14.0-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted rust-quick-xml [armhf] (eoan-proposed) [0.14.0-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted rust-quick-xml [ppc64el] (eoan-proposed) [0.14.0-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted rust-quick-xml [arm64] (eoan-proposed) [0.14.0-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted rust-quick-xml [s390x] (eoan-proposed) [0.14.0-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted rust-quick-xml [i386] (eoan-proposed) [0.14.0-2ubuntu1]
<vorlon> ginggs: done
<seb128> hey vorlon, do you know what's the status of libvpx (and other transitions) in eoan-proposed? I always have difficulties to read/understand update_output.txt
<ginggs> vorlon: ta!
<seb128> vorlon, do you know if there is anything I can help with? I would like to see some of it cleared off before we stack other incoming debian transitions
<vorlon> seb128: checking current status now.  When I last looked, ffmpeg was waiting for tests; and I see it's tied to the mysql-8.0 transition as well (unless we bounce mythtv out temporarily)
<vorlon> seb128: so, ffmpeg has a failing autopkgtest on armhf which is probably the source of a lot of noise
<vorlon> and xpra has a failure on ppc64el
<vorlon> and then mythtv
<vorlon> that's all I see
<vorlon> Locutusofborg: why did you manually sync qtwebkit?  all this does is put packages on the slow path through the NEW queue requiring manual review
-queuebot:#ubuntu-release- New: accepted qtwebkit [sync] (eoan-proposed) [2.3.4.dfsg-10]
<seb128> vorlon, k, thanks, I will try to see if I can help with some of that
<seb128> vorlon, we have a poppler transition and an evolution-data-server one coming from the desktop side in the next week (before ff)
<RikMills> vorlon: so you will remove? https://launchpad.net/ubuntu/+source/qtwebkit-source
<vorlon> RikMills: that should eventually be processed as a removal of a package removed from Debian
<RikMills> ok
-queuebot:#ubuntu-release- New: accepted magnus [sync] (eoan-proposed) [1.0.2-2]
 * vorlon squints at new-binary-debian-universe not matching on skalibs
-queuebot:#ubuntu-release- New: accepted skalibs [amd64] (eoan-proposed) [2.8.1.0-2]
-queuebot:#ubuntu-release- New: accepted skalibs [armhf] (eoan-proposed) [2.8.1.0-2]
-queuebot:#ubuntu-release- New: accepted skalibs [ppc64el] (eoan-proposed) [2.8.1.0-2]
-queuebot:#ubuntu-release- New: accepted skalibs [arm64] (eoan-proposed) [2.8.1.0-2]
-queuebot:#ubuntu-release- New: accepted skalibs [s390x] (eoan-proposed) [2.8.1.0-2]
-queuebot:#ubuntu-release- New: accepted skalibs [i386] (eoan-proposed) [2.8.1.0-2]
-queuebot:#ubuntu-release- New binary: magnus [amd64] (eoan-proposed/none) [1.0.2-2] (no packageset)
<rbalint> vorlon, doko: we discussed it with xnox anc please drop systemd 243~rc1-0ubuntu2 from eoan proposed
<rbalint> 243~rc1 is not a good candindate for eoan since 243 may not be releases early enough, thus i'm rebasing the delta on top of 241 for eoan to see if it regresses netplan and network-manager and get is migrated to release
<vorlon> rbalint: done
<rbalint> vorlon, thanks! i collected the packages to be rebuilt on amd64 and they are gamemode and libratbag https://pastebin.ubuntu.com/p/V6mqMRCxqx/ - this is consistent with them being blocked on systemd on update_excuses
<vorlon> rbalint: ok. are you doing those rebuilds?
<rbalint> vorlon, yes, how long should i wait before uploading them?
<vorlon> rbalint: 1h is generally enough
<rbalint> vorlon, ok, thanks!
<cyphermox> rbalint: 243~rc1 still in a PPA or elsewhere?
<cyphermox> I'm hoping to upload a new netplan today, I'd love to fix the tests at that point to work with current and futures systems
<cyphermox> *systemd
<rbalint> cyphermox, yes, i saved it to ppa:rbalint/systemd-save
<cyphermox> cool, ta
<rbalint> i keep working on getting 243 into a good packaged shape, but it blocks too much in eoan-proposed for now
<rbalint> 241 is in Debian stable thus it should be a safe bet for eoan
-queuebot:#ubuntu-release- New: accepted kdevelop [amd64] (eoan-proposed) [4:5.4.0-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted kdevelop [armhf] (eoan-proposed) [4:5.4.0-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted kdevelop [ppc64el] (eoan-proposed) [4:5.4.0-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted kdevelop [arm64] (eoan-proposed) [4:5.4.0-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted kdevelop [s390x] (eoan-proposed) [4:5.4.0-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted kdevelop [i386] (eoan-proposed) [4:5.4.0-2ubuntu1]
<teward> vorlon: when time permits, can you check raysession in NEW this time to see if it meets with the required needs?  I reviewed what we discussed about last time and think all the issues were ironed out.
<teward> Eickmeyer wants it to land before FF
<vorlon> teward: yes
<teward> thank you kindly
-queuebot:#ubuntu-release- New: accepted magnus [amd64] (eoan-proposed) [1.0.2-2]
<vorlon> E: linux-firmware-dragonboard410 source: source-only-upload-to-non-free-without-autobuild
<vorlon> who mapped 'non-free' to 'multiverse' in the Ubuntu lintian package and why?
<vorlon> ah because there's a generic mapping of "is non-free" which this keys on
<vorlon> even though we don't use the XS-Autobuild field in lp
-queuebot:#ubuntu-release- New binary: captagent [amd64] (eoan-proposed/none) [6.1.0.20-3.1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-stream-to-observable [amd64] (eoan-proposed/none) [0.2.0+repack-1] (no packageset)
-queuebot:#ubuntu-release- New binary: magics-python [s390x] (eoan-proposed/universe) [1:1.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: captagent [s390x] (eoan-proposed/universe) [6.1.0.20-3.1] (no packageset)
-queuebot:#ubuntu-release- New binary: rtl-433 [amd64] (eoan-proposed/universe) [18.12+git20190808-1] (no packageset)
-queuebot:#ubuntu-release- New binary: magics-python [amd64] (eoan-proposed/universe) [1:1.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rtl-433 [s390x] (eoan-proposed/universe) [18.12+git20190808-1] (no packageset)
-queuebot:#ubuntu-release- New binary: captagent [i386] (eoan-proposed/universe) [6.1.0.20-3.1] (no packageset)
-queuebot:#ubuntu-release- New binary: magics-python [i386] (eoan-proposed/universe) [1:1.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rtl-433 [i386] (eoan-proposed/universe) [18.12+git20190808-1] (no packageset)
-queuebot:#ubuntu-release- New binary: captagent [ppc64el] (eoan-proposed/universe) [6.1.0.20-3.1] (no packageset)
-queuebot:#ubuntu-release- New binary: rtl-433 [ppc64el] (eoan-proposed/universe) [18.12+git20190808-1] (no packageset)
-queuebot:#ubuntu-release- New binary: magics-python [ppc64el] (eoan-proposed/universe) [1:1.0.1-2] (no packageset)
<ogra> hmm, why is linux-raspi2 in universe in bionic ? is that on purpose or is that a sync error
-queuebot:#ubuntu-release- New binary: captagent [armhf] (eoan-proposed/universe) [6.1.0.20-3.1] (no packageset)
-queuebot:#ubuntu-release- New binary: magics-python [arm64] (eoan-proposed/universe) [1:1.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: magics-python [armhf] (eoan-proposed/universe) [1:1.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rtl-433 [armhf] (eoan-proposed/universe) [18.12+git20190808-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rtl-433 [arm64] (eoan-proposed/universe) [18.12+git20190808-1] (no packageset)
-queuebot:#ubuntu-release- New binary: captagent [arm64] (eoan-proposed/universe) [6.1.0.20-3.1] (no packageset)
<vorlon> ogra: it's in universe in all releases
<ogra> oh
<ogra> interesting
<ogra> the files it depends on are not
-queuebot:#ubuntu-release- New: accepted captagent [arm64] (eoan-proposed) [6.1.0.20-3.1]
-queuebot:#ubuntu-release- New: accepted rtl-433 [arm64] (eoan-proposed) [18.12+git20190808-1]
-queuebot:#ubuntu-release- New: accepted magics-python [armhf] (eoan-proposed) [1:1.0.1-2]
-queuebot:#ubuntu-release- New: accepted rtl-433 [armhf] (eoan-proposed) [18.12+git20190808-1]
-queuebot:#ubuntu-release- New: accepted captagent [armhf] (eoan-proposed) [6.1.0.20-3.1]
-queuebot:#ubuntu-release- New: accepted captagent [ppc64el] (eoan-proposed) [6.1.0.20-3.1]
-queuebot:#ubuntu-release- New: accepted magics-python [arm64] (eoan-proposed) [1:1.0.1-2]
-queuebot:#ubuntu-release- New: accepted magics-python [ppc64el] (eoan-proposed) [1:1.0.1-2]
-queuebot:#ubuntu-release- New: accepted rtl-433 [i386] (eoan-proposed) [18.12+git20190808-1]
-queuebot:#ubuntu-release- New: accepted rtl-433 [s390x] (eoan-proposed) [18.12+git20190808-1]
-queuebot:#ubuntu-release- New: accepted captagent [i386] (eoan-proposed) [6.1.0.20-3.1]
-queuebot:#ubuntu-release- New: accepted magics-python [i386] (eoan-proposed) [1:1.0.1-2]
-queuebot:#ubuntu-release- New: accepted rtl-433 [ppc64el] (eoan-proposed) [18.12+git20190808-1]
-queuebot:#ubuntu-release- New: accepted captagent [s390x] (eoan-proposed) [6.1.0.20-3.1]
-queuebot:#ubuntu-release- New: accepted rtl-433 [amd64] (eoan-proposed) [18.12+git20190808-1]
-queuebot:#ubuntu-release- New: accepted captagent [amd64] (eoan-proposed) [6.1.0.20-3.1]
-queuebot:#ubuntu-release- New: accepted magics-python [s390x] (eoan-proposed) [1:1.0.1-2]
-queuebot:#ubuntu-release- New: accepted magics-python [amd64] (eoan-proposed) [1:1.0.1-2]
-queuebot:#ubuntu-release- New: accepted node-stream-to-observable [amd64] (eoan-proposed) [0.2.0+repack-1]
-queuebot:#ubuntu-release- Unapproved: uw-imap (bionic-proposed/universe) [8:2007f~dfsg-5build1 => 8:2007f~dfsg-5ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: uw-imap (disco-proposed/universe) [8:2007f~dfsg-5build1 => 8:2007f~dfsg-5ubuntu0.19.04.1] (no packageset)
<Locutusofborg> vorlon, it was not autosyncd
<Locutusofborg> don't ask me why, there was an ubuntu qtwebkit-source with same binaries, but *broken*
<Locutusofborg> so, I had to sync it
<Locutusofborg> (all qtwebkit reverse-deps are broken on amd64 and arm64, and also qtwebkit-source itself)
<vorlon> Locutusofborg: ah ok
<vorlon> right, I think autosync defaults to not pulling in source packages that ship binary packages that exist in Ubuntu with an Ubuntu version number
<vorlon> mitya57: do we want the epoch + reversioning of compiz from Debian? I ask because compiz-plugins-experimental is dep-wait for 242 days on the epoch-bumped compiz
<Locutusofborg> vorlon, interestingly, the autosync log didn't mention it
<Locutusofborg> meh
<Locutusofborg> not sure why autosync never tried to pick it up
<Locutusofborg> (I'm usually searching for such packages, to see what can be sycnd)
-queuebot:#ubuntu-release- New binary: ruby-jekyll-readme-index [amd64] (eoan-proposed/none) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-jekyll-relative-links [amd64] (eoan-proposed/none) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: openvr [amd64] (eoan-proposed/none) [1.5.17~ds1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-acme-client [amd64] (eoan-proposed/none) [2.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-freetype-sys [amd64] (eoan-proposed/none) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: openvr [i386] (eoan-proposed/none) [1.5.17~ds1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-jekyll-default-layout [amd64] (eoan-proposed/none) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: omnidb [s390x] (eoan-proposed/none) [2.16.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-freetype-sys [i386] (eoan-proposed/none) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-fuchsia-cprng [amd64] (eoan-proposed/none) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-fuchsia-cprng [s390x] (eoan-proposed/none) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-lyon-path [s390x] (eoan-proposed/none) [0.13.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: postgresfixture [amd64] (eoan-proposed/none) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-fuchsia-cprng [i386] (eoan-proposed/none) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-url [s390x] (eoan-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-freetype-sys [s390x] (eoan-proposed/none) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-lyon-path [amd64] (eoan-proposed/none) [0.13.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: omnidb [amd64] (eoan-proposed/none) [2.16.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-jekyll-data [amd64] (eoan-proposed/none) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: omnidb [i386] (eoan-proposed/none) [2.16.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rle-decode-fast [i386] (eoan-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bidict [amd64] (eoan-proposed/none) [0.18.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-apollo-upload-server [amd64] (eoan-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cookie [amd64] (eoan-proposed/universe) [0.12.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cookie [s390x] (eoan-proposed/universe) [0.12.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rle-decode-fast [amd64] (eoan-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-url [i386] (eoan-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: thunarx-python [amd64] (eoan-proposed/none) [0.5.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-googleapi [amd64] (eoan-proposed/universe) [1.7.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cookie [armhf] (eoan-proposed/universe) [0.12.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-url [amd64] (eoan-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tophat-recondition [amd64] (eoan-proposed/none) [1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-jekyll-sitemap [amd64] (eoan-proposed/none) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-url [ppc64el] (eoan-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-lyon-path [i386] (eoan-proposed/none) [0.13.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cookie [arm64] (eoan-proposed/universe) [0.12.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cookie [ppc64el] (eoan-proposed/universe) [0.12.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-fuchsia-cprng [armhf] (eoan-proposed/none) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cookie [i386] (eoan-proposed/universe) [0.12.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: thunarx-python [i386] (eoan-proposed/none) [0.5.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-fuchsia-cprng [arm64] (eoan-proposed/none) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: omnidb [arm64] (eoan-proposed/none) [2.16.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-freetype-sys [arm64] (eoan-proposed/none) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-lyon-path [arm64] (eoan-proposed/none) [0.13.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: omnidb [armhf] (eoan-proposed/none) [2.16.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-url [arm64] (eoan-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-freetype-sys [armhf] (eoan-proposed/none) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: omnidb [ppc64el] (eoan-proposed/none) [2.16.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rle-decode-fast [s390x] (eoan-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: thunarx-python [s390x] (eoan-proposed/none) [0.5.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: openvr [s390x] (eoan-proposed/none) [1.5.17~ds1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-url [armhf] (eoan-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-freetype-sys [ppc64el] (eoan-proposed/none) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-lyon-path [ppc64el] (eoan-proposed/none) [0.13.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rle-decode-fast [ppc64el] (eoan-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-fuchsia-cprng [ppc64el] (eoan-proposed/none) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rle-decode-fast [arm64] (eoan-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: openvr [arm64] (eoan-proposed/none) [1.5.17~ds1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: openvr [ppc64el] (eoan-proposed/none) [1.5.17~ds1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rle-decode-fast [armhf] (eoan-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: openvr [armhf] (eoan-proposed/none) [1.5.17~ds1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: thunarx-python [ppc64el] (eoan-proposed/none) [0.5.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-lyon-path [armhf] (eoan-proposed/none) [0.13.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: thunarx-python [arm64] (eoan-proposed/universe) [0.5.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: thunarx-python [armhf] (eoan-proposed/universe) [0.5.1-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted thunarx-python [armhf] (eoan-proposed) [0.5.1-2]
-queuebot:#ubuntu-release- New: accepted openvr [arm64] (eoan-proposed) [1.5.17~ds1-2]
-queuebot:#ubuntu-release- New: accepted openvr [ppc64el] (eoan-proposed) [1.5.17~ds1-2]
-queuebot:#ubuntu-release- New: accepted rust-fuchsia-cprng [ppc64el] (eoan-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-lyon-path [ppc64el] (eoan-proposed) [0.13.2-2]
-queuebot:#ubuntu-release- New: accepted rust-rle-decode-fast [armhf] (eoan-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted thunarx-python [ppc64el] (eoan-proposed) [0.5.1-2]
-queuebot:#ubuntu-release- New: accepted openvr [armhf] (eoan-proposed) [1.5.17~ds1-2]
-queuebot:#ubuntu-release- New: accepted rust-lyon-path [armhf] (eoan-proposed) [0.13.2-2]
-queuebot:#ubuntu-release- New: accepted thunarx-python [arm64] (eoan-proposed) [0.5.1-2]
-queuebot:#ubuntu-release- New: accepted rust-freetype-sys [ppc64el] (eoan-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted rust-rle-decode-fast [arm64] (eoan-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted omnidb [ppc64el] (eoan-proposed) [2.16.0+ds-1]
-queuebot:#ubuntu-release- New: accepted rust-freetype-sys [arm64] (eoan-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted rust-lyon-path [arm64] (eoan-proposed) [0.13.2-2]
-queuebot:#ubuntu-release- New: accepted rust-rle-decode-fast [s390x] (eoan-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-url [armhf] (eoan-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted openvr [s390x] (eoan-proposed) [1.5.17~ds1-2]
-queuebot:#ubuntu-release- New: accepted rust-rle-decode-fast [ppc64el] (eoan-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted thunarx-python [s390x] (eoan-proposed) [0.5.1-2]
-queuebot:#ubuntu-release- New: accepted rust-freetype-sys [armhf] (eoan-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted rust-url [arm64] (eoan-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted bidict [amd64] (eoan-proposed) [0.18.0-2]
-queuebot:#ubuntu-release- New: accepted omnidb [armhf] (eoan-proposed) [2.16.0+ds-1]
-queuebot:#ubuntu-release- New: accepted rust-cookie [armhf] (eoan-proposed) [0.12.0-3]
-queuebot:#ubuntu-release- New: accepted rust-cookie [ppc64el] (eoan-proposed) [0.12.0-3]
-queuebot:#ubuntu-release- New: accepted rust-fuchsia-cprng [armhf] (eoan-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted thunarx-python [i386] (eoan-proposed) [0.5.1-2]
-queuebot:#ubuntu-release- New: accepted omnidb [arm64] (eoan-proposed) [2.16.0+ds-1]
-queuebot:#ubuntu-release- New: accepted rust-cookie [i386] (eoan-proposed) [0.12.0-3]
-queuebot:#ubuntu-release- New: accepted rust-lyon-path [i386] (eoan-proposed) [0.13.2-2]
-queuebot:#ubuntu-release- New: accepted rust-cookie [arm64] (eoan-proposed) [0.12.0-3]
-queuebot:#ubuntu-release- New: accepted rust-fuchsia-cprng [arm64] (eoan-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted python-googleapi [amd64] (eoan-proposed) [1.7.11-1]
-queuebot:#ubuntu-release- New: accepted ruby-jekyll-sitemap [amd64] (eoan-proposed) [1.3.1-1]
-queuebot:#ubuntu-release- New: accepted rust-cookie [s390x] (eoan-proposed) [0.12.0-3]
-queuebot:#ubuntu-release- New: accepted rust-url [amd64] (eoan-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-url [ppc64el] (eoan-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted tophat-recondition [amd64] (eoan-proposed) [1.4-1]
-queuebot:#ubuntu-release- New: accepted ruby-apollo-upload-server [amd64] (eoan-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-rle-decode-fast [amd64] (eoan-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted thunarx-python [amd64] (eoan-proposed) [0.5.1-2]
-queuebot:#ubuntu-release- New: accepted rust-cookie [amd64] (eoan-proposed) [0.12.0-3]
-queuebot:#ubuntu-release- New: accepted rust-url [i386] (eoan-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted omnidb [amd64] (eoan-proposed) [2.16.0+ds-1]
-queuebot:#ubuntu-release- New: accepted omnidb [s390x] (eoan-proposed) [2.16.0+ds-1]
-queuebot:#ubuntu-release- New: accepted rust-freetype-sys [s390x] (eoan-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted rust-fuchsia-cprng [s390x] (eoan-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-lyon-path [s390x] (eoan-proposed) [0.13.2-2]
-queuebot:#ubuntu-release- New: accepted rust-url [s390x] (eoan-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted omnidb [i386] (eoan-proposed) [2.16.0+ds-1]
-queuebot:#ubuntu-release- New: accepted rust-fuchsia-cprng [i386] (eoan-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-rle-decode-fast [i386] (eoan-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted ruby-jekyll-data [amd64] (eoan-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted rust-lyon-path [amd64] (eoan-proposed) [0.13.2-2]
-queuebot:#ubuntu-release- New: accepted openvr [amd64] (eoan-proposed) [1.5.17~ds1-2]
-queuebot:#ubuntu-release- New: accepted postgresfixture [amd64] (eoan-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted ruby-jekyll-default-layout [amd64] (eoan-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted ruby-jekyll-relative-links [amd64] (eoan-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted rust-freetype-sys [i386] (eoan-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted openvr [i386] (eoan-proposed) [1.5.17~ds1-2]
-queuebot:#ubuntu-release- New: accepted ruby-jekyll-readme-index [amd64] (eoan-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-fuchsia-cprng [amd64] (eoan-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted ruby-acme-client [amd64] (eoan-proposed) [2.0.3-1]
-queuebot:#ubuntu-release- New: accepted rust-freetype-sys [amd64] (eoan-proposed) [0.7.1-1]
#ubuntu-release 2019-08-15
<mwhudson> vorlon: can you kick grub2 along pls
<mwhudson> (at some point in the next 24 hrs, no real hurry!)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (eoan-proposed) [2.04-1ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (eoan-proposed) [2.04-1ubuntu5]
<vorlon> mwhudson: ^^
<mwhudson> vorlon: thanks
<mwhudson> vorlon: why does that happen, is it just so an AA can check there is a grub-signed upload waiting?
<vorlon> mwhudson: it's so that objects don't get signed with the UEFI key without an AA signing off on it
<mwhudson> vorlon: ah makes sense
-queuebot:#ubuntu-release- New binary: r-cran-ica [amd64] (eoan-proposed/none) [1.0-2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-lsei [i386] (eoan-proposed/none) [1.2-0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-lsei [amd64] (eoan-proposed/none) [1.2-0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-metap [amd64] (eoan-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-tximport [amd64] (eoan-proposed/none) [1.12.3+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-lsei [s390x] (eoan-proposed/none) [1.2-0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-future.apply [amd64] (eoan-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-tsne [amd64] (eoan-proposed/universe) [0.1-3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-lsei [armhf] (eoan-proposed/universe) [1.2-0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-lsei [arm64] (eoan-proposed/universe) [1.2-0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-lsei [ppc64el] (eoan-proposed/universe) [1.2-0-1] (no packageset)
<mitya57> vorlon: Debian actually ships a fork of compiz, while we ship mainstream compiz. We do not need compiz-plugins-* source packages at all because we build the corresponding binaries from compiz source.
<mitya57> I think src:compiz-plugins-experimental should be removed from eoan-proposed and added to sync blacklist.
<mitya57> To clarify, upstream compiz is https://launchpad.net/compiz, Debian uses https://gitlab.com/compiz aka compiz-reloaded.
<infinity> mitya57: Is there a reason we can't move to using the Debian sources and maintain one less thing in Ubuntu?
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (disco-proposed/main) [5.0.0-26.27] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (disco-proposed/main) [5.0.0-26.27] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (disco-proposed/main) [5.0.0-26.27] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (disco-proposed) [5.0.0-26.27]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (disco-proposed) [5.0.0-26.27]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (disco-proposed) [5.0.0-26.27]
<mitya57> infinity: That would mean erasing 10 years work that Canonical did on refactoring Compiz and rewriting it in C++ (compiz-reloaded is based on compiz 0.8). Also Unity won't work with compiz-reloaded.
<infinity> mitya57: "Erasing work" is just sunk cost fallacy rearing its ugly head, but the "won't work with Unity" point is the important bit.
<infinity> mitya57: Would still be nice to have Debian and Ubuntu shipping vaguely the same code, but maybe the argument needs to be made in the other direction then.
<xnox> well compiz is such an overloaded term..... each series and forks of it, should have had a separate name =/
<mitya57> Debian tried 0.9 but then reverted to 0.8, unfortunately I don't know their reasons.
<mitya57> The only explanation I can find is in Debian #907640
<ubot5> Debian bug 907640 in compiz "compiz: Migrating to compiz-reloaded?" [Important,Fixed] http://bugs.debian.org/907640
<mitya57> âThe launchpad upstream for compiz has switched to light maintenance mode and will not make further development since Ubuntu has stopped using it.â
<mitya57> I am not using compiz or unity myself, so I'm not the person to make any decision about their future.
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (disco-proposed/main) [5.0.0-1014.14] (core, kernel)
-queuebot:#ubuntu-release- New binary: qtdoc-opensource-src [i386] (eoan-proposed/universe) [5.12.2-1] (kubuntu, qt5)
-queuebot:#ubuntu-release- New binary: qtdoc-opensource-src [ppc64el] (eoan-proposed/universe) [5.12.2-1] (kubuntu, qt5)
-queuebot:#ubuntu-release- New binary: qtdoc-opensource-src [s390x] (eoan-proposed/universe) [5.12.2-1] (kubuntu, qt5)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (disco-proposed) [5.0.0-1014.14]
-queuebot:#ubuntu-release- New binary: qtdoc-opensource-src [armhf] (eoan-proposed/universe) [5.12.2-1] (kubuntu, qt5)
-queuebot:#ubuntu-release- New binary: qtdoc-opensource-src [amd64] (eoan-proposed/universe) [5.12.2-1] (kubuntu, qt5)
-queuebot:#ubuntu-release- New binary: qtdoc-opensource-src [arm64] (eoan-proposed/universe) [5.12.2-1] (kubuntu, qt5)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-59.66] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-59.66] (core, kernel)
<tjaalton> can we get a newer meson in bionic, please?
<seb128> tjaalton, you could be the one doing that SRU if you need it :)
<seb128> I don't think we have a specific maintainer for it
<tjaalton> I'll try
<seb128> tjaalton, is it strictly needed? for fwupdate we patch out the meson build thing to be able to build with an older version which was easier to do
<tjaalton> we miss changes like https://github.com/mesonbuild/meson/commit/12bac512f6497e46ada8ed980cbcb1631506691c which result in asserts in DRI drivers, for instance
<seb128> :-/
<seb128> the problem is that meson updates include some feature and behaviour changes so that's not really trivial to SRU
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-59.66]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-59.66]
<tjaalton> could be
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (bionic-proposed/main) [5.0.0-26.27~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (bionic-proposed/main) [5.0.0-26.27~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [arm64] (bionic-proposed/main) [5.0.0-26.27~18.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (bionic-proposed) [5.0.0-26.27~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (bionic-proposed) [5.0.0-26.27~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [arm64] (bionic-proposed) [5.0.0-26.27~18.04.1]
-queuebot:#ubuntu-release- Unapproved: thermald (bionic-proposed/main) [1.7.0-5ubuntu3 => 1.7.0-5ubuntu4] (core)
-queuebot:#ubuntu-release- Unapproved: rejected thermald [source] (bionic-proposed) [1.7.0-5ubuntu4]
-queuebot:#ubuntu-release- Unapproved: thermald (bionic-proposed/main) [1.7.0-5ubuntu3 => 1.7.0-5ubuntu4] (core)
-queuebot:#ubuntu-release- Unapproved: accepted thermald [source] (bionic-proposed) [1.7.0-5ubuntu4]
-queuebot:#ubuntu-release- Unapproved: thermald (bionic-proposed/main) [1.7.0-5ubuntu4 => 1.7.0-5ubuntu5] (core)
-queuebot:#ubuntu-release- Unapproved: accepted thermald [source] (bionic-proposed) [1.7.0-5ubuntu5]
-queuebot:#ubuntu-release- New binary: linux-signed-gke-5.0 [amd64] (bionic-proposed/universe) [5.0.0-1014.14~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gke-4.15 [amd64] (bionic-proposed/main) [4.15.0-1041.43] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-160.188] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-4.15 [amd64] (bionic-proposed) [4.15.0-1041.43]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-160.188]
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.0 [amd64] (bionic-proposed) [5.0.0-1014.14~18.04.1]
<teward|web> can someone assist me in figuring out where https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/arm64/l/lemonldap-ng/20190815_182233_6ab22@/log.gz is failing?  It's being triggered by the nginx upload but I can't find where the failure exactly happens, nor do I think the failure is nginx /
<teward|web>  httpd related
<vorlon> teward|web: the first thing to do is check whether the failure also happens without the new nginx
<vorlon> and if it is, get the release team to add a 'badtest' hint, and decouple resolving this autopkgtest failure from the nginx package migration
<vorlon> teward|web: but I also see the arm64 autopkgtest failed in connection with an apache2 upload, so maybe it's just a flaky test
<teward|web> vorlon: right that's what i had thought, the headache I have here is, the same i386 tests pass and its only arm and amd64 that failed
<vorlon> sure, hence 'flaky'
<teward|web> yep.  going to run the amd64 tests locally, if the ubuntu-daily LXD images speed up.  The storm overhead here doesn't help the internet speed at all either, nor does the fact it knocked out my power long enough for my backup UPSes to die out and my infra to shut off
<teward|web> at home
<vorlon> well, I've already triggered them on the Ubuntu infra; if they pass the second time, nginx gets let through automatically
<teward|web> right, i actually triggered the amd64 earlier after i noticed the regression, and it still returned as a failure
<teward|web> still want to test it locally too
<vorlon> I only see one amd64 failure listed on http://autopkgtest.ubuntu.com/packages/l/lemonldap-ng/eoan/amd64
<teward|web> my poke might still be in the queue
<teward|web> it's weird though
 * teward|web wonders what deps are defined in the autopkgtests, goes to look
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [5.0.0-1016.17~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (disco-proposed/main) [5.0.0-1016.17] (core, kernel)
<teward|web> vorlon: it LOOKS like the only failure now is amd64
<teward|web> xnox repoked it for arm and that seems to have succeeded
<vorlon> teward|web: both the failure and the repoke listed there are with apache2 as a trigger, not nginx
<vorlon> the nginx/arm64 failure doesn't even show up on the report yet (because the report generation sometimes lags the update_excuses generation)
<teward|web> hmm
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [5.0.0-1016.17~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (disco-proposed) [5.0.0-1016.17]
<teward|web> vorlon: ***weird*** that amd64 passed now... https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/l/lemonldap-ng/20190815_190300_f0da2@/log.gz
<teward|web> that test that failed I *think* is a TOTP test that shouldn't be nginx related I don't think...
<doko> sforshee, apw: binutils and gcc-9 blocked by linux autopkg test failures
<apw> doko, aware, if those are the last issues for those two package let me knwo and i'll hint them out
<doko> apw: they are
<apw> doko, hinted
-queuebot:#ubuntu-release- Unapproved: stress-ng (bionic-proposed/universe) [0.09.25-1ubuntu2 => 0.09.25-1ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New binary: libinputsynth [amd64] (eoan-proposed/none) [0.12.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kdeplasma-applets-xrdesktop [amd64] (eoan-proposed/none) [0.12.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pylint-flask [amd64] (eoan-proposed/universe) [0.5-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libinputsynth [i386] (eoan-proposed/none) [0.12.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libinputsynth [arm64] (eoan-proposed/universe) [0.12.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: volk [i386] (eoan-proposed/universe) [2.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: volk [amd64] (eoan-proposed/universe) [2.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libinputsynth [s390x] (eoan-proposed/universe) [0.12.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: volk [s390x] (eoan-proposed/universe) [2.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libinputsynth [armhf] (eoan-proposed/universe) [0.12.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: volk [armhf] (eoan-proposed/universe) [2.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: volk [arm64] (eoan-proposed/universe) [2.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libinputsynth [ppc64el] (eoan-proposed/universe) [0.12.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: volk [ppc64el] (eoan-proposed/universe) [2.0.0-2] (no packageset)
#ubuntu-release 2019-08-16
-queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu10.25 => 237-3ubuntu10.26] (core)
-queuebot:#ubuntu-release- New source: golang-1.12-race-detector-runtime (eoan-proposed/primary) [0.0+svn332029-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libinputsynth [armhf] (eoan-proposed) [0.12.1-1]
-queuebot:#ubuntu-release- New: accepted libinputsynth [s390x] (eoan-proposed) [0.12.1-1]
-queuebot:#ubuntu-release- New: accepted volk [armhf] (eoan-proposed) [2.0.0-2]
-queuebot:#ubuntu-release- New: accepted volk [s390x] (eoan-proposed) [2.0.0-2]
-queuebot:#ubuntu-release- New: accepted libinputsynth [ppc64el] (eoan-proposed) [0.12.1-1]
-queuebot:#ubuntu-release- New: accepted volk [ppc64el] (eoan-proposed) [2.0.0-2]
-queuebot:#ubuntu-release- New: accepted volk [arm64] (eoan-proposed) [2.0.0-2]
-queuebot:#ubuntu-release- New: accepted kdeplasma-applets-xrdesktop [amd64] (eoan-proposed) [0.12.1-1]
-queuebot:#ubuntu-release- New: accepted libinputsynth [arm64] (eoan-proposed) [0.12.1-1]
-queuebot:#ubuntu-release- New: accepted pylint-flask [amd64] (eoan-proposed) [0.5-3]
-queuebot:#ubuntu-release- New: accepted volk [amd64] (eoan-proposed) [2.0.0-2]
-queuebot:#ubuntu-release- New: accepted libinputsynth [amd64] (eoan-proposed) [0.12.1-1]
-queuebot:#ubuntu-release- New: accepted qtdoc-opensource-src [arm64] (eoan-proposed) [5.12.2-1]
-queuebot:#ubuntu-release- New: accepted libinputsynth [i386] (eoan-proposed) [0.12.1-1]
-queuebot:#ubuntu-release- New: accepted volk [i386] (eoan-proposed) [2.0.0-2]
-queuebot:#ubuntu-release- New: accepted qtdoc-opensource-src [amd64] (eoan-proposed) [5.12.2-1]
-queuebot:#ubuntu-release- New: accepted qtdoc-opensource-src [i386] (eoan-proposed) [5.12.2-1]
-queuebot:#ubuntu-release- New: accepted qtdoc-opensource-src [s390x] (eoan-proposed) [5.12.2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-lsei [ppc64el] (eoan-proposed) [1.2-0-1]
-queuebot:#ubuntu-release- New: accepted qtdoc-opensource-src [armhf] (eoan-proposed) [5.12.2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-lsei [arm64] (eoan-proposed) [1.2-0-1]
-queuebot:#ubuntu-release- New: accepted qtdoc-opensource-src [ppc64el] (eoan-proposed) [5.12.2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-tsne [amd64] (eoan-proposed) [0.1-3-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-tximport [amd64] (eoan-proposed) [1.12.3+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-lsei [amd64] (eoan-proposed) [1.2-0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-lsei [i386] (eoan-proposed) [1.2-0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-metap [amd64] (eoan-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-future.apply [amd64] (eoan-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-lsei [s390x] (eoan-proposed) [1.2-0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-lsei [armhf] (eoan-proposed) [1.2-0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ica [amd64] (eoan-proposed) [1.0-2-1]
-queuebot:#ubuntu-release- New binary: prospector [amd64] (eoan-proposed/universe) [0.12.7-2.1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-npsurv [amd64] (eoan-proposed/universe) [0.4-0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-sctransform [amd64] (eoan-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-sctransform [s390x] (eoan-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-sctransform [i386] (eoan-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-sctransform [arm64] (eoan-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-sctransform [armhf] (eoan-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-sctransform [ppc64el] (eoan-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-onig [amd64] (eoan-proposed/universe) [4.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-onig [ppc64el] (eoan-proposed/universe) [4.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-onig [i386] (eoan-proposed/universe) [4.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-onig [s390x] (eoan-proposed/universe) [4.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted r-cran-sctransform [armhf] (eoan-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-onig [amd64] (eoan-proposed) [4.3.2-1]
-queuebot:#ubuntu-release- New: accepted rust-onig [ppc64el] (eoan-proposed) [4.3.2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-sctransform [ppc64el] (eoan-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-onig [s390x] (eoan-proposed) [4.3.2-1]
-queuebot:#ubuntu-release- New: accepted rust-onig [i386] (eoan-proposed) [4.3.2-1]
-queuebot:#ubuntu-release- New: accepted prospector [amd64] (eoan-proposed) [0.12.7-2.1]
-queuebot:#ubuntu-release- New: accepted r-cran-sctransform [amd64] (eoan-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-sctransform [i386] (eoan-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-npsurv [amd64] (eoan-proposed) [0.4-0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-sctransform [s390x] (eoan-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-sctransform [arm64] (eoan-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New binary: r-cran-corrplot [amd64] (eoan-proposed/none) [0.84-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rann [amd64] (eoan-proposed/none) [2.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-hdrhistogram [amd64] (eoan-proposed/none) [6.3.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-gprofiler [amd64] (eoan-proposed/none) [0.6.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-lzma-sys [i386] (eoan-proposed/none) [0.1.14-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rann [i386] (eoan-proposed/none) [2.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rann [s390x] (eoan-proposed/universe) [2.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gdk [amd64] (eoan-proposed/universe) [0.11.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-mio-extras [amd64] (eoan-proposed/universe) [2.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rsvd [amd64] (eoan-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pool [amd64] (eoan-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-lzma-sys [amd64] (eoan-proposed/universe) [0.1.14-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fonts-havana [amd64] (eoan-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gdk [s390x] (eoan-proposed/universe) [0.11.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-future.batchtools [amd64] (eoan-proposed/universe) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-sized-chunks [amd64] (eoan-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-atk [amd64] (eoan-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-hdrhistogram [i386] (eoan-proposed/universe) [6.3.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-mio-extras [i386] (eoan-proposed/universe) [2.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-native-tls [i386] (eoan-proposed/universe) [0.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-sized-chunks [i386] (eoan-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-atk [i386] (eoan-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-native-tls [amd64] (eoan-proposed/universe) [0.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-lzma-sys [s390x] (eoan-proposed/universe) [0.1.14-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pool [i386] (eoan-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gdk [i386] (eoan-proposed/universe) [0.11.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-hdrhistogram [s390x] (eoan-proposed/universe) [6.3.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-atk [s390x] (eoan-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-native-tls [s390x] (eoan-proposed/universe) [0.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-sized-chunks [s390x] (eoan-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-mio-extras [s390x] (eoan-proposed/universe) [2.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pool [s390x] (eoan-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rann [arm64] (eoan-proposed/universe) [2.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-hdrhistogram [arm64] (eoan-proposed/universe) [6.3.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-lzma-sys [arm64] (eoan-proposed/universe) [0.1.14-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-mio-extras [arm64] (eoan-proposed/universe) [2.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gdk [ppc64el] (eoan-proposed/universe) [0.11.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-lzma-sys [armhf] (eoan-proposed/universe) [0.1.14-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-hdrhistogram [armhf] (eoan-proposed/universe) [6.3.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-mio-extras [armhf] (eoan-proposed/universe) [2.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rann [armhf] (eoan-proposed/universe) [2.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gdk [arm64] (eoan-proposed/universe) [0.11.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rann [ppc64el] (eoan-proposed/universe) [2.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gdk [armhf] (eoan-proposed/universe) [0.11.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-atk [arm64] (eoan-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-atk [ppc64el] (eoan-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-native-tls [armhf] (eoan-proposed/universe) [0.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pool [armhf] (eoan-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-atk [armhf] (eoan-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pool [arm64] (eoan-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-hdrhistogram [ppc64el] (eoan-proposed/universe) [6.3.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-sized-chunks [arm64] (eoan-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-native-tls [arm64] (eoan-proposed/universe) [0.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-sized-chunks [armhf] (eoan-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-lzma-sys [ppc64el] (eoan-proposed/universe) [0.1.14-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-mio-extras [ppc64el] (eoan-proposed/universe) [2.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-native-tls [ppc64el] (eoan-proposed/universe) [0.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pool [ppc64el] (eoan-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-sized-chunks [ppc64el] (eoan-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: uhd [i386] (eoan-proposed/universe) [3.14.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: uhd [s390x] (eoan-proposed/universe) [3.14.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: uhd [amd64] (eoan-proposed/universe) [3.14.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: uhd [ppc64el] (eoan-proposed/universe) [3.14.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted uhd [amd64] (eoan-proposed) [3.14.1.0-2]
-queuebot:#ubuntu-release- New: accepted uhd [s390x] (eoan-proposed) [3.14.1.0-2]
-queuebot:#ubuntu-release- New: accepted uhd [ppc64el] (eoan-proposed) [3.14.1.0-2]
-queuebot:#ubuntu-release- New: accepted rust-lzma-sys [ppc64el] (eoan-proposed) [0.1.14-1]
-queuebot:#ubuntu-release- New: accepted rust-native-tls [arm64] (eoan-proposed) [0.2.3-1]
-queuebot:#ubuntu-release- New: accepted rust-pool [ppc64el] (eoan-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted rust-sized-chunks [ppc64el] (eoan-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted rust-mio-extras [ppc64el] (eoan-proposed) [2.0.5-1]
-queuebot:#ubuntu-release- New: accepted rust-sized-chunks [armhf] (eoan-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted rust-native-tls [ppc64el] (eoan-proposed) [0.2.3-1]
-queuebot:#ubuntu-release- New: accepted uhd [i386] (eoan-proposed) [3.14.1.0-2]
-queuebot:#ubuntu-release- New: accepted r-cran-rann [ppc64el] (eoan-proposed) [2.6.1-1]
-queuebot:#ubuntu-release- New: accepted rust-atk [armhf] (eoan-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-hdrhistogram [ppc64el] (eoan-proposed) [6.3.4-1]
-queuebot:#ubuntu-release- New: accepted rust-pool [arm64] (eoan-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted rust-sized-chunks [arm64] (eoan-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted rust-atk [arm64] (eoan-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-native-tls [armhf] (eoan-proposed) [0.2.3-1]
-queuebot:#ubuntu-release- New: accepted rust-atk [ppc64el] (eoan-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-pool [armhf] (eoan-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rann [armhf] (eoan-proposed) [2.6.1-1]
-queuebot:#ubuntu-release- New: accepted rust-gdk [armhf] (eoan-proposed) [0.11.0-1]
-queuebot:#ubuntu-release- New: accepted rust-lzma-sys [arm64] (eoan-proposed) [0.1.14-1]
-queuebot:#ubuntu-release- New: accepted rust-mio-extras [armhf] (eoan-proposed) [2.0.5-1]
-queuebot:#ubuntu-release- New: accepted rust-gdk [arm64] (eoan-proposed) [0.11.0-1]
-queuebot:#ubuntu-release- New: accepted rust-mio-extras [arm64] (eoan-proposed) [2.0.5-1]
-queuebot:#ubuntu-release- New: accepted rust-hdrhistogram [armhf] (eoan-proposed) [6.3.4-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rann [arm64] (eoan-proposed) [2.6.1-1]
-queuebot:#ubuntu-release- New: accepted rust-hdrhistogram [arm64] (eoan-proposed) [6.3.4-1]
-queuebot:#ubuntu-release- New: accepted rust-mio-extras [s390x] (eoan-proposed) [2.0.5-1]
-queuebot:#ubuntu-release- New: accepted rust-sized-chunks [s390x] (eoan-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted rust-gdk [ppc64el] (eoan-proposed) [0.11.0-1]
-queuebot:#ubuntu-release- New: accepted rust-pool [s390x] (eoan-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted rust-lzma-sys [armhf] (eoan-proposed) [0.1.14-1]
-queuebot:#ubuntu-release- New: accepted rust-atk [i386] (eoan-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-gdk [i386] (eoan-proposed) [0.11.0-1]
-queuebot:#ubuntu-release- New: accepted rust-lzma-sys [s390x] (eoan-proposed) [0.1.14-1]
-queuebot:#ubuntu-release- New: accepted rust-native-tls [s390x] (eoan-proposed) [0.2.3-1]
-queuebot:#ubuntu-release- New: accepted rust-atk [s390x] (eoan-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-native-tls [i386] (eoan-proposed) [0.2.3-1]
-queuebot:#ubuntu-release- New: accepted rust-hdrhistogram [s390x] (eoan-proposed) [6.3.4-1]
-queuebot:#ubuntu-release- New: accepted rust-sized-chunks [i386] (eoan-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted fonts-havana [amd64] (eoan-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-atk [amd64] (eoan-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-hdrhistogram [i386] (eoan-proposed) [6.3.4-1]
-queuebot:#ubuntu-release- New: accepted rust-native-tls [amd64] (eoan-proposed) [0.2.3-1]
-queuebot:#ubuntu-release- New: accepted r-cran-future.batchtools [amd64] (eoan-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted rust-mio-extras [i386] (eoan-proposed) [2.0.5-1]
-queuebot:#ubuntu-release- New: accepted rust-gdk [s390x] (eoan-proposed) [0.11.0-1]
-queuebot:#ubuntu-release- New: accepted rust-pool [i386] (eoan-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rann [s390x] (eoan-proposed) [2.6.1-1]
-queuebot:#ubuntu-release- New: accepted rust-gdk [amd64] (eoan-proposed) [0.11.0-1]
-queuebot:#ubuntu-release- New: accepted rust-mio-extras [amd64] (eoan-proposed) [2.0.5-1]
-queuebot:#ubuntu-release- New: accepted rust-sized-chunks [amd64] (eoan-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rsvd [amd64] (eoan-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted rust-pool [amd64] (eoan-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted rust-lzma-sys [amd64] (eoan-proposed) [0.1.14-1]
-queuebot:#ubuntu-release- New: accepted r-cran-corrplot [amd64] (eoan-proposed) [0.84-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rann [amd64] (eoan-proposed) [2.6.1-1]
-queuebot:#ubuntu-release- New: accepted rust-hdrhistogram [amd64] (eoan-proposed) [6.3.4-1]
-queuebot:#ubuntu-release- New: accepted r-cran-gprofiler [amd64] (eoan-proposed) [0.6.7-1]
-queuebot:#ubuntu-release- New: accepted rust-lzma-sys [i386] (eoan-proposed) [0.1.14-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rann [i386] (eoan-proposed) [2.6.1-1]
-queuebot:#ubuntu-release- New binary: cgal [s390x] (eoan-proposed/universe) [4.14-4] (no packageset)
-queuebot:#ubuntu-release- New binary: cgal [amd64] (eoan-proposed/universe) [4.14-4] (no packageset)
-queuebot:#ubuntu-release- New binary: cgal [ppc64el] (eoan-proposed/universe) [4.14-4] (no packageset)
-queuebot:#ubuntu-release- New binary: cgal [i386] (eoan-proposed/universe) [4.14-4] (no packageset)
-queuebot:#ubuntu-release- New binary: cgal [arm64] (eoan-proposed/universe) [4.14-4] (no packageset)
-queuebot:#ubuntu-release- New: rejected ibus-avro [source] (bionic-backports) [1.1-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New: rejected ibus-avro [source] (xenial-backports) [1.1-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- New source: ibus-avro (bionic-backports/primary) [1.1-3~ubuntu18.04.1]
-queuebot:#ubuntu-release- New source: ibus-avro (xenial-backports/primary) [1.1-3~ubuntu16.04.1]
-queuebot:#ubuntu-release- New source: ibus-avro (disco-backports/primary) [1.1-3~ubuntu19.04.1]
-queuebot:#ubuntu-release- New: rejected ibus-avro [source] (disco-backports) [1.1-0ubuntu0.19.04.1]
-queuebot:#ubuntu-release- New: accepted ibus-avro [source] (xenial-backports) [1.1-3~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted ibus-avro [source] (bionic-backports) [1.1-3~ubuntu18.04.1]
-queuebot:#ubuntu-release- New: accepted ibus-avro [source] (disco-backports) [1.1-3~ubuntu19.04.1]
-queuebot:#ubuntu-release- New binary: ibus-avro [amd64] (disco-backports/universe) [1.1-3~ubuntu19.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: ibus-avro [amd64] (bionic-backports/universe) [1.1-3~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: ibus-avro [amd64] (xenial-backports/universe) [1.1-3~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ibus-avro [amd64] (bionic-backports) [1.1-3~ubuntu18.04.1]
-queuebot:#ubuntu-release- New: accepted ibus-avro [amd64] (xenial-backports) [1.1-3~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted ibus-avro [amd64] (disco-backports) [1.1-3~ubuntu19.04.1]
<tjaalton> fossfreedom: did you ever test the 32bit kernel I built?
<tjaalton> I'll update the bug
<mdeslaur> is anyone from the SRU team available to push an emergency package?
<mdeslaur> apw: ^
<mdeslaur> rbasak, tjaalton ^
-queuebot:#ubuntu-release- Unapproved: nginx (bionic-proposed/main) [1.14.0-0ubuntu1.4 => 1.14.0-0ubuntu1.5] (ubuntu-server)
<tjaalton> yes
<tjaalton> mdeslaur: which one?
<mdeslaur> hi tjaalton, nginx
<tjaalton> okay
<mdeslaur> it got built without openssl 1.1.1 because openssl isn't in -security yet
<mdeslaur> so I need to build it in -proposed, sanity check it, then release it
<mdeslaur> all today
-queuebot:#ubuntu-release- Unapproved: accepted nginx [source] (bionic-proposed) [1.14.0-0ubuntu1.5]
<mdeslaur> thanks tjaalton
<tjaalton> yw
<mdeslaur> tjaalton: hi! I tested the nginx package, it works ok and fixes my regression. Could you please release it to -updates?
<tjaalton> sure
<mdeslaur> thanks tjaalton
<juliank> mdeslaur: /me goes update nginx on his vps
<juliank> So basically, packages that are linked against openssl 1.1.1 in updates need two uploads for security and updates
<mdeslaur> juliank: yeah, hopefully we'll be able to copy over openssl+zillion packages into -security next week so this insanity will end
<mdeslaur> I honestly completely forgot about it when I did the nginx update this week
<juliank> I don't think I care a lot really, because my nginx config has tls1.3 enabled anyway
<juliank> (I also don't understand why people would turn it off, but that's another topic)
<teward> juliank: re: turning off TLS1.3: policies
<teward> HIPAA, PCI DSS Compliance, etc. all disallow TLS 1.3
<teward> mdeslaur: tjaalton: thanks for the rapid response to handling the nginx 'regression' that was reported
<juliank> mdeslaur: teward: A problem I guess is that unattended-upgrades probably still pulls in the security update, and ignores the one in updates
<juliank> though I haven't trie
<teward> you mean apt
<teward> the issue is versionings
<juliank> apt is fine
<mdeslaur> juliank: yes, but it wouldn't get openssl 1.1.1 yet
<teward> if version in security is higher than version in updates it pulls from security
<teward> which doesn't have 1.1.1 openssl yet
<teward> so it builds against 1.1.0
<teward> hence the need to rebuild AND version bump in -updates for now
<juliank> teward: unattended-upgrades only pulls from security, it ignores -updates
<teward> to get it to pick up on the TLS1.3 symbols and such from OpenSSL.
<teward> juliank: you can configure it to do otherwise
<teward> but you're right
<juliank> So if you upgraded nginx to updates; unattended-upgrades will still install the broken upgrade I think
<teward> that's a "manual sysadmin intervention" headache until 1.1.1 is available in -security as well as -updates
<teward> mdeslaur: i think you said a tentative ETA of next week on that?
<mdeslaur> I was planning on seeing what still needs to be done on monday...I think we're just waiting on the ruby2.5 SRU
<Eickmeyer> vorlon: If you wouldn't mind re-reviewing raysession, I'd appreciate it. It would be good to have some input if there are more changes to be made so those changes can get in before FF.
<Eickmeyer> Additionally, I have seed changes to make when raysession gets greenlighted since it means I can remove some rather obsolete software from the Ubuntu Studio seed since raysession replaces that.
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (bionic-proposed/universe) [20190522-0ubuntu1~18.04.0 => 20190801-0ubuntu1~18.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (xenial-proposed/universe) [20190522-0ubuntu1~16.04.0 => 20190801-0ubuntu1~16.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (disco-proposed/main) [20190522-0ubuntu1~19.04.0 => 20190801-0ubuntu1~19.04.0] (core, ubuntu-cloud)
<vorlon> Eickmeyer: did you run lintian -I over the source?
<vorlon> I: raysession source: wildcard-matches-nothing-in-dep5-copyright src/clients/jackpatch/jacklib.py (paragraph at line 9)
<vorlon> Eickmeyer: src/clients/jackpatch/jacklib.py is a symlink to src/shared/jacklib.py so it's actually the same file and I won't block on this, but it's a bit odd
<Eickmeyer> Yeah, that is odd. I did, but I guess I didn't consider it an issue since it's a symlink. (memory gets fuzzy with the wait).
<Eickmeyer> Also, I would've been certain teward would've run it.
<Eickmeyer> vorlon: ^
<vorlon> Eickmeyer: didn't consider it an issue> ok, but it would've been straightforward to fix the message by using the canonical path of the file
<Eickmeyer> vorlon: Good point. If you'd like me to fix it, I'd be okay for that, but I'd need teward to responsor.
<vorlon> Eickmeyer: I think you should fix it, but I'm not blocking on it
<Eickmeyer> Ok. Will do for the next upload then (whenever that is).
<teward> vorlon: i noticed that, but I was headscratching as it LOOKED like it was there.  That's an oversight on my part, I apologize.  Odd that it's a symlink though...
<teward> (it's always those pesky minor things that get me >.<)
<teward> vorlon: from within the sbuild environment chroot I was using, it didn't *appear* as a symlink so I guess that's my bad?
<teward> again?
<teward> (I'm also running around like a chicken with its head cut off, major networking outage at the workplace)
<teward> (so...)
-queuebot:#ubuntu-release- New: accepted raysession [source] (eoan-proposed) [0.7.2-0ubuntu1]
<Eickmeyer> Thank you, vorlon!
-queuebot:#ubuntu-release- New: accepted cgal [arm64] (eoan-proposed) [4.14-4]
-queuebot:#ubuntu-release- New: accepted cgal [amd64] (eoan-proposed) [4.14-4]
-queuebot:#ubuntu-release- New: accepted cgal [ppc64el] (eoan-proposed) [4.14-4]
-queuebot:#ubuntu-release- New: accepted cgal [i386] (eoan-proposed) [4.14-4]
-queuebot:#ubuntu-release- New: accepted cgal [s390x] (eoan-proposed) [4.14-4]
-queuebot:#ubuntu-release- New binary: raysession [s390x] (eoan-proposed/universe) [0.7.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: raysession [amd64] (eoan-proposed/universe) [0.7.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: raysession [ppc64el] (eoan-proposed/universe) [0.7.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: raysession [i386] (eoan-proposed/universe) [0.7.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: raysession [arm64] (eoan-proposed/universe) [0.7.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: raysession [armhf] (eoan-proposed/universe) [0.7.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-1.12-race-detector-runtime [source] (eoan-proposed) [0.0+svn332029-0ubuntu1]
-queuebot:#ubuntu-release- New binary: golang-1.12-race-detector-runtime [amd64] (eoan-proposed/none) [0.0+svn332029-0ubuntu1] (no packageset)
<vorlon> Eickmeyer, teward: why is raysession not an Arch: all package?
<vorlon> I: raysession: arch-dep-package-has-big-usr-share 5159kB 100%
<teward> as Eickmeyer told me it's because the deps arent in all archs
<teward> and he intentionally only specified the archs that it should build for
<Eickmeyer> teward: No, I said it builds on all archs.
<teward> then why did you not set arch all which is why I ASKED you why the arch setting was otherwise
<teward> that's a miscommunication in that case the way you explained it was "it was set this way intentionally" basically
<Eickmeyer> It's set to any. You may have been referring to lsp-plugins or dfp-plugins at the time.
<Eickmeyer> I can change it to all.
 * Eickmeyer needs to learn the difference between any and all
<Eickmeyer> vorlon: Can you tell me the difference between any and all?
<Eickmeyer> teward: It's set to any, we were talking about lsp-plugins or dfp-plugins at the time you asked abou the arch settings.
<Eickmeyer> vorlon: Additionally, that seems to be a wishlist lintian tag, which is why I didn't catch it.
<vorlon> Eickmeyer: 'all' means there is a single binary package built that works on all architectures. 'any' means the package is expected to be portable to all architectures, but each binary package contains architecture-specific contents generated at build-time (e.g. with a compiler)
<Eickmeyer> vorlon: Then wouldn't "any" be more appropriate?
<vorlon> this appears to be 'all' in nature, and I'd rather get that resolved rather than accepting the current per-arch binaries, since they'll just be a hassle to remove afterwards via proposed-migration
<vorlon> Eickmeyer: why?
<Eickmeyer> Ok, I'll change it to all. Please reject.
<Eickmeyer> vorlon, teward^
-queuebot:#ubuntu-release- New: rejected raysession [amd64] (eoan-proposed) [0.7.2-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected raysession [s390x] (eoan-proposed) [0.7.2-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected raysession [arm64] (eoan-proposed) [0.7.2-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected raysession [i386] (eoan-proposed) [0.7.2-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected raysession [armhf] (eoan-proposed) [0.7.2-0ubuntu1]
<Eickmeyer> teward: Fix pushed, could you upload ASAP?
-queuebot:#ubuntu-release- New: rejected raysession [ppc64el] (eoan-proposed) [0.7.2-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected linux-firmware-dragonboard410 [source] (eoan-proposed) [88-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-1.12-race-detector-runtime [amd64] (eoan-proposed) [0.0+svn332029-0ubuntu1]
<teward> Eickmeyer: putting out workplace networking fires still cant atm will push later in, say, 2 hours?
<teward> if I am lucky
<Eickmeyer> teward: Works for me.
<bryce> vorlon, btw, php ffe is at https://bugs.launchpad.net/ubuntu/+source/php-defaults/+bug/1840334
<ubot5> Ubuntu bug 1840334 in php-defaults (Ubuntu) "[FFe] PHP 7.3 transition" [Undecided,New]
<bryce> vorlon, I'm out next week but looking to start on it Aug 26th
#ubuntu-release 2019-08-17
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1019.21] (no packageset)
-queuebot:#ubuntu-release- New binary: kcov [amd64] (eoan-proposed/universe) [36+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kcov [i386] (eoan-proposed/universe) [36+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: janest-base [amd64] (eoan-proposed/universe) [0.12.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: janest-ocaml-compiler-libs [amd64] (eoan-proposed/universe) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-mccs [i386] (eoan-proposed/universe) [1.1+10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: janest-base [i386] (eoan-proposed/universe) [0.12.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: janest-ocaml-compiler-libs [i386] (eoan-proposed/universe) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lablgtk3 [amd64] (eoan-proposed/universe) [3.0~beta6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-mccs [amd64] (eoan-proposed/universe) [1.1+10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lablgtk3 [i386] (eoan-proposed/universe) [3.0~beta6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kcov [arm64] (eoan-proposed/universe) [36+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kcov [armhf] (eoan-proposed/universe) [36+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: janest-ocaml-compiler-libs [arm64] (eoan-proposed/universe) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: janest-ocaml-compiler-libs [armhf] (eoan-proposed/universe) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-mccs [arm64] (eoan-proposed/universe) [1.1+10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: janest-base [arm64] (eoan-proposed/universe) [0.12.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-mccs [armhf] (eoan-proposed/universe) [1.1+10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lablgtk3 [armhf] (eoan-proposed/universe) [3.0~beta6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: janest-base [armhf] (eoan-proposed/universe) [0.12.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lablgtk3 [arm64] (eoan-proposed/universe) [3.0~beta6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lablgtk3 [s390x] (eoan-proposed/universe) [3.0~beta6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kcov [ppc64el] (eoan-proposed/universe) [36+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: janest-base [s390x] (eoan-proposed/universe) [0.12.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lablgtk3 [ppc64el] (eoan-proposed/universe) [3.0~beta6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: janest-ocaml-compiler-libs [s390x] (eoan-proposed/universe) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-mccs [s390x] (eoan-proposed/universe) [1.1+10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: janest-ocaml-compiler-libs [ppc64el] (eoan-proposed/universe) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: janest-base [ppc64el] (eoan-proposed/universe) [0.12.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-mccs [ppc64el] (eoan-proposed/universe) [1.1+10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [s390x] (eoan-proposed/universe) [1.36.0+dfsg1+llvm-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [amd64] (eoan-proposed/universe) [1.36.0+dfsg1+llvm-2ubuntu1] (no packageset)
<mitya57> vorlon: Hi! You dropped Python 2 support from statsmodels but pandas autopkgtest still depends on it. Can you please take a look?
<mitya57> Maybe wrong channel, but I noticed that because it is one of things blocking sphinx migration.
<ginggs> mitya57: i believe v.orlon's intention is to drop python2 from pandas too
<mitya57> That will work for me :)
<ginggs> mitya57: e.g. see debian #934941
<ubot5> Debian bug 934941 in python-bumps "python-bumps: Please drop unused (build,test) dependency on python{3,}-sklearn" [Minor,Open] http://bugs.debian.org/934941
<mitya57> Nice!
-queuebot:#ubuntu-release- New binary: rustc [i386] (eoan-proposed/universe) [1.36.0+dfsg1+llvm-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [ppc64el] (eoan-proposed/universe) [1.36.0+dfsg1+llvm-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-django-js-asset [amd64] (eoan-proposed/universe) [1.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [armhf] (eoan-proposed/universe) [1.36.0+dfsg1+llvm-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [arm64] (eoan-proposed/universe) [1.36.0+dfsg1+llvm-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: janest-base [amd64] (eoan-proposed/universe) [0.12.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: janest-base [s390x] (eoan-proposed/universe) [0.12.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: janest-base [i386] (eoan-proposed/universe) [0.12.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-rosconsole [amd64] (eoan-proposed/universe) [1.13.10-2] (no packageset)
-queuebot:#ubuntu-release- New binary: janest-base [ppc64el] (eoan-proposed/universe) [0.12.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-rosconsole [i386] (eoan-proposed/universe) [1.13.10-2] (no packageset)
-queuebot:#ubuntu-release- New binary: janest-base [arm64] (eoan-proposed/universe) [0.12.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: janest-base [armhf] (eoan-proposed/universe) [0.12.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-rosconsole [arm64] (eoan-proposed/universe) [1.13.10-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-rosconsole [s390x] (eoan-proposed/universe) [1.13.10-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-rosconsole [armhf] (eoan-proposed/universe) [1.13.10-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-rosconsole [ppc64el] (eoan-proposed/universe) [1.13.10-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-alignlib [amd64] (eoan-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-alignlib [i386] (eoan-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-bids-validator [amd64] (eoan-proposed/universe) [1.2.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-alignlib [arm64] (eoan-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-alignlib [armhf] (eoan-proposed/universe) [0.1.1-1] (no packageset)
<vorlon> mitya57: yeah, and the pandas python2 autopkgtest was already failing on ppc64el which is why I started digging into this... I'll get there soon, I believe :)
-queuebot:#ubuntu-release- New: accepted python-alignlib [arm64] (eoan-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted python-alignlib [i386] (eoan-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New binary: python-alignlib [s390x] (eoan-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-alignlib [armhf] (eoan-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted python-bids-validator [amd64] (eoan-proposed) [1.2.4-1]
-queuebot:#ubuntu-release- New: accepted janest-base [arm64] (eoan-proposed) [0.12.2-2]
-queuebot:#ubuntu-release- New: accepted python-alignlib [amd64] (eoan-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted ros-rosconsole [armhf] (eoan-proposed) [1.13.10-2]
-queuebot:#ubuntu-release- New: accepted ros-rosconsole [ppc64el] (eoan-proposed) [1.13.10-2]
-queuebot:#ubuntu-release- New: accepted janest-base [armhf] (eoan-proposed) [0.12.2-2]
-queuebot:#ubuntu-release- New: accepted ros-rosconsole [i386] (eoan-proposed) [1.13.10-2]
-queuebot:#ubuntu-release- New: accepted ros-rosconsole [arm64] (eoan-proposed) [1.13.10-2]
-queuebot:#ubuntu-release- New: accepted ros-rosconsole [s390x] (eoan-proposed) [1.13.10-2]
-queuebot:#ubuntu-release- New: accepted janest-base [amd64] (eoan-proposed) [0.12.2-2]
-queuebot:#ubuntu-release- New: accepted janest-base [ppc64el] (eoan-proposed) [0.12.2-2]
-queuebot:#ubuntu-release- New: accepted ocaml-mccs [ppc64el] (eoan-proposed) [1.1+10-1]
-queuebot:#ubuntu-release- New: accepted ros-rosconsole [amd64] (eoan-proposed) [1.13.10-2]
-queuebot:#ubuntu-release- New: accepted janest-base [i386] (eoan-proposed) [0.12.2-2]
-queuebot:#ubuntu-release- New: accepted python-django-js-asset [amd64] (eoan-proposed) [1.2.2-1]
-queuebot:#ubuntu-release- New: accepted janest-base [s390x] (eoan-proposed) [0.12.2-2]
-queuebot:#ubuntu-release- New: accepted janest-base [ppc64el] (eoan-proposed) [0.12.2-1]
-queuebot:#ubuntu-release- New: accepted janest-ocaml-compiler-libs [ppc64el] (eoan-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted kcov [ppc64el] (eoan-proposed) [36+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ocaml-mccs [s390x] (eoan-proposed) [1.1+10-1]
-queuebot:#ubuntu-release- New: accepted janest-base [s390x] (eoan-proposed) [0.12.2-1]
-queuebot:#ubuntu-release- New: accepted lablgtk3 [ppc64el] (eoan-proposed) [3.0~beta6-1]
-queuebot:#ubuntu-release- New: accepted janest-ocaml-compiler-libs [s390x] (eoan-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted janest-base [arm64] (eoan-proposed) [0.12.2-1]
-queuebot:#ubuntu-release- New: accepted janest-ocaml-compiler-libs [armhf] (eoan-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted lablgtk3 [armhf] (eoan-proposed) [3.0~beta6-1]
-queuebot:#ubuntu-release- New: accepted ocaml-mccs [arm64] (eoan-proposed) [1.1+10-1]
-queuebot:#ubuntu-release- New: accepted janest-base [armhf] (eoan-proposed) [0.12.2-1]
-queuebot:#ubuntu-release- New: accepted lablgtk3 [s390x] (eoan-proposed) [3.0~beta6-1]
-queuebot:#ubuntu-release- New: accepted lablgtk3 [arm64] (eoan-proposed) [3.0~beta6-1]
-queuebot:#ubuntu-release- New: accepted ocaml-mccs [armhf] (eoan-proposed) [1.1+10-1]
-queuebot:#ubuntu-release- New: accepted janest-base [i386] (eoan-proposed) [0.12.2-1]
-queuebot:#ubuntu-release- New: accepted janest-ocaml-compiler-libs [i386] (eoan-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted kcov [armhf] (eoan-proposed) [36+dfsg-1]
-queuebot:#ubuntu-release- New: accepted lablgtk3 [i386] (eoan-proposed) [3.0~beta6-1]
-queuebot:#ubuntu-release- New: accepted janest-ocaml-compiler-libs [arm64] (eoan-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted lablgtk3 [amd64] (eoan-proposed) [3.0~beta6-1]
-queuebot:#ubuntu-release- New: accepted kcov [arm64] (eoan-proposed) [36+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ocaml-mccs [amd64] (eoan-proposed) [1.1+10-1]
-queuebot:#ubuntu-release- New: accepted janest-base [amd64] (eoan-proposed) [0.12.2-1]
-queuebot:#ubuntu-release- New: accepted kcov [amd64] (eoan-proposed) [36+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ocaml-mccs [i386] (eoan-proposed) [1.1+10-1]
-queuebot:#ubuntu-release- New: accepted janest-ocaml-compiler-libs [amd64] (eoan-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted kcov [i386] (eoan-proposed) [36+dfsg-1]
-queuebot:#ubuntu-release- New binary: python-alignlib [ppc64el] (eoan-proposed/universe) [0.1.1-1] (no packageset)
#ubuntu-release 2019-08-18
-queuebot:#ubuntu-release- New binary: raysession [amd64] (eoan-proposed/universe) [0.7.2-0ubuntu2] (no packageset)
<mitya57> vorlon: thanks for your work on this!
<RikMills> is autopkgtest.ubuntu.com not updating properly?
<RikMills> latest test in "Recent test runs" was 2019-08-17 21:13:06 UTC
<RikMills> RIP autopkgtest.ubuntu.com
#ubuntu-release 2020-08-10
-queuebot:#ubuntu-release- New: accepted macopix [amd64] (groovy-proposed) [3.4.0+dfsg.1-1]
-queuebot:#ubuntu-release- New: accepted macopix [armhf] (groovy-proposed) [3.4.0+dfsg.1-1]
-queuebot:#ubuntu-release- New: accepted macopix [riscv64] (groovy-proposed) [3.4.0+dfsg.1-1]
-queuebot:#ubuntu-release- New: accepted redkite [amd64] (groovy-proposed) [0.8.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted redkite [armhf] (groovy-proposed) [0.8.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted redkite [riscv64] (groovy-proposed) [0.8.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted macopix [arm64] (groovy-proposed) [3.4.0+dfsg.1-1]
-queuebot:#ubuntu-release- New: accepted macopix [s390x] (groovy-proposed) [3.4.0+dfsg.1-1]
-queuebot:#ubuntu-release- New: accepted redkite [ppc64el] (groovy-proposed) [0.8.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted macopix [ppc64el] (groovy-proposed) [3.4.0+dfsg.1-1]
-queuebot:#ubuntu-release- New: accepted redkite [s390x] (groovy-proposed) [0.8.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted redkite [arm64] (groovy-proposed) [0.8.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted bslizr [source] (groovy-proposed) [1.2.6-0ubuntu1]
-queuebot:#ubuntu-release- New binary: bsequencer [riscv64] (groovy-proposed/universe) [1.4.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: bshapr [riscv64] (groovy-proposed/universe) [0.9-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted bsequencer [amd64] (groovy-proposed) [1.4.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted bsequencer [armhf] (groovy-proposed) [1.4.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted bsequencer [riscv64] (groovy-proposed) [1.4.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted bsequencer [arm64] (groovy-proposed) [1.4.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted bsequencer [s390x] (groovy-proposed) [1.4.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted bsequencer [ppc64el] (groovy-proposed) [1.4.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted bshapr [amd64] (groovy-proposed) [0.9-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted bshapr [armhf] (groovy-proposed) [0.9-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted bshapr [riscv64] (groovy-proposed) [0.9-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted bshapr [arm64] (groovy-proposed) [0.9-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted bshapr [s390x] (groovy-proposed) [0.9-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted bshapr [ppc64el] (groovy-proposed) [0.9-0ubuntu1]
-queuebot:#ubuntu-release- New binary: xrayutilities [riscv64] (groovy-proposed/universe) [1.6.0-3] (no packageset)
<cpaelzer> ubuntu-archive: could one take a look at this removal https://bugs.launchpad.net/ubuntu/+source/sgabios/+bug/1890097 ?
<ubot5> Ubuntu bug 1890097 in sgabios (Ubuntu) "[RM] sgabios - swallowed by the only user (qemu)" [Undecided,New]
<cpaelzer> thank you RAOF
<RAOF> NP
<sil2100> xnox: thanks for the seeds fix for bionic d-i!
<sil2100> I'll check if all is in place and respin what's needed
 * sil2100 forgot about checking the seeds, this sounds like a good thing to have on the checklist
<sil2100> Ok, looks like it's safe to just respin the d-i images
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Bionic 18.04.5] has been updated (20200810)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Bionic 18.04.5] has been updated (20200810)
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Bionic 18.04.5] has been updated (20200810)
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Bionic 18.04.5] has been updated (20200810)
-queuebot:#ubuntu-release- New: accepted xrayutilities [amd64] (groovy-proposed) [1.6.0-3]
-queuebot:#ubuntu-release- New: accepted xrayutilities [armhf] (groovy-proposed) [1.6.0-3]
-queuebot:#ubuntu-release- New: accepted xrayutilities [riscv64] (groovy-proposed) [1.6.0-3]
-queuebot:#ubuntu-release- New: accepted xrayutilities [arm64] (groovy-proposed) [1.6.0-3]
-queuebot:#ubuntu-release- New: accepted xrayutilities [s390x] (groovy-proposed) [1.6.0-3]
-queuebot:#ubuntu-release- New: accepted xrayutilities [ppc64el] (groovy-proposed) [1.6.0-3]
<sil2100> juliank: hmm, so in the focal-proposed queue I see two shim syncs
<sil2100> juliank: I assume I can just remove the older one?
<juliank> sil2100: Yes, the older one is source-only, the newer one has binaries too
-queuebot:#ubuntu-release- Unapproved: rejected shim-signed [source] (focal-proposed) [1.40.4]
<juliank> I accidentally synced source-only first time :(
<juliank> syncing is hard!
<sil2100> juliank: hm, weird, so the tooling isn't very helpful as I see binaries for both of the syncs (at least for focal)! But yeah, let me reject the older one then ;)
-queuebot:#ubuntu-release- Packageset: Added bchoppr to ubuntustudio in groovy
-queuebot:#ubuntu-release- Packageset: Added bslizr to ubuntustudio in groovy
-queuebot:#ubuntu-release- Unapproved: rejected shim [sync] (bionic-proposed) [15+1552672080.a4a1fbe-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: rejected shim [sync] (focal-proposed) [15+1552672080.a4a1fbe-0ubuntu2]
<LocutusOfBorg> hello release team, is it possibile to do something for multipath-tools udeb in main? maybe move them to universe?
<LocutusOfBorg> e.g. libaio1-udeb liburcu6-udeb sg3-udeb
<LocutusOfBorg> mmm they have been already moved to universe in groovy
<LocutusOfBorg>  multipath-udeb | 0.8.4-1ubuntu1                 | groovy/universe/debian-installer      | amd64, arm64, armhf, ppc64el, riscv64, s390x
<LocutusOfBorg>  multipath-udeb | 0.8.4-2ubuntu1                 | groovy-proposed/main/debian-installer | amd64, arm64, armhf, ppc64el, riscv64, s390x
<LocutusOfBorg> maybe just moving multipath-udeb to universe should fix that...
<LocutusOfBorg> who did promote it to main again? ^^
<cjwatson> Nobody
<LocutusOfBorg> mmm how did it move then?
<cjwatson> It didn't :)
<LocutusOfBorg> hello Laney, looks like ppc64el fails with ENOSPACE... https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/ppc64el/d/distro-info/20200810_100125_f0294@/log.gz
<LocutusOfBorg> mmm cjwatson I can't really understand lol :)
<cjwatson> vorlon moved it from main to universe in release, but at the time it was in both release and proposed
<LocutusOfBorg> oh.... :D
<cjwatson> Override changes don't propagate automatically in that situation
<cjwatson> You can see this on https://launchpad.net/ubuntu/groovy/amd64/multipath-udeb
<LocutusOfBorg> so, moving the one in proposed to universe "heals" it
<cjwatson> I expect so; I'll do that now
<LocutusOfBorg> lovely thanks!
<cjwatson> Done
<LocutusOfBorg> I'm thinking about making the tool smarter, to give a warning if something in proposed exists...
<Laney> LocutusOfBorg: yeah I'm fixing it, calculix-cgx is inifintely outputting "ERROR: not valid" to its log
<LocutusOfBorg> :/ thanks
<Laney> going to blacklist that
<LocutusOfBorg> interesting, allowSysFlag seems set to 1, so I don't understand why it is going into that else branch... shouldn't you just create a cgx file to let it run sys commands?
<Laney> I think if you want to debug it, the maintainer would be a better person to do that with :p
-queuebot:#ubuntu-release- Packageset: Added libref-util-perl to i386-whitelist in groovy
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (focal-proposed/main) [5.4.0-43.47] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (focal-proposed/main) [5.4.0-43.47] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (focal-proposed/main) [5.4.0-43.47] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (focal-proposed/main) [5.4.0-43.47] (core, kernel)
<ahasenack> hello ubuntu-archive, memcached failed to build on riscv64 (https://launchpad.net/ubuntu/+source/memcached/1.6.6-1), and I have gearmand that is not building on riscv64 because of this missing dep (https://launchpad.net/ubuntu/+source/gearmand/1.1.19.1+ds-2/+build/19782640)
<ahasenack> yet memcached migrated
<ahasenack> but gearmand is now stuck: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gearmand
<ahasenack> or is it because of sphinx? hmm
<ahasenack> hm, I'm thinking it's because of sphinx, still many tests to go there
<seb128> ahasenack, hey, the previous version of memcached didn't build on riscv either so that wasn't a regression and britney had no reason to block it
<seb128> ahasenack, but yeah, gearmand is blocked by its depends on sphinx
<seb128> the 'not considered' is the clue that this depends is problematic
<seb128> but it sounds like it's going to need work to be candidate
<seb128> several red tests
<ahasenack> yeah
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (focal-proposed) [5.4.0-43.47]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (focal-proposed) [5.4.0-43.47]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (focal-proposed) [5.4.0-43.47]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (focal-proposed) [5.4.0-43.47]
 * RikMills realises he really needs to update the Kubuntu packageset!
<slyon> Hey core-devs! Could somebody please review/sponsor my fix for bug #1889138 (debdiff attached) â so I can move forward with getting sbuild/dpkg migrated from -proposed?
<ubot5> bug 1889138 in procenv (Ubuntu Groovy) "procenv is FTBFS in Groovy" [Undecided,New] https://launchpad.net/bugs/1889138
<seb128> slyon, do you plan to mp the fix upstream?
<slyon> seb128: I think that would be useful and I want to do that
<seb128> slyon, please do then :-) also #ubuntu-devel is a better place to ask for sponsoring, that's not a release issue
<slyon> seb128: I just did: https://github.com/jamesodhunt/procenv/pull/16 â Thanks, I'll ask in #ubuntu-devel then!
<gitbot> jamesodhunt issue (Pull request) 16 in procenv "Fix GCC-10 build when used with -Werror=format-overflow= (Fixes #15)" [Open]
<seb128> slyon, thanks
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-113.114] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-113.114] (core, kernel)
<rbalint> doko i've added https://bazaar.launchpad.net/~ubuntu-archive/+junk/sync-blacklist/view/head:/extra-removals.txt to https://wiki.ubuntu.com/PlusOneMaintenanceTeam/Specs/Infrastructure until the whole process around it is documented even better
<seb128> rbalint, thanks
-queuebot:#ubuntu-release- New binary: bchoppr [ppc64el] (groovy-proposed/universe) [1.6.4-0ubuntu1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: bslizr [amd64] (groovy-proposed/universe) [1.2.8-0ubuntu1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: bslizr [s390x] (groovy-proposed/universe) [1.2.8-0ubuntu1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: bchoppr [s390x] (groovy-proposed/universe) [1.6.4-0ubuntu1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: bslizr [ppc64el] (groovy-proposed/universe) [1.2.8-0ubuntu1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: bchoppr [arm64] (groovy-proposed/universe) [1.6.4-0ubuntu1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: bslizr [arm64] (groovy-proposed/universe) [1.2.8-0ubuntu1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: bchoppr [armhf] (groovy-proposed/universe) [1.6.4-0ubuntu1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: bchoppr [amd64] (groovy-proposed/universe) [1.6.4-0ubuntu1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: bslizr [armhf] (groovy-proposed/universe) [1.2.8-0ubuntu1] (ubuntustudio)
<Eickmeyer> Should I be worried about bslizr or bchoppr FTBFS in risc64?
<Eickmeyer> In other words, will that prevent migration?
<seb128> not if they haven't build previously on those archs
-queuebot:#ubuntu-release- Unapproved: rpcbind (xenial-proposed/main) [0.2.3-0.2ubuntu0.1 => 0.2.3-0.2ubuntu0.16.04.1] (core)
<Eickmeyer> seb128: Thanks. It hasn't built previously for that, so it looks like it's going to be good.
<Eickmeyer> ubuntu-archive: Where are we at with reviewing mcpdisp, new-session-manager, and dragonfly-reverb? I realize my email about this was rather rude and apologize (even apologized in the email). I do want to thank whoever approved the other 5 packages that were waiting. :)
<vorlon> Eickmeyer: I don't know who's been reviewing, but I've started looking at dragonfly-reverb this morning; have you seen the lintian -I output which reports issues with debian/copyright?
<vorlon> I: dragonfly-reverb source: unused-file-paragraph-in-dep5-copyright paragraph at line 144
<vorlon> etc
<Eickmeyer> vorlon: That should be an easy fix, and I'll take a second look at it. Last time I worked on that package was in March where it sat in queue and never got looked at for focal.
<cjwatson> I did some reviewing to help out a bit - it's not my usual wheelhouse these days so don't count on me for more
<Eickmeyer> cjwatson: Understood, and thank you. :)
<vorlon> Eickmeyer: ok, do you want to clean up debian/copyright and reupload? since license review is a key part of source package review, that would speed things up
<Eickmeyer> vorlon: Yep, can do. I'll have to bug teward to upload it for me though (this ping is me bugging him).
<vorlon> :)
-queuebot:#ubuntu-release- Unapproved: grub2 (groovy-proposed/main) [2.04-1ubuntu28 => 2.04-1ubuntu28] (core)
<bdmurray> Laney: Did you update autopkgtest-cloud on the server?
<bdmurray> I want to rerun skimage now that's in big_packages
<Laney> bdmurray: I did about 6 hours ago, so depends when said commit was made
<Laney> as to whether it's effective
<bdmurray> Laney: on Thursday so it should be good
<bdmurray> Laney: Is there any way to track when it is updated?
<Laney> not afaik
-queuebot:#ubuntu-release- Unapproved: grub2 (groovy-proposed/main) [2.04-1ubuntu28 => 2.04-1ubuntu28] (core)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (groovy-proposed) [2.04-1ubuntu28]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (groovy-proposed) [2.04-1ubuntu28]
-queuebot:#ubuntu-release- New: rejected dragonfly-reverb [source] (groovy-proposed) [3.2.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-113.114]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-113.114]
<vorlon> Eickmeyer: new-session-manager also has a typo in debian/copyright, s/scr/src/; nothing that I consider blocking approval but it should be fixed
<Eickmeyer> vorlon: Thanks, I'll take a look there. Should be easy.
<Eickmeyer> Probably my personal typo. :)
<vorlon> Eickmeyer: one concern about this package is the generic name. 'session-manager' is used elsewhere in the archive to refer to x-session-manager, which is a completely different kind of session.  Could this package name be qualified somehow to better show what it is, or who the upstream is?
<vorlon> (cf mate-session-manager and ukui-session-manager)
<Eickmeyer> vorlon: So, it's a replacement for non-session-manager. They forked it to make new-session-manager and make it 100% compatible since the original non-session-manager developer was uncooperative, would curse people for pull requests and contributions, yet licensed it GPL.
<Eickmeyer> vorlon: I was hoping the description would explain that it's for audio, including the category.
<vorlon> yes, the description makes sense, but as a namespace question the generic name of the package makes me uncomfortable
<Eickmeyer> What would you suggest?
<vorlon> would linuxaudio-new-session-manager be a better name?
<Eickmeyer> I don't see why not. The only thing is the binary is new-session-manager with a symlink to it from non-session-manager. Would the package name confuse people?
<vorlon> I don't think it would
<Eickmeyer> Ok, that's an easy change regardless.
<vorlon> ok
<LocutusOfBorg> Err:101 http://ftpmaster.internal/ubuntu groovy/main amd64 libmtdev1 amd64 1.1.6-1
<LocutusOfBorg>   Data left in buffer [IP: 91.189.89.99 80]
<LocutusOfBorg> mmm what is going on?
<LocutusOfBorg> https://launchpadlibrarian.net/492750342/buildlog_ubuntu-groovy-amd64.virtualbox-hwe_6.1.12-dfsg-9ubuntu1.20.10.1_BUILDING.txt.gz
<fyf> please direct me elsewhere if offtopic. Are there channels to discuss working at ubuntu + how to get better at working there? is a github required or launchpad account enough?
<Eickmeyer> vorlon: Go ahead and reject new-session-manager and dragonfly-reverb for now. Fixes are in as requested, just need teward (or yourself, if you want, they're at lp:new-session-manager and lp:dragonfly-reverb respectively) to re-upload.
<Eickmeyer> Of course, you've probably rejected already. heh
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Xenial 16.04.7] has been updated (20200810)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Xenial 16.04.7] has been updated (20200810)
<bdmurray> Laney: Is there a way to tell if the test ran on a "big_packages" unit?
<ddstreet> bdmurray for any arch besides armhf, grep the output for 'make -j4' since big_packages is the only type with more than 1 cpu
<ddstreet> except armhf which is always 4 cpus, but inside a container
<bdmurray> ddstreet: Oh that sounds useful but I'm not seeing make at all https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/amd64/s/skimage/20200810_170805_8946a@/log.gz
<ddstreet> ah well not sure how to check in that case then
<ddstreet> bdmurray if you download the 'result.tar' file for the test, i think the 'testinfo.json' it contains includes the item 'nproc' which tells how many cpus the testbed had
<bdmurray> ddstreet: hunh, I didn't realize result.tar was a thing
<ddstreet> yeah, log.gz, result.tar, and artifacts.tar.gz
<bdmurray> only 2 of those are linked to
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (focal-proposed/main) [2.664.4 => 2.664.5] (desktop-core, i386-whitelist)
<bdmurray> Laney, vorlon: Did I miss something with this commit? https://git.launchpad.net/autopkgtest-cloud/commit/?id=02041e41693c909e25f6d87b45b18e11af9d1a83 arm64 and ppc64el are running on "big" units but amd64 is not.
<vorlon> bdmurray: amd64 isn't in bos0[12]
<vorlon> the amd64 regions are lcy01, lgw01
<bdmurray> which is worker-canonistack then?
<bdmurray> or just worker.conf?
<bdmurray> seems like worker.conf
<vorlon> bdmurray: correct, worker.conf
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.45 => 2.525.46] (desktop-core)
<cjwatson> LocutusOfBorg: I'm not sure, but I think that might be an apt regression?  https://launchpad.net/ubuntu/+source/apt/2.1.9
-queuebot:#ubuntu-release- New: rejected new-session-manager [source] (groovy-proposed) [1.3.2-0ubuntu1]
<seb128> builds are randomly failing in groovy, I uploaded/synced a bunch of packages and most builds hit errors like
<seb128> E: Failed to fetch http://ftpmaster.internal/ubuntu/pool/main/libx/libxxf86vm/libxxf86vm1_1.1.4-1build1_amd64.deb  Data left in buffer [IP: 91.189.89.99 80]
<bdmurray> vorlon: Okay, I've updated that file. Can you update the environment?
<vorlon> bdmurray: done
<xnox> juliank:  ^^^^
<vorlon> Eickmeyer: ideally packages like mcpdisp would list an ubuntustudio address as the maintainer, rather than just Ubuntu Developers more generally
-queuebot:#ubuntu-release- New: accepted mcpdisp [source] (groovy-proposed) [0.1.2-0ubuntu1]
-queuebot:#ubuntu-release- New binary: mcpdisp [s390x] (groovy-proposed/none) [0.1.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: mcpdisp [ppc64el] (groovy-proposed/none) [0.1.2-0ubuntu1] (no packageset)
<vorlon> jibel: do you know about the new pattern of using Build-Depends: debhelper-compat (= 13)?  Nicer than having to repeat between debian/control and debian/compat (kstore)
-queuebot:#ubuntu-release- New: accepted kstore [source] (groovy-proposed) [0.1.0]
-queuebot:#ubuntu-release- New binary: mcpdisp [arm64] (groovy-proposed/none) [0.1.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: mcpdisp [armhf] (groovy-proposed/none) [0.1.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kstore [ppc64el] (groovy-proposed/none) [0.1.0] (no packageset)
-queuebot:#ubuntu-release- New binary: kstore [amd64] (groovy-proposed/none) [0.1.0] (no packageset)
-queuebot:#ubuntu-release- New binary: kstore [s390x] (groovy-proposed/none) [0.1.0] (no packageset)
-queuebot:#ubuntu-release- New: rejected telegraf [source] (groovy-proposed) [1.15.1+ds1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: kstore [armhf] (groovy-proposed/none) [0.1.0] (no packageset)
-queuebot:#ubuntu-release- New binary: kstore [arm64] (groovy-proposed/none) [0.1.0] (no packageset)
-queuebot:#ubuntu-release- New binary: kstore [riscv64] (groovy-proposed/none) [0.1.0] (no packageset)
<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!
<Eickmeyer> vorlon: That makes sense, but for background, that address is the result of the update-maintainers command, so if that shouldn't be used then that would be good. Additionally, I don't have an ubuntustudio address, and it would likely throw the same lintian error.
<Eickmeyer> Rather, if update-maintainers shouldn't be used, then something needs to be updated/documented somewhere.
<Eickmeyer> vorlon: Also, mcpdisp FTBFS, looks like it had a package installation hiccup on downloading build-deps.
<Eickmeyer> Not sure if there's anything you can do on your end.
<bdmurray> Eickmeyer: you might want to look at the manual for update-maintainer to better understand when it should be used.
<Eickmeyer> teward: ^
<Eickmeyer> bdmurray: teward is the one who told me to use it.
<bdmurray> Eickmeyer: it'd still be good if you looked at it
<Eickmeyer> bdmurray: I did.
<Eickmeyer> There's not much to it.
<bdmurray> There's a "SEE ALSO" link which has "more to it"
<bdmurray> update-mainter is a script used to just change the Maintainer field when ubuntu is introducing packaging differences from debian
<bdmurray> for native packages e.g. whoopsie there is no need to change the Maintainer field because the package does not exist in debian
<Eickmeyer> bdmurray: Ok, so what you're saying is it should not be used unless we're introducing changes/updating from a Debian package.
<bdmurray> That is correct
<Eickmeyer> bdmurray: Ok, this is good to know. I thought it was for brand-new packages as well, so I'll probably throw my own .ubuntu address in the maintainer section then.
<vorlon> Eickmeyer: ftbfs> probably related to what seb128 mentioned?
<Eickmeyer> vorlon: Yep, 100%.
<vorlon> I've hit the retry button
<Eickmeyer> Ok.
<Eickmeyer> vorlon: Yeah, still FTBFS for what looks like the same reason.
<vorlon> ok; we'll probably need a mass-retry of those failures at some point
<Eickmeyer> Yep. No worries.
<teward> bdmurray: signing fails on attempting to sign/upload/build with -0ubuntuX in the rev no
<teward> unless there's a way to override?
<cjwatson> What's the failure message?
<cjwatson> Signing shouldn't care about the version
<teward> well Eickmeyer is using a semi-gbp method
<teward> so all i get is the source no changes file to sing
<teward> sign* and gbp (and git ubuntu) keep trying to build the package :P
<cjwatson> Uh
<cjwatson> This isn't clear enough to debug, sorry
<teward> cjwatson: i'm in the hospital recovering from having my appendix removed sue me
<teward> i don't have the details available on hand all i know is it errors hard
<cjwatson> Yep, totally fair, just saying probably can't debug without a transcript
<teward> yep the error was along the line of version string suggests ubuntu changes but maintainer is not @ubuntu address
<teward> something along those lines
<cjwatson> Oh, that's not signing then
<teward> as i stataedL
<teward> stated*
<teward> all I get is the source code
<teward> gbp and even old school debuild require to build the _changes file :p
<teward> and then it just fubars
<cjwatson> That only happens if DEBEMAIL contains ubuntu.com
<cjwatson> Or rather it's only an error if that is the case
<teward> hmm well i do sign with @ubuntu.com so maybe that's the problem... *shrugs*
<cjwatson> You can temporarily set DEBEMAIL to something else for the duration of building the source package
<cjwatson> Or you can make sure that the Maintainer has the substring 'ubuntu' in it
<cjwatson> Either works
<teward> makes sense but if Eickmeyer simply adjusts maintainer for the stuff he's going to maintaion to his @ubuntu address that'll solve the headache
<teward> i'mma focus on healing up first so :p
<cjwatson> Right, indeed!
<cjwatson> When I'm building something for a PPA and just Do Not Care I tend to just ram it through with DEBEMAIL=cjwatson@debian.org debuild -S.  When uploading to Ubuntu I'd fix up Maintainer
<teward> also half-roped into review of a backport in #ubuntu-devel so
<teward> *blames sarnold and rbasak*
<teward> cjwatson: ack, i might spin a local script a-la update-maintainer to update Maintainer accordingly :P
<teward> for now though
<teward> recovery
<Eickmeyer> cjwatson, teward: I'll go ahead and update to my address as I go from here on out.
<teward> ... and figuring out why my left arm just lost slight feeling in it...
<teward> Eickmeyer: ack
<teward> well this is disconcerting: E: Failed to fetch http://ftpmaster.internal/ubuntu/pool/main/libx/libxinerama/libxinerama1_1.1.4-2_amd64.deb  Data left in buffer [IP: 91.189.89.99 80]
<teward> anyone want to go and figure out why that's failing repeatedly for mcpdist amd64 and risc?
<cjwatson> teward: Brought up a couple of times above - looks like an apt regression but I don't think the apt maintainer has had a chance to dig into it yet
<vorlon> is that apt in groovy? do we need to roll back?
-queuebot:#ubuntu-release- New: accepted bchoppr [amd64] (groovy-proposed) [1.6.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted bchoppr [armhf] (groovy-proposed) [1.6.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted bchoppr [s390x] (groovy-proposed) [1.6.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted bchoppr [arm64] (groovy-proposed) [1.6.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted bchoppr [ppc64el] (groovy-proposed) [1.6.4-0ubuntu1]
#ubuntu-release 2020-08-11
<teward> vorlon: that be in Groovy yes
<teward> vorlon: do we need to wait for the apt maintainer first?
<teward> cjwatson: well it's failing multiple studio builds so it's on the radar for "this is broken hard"
<teward> as virtually all studio packages Eickmeyer's trying to get out of proposed and NEW dep on it
<teward> so it kind of is breaking Studio stuff :P
<teward> haven't noticed if there's any OTHER packages of mine affected (triggering PPA builds in Groovy of xca, vmfs6-tools, nginx "soon")
<teward> but......
<teward> not sure if you should rollback until someone fixes it or not
<teward> ODDLY ENOUGH the fails are only in amd64 and risc, somehow the builds for mcpdist in other archs succeeded
<vorlon> teward: is this happening with the -proposed version of apt?
<vorlon> since apt hasn't updated in the release pocket since July 9
<vorlon> if so, I think we should just bounce 2.1.9 out of -proposed
<vorlon> and let juliank look it over at his leisure
<vorlon> teward: amd64 and riscv64 have commonality in terms of which network the builders run on, vs the other architectures
<wgrant> teward, vorlon: Specifically, amd64 and riscv64 are talking to Apache, while the others are usually talking to Squid.
<cjwatson> vorlon: The reports I've seen have been with apt from groovy-proposed.  I haven't done any kind of exhaustive analysis
<cjwatson> But I think rolling back is probably appropriate here
<wgrant> The changes in groovy-proposed look very very suspicious, and it's clearly only that version that is showing trouble.
<wgrant> So yeah, backing 2.1.9 out of groovy-proposed seems the right path.
<vorlon> ok, removing
<vorlon> juliank: ^^ apt 2.1.9 removed from proposed due to the regressions it causes for package builds
<cjwatson> Thanks.  I can do some kind of bulk retry tomorrow if nobody beats me to it before then
-queuebot:#ubuntu-release- New: accepted bslizr [amd64] (groovy-proposed) [1.2.8-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted bslizr [armhf] (groovy-proposed) [1.2.8-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted bslizr [s390x] (groovy-proposed) [1.2.8-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted bslizr [arm64] (groovy-proposed) [1.2.8-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted bslizr [ppc64el] (groovy-proposed) [1.2.8-0ubuntu1]
<wgrant> I'm doing it.
<wgrant> Well, for the primary archive.
<cjwatson> Thanks
<teward> vorlon: all these packages are in proposed
<teward> so if groovy-proposed builds with -proposed enabled and available I'd say "yes" to it being apt in proposed
<teward> let me check
<teward> 'cause i just got spammed
<teward> apt 2.1.9
<teward> ah good so you just yanked it
<teward> i'm slow :)
<teward> wgrant: so can i retrigger the mspdisp errors in Studio's builds then or is that on your radar too
<vorlon> teward: you wouldn't have to wait on him to do it, in any case; but I've just retriggered those fwiw
-queuebot:#ubuntu-release- New binary: mcpdisp [amd64] (groovy-proposed/universe) [0.1.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: mcpdisp [riscv64] (groovy-proposed/universe) [0.1.2-0ubuntu1] (no packageset)
<teward> vorlon: tyvm
<teward> is apt source tracked somewhere curious what changes were made that broke this so hard
<teward> esp. between 2.1.7 and 2.1.9 (where'd 2.1.8 go xD)
<teward> not a pro but i want to know heh
<juliank> vorlon: ooh failures. I need to reproduce
<juliank> Because I removed the code masking them, as it caused other bugs
<juliank> And now need to fix the bugs
<juliank> cjwatson: wgrant I might actually need shell access to an instance that can trigger the data left in buffer bug. Also am I hiding actual error message? I think I am! Because data left in buffer is a server side connection closure that was not handled properly
<juliank>  I can't reproduce any bugs locally really, these are all very connection specific.
<juliank> Arguably they might depend on MTU, package size, and transfer speeds
<juliank> frustrating!
-queuebot:#ubuntu-release- Unapproved: muffin (focal-proposed/universe) [4.4.3-1 => 4.4.3-1ubuntu0.1] (no packageset)
<cjwatson> juliank: I don't have a way to give you shell access to any of our builders
<juliank> ack
<cjwatson> juliank: Hopefully it can be reproduced from something else in the Canonical DC that has direct access to ftpmaster.internal:80 (may not be required, but it's possible)
<juliank> cjwatson: The funny thing is I have another reproducer on debian, it fails like 10%
<juliank> cjwatson: The bug only happens if headers and content are in the same packet :/
<juliank> At least the one I see
<juliank> I've made good progress
<Laney> juliank: Use autopkgtest's access to scalingstack if you want, that might be close enough
<juliank> That makes sense
<juliank> I also need a failing build
<cjwatson> That sounds promising.  So effectively only if your internet connection is too fast? :)
<cjwatson> nautilus/groovy-proposed was failing I think
<cjwatson> It's been retried now, but you could try rebuilding the same thing
<juliank> yeah
<juliank> I bet there's a ton more bugs
<juliank> this fixed some https://salsa.debian.org/apt-team/apt/-/merge_requests/130/diffs?commit_id=d3ce6323d450c80bbcc8daee944271f1c0af9691
<juliank> also this one https://salsa.debian.org/apt-team/apt/-/merge_requests/130/diffs?commit_id=4b910d12a51f812b802951cf011f5abeaf410299
<juliank> I think I broke pipelining
<juliank> because I stopped exiting successfully on In.IsLimit() == true
<juliank> And this was all papered over before because apt silently retried
<juliank> with a brand new connection
<juliank> Still need to improve error handling a bit
<juliank> or rather, reporting
<seb128> cjwatson, juliank , that was not source specific, random packages were failing to get some of the debs and different ones at each retry
<juliank> seb128: it is
<seb128> so I think just apt build-dep for some non trivial package should be enough to trigger
<juliank> seb128: always specific
<juliank> it just does not appear so
<juliank> but it depends on the pipeline and response order, and length of packets and such
<seb128> k, well it happened like on half the packages I uploaded/synced yesterday
<seb128> I would say it's just random and if you download enough debs from the archive you would end up hitting it
<seb128> I'm unsure how it could be specific to a source, the source code isn't involved at this point
<juliank> I think you currently don't see Error reading from server. Remote end closed connection, but I can't test it really, my connection is too fast
<LocutusOfBorg> vorlon, would it be possible to hint gfs2-utils on ppc64el that has regressed in release? https://autopkgtest.ubuntu.com/packages/g/gfs2-utils/groovy/ppc64el
<juliank> I'm fairly optimistic that this works now, I messed up the success recovery paths in the connection closure path
<juliank> I've also rewritten the entire thing to do the same in readable
<juliank> which meant doing code path analysis
 * juliank wonders if there's a tool for that
<juliank> (like, tell it which boolean variables it is allowed to toggle and give me the outputs in a table)
<juliank> I can reproduce
<juliank> on autopkgtest
<Laney> â
<juliank> I installed apt build-deps and I can no longer reproduce with my test, so I now download all of plasma-desktop
<juliank> because I need to download enough files for the server to close the connection on me
<juliank> All I can say is do not maintain 22 year old http clients
<juliank> Fix seems to work
<juliank> new apt landing, please stay attentive and ping me immediately if you see download errors https://launchpad.net/ubuntu/+source/apt/2.1.10
<teward> juliank: so you fixed the 2.1.9 regression issue?  they rolled back because it broke every build on select archs :P
<juliank> teward: yup
<teward> juliank: cool as long as it stops erroring heh
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (focal-proposed) [2.20.11-0ubuntu27.8]
-queuebot:#ubuntu-release- Unapproved: rejected rpcbind [source] (xenial-proposed) [0.2.3-0.2ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (bionic-proposed/partner) [1:20200609.1-0ubuntu0.18.04.1 => 1:20200811.1-0ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20200609.1-0ubuntu0.16.04.1 => 1:20200811.1-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (focal-proposed/partner) [1:20200609.1-0ubuntu0.20.04.1 => 1:20200811.1-0ubuntu0.20.04.1] (no packageset)
<xnox> argh
<xnox> isn't it dead?! =)
<xnox> i thought 20202 was the year it will die
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (bionic-proposed) [1:20200811.1-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (focal-proposed) [1:20200811.1-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20200811.1-0ubuntu0.16.04.1]
<Odd_Bloke> xnox: End of the year, I think?
<cjwatson> 20202> perhaps that typo is more true than you think
<xnox> hahahhahahahhahahhahahhahahahhaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaahahhhhhhhhhhhhhhhhhhhhhhahahahhahahahahahhahahhahaha
<patriciadomin> hello. I see 16.04.7rc ISO ready for testing on arm64 and amd64. Are you planning to build it for ppc64le and s390x?
-queuebot:#ubuntu-release- New: accepted mcpdisp [amd64] (groovy-proposed) [0.1.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mcpdisp [armhf] (groovy-proposed) [0.1.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mcpdisp [riscv64] (groovy-proposed) [0.1.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mcpdisp [arm64] (groovy-proposed) [0.1.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mcpdisp [s390x] (groovy-proposed) [0.1.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mcpdisp [ppc64el] (groovy-proposed) [0.1.2-0ubuntu1]
<vorlon> LocutusOfBorg: gfs2-utils/ppc64el hinted, thanks
<xnox> patriciadomin:  no, we do not.
<xnox> patriciadomin:  the BootHole does not affect ppc64le nor s390x. It only affect UEFI platforms.
<vorlon> cpaelzer: fyi after yesterday's conversation (and britney nagging me about a number of packages that I "uploaded" being stuck in -proposed too long ;), I am going ahead and rolling forward the various haskell packages that had been rolled back, after confirming they're not entangled with any current transitions.  (e.g. the haskell-gi-* stuff can't be since it was all removed from release pocket)
<vorlon> WHY DOES REVERSE-DEPENDS OUTPUT TO STDERR
<patriciadomin> ok thanks xnox
-queuebot:#ubuntu-release- New binary: libnfc [s390x] (groovy-proposed/universe) [1.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: aflplusplus [amd64] (groovy-proposed/universe) [2.66c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libzorpll [s390x] (groovy-proposed/universe) [7.0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libnfc [amd64] (groovy-proposed/universe) [1.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libnfc [ppc64el] (groovy-proposed/universe) [1.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libzorpll [amd64] (groovy-proposed/universe) [7.0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libzorpll [ppc64el] (groovy-proposed/universe) [7.0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wtdbg2 [amd64] (groovy-proposed/universe) [2.5-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libnfc [armhf] (groovy-proposed/universe) [1.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libnfc [arm64] (groovy-proposed/universe) [1.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libzorpll [armhf] (groovy-proposed/universe) [7.0.4.0-1] (no packageset)
<vorlon> not rolling forward haskell-ansi-terminal because pandoc.  not rolling forward haskell-tasty / haskell-tasty-hunit, haskell-hledger-lib, haskell-hledger, because intertwined with haskell-ansi-terminal.  not rolling forward haskell-quickcheck, because pandoc.
<vorlon> all the rest of my rollbacks have been rolled forward again
-queuebot:#ubuntu-release- New binary: libzorpll [arm64] (groovy-proposed/universe) [7.0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libnfc [riscv64] (groovy-proposed/universe) [1.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libzorpll [riscv64] (groovy-proposed/universe) [7.0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libnfc [amd64] (groovy-proposed) [1.8.0-1]
-queuebot:#ubuntu-release- New: accepted libnfc [armhf] (groovy-proposed) [1.8.0-1]
-queuebot:#ubuntu-release- New: accepted libnfc [riscv64] (groovy-proposed) [1.8.0-1]
-queuebot:#ubuntu-release- New: accepted libzorpll [amd64] (groovy-proposed) [7.0.4.0-1]
-queuebot:#ubuntu-release- New: accepted libzorpll [armhf] (groovy-proposed) [7.0.4.0-1]
-queuebot:#ubuntu-release- New: accepted libzorpll [riscv64] (groovy-proposed) [7.0.4.0-1]
-queuebot:#ubuntu-release- New: accepted wtdbg2 [amd64] (groovy-proposed) [2.5-4]
-queuebot:#ubuntu-release- New: accepted libnfc [arm64] (groovy-proposed) [1.8.0-1]
-queuebot:#ubuntu-release- New: accepted libnfc [s390x] (groovy-proposed) [1.8.0-1]
-queuebot:#ubuntu-release- New: accepted libzorpll [ppc64el] (groovy-proposed) [7.0.4.0-1]
-queuebot:#ubuntu-release- New: accepted libnfc [ppc64el] (groovy-proposed) [1.8.0-1]
-queuebot:#ubuntu-release- New: accepted libzorpll [s390x] (groovy-proposed) [7.0.4.0-1]
-queuebot:#ubuntu-release- New: accepted libzorpll [arm64] (groovy-proposed) [7.0.4.0-1]
-queuebot:#ubuntu-release- New: accepted aflplusplus [amd64] (groovy-proposed) [2.66c-1]
-queuebot:#ubuntu-release- Unapproved: accepted umockdev [source] (focal-proposed) [0.14.1-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted umockdev [source] (bionic-proposed) [0.11.1-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-boxes [source] (focal-proposed) [3.36.5-0ubuntu2]
<sergiodj> hello again, archive-admin :-).  just a friendly ping to see if anyone can review telegraf, which is currently sitting at the NEW queue.  TIA
<vorlon> node-sha.js - what incredibly terrible testsuite output
<vorlon> I'll just look for the "should be equal" test, shall I
<LocutusOfBorg> vorlon, ocaml-ctypes needs lwt on i386... can you please restore it?
<vorlon> why is anything ocaml part of the i386 set?
<vorlon> llvm-toolchain-10 build-depends on it? :P
<vorlon> ok I'll get it in
<LocutusOfBorg> :)
<seb128> vorlon, did you see https://irclogs.ubuntu.com/2020/08/07/%23ubuntu-devel.html#t12:21 ? (just mentioning because you said you were looking at the package earlier)
<vorlon> seb128: had not seen it, thanks for the link
<seb128> vorlon, np!
<seb128> I see that bryce also replied on the list with pointers to the upstream bug and that they commit a fix today
<seb128> (Olivier is off this week also so don't wait on him)
<xnox> vorlon:  cleaned up more udebs, from unused seeds, which components-missmatches looks at. Hopefully next run of components missmatches will allow more things to be demoted or removed.
<RikMills> vorlon: hi, would you consider skiptesting kio and kconfig in proposed to get most of the KDE things through? the libreoffice armhf mess/fails are not their fault
-queuebot:#ubuntu-release- Packageset: 55 entries have been added or removed
#ubuntu-release 2020-08-12
<vorlon> LocutusOfBorg: now 3 packages deep; how about if we patch llvm-toolchain-10 to not require ocaml instead? :P
-queuebot:#ubuntu-release- Packageset: Added ocplib-endian to i386-whitelist in groovy
<RAOF> sergiodj: I'm not expert in reviewing golang packages, but telegraf seems to vendor a *lot* of other packages, at least some of which appear to be in the archive already? (golang-thrift-dev, golang-collectd-dev, â¦)
-queuebot:#ubuntu-release- Packageset: Added cppo to i386-whitelist in groovy
<sergiodj> RAOF: that's (unfortunately) correct.  telegraf requires a lot of go dependencies to work properly, and on top of that the version requirements for each of these dependencies can vary wildly.  that's very unfortunate, but it's something more and more common with these new languages.  for that reason, I chose to bundle everything in the package itself.  this way we will have a better control
<sergiodj> of dependencies & versions, and won't find ourselves in a state where updating a golang package in the archive because of package XYZ doesn't break telegraf (or the other way around)
<sergiodj> thanks for looking into the package, btw
<RAOF> I'm not sure how much the security team is going to enjoy a fork lots of packages bundled into the source on .orig construction, for when you want to get it into main, but ok.
<sergiodj> that's a very good point, and I'm thinking about this as well.  I will look into which packages I can remove from the bundle tomorrow (it's almost midnight for me here)
<sergiodj> in all fairness, there is precedence for bundling golang deps into the source package, but I'm not sure if we bundle deps whose packages already exist in the archive
<RAOF> Yeah, it's an understandably difficult situation. There are advantages for each individual upstream to vendor the world, but the aggregate cost of that falls on distributions like us :)
<RAOF> (I guess the other question is whether or not this would be better as a snap, where you have access to the network during build)
-queuebot:#ubuntu-release- New: rejected sane-airscan [source] (groovy-proposed) [0.99.12-1ubuntu1]
-queuebot:#ubuntu-release- Packageset: Removed what-is-python from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added ocamlbuild to i386-whitelist in groovy
-queuebot:#ubuntu-release- New: rejected microcode-initrd [source] (groovy-proposed) [1]
<cpaelzer> ok vorlon, I have added the info that you rolled things forward to the state of haskell on the plusone wiki page
<Laney> bah why did fwupd migrate
<LocutusOfBorg> vorlon, I'm going to sync the haskell packages now that the Debian stack has migrated
<LocutusOfBorg> everything has been forwarded/fixed in Debian too, lets sync them (e.g. haskell-ansi-wl-pprint	haskell-byte-order)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-114.115] (core, kernel)
-queuebot:#ubuntu-release- New binary: libcec [amd64] (groovy-proposed/universe) [6.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcec [s390x] (groovy-proposed/universe) [6.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcec [armhf] (groovy-proposed/universe) [6.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcec [arm64] (groovy-proposed/universe) [6.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcec [riscv64] (groovy-proposed/universe) [6.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-rio-prettyprint [s390x] (groovy-proposed/universe) [0.1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libcec [ppc64el] (groovy-proposed/universe) [6.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-rio-prettyprint [amd64] (groovy-proposed/universe) [0.1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New source: microcode-initrd (groovy-proposed/primary) [1]
-queuebot:#ubuntu-release- New binary: haskell-rio-prettyprint [arm64] (groovy-proposed/universe) [0.1.0.0-2] (no packageset)
<Laney> ok
<Laney> fixed that ://///
<Laney> https://people.canonical.com/~ubuntu-archive/laney/proposed-migration/update_excuses.html#fwupd
<Laney> slightly nicer output for component-mismatches too, search for "cannot depend on"
<seb128> Laney, ah, nice
<Laney> ð¬
<Laney> maybe I should try to roll back fwupd{,-signed}
<Laney> feels mildly scary
<Laney> https://paste.ubuntu.com/p/B6mcCQfc95/ if someone wanted to review I could do it
-queuebot:#ubuntu-release- New binary: haskell-rio-prettyprint [ppc64el] (groovy-proposed/universe) [0.1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (focal-proposed/main) [5.4.0-44.48] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-114.115] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (focal-proposed/main) [5.4.0-44.48] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (focal-proposed/main) [5.4.0-44.48] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (focal-proposed/main) [5.4.0-44.48] (core, kernel)
<Laney> apw / sil2100 ^- ?
<apw> Laney, wassup?
-queuebot:#ubuntu-release- Unapproved: accepted landscape-client [source] (xenial-proposed) [16.03-0ubuntu2.16.04.8]
<apw> Laney, the linux-signed stuff; thats me
<Laney> nooooo
<Laney> apw: I want someone to review fwupd/signed with me, thought one of you might have interacted with it before from the AA side
<Laney> would like to revert it in groovy to the previous version
<apw> Laney, oh not me; temporary downgrade to get something out i assume yes ?
<apw> Laney, oh in Release ?
<Laney> yus
<Laney> I want to unmigrate that fwupd
<seb128> Laney, the commands should be fine/do what you want but I hadn't had to do that sort of things often so I could be overlooking something
<seb128> Laney, in any case if that doesn't do what we want it should be easy to iterate/fix harder
<apw> Laney, i have no objection to pulling it back
<Laney> ok
<Laney> I was mainly worried wrt signed stuff
<Laney> I guess a broken groovy for a bit isn't the end of the world
<Laney> lemme try it
<Laney> looks ok
<Laney> thanks apw and seb128!
 * Laney is still nervous about this stuff :>
<seb128> yw!
<LocutusOfBorg> can you please kick haskell-chell out from release? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964825
<ubot5> Debian bug 964825 in src:haskell-chell "haskell-chell: BD-Uninstallable" [Serious,Open]
<LocutusOfBorg> vorlon, ^^ please^
-queuebot:#ubuntu-release- New binary: haskell-rio-prettyprint [armhf] (groovy-proposed/universe) [0.1.0.0-2] (no packageset)
<apw> Laney, we may have issues when and if it does remigrate, but nothing to worry about right now
<Laney> AFAIK demotions can migrate back, but I'll keep an eye on it
-queuebot:#ubuntu-release- Unapproved: rejected apport [source] (bionic-proposed) [2.20.9-0ubuntu7.17]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-114.115]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (focal-proposed) [5.4.0-44.48]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (focal-proposed) [5.4.0-44.48]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-114.115]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (focal-proposed) [5.4.0-44.48]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (focal-proposed) [5.4.0-44.48]
-queuebot:#ubuntu-release- New binary: haskell-rio-prettyprint [riscv64] (groovy-proposed/universe) [0.1.0.0-2] (no packageset)
<LocutusOfBorg> can anybody please move this hint force-badtest makedumpfile/1:1.6.7-3ubuntu1/ppc64el to force-badtest makedumpfile/1:1.6.7-4ubuntu1/ppc64el ? thanks
-queuebot:#ubuntu-release- New binary: libwfut [s390x] (groovy-proposed/universe) [0.2.3-7] (no packageset)
-queuebot:#ubuntu-release- New binary: libwfut [ppc64el] (groovy-proposed/universe) [0.2.3-7] (no packageset)
-queuebot:#ubuntu-release- New binary: libwfut [arm64] (groovy-proposed/universe) [0.2.3-7] (no packageset)
-queuebot:#ubuntu-release- New binary: libwfut [armhf] (groovy-proposed/universe) [0.2.3-7] (no packageset)
-queuebot:#ubuntu-release- New binary: libwfut [amd64] (groovy-proposed/universe) [0.2.3-7] (no packageset)
-queuebot:#ubuntu-release- New binary: libwfut [riscv64] (groovy-proposed/universe) [0.2.3-7] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (groovy-proposed/main) [5.8.0-16.17] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (groovy-proposed/main) [5.8.0-16.17] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (groovy-proposed/main) [5.8.0-16.17] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (groovy-proposed) [5.8.0-16.17]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (groovy-proposed) [5.8.0-16.17]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (groovy-proposed) [5.8.0-16.17]
<sergiodj> RAOF: we thought about going the snap route for telegraf, but decided it is better to ship it as a regular .deb because its purpose is to be installed on the hosts that are going to be monitored, and sometimes installing snaps is not an option
-queuebot:#ubuntu-release- Packageset: Removed cppo from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed lwt from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed ocamlbuild from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed ocplib-endian from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added lzop to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added python-stdlib-extensions to i386-whitelist in groovy
-queuebot:#ubuntu-release- Unapproved: bcache-tools (bionic-proposed/main) [1.0.8-2build1 => 1.0.8-2ubuntu0.18.04.1] (edubuntu, kubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected bcache-tools [source] (bionic-proposed) [1.0.8-2ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted bcache-tools [source] (bionic-proposed) [1.0.8-2ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Packageset: Added cppo to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added lwt to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added ocaml-migrate-parsetree to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added ocamlbuild to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added ocplib-endian to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added ppx-tools-versioned to i386-whitelist in groovy
<Laney> juliank: you know we're getting emailed about syntax errors, right? :>
<juliank> Laney: no, odd, I ran the script
<juliank> Laney: Something went wrong committing it
<juliank> I guess
<juliank> Laney: Oh good, I see what went wrong...
-queuebot:#ubuntu-release- Packageset: Added ocaml-result to i386-whitelist in groovy
<juliank> Laney: fixed
<Laney> ty
-queuebot:#ubuntu-release- Unapproved: vala (focal-proposed/universe) [0.48.6-0ubuntu1 => 0.48.9-0ubuntu1] (i386-whitelist, ubuntu-desktop)
<juliank> Laney: I was copying the code from wendigo terminal to local git repo, but ended up copying not the complete line but editor's (or whatever's) $ ...
<juliank> I'm bad
<juliank> That's what I get for doing local first
<Laney> come work for the ubuntu release team, we have the best engineering practices
-queuebot:#ubuntu-release- Packageset: Added ppx-derivers to i386-whitelist in groovy
-queuebot:#ubuntu-release- Unapproved: bind9-libs (focal-proposed/main) [1:9.11.16+dfsg-3~build1 => 1:9.11.16+dfsg-3~ubuntu1] (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: airspyhf [s390x] (groovy-proposed/universe) [1.6.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: airspyhf [amd64] (groovy-proposed/universe) [1.6.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: airspyhf [ppc64el] (groovy-proposed/universe) [1.6.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: airspyhf [arm64] (groovy-proposed/universe) [1.6.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: airspyhf [armhf] (groovy-proposed/universe) [1.6.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: airspyhf [riscv64] (groovy-proposed/universe) [1.6.8-1] (no packageset)
<bdmurray> LocutusOfBorg: I gather you have some familiarity with llvm. Do you have any ideas about bug 1886748?
<ubot5> bug 1886748 in ubuntu-release-upgrader (Ubuntu Focal) "upgrade from 18.04 to 20.04 fails to calculate if libomp5 is installed" [High,Confirmed] https://launchpad.net/bugs/1886748
<sergiodj> vorlon: hey, just wondering if you have an opinion on the topic raised by RAOF re. telegraf, and while at it, if you could review it
-queuebot:#ubuntu-release- Packageset: Added ocaml-mmap to i386-whitelist in groovy
-queuebot:#ubuntu-release- New: accepted airspyhf [amd64] (groovy-proposed) [1.6.8-1]
-queuebot:#ubuntu-release- New: accepted airspyhf [armhf] (groovy-proposed) [1.6.8-1]
-queuebot:#ubuntu-release- New: accepted airspyhf [riscv64] (groovy-proposed) [1.6.8-1]
-queuebot:#ubuntu-release- New: accepted libwfut [amd64] (groovy-proposed) [0.2.3-7]
-queuebot:#ubuntu-release- New: accepted libwfut [armhf] (groovy-proposed) [0.2.3-7]
-queuebot:#ubuntu-release- New: accepted libwfut [riscv64] (groovy-proposed) [0.2.3-7]
-queuebot:#ubuntu-release- New: accepted airspyhf [arm64] (groovy-proposed) [1.6.8-1]
-queuebot:#ubuntu-release- New: accepted airspyhf [s390x] (groovy-proposed) [1.6.8-1]
-queuebot:#ubuntu-release- New: accepted libwfut [ppc64el] (groovy-proposed) [0.2.3-7]
-queuebot:#ubuntu-release- New: accepted airspyhf [ppc64el] (groovy-proposed) [1.6.8-1]
-queuebot:#ubuntu-release- New: accepted libwfut [s390x] (groovy-proposed) [0.2.3-7]
-queuebot:#ubuntu-release- New: accepted libwfut [arm64] (groovy-proposed) [0.2.3-7]
-queuebot:#ubuntu-release- New: accepted libcec [amd64] (groovy-proposed) [6.0.2-1]
-queuebot:#ubuntu-release- New: accepted libcec [armhf] (groovy-proposed) [6.0.2-1]
-queuebot:#ubuntu-release- New: accepted libcec [riscv64] (groovy-proposed) [6.0.2-1]
-queuebot:#ubuntu-release- New: accepted libcec [arm64] (groovy-proposed) [6.0.2-1]
-queuebot:#ubuntu-release- New: accepted libcec [s390x] (groovy-proposed) [6.0.2-1]
-queuebot:#ubuntu-release- New: accepted libcec [ppc64el] (groovy-proposed) [6.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-rio-prettyprint [amd64] (groovy-proposed) [0.1.0.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-rio-prettyprint [armhf] (groovy-proposed) [0.1.0.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-rio-prettyprint [riscv64] (groovy-proposed) [0.1.0.0-2]
-queuebot:#ubuntu-release- New: accepted kstore [amd64] (groovy-proposed) [0.1.0]
-queuebot:#ubuntu-release- New: accepted kstore [armhf] (groovy-proposed) [0.1.0]
-queuebot:#ubuntu-release- New: accepted kstore [riscv64] (groovy-proposed) [0.1.0]
-queuebot:#ubuntu-release- New: accepted haskell-rio-prettyprint [arm64] (groovy-proposed) [0.1.0.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-rio-prettyprint [s390x] (groovy-proposed) [0.1.0.0-2]
-queuebot:#ubuntu-release- New: accepted kstore [ppc64el] (groovy-proposed) [0.1.0]
-queuebot:#ubuntu-release- New: accepted haskell-rio-prettyprint [ppc64el] (groovy-proposed) [0.1.0.0-2]
-queuebot:#ubuntu-release- New: accepted kstore [s390x] (groovy-proposed) [0.1.0]
-queuebot:#ubuntu-release- New: accepted kstore [arm64] (groovy-proposed) [0.1.0]
-queuebot:#ubuntu-release- Packageset: Added react to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added opam to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added opam-file-format to i386-whitelist in groovy
<vorlon> LocutusOfBorg: sync the haskell packages> uh what haskell packages that aren't already in sync?  please don't do anything that would upend the icu et al transitions
<vorlon> LocutusOfBorg: haskell-chell> removed
<vorlon> LocutusOfBorg: makedumpfile hint updated
<vorlon> sergiodj, RAOF: there is definitely an exception in Ubuntu for vendorizing of golang dependencies
<sergiodj> vorlon: yeah, I was told about some precedences as well
-queuebot:#ubuntu-release- Packageset: Added ocamlgraph to i386-whitelist in groovy
<sergiodj> vorlon: I'm not sure if you were able to review the package in length last week, and if you have any other comments about it
<vorlon> LocutusOfBorg: we're up to 16 source packages now for lwt, are you sure you don't just want to fix llvm-toolchain-10 to not depend on ocamlage?
<LocutusOfBorg> not really sure about the answer... I think dropping ocaml bindings now is a bit premature, even if just for i386...
<LocutusOfBorg> thanks for doing the haskell stuff
<LocutusOfBorg> I don't remember which haskell that were removed and not put back, I did them this morning
<LocutusOfBorg> this one https://launchpad.net/ubuntu/+source/haskell-ansi-wl-pprint/0.6.9-2build2
<LocutusOfBorg> haskell-ansi-terminal, haskell-tasty, haskell-tasty-hunit
<LocutusOfBorg> haskell-concurrent-output were all missing
<LocutusOfBorg> in any case, a no change rebuild was needed for s390x anyway, so I just reuploaded as sources
<vorlon> LocutusOfBorg: the ocaml bindings are certainly not /useful/ on i386; the only thing they might be used for is building the exact set of ocaml packages that are in the archive only because llvm build-depends on them
<vorlon> LocutusOfBorg: I was explicitly holding haskell-ansi-terminal back because it impacts pandoc which is in -proposed and entangled in the current transition
<vorlon> LocutusOfBorg: ugh and the ocaml deps just hit glpk -> suitesparse.  heavy -1 on supporting suitesparse on i386
-queuebot:#ubuntu-release- Packageset: Added cmdliner to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added cudf to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added dose3 to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added ocaml-re to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added extlib to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added ocaml-mccs to i386-whitelist in groovy
<vorlon> LocutusOfBorg: so the change to llvm-toolchain to drop ocaml support is straightforward enough; I'm going to go ahead and do that, an llvm Ubuntu delta is going to be easier to manage than chasing ocaml recursive build-deps over time
<vorlon> (and I don't see a specific way to unpick suitesparse from the dep tree)
-queuebot:#ubuntu-release- Packageset: Removed cmdliner from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed cppo from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed cudf from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed dose3 from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed extlib from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed lwt from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed ocaml-mccs from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed ocaml-migrate-parsetree from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed ocaml-mmap from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed ocaml-re from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed ocaml-result from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed ocamlbuild from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed ocamlgraph from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed ocplib-endian from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed opam from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed opam-file-format from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed ppx-derivers from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed ppx-tools-versioned from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed react from i386-whitelist in groovy
<rbalint> vorlon, please drop glibc from focal unapproved, there are two more incoming fixes
-queuebot:#ubuntu-release- New binary: libcdio [s390x] (groovy-proposed/main) [2.1.0-2] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libcdio [amd64] (groovy-proposed/main) [2.1.0-2] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libcdio [ppc64el] (groovy-proposed/main) [2.1.0-2] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libcdio [i386] (groovy-proposed/main) [2.1.0-2] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: ocaml-melt [s390x] (groovy-proposed/universe) [1.4.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libcdio [arm64] (groovy-proposed/main) [2.1.0-2] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: ocaml-melt [amd64] (groovy-proposed/universe) [1.4.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libcdio [armhf] (groovy-proposed/main) [2.1.0-2] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: ocaml-melt [ppc64el] (groovy-proposed/universe) [1.4.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-melt [arm64] (groovy-proposed/universe) [1.4.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-melt [armhf] (groovy-proposed/universe) [1.4.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libcdio [riscv64] (groovy-proposed/main) [2.1.0-2] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rejected glibc [source] (focal-proposed) [2.31-0ubuntu9.1]
<vorlon> rbalint: done
<vorlon> rolling back nodejs to disentangle from icu
#ubuntu-release 2020-08-13
<cpaelzer> hi ubuntu-archive, can I get someone to look at bug 1891340 and either action on it or tell me how this kind of cases would have to be solved?
<ubot5> bug 1891340 in gubbins (Ubuntu) "[RM] non amd64 binaries of gubbins in groovy to allow 2.4.x to migrate" [Undecided,New] https://launchpad.net/bugs/1891340
<RAOF> cpaelzer: Hm. If we just remove the !amd64 binaries, won't subsequent updates FTBFS on all other architectures anyway?
<RAOF> Hm, no. The builds won't be dispatched, because LP will notice the missing build-depends first.
<cpaelzer> yeah it does detect the missing b-dep as you see here https://launchpad.net/ubuntu/+source/gubbins/2.4.1-2
<cpaelzer> yet it can't migrate as it thinks it needs to wait on non-x86
<cpaelzer> because Ubuntu had non-x86 builds before
<RAOF> Yeah.
<cpaelzer> Debian didn't and I'd have hoped that removing the !x86 bins makes this check pass
<RAOF> How did Debian not build it on all architectures?
<cpaelzer> really I'm only 75% sure on this, so if there is a different/better way let me know
<RAOF> (That's somewhat of a tangent, as I think removing the binaries is indeed the correct path)
<cpaelzer> RAOF: yeah the "how did Debian do it" is confusing on this one
<cpaelzer> RAOF: e.g. https://buildd.debian.org/status/package.php?p=gubbins&suite=buster
<cpaelzer> https://trello.com/c/9d4tprP6/919-ciphersuite-recommendation-package-proposal
<cpaelzer> that looks like it would be there, but it isn't
<cpaelzer> maybe they removed them as well for some reason, but I haven't found a Debian bug that discusses that
<RAOF> Why is jqtree amd64 only, anyway?
<cpaelzer> ask me something I know please :-)
<cpaelzer> "iqtree"
<cpaelzer> not "jqtree"
<cpaelzer> RAOF: ^^
<cpaelzer> I mix them, my bad
<RAOF> Ah, no. iqtree. Looks like it's a bit of core computational-biology software, so my guess would be contains x86 asm.
<cpaelzer> Thank you RAOF, I'll in a few hours re-cehck what happened to the package
<cpaelzer> just to be sure
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Xenial 16.04.7] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Xenial 16.04.7] has been marked as ready
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Bionic 18.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Bionic 18.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Xenial 16.04.7] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Xenial 16.04.7] has been marked as ready
<LocutusOfBorg> bdmurray, libomp5 was part of another package... sad story
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Bionic 18.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Bionic 18.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Bionic 18.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Bionic 18.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Bionic 18.04.5] has been marked as ready
<LocutusOfBorg> now it is provided by llvm-defaults
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Bionic 18.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Bionic 18.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Bionic 18.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Bionic 18.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Bionic 18.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Bionic 18.04.5] has been marked as ready
<seb128> could someone get gst-plugins-base1.0 gtk+3.0 ignore the libreoffice/armhf autopkgtest regression? those updates are ftbfs fixes and not what is make libreoffice red
<seb128> also the icu transition depending on libreoffice arm issues to be resolved is no fun :-(
<LocutusOfBorg> vorlon, please kick out marionnet? blocking ocaml transition https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952310
<ubot5> Debian bug 952310 in src:marionnet "marionnet: FTBFS: Error: This expression has type bytes but an expression was expected of type string" [Serious,Open]
<LocutusOfBorg> vorlon, can you please upgrade the faketime hint to 0.9.7-3.1 ?
<LocutusOfBorg> btw, I did some analysis, and this is a multiarch issue, the code injects this in LD_LIBRARY_PATH
<LocutusOfBorg>         ftpl_path = PREFIX "/$LIB/faketime/libfaketimeMT.so.1";
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Bionic 18.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Bionic 18.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Bionic 18.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Bionic 18.04.5] has been marked as ready
<LocutusOfBorg> bdmurray, can you please try to change the "Breaks: libomp5 (<< 44)" in libomp5-10 to see if changes something?
<LocutusOfBorg> maybe Breaks: libiomp5 (<< 3.7-1) might help
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Xenial 16.04.7] has been marked as ready
<Laney> seb128: can you make a merge proposal adding force-skiptest for those two?
<seb128> Laney, yes, I'm still unsure to grasp the spirit behind those though, isn't it easy to issue a command to skip (you guys can do that right?) for a one time thing rather than commit (and then having to revert or keep noise about old versions)?
<Laney> what?
<Laney> oh I see
<Laney> there is no command, no
<seb128> ah ok
<Laney> it is all hints
<seb128> I though you guys had a command line interface to do a one time hint
<seb128> k
<seb128> should we consider skiptest the libreoffice/armhf result for libreoffice itself to have a chance to see icu getting ready this week? it sucks to let it through if there is a problem on that arch, which might be the case, but if we chase a fix and go through another upload, build, autopkgtests round it's going to take another week of delay...
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Bionic 18.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Bionic 18.04.5] has been marked as ready
<Laney> that would become a force-badtest then
<Laney> but maybe, if icu becomes otherwise ready ...
<seb128> vorlon, ^ opinion?
<seb128> Laney, so, I'm probably just not properly awake, but what do I need to skiptest to have e.g gtk+3.0 migrating?
<Laney> gtk
<seb128> Laney, I can't skiptest libreoffice/armhf
<seb128> ah
<seb128> but that would skip any problem and not only the one specific? (which is fine in that case sine that's only libreoffice blocking)
<seb128> so the hammer is 'we skip results now because we determined that the remaining problems are the ones we decided to ignore'?
<seb128> no granularity in what we ignore?
<Laney> that's what we have
<seb128> k, thanks!
<seb128> learning every day :)
<Laney> it's going to be a while before the new nodejs finishes running everything, I think we still have a bit of time
<Laney> e.g. for hellswort_h to figure out some clues as to which direction to look in
<Laney> also, https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#firebird3.0 "firebird3.0 unsatisfiable Build-Depends(-Arch) on i386: recode"
<Laney> that seems true, and " Deleted 9 hours ago by Steve Langasek
<Laney> i386 deprecated as host arch
<Laney> "
<Laney> also will block icu ;-)
<Laney> vorlon: can you check the recode/firebird3.0 situation please? some of the tooling is not agreeing with some other part of the tooling and I'm not sure in which direction that is
<seb128> Laney, had, I hadn't noticed recode was deleted, I asked about that earlier, thanks
<Laney> nod
<seb128> Laney, https://code.launchpad.net/~seb128/britney/ignore-libreoffice-armhf/+merge/389227
<Laney> cheers!
<LocutusOfBorg> Laney, we have to roll-back node-gulp-util please?
<LocutusOfBorg> 3.0.8-1 is fine, 3.0.8-2 has a specific dependency on new nodejs, leading to uninstallability in autopkgtests
<Laney> LocutusOfBorg: not me, or at least not now sorry
<Laney> I don't want to context switch atm
<Laney> maybe seb128 can help you :>
<seb128> LocutusOfBorg, Laney , k
<seb128> small improvement to the team report
<seb128> https://code.launchpad.net/~seb128/ubuntu-archive-scripts/include-build-depends/+merge/389229
-queuebot:#ubuntu-release- Unapproved: build-essential (focal-proposed/main) [12.8ubuntu1 => 12.8ubuntu1.1] (core, i386-whitelist)
<seb128> (include the 'missing build-depends' info)
<seb128> Laney, ^ for later, I'm not asking you to context switch, but is it normal that there is no 'reason' in that case?
<seb128> LocutusOfBorg, how did it ever migrate if it's missing a depends?
-queuebot:#ubuntu-release- New: accepted libcdio [amd64] (groovy-proposed) [2.1.0-2]
-queuebot:#ubuntu-release- New: accepted libcdio [armhf] (groovy-proposed) [2.1.0-2]
-queuebot:#ubuntu-release- New: accepted libcdio [ppc64el] (groovy-proposed) [2.1.0-2]
-queuebot:#ubuntu-release- New: accepted libcdio [s390x] (groovy-proposed) [2.1.0-2]
-queuebot:#ubuntu-release- New: accepted libcdio [arm64] (groovy-proposed) [2.1.0-2]
-queuebot:#ubuntu-release- New: accepted libcdio [riscv64] (groovy-proposed) [2.1.0-2]
-queuebot:#ubuntu-release- New: accepted libcdio [i386] (groovy-proposed) [2.1.0-2]
<Laney> seb128: I don't think the reasons are super consistently used, but I guess it would be ok
<seb128> Laney, k
<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
<seb128> ginggs, done!
<ginggs> seb128: thanks!
<seb128> LocutusOfBorg, unsure how it migrated and if it's right to copy over it in the release pocket ... what about doing a new upload with the lowered requirement? and then if it's blocked in proposed then retry with the right triggers
<cpaelzer> RAOF: https://launchpad.net/ubuntu/+source/gubbins/2.4.1-2 worked and migrated
<cpaelzer> just FYI and thanks again
<RAOF> Always nice to have your understanding of how things work confirmed by them working ð
-queuebot:#ubuntu-release- New binary: sane-airscan [amd64] (groovy-proposed/universe) [0.99.12-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: sane-airscan [s390x] (groovy-proposed/universe) [0.99.12-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: sane-airscan [ppc64el] (groovy-proposed/universe) [0.99.12-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: sane-airscan [armhf] (groovy-proposed/universe) [0.99.12-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: sane-airscan [arm64] (groovy-proposed/universe) [0.99.12-1ubuntu2] (no packageset)
<xnox> ubuntu-archive can wasi-libc please be rolled back to a previous version, such that rustc 43 can migrate?
<juliank> I just rebased the autopkgtest on our infra, let me know if any new issues popped up
-queuebot:#ubuntu-release- New binary: sane-airscan [riscv64] (groovy-proposed/universe) [0.99.12-1ubuntu2] (no packageset)
<juliank> Starting with the next images, haveged is replaced by rng-tools, which feeds entropy to /dev/random from the host (via virtio-hwrng)
<Laney> ð
<LocutusOfBorg> seb128, will have a look
<LocutusOfBorg> seb128, btw the build-dependency was bumped to >=12 to make sure it was picking up nodejs
<LocutusOfBorg> not sure if the patch is retro-compatible, but at runtime there is no enforcing of version
 * LocutusOfBorg meh nodejs
<LocutusOfBorg> can anybody please unblock the patch for https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1872118 ?
<ubot5> Ubuntu bug 1872118 in bind9-libs (Ubuntu Focal) "[SRU] DHCP Cluster crashes after a few hours" [Undecided,In progress]
<LocutusOfBorg> groovy is fixed, focal is in unapproved
<LocutusOfBorg> this is a serious bug...
<seb128> Laney, gtk and gstreamer migrated, we can revert that commit ... could you do that or do you prefer a mp?
<Laney> can do later
<seb128> (the mp would make sense if we had a merge button but if you need to pull/commit/push to land it that might be less for you and for me if you just do directly the revert?)
<seb128> thanks
-queuebot:#ubuntu-release- New binary: linux-signed-gke-4.15 [amd64] (bionic-proposed/main) [4.15.0-1067.70] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp-4.15 [amd64] (bionic-proposed/universe) [4.15.0-1081.92] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-kvm [amd64] (focal-proposed/main) [5.4.0-1021.21] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted chromium-browser [source] (focal-proposed) [84.0.4147.105-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (focal-proposed/main) [5.4.0-1022.22] (core, kernel)
<LocutusOfBorg> vorlon, can we please have haskell-cborg{,-json} removed on armhf? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968084
<ubot5> Debian bug 968084 in ftp.debian.org "RM: haskell-cborg [armhf] -- ROM; unbuildable" [Normal,Open]
<rbalint> sil2100, please proceed phasing u-u in focal, i've opened a bug for the non-regression
<sil2100> rbalint: ok
<rbalint> Laney/ubuntu-archive i need with systemd in groovy-proposed in update_output i see migrating systemd makes kworkflow uninstallable, but locally chdist seem to be happy to install both kworkflow and all systemd binary packages
<rbalint> i need help :-)
-queuebot:#ubuntu-release- Unapproved: python-babel (focal-proposed/main) [2.6.0+dfsg.1-1ubuntu2 => 2.6.0+dfsg.1-1ubuntu2.1] (i386-whitelist, ubuntu-server)
<rbalint> hm, it pulls in other stuff from -proposed, like gmp, so i figured this out it seems
<seb128> rbalint, k, good :)
-queuebot:#ubuntu-release- Unapproved: ceph (bionic-proposed/main) [12.2.13-0ubuntu0.18.04.2 => 12.2.13-0ubuntu0.18.04.3] (desktop-core, ubuntu-server)
<rbalint> sil2100, could you please merge this for lintian and other packges? https://code.launchpad.net/~rbalint/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/389166
<sil2100> rbalint: will do all of that soonish! Just need to finish some point-release preps
<xnox> cpaelzer:  sigh, https://autopkgtest.ubuntu.com/packages/s/systemd/groovy/arm64 your trigger build after mine, and fails isc-dhcp migration.
<xnox> cpaelzer:  it must be retried against new systemd, let me do that please.
<seb128> xnox, are you sure it's not going to pick the successful one and is just timing that the current iteration didn't get the result yet?
<xnox> seb128:  hm =/ not sure, in the past it did pick the latest one.
<xnox> i guess i'll need to wait
<seb128> k, I'm not sure either but I think I had case where it picked the good one even if a more recent retry failed
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.45 => 2.525.47] (desktop-core)
-queuebot:#ubuntu-release- New: accepted ocaml-melt [amd64] (groovy-proposed) [1.4.0-3]
-queuebot:#ubuntu-release- New: accepted ocaml-melt [armhf] (groovy-proposed) [1.4.0-3]
-queuebot:#ubuntu-release- New: accepted ocaml-melt [s390x] (groovy-proposed) [1.4.0-3]
-queuebot:#ubuntu-release- New: accepted sane-airscan [arm64] (groovy-proposed) [0.99.12-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted sane-airscan [ppc64el] (groovy-proposed) [0.99.12-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted sane-airscan [s390x] (groovy-proposed) [0.99.12-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted ocaml-melt [arm64] (groovy-proposed) [1.4.0-3]
-queuebot:#ubuntu-release- New: accepted sane-airscan [amd64] (groovy-proposed) [0.99.12-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted sane-airscan [riscv64] (groovy-proposed) [0.99.12-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted ocaml-melt [ppc64el] (groovy-proposed) [1.4.0-3]
-queuebot:#ubuntu-release- New binary: base-files [amd64] (groovy-proposed/main) [11ubuntu11] (core, i386-whitelist)
-queuebot:#ubuntu-release- New: accepted sane-airscan [armhf] (groovy-proposed) [0.99.12-1ubuntu2]
<RikMills> seb128: a later fail does not invalidate a pass
<seb128> RikMills, what I though, thanks
<LocutusOfBorg> apw, can you please do the hlint removals on arm64 armhf riscv64 s390x? debian bug: #967899
<ubot5> Debian bug 967899 in ftp.debian.org "RM: hlint [armel armhf mips64el mipsel s390x] -- ROM; Unbuildable" [Normal,Open] http://bugs.debian.org/967899
<Laney> I don't think we have ever picked the 'latest' one, or if we did at least not for many years
<cpaelzer> xnox: ok will leave it to you
<cpaelzer> I was sorting out plenty of those tests yesterday and they worked fine, glad to learn that these new ones need a combined trigger again
<cpaelzer> all yours
<cpaelzer> xnox: in the past (for me) it didn't insist on "the last result" btw, just one good one was ok
<seb128> cpaelzer, from the backlog is looks like that was a wrong assumption from him so it's fine to ignore imho
<cpaelzer> ok
<cpaelzer> thanks seb128
<seb128> np!
<cpaelzer> xnox: BTW on s390x I did the combined one already and it is good https://autopkgtest.ubuntu.com/packages/s/systemd/groovy/s390x
<cpaelzer> and also the one you missed was already in the queue when you asked - so we have two good ones now https://autopkgtest.ubuntu.com/packages/s/systemd/groovy/arm64
<cpaelzer> never the less I'm happy to leave these tests to you
<cpaelzer> I have yesterday needed a table for the 2D matrix of arch/result of the many outstanding sytsmed tests
<cpaelzer> so I'm glad if you watch&kick those as part of the new version
<ahasenack> vorlon: base-files uploaded to groovy, awaiting in the new queue because of the new binary motd-news-config
<ahasenack> I need that accepted before I can upload ubuntu-meta with the seed change for ubuntu-server (already committed and pushed)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Bionic 18.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Bionic 18.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Bionic 18.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Bionic 18.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi3 [Bionic 18.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi3 [Bionic 18.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Bionic 18.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Bionic 18.04.5] has been marked as ready
<xnox> cpaelzer:  seb128: looks like it did pick up whatever success tests. and at least some things are up for migration now.
<Laney> wonder how many times we need to confirm this is the behaviour :p
<sil2100> rbalint: could you give me a link to the bug for the non-regression of u-u ?
<sil2100> (for focal)
-queuebot:#ubuntu-release- New binary: haveged [s390x] (groovy-proposed/universe) [1.9.8-4ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: haveged [ppc64el] (groovy-proposed/universe) [1.9.8-4ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: haveged [arm64] (groovy-proposed/universe) [1.9.8-4ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: haveged [armhf] (groovy-proposed/universe) [1.9.8-4ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: haveged [amd64] (groovy-proposed/universe) [1.9.8-4ubuntu1] (kubuntu)
<sil2100> Publishing .5!
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp-4.15 [amd64] (bionic-proposed) [4.15.0-1081.92]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (focal-proposed) [5.4.0-1022.22]
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-4.15 [amd64] (bionic-proposed) [4.15.0-1067.70]
-queuebot:#ubuntu-release- New: accepted linux-signed-kvm [amd64] (focal-proposed) [5.4.0-1021.21]
-queuebot:#ubuntu-release- New binary: haveged [riscv64] (groovy-proposed/universe) [1.9.8-4ubuntu1] (kubuntu)
<Laney> \o\
<rbalint> sil2100, bdmurray please merge https://code.launchpad.net/~rbalint/britney/hints-ubuntu/+merge/389256 to make glibc not block other packages
-queuebot:#ubuntu-release- Unapproved: pycurl (focal-proposed/main) [7.43.0.2-1ubuntu5 => 7.43.0.2-1ubuntu6] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted base-files [amd64] (groovy-proposed) [11ubuntu11]
-queuebot:#ubuntu-release- New: accepted haveged [arm64] (groovy-proposed) [1.9.8-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted haveged [ppc64el] (groovy-proposed) [1.9.8-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted haveged [s390x] (groovy-proposed) [1.9.8-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted haveged [amd64] (groovy-proposed) [1.9.8-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted haveged [riscv64] (groovy-proposed) [1.9.8-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted haveged [armhf] (groovy-proposed) [1.9.8-4ubuntu1]
<sil2100> 18.04.5 and 16.04.7 are out!
* sil2100 changed the topic of #ubuntu-release to: Released: Focal 20.04.1, Bionic 18.04.5 | Archive: Open | Highlight ubuntu-archive for archive admin help | Groovy Release Coordination | We accept payment in cash, cheque or gin | melius malum quod cognoscis
<ahasenack> vorlon: the update script inside src:ubuntu-meta doesn't seem to know about groovy-proposed, so it doesn't find motd-news-config:
<ahasenack> ? Unknown server package: motd-news-config
<ahasenack> that package also won't migrate, because it makes ubuntu-server uninstallable
<ahasenack> should I just hack the depends manually in d/control in an upload, and once both migrated, upload another ubuntu-meta with the update script run?
<ahasenack> or is my reading of the above incorrect
-queuebot:#ubuntu-release- New binary: cppy [amd64] (groovy-proposed/none) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sphinxcontrib-log-cabinet [amd64] (groovy-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- Packageset: Added python-cryptography to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added simplejson to i386-whitelist in groovy
<bdmurray> LocutusOfBorg: That worked but I had to change it for libomp5-10 and libomp5-9.
<bdmurray> LocutusOfBorg: and actually just removing the Breaks field from those packages allows the upgrade to calculate. Why is << 44 in there anyway?
<LocutusOfBorg> bdmurray, meh, a while ago llvm-defaults had the real package, let me double check
<LocutusOfBorg> I don't remember...
<LocutusOfBorg> git log might help
<bdmurray> LocutusOfBorg: How do you want to proceed with fixing this?
<LocutusOfBorg> do you have a patch?
<bdmurray> No
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (bionic-proposed/main) [5.3.0-66.60] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (bionic-proposed/main) [4.15.0-1051.55] (kernel)
-queuebot:#ubuntu-release- New: accepted cppy [amd64] (groovy-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted sphinxcontrib-log-cabinet [amd64] (groovy-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- Packageset: Added python-cffi to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added recode to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed libclass-load-xs-perl from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed libdata-messagepack-perl from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed libmoose-perl from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed libmouse-perl from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed libpackage-stash-xs-perl from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed libpadwalker-perl from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed libtext-levenshteinxs-perl from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed libtext-xslate-perl from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed lzop from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed msgpack-c from i386-whitelist in groovy
<vorlon> rolling back postgresql-12, which synced and reset the icu transition
<ginggs> vorlon: hi!  what needs to happen for #1889111 ?
<ginggs> LP: #1889111
<ubot5> Launchpad bug 1889111 in nvidia-graphics-drivers-450 (Ubuntu) "nvidia-450 can't promote until linux+linux-restricted-modules is rebuilt against it" [Undecided,New] https://launchpad.net/bugs/1889111
<ginggs> thanks ubot5
<vorlon> ginggs: the linux-restricted-modules in groovy-proposed needs to be otherwise ready to migrate, at which point the block-proposed bug can be closed
<ginggs> vorlon: ack, thanks
<LocutusOfBorg> vorlon, can you please process hlint above? also haskell-cborg{,-json} and maybe bump faketime hint? faketime I did some analysis on i386, it fails because the code tries to inject $LIB into LD_LIBRARY_PATH, and maybe $LIB is not set on multiarch?
<LocutusOfBorg> I'm progressing with haskell, leaving behind everything that is icu entangled
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (bionic-proposed) [5.3.0-66.60]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1051.55]
<bdmurray> LocutusOfBorg: I found this commit but it still doesn't really clarify why 44 was chosen https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/commit/d9b6d3fd40bc1079d47db90021e01d8bcd9a97b8
<vorlon> LocutusOfBorg: marionnet: removed.  faketime: this should be faketime/all/i386 instead now that I've looked at the tests.
<vorlon> Laney: I'm not enthusiastic about skiptesting (or rather, should be badtesting) libreoffice/armhf.  I suppose downgrading to the release version and doing a no-change rebuild is not wanted?  libreoffice is pretty much the only real blocker now afaics
<vorlon> Laney: the firebird3.0+recode issue was because "someone" did a binary-copy of recode to groovy-proposed to resurrect the i386 binaries, but without talking to archive admins to make sure it got into the packageset, so my cleanup scripts removed it again :P
<vorlon> LocutusOfBorg: so if node-gulp-util had a nodejs12-specific change, how did https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/amd64/n/node-gulp-util/20200625_183437_f2a04@/log.gz pass with nodejs 10 and the package migrated?
<vorlon> ahasenack: motd-news-config vs ubuntu-server: yes, manually hacking the dependencies is in order here
<ahasenack> vorlon: ah, thanks
<ahasenack> I think in the next migration page refresh it will be clean wrt tests
<vorlon> LocutusOfBorg: and haskell-cborg binaries also now removed
<LocutusOfBorg> vorlon, node-gulp-utils had an ubuntu1 that removed the patch
<LocutusOfBorg> and it migrated
<LocutusOfBorg> and retried the tests
<LocutusOfBorg> I'll upload an ubuntu2 that goes in sync again once nodejs/icu migrates and nodejs12 is restored
<LocutusOfBorg> thanks for doing everything!
<vorlon> LocutusOfBorg: but the 3.0.8-2 itself migrated to the release pocket, so why did that happen
<LocutusOfBorg> vorlon, because it had a *build* dependency on nodejs >= 12, but not a runtime one?
<LocutusOfBorg> and autopkgtests was probably retried against proposed nodejs
<vorlon> LocutusOfBorg: it was not, that's what I'm saying
<vorlon> it passed against nodejs 10 at the time it migrated to the release pocket
<LocutusOfBorg> oh because that change was not probably related to nodejs/12 but a combo of nodejs+something else?
<LocutusOfBorg> mocha, or something similar, they now embed lots of stuff
<vorlon> bdmurray: node-redis/arm64... this is still failing with nodejs 10, and none of these runs are running for a particularly long time, so long-tests doesn't seem to help?
<vorlon> LocutusOfBorg: ugh, ok
<LocutusOfBorg> or maybe node-autopkgtests added some more test stuff...
<vorlon> now, what the heck happened with contextfree + x264? this wasn't blocking before
<LocutusOfBorg> bdmurray, looking at the other breaks, that "44" looks more a copy-paste error?
<bdmurray> LocutusOfBorg: given that libomp isn't managed by llvm-defaults I'd agree
<vorlon> wasn't blocking before, but none of the issues with contextfree + x264 are new afaict, so... a britney bug that it didn't report on this? :/
<vorlon> Laney: since we're trying to get this transition moved sooner rather than later, unless you plan to hint the libreoffice/armhf failures, I'd like to roll it back asap to get the build started sooner rather than later
<bdmurray> vorlon: I see - I looked at the 3 hour test not the whole history of tests
<LocutusOfBorg> reverse-depends -r groovy src:contextfree
<LocutusOfBorg> No reverse dependencies found
<LocutusOfBorg> vorlon, ^^ what about kicking it out from release to disentangle x264? :)
<vorlon> LocutusOfBorg: possibly. In the meantime I've triggered rebuilds for the other x264 revdeps that hadn't been handled... there's a good chance that'll be done before libreoffice
<LocutusOfBorg> in any case kicking it out won't hurt too much :D
<LocutusOfBorg> there is also a possibility that haskell will finish before libreoffice :p
<seb128> vorlon, did you come to a conclusion on what to do with libreoffice?
<LocutusOfBorg> but without free builders (all stuch in cleaning)... we can't progress too much
 * LocutusOfBorg goes to bed, g'night
<LocutusOfBorg> vorlon, did you do hlint removal? on arm64 armhf riscv64 s390x? debian bug: #967899
<ubot5> Debian bug 967899 in ftp.debian.org "RM: hlint [armel armhf mips64el mipsel s390x] -- ROM; Unbuildable" [Normal,Open] http://bugs.debian.org/967899
<sergiodj> friendly ping to archive-admin re. the telegraf package that's sitting on the NEW queue.  thanks
-queuebot:#ubuntu-release- New binary: hg-git [amd64] (groovy-proposed/none) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pytest-twisted [amd64] (groovy-proposed/none) [1.12-1] (no packageset)
<vorlon> LocutusOfBorg: hlint> done now
-queuebot:#ubuntu-release- Packageset: Added asn1crypto to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added pycparser to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added python-cryptography-vectors to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added python-filelock to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added python-hypothesis to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added python-iso8601 to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added python-pretend to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added python-virtualenv to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added sortedcontainers to i386-whitelist in groovy
#ubuntu-release 2020-08-14
-queuebot:#ubuntu-release- New source: plasma-wallpaper-dynamic (groovy-proposed/primary) [3.3.3-0ubuntu1]
-queuebot:#ubuntu-release- New source: jack-mixer (groovy-proposed/primary) [13-0ubuntu1]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-189.219] (core, kernel)
<vorlon> LocutusOfBorg: yeah, x264 just picked up another entangled transition from just-synced libcdio, so dumping contextfree now
-queuebot:#ubuntu-release- New binary: ntopng [amd64] (groovy-proposed/universe) [3.8.1+dfsg1-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: ntopng [armhf] (groovy-proposed/universe) [3.8.1+dfsg1-1build1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ntopng [amd64] (groovy-proposed) [3.8.1+dfsg1-1build1]
-queuebot:#ubuntu-release- New: accepted ntopng [armhf] (groovy-proposed) [3.8.1+dfsg1-1build1]
<Mirv> has the topic ever been discussed whether it could or should be prevented that urls like https://releases.ubuntu.com/20.04/ubuntu-20.04-desktop-amd64.iso stop working on the day of .1 release etc?
<Mirv> or if that's preferable instead
<Mirv> I could see it's preferable from letting people always use the official pages, but the official pages aren't localized so LoCos tend to maintain their own pages
<Mirv> I'm also still missing Lubuntu 14.04 from old-releases, while it has been removed from releases
<LocutusOfBorg> vorlon, you know, haskell-cborg-json might need another hammer? haskell-cborg-json unsatisfiable Build-Depends(-Arch) on armhf: libghc-cborg-dev (>= 0.2)
<LocutusOfBorg> ghc: 8.8.4-1	proposed (universe)	8 hours ago
<LocutusOfBorg> world: why do you hate me so much?
<vorlon> LocutusOfBorg: sorry, that was an NBS binary in -proposed; I managed to remove -dev but not -prof
-queuebot:#ubuntu-release- New: accepted hg-git [amd64] (groovy-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted pytest-twisted [amd64] (groovy-proposed) [1.12-1]
<LocutusOfBorg> vorlon, I would rollback ghc when it finishes building, so we can let this haskell migrate and start rebuilds?
<vorlon> Mirv: I don't recall this having been discussed
<LocutusOfBorg> thanks for doing it :)
<LocutusOfBorg> (the json removal)
<LocutusOfBorg> btw x264 rebuilds missed mythtv, I issued it now
<vorlon> LocutusOfBorg: so this is rolling back to 8.8.3-3?
<LocutusOfBorg> not sure if you left it behind because it was in multiverse, or something else :D
<LocutusOfBorg> vorlon, rolling it back, will let the current mini transition end
<vorlon> yeah, I didn't have multiverse enabled in my sources when I ran that script, sorry
<LocutusOfBorg> but better wait for it to finish building? :)
<vorlon> ok; in that case, catch me in my morning if no one else takes care of it
<LocutusOfBorg> oh nice to know, I always wonder if people do not issue rebuilds because they know about some ftbfs or such
<LocutusOfBorg> well, riscv64/armhf takes days to finish
<LocutusOfBorg> I'm wondering if we should just kick it out
<LocutusOfBorg> in days, the current ghc transition will end, I'm at level 18...
<LocutusOfBorg> we can upload 8.8.4-1build1
<LocutusOfBorg> so, if you want to kick it out, please go ahead :D
<vorlon> done
<vorlon> (rolling back ghc)
<vorlon> rolling back dovecot :P
<seb128> hey vorlon , I see you went for rolling back libreoffice, I guess it means no icu migration before next week now?
<seb128> with hoping that the revert doesn't get the armhf issue...
<seb128> (which I'm not convinced about since 6.4.5 autopkgtests are green on the focal SRU which is the same source so it could be a toolchain or rdepends issue)
<Laney> I would have waited to hear back from us :/
<Laney> I was quite deliberate in my use of skiptest vs badtest
<LocutusOfBorg> tjaalton, what is happening?
<LocutusOfBorg> dpkg: error processing archive /tmp/apt-dpkg-install-IzpqYj/460-libraspberrypi0_0~20200520+git2fe4ca3-0ubuntu1_armhf.deb (--unpack):
<LocutusOfBorg>  trying to overwrite '/usr/lib/arm-linux-gnueabihf/libEGL.so', which is also in package libegl-dev:armhf 1.3.2-1
<LocutusOfBorg> (mythtv fails to build on armhf) ^^
<tjaalton> where?
<LocutusOfBorg> mythtv on armhf
<tjaalton> what's libraspberrypi0?
<LocutusOfBorg> who knows?
<tjaalton> complain to it's maintainer
<LocutusOfBorg>  libraspberrypi0 | 0~20200520+git2fe4ca3-0ubuntu1 | groovy/universe | arm64, armhf
<LocutusOfBorg> ok its mesa related, this is why I'm pinging you
<tjaalton> libegl-dev is built by libglvnd
<tjaalton> and it's the right place to have these
<LocutusOfBorg> maybe on raspberrypi they need to break/replaces them?
<tjaalton> pull-lp-source says it's not in ubuntu
<LocutusOfBorg> tjaalton, not build on amd64
<LocutusOfBorg> found it https://launchpad.net/ubuntu/+source/raspberrypi-userland/0~20200520+git2fe4ca3-0ubuntu1
<LocutusOfBorg> waveform, ^^
<LocutusOfBorg> I blame you :p
<LocutusOfBorg> for now I'm removing libraspberrypi dependency on armhf
<tjaalton> libEGL.so (and libGLESv2.so) are only built on armhf for some reason, arm64 doesn't build those
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/libglvnd/+bug/1891613
<ubot5> Ubuntu bug 1891613 in raspberrypi-userland (Ubuntu) "libraspberrypi0 not installable" [High,Confirmed]
<LocutusOfBorg> tjaalton, ^^ if you want to provide some input, I opened a bug
<tjaalton> wrong target
<tjaalton> ah it had both
<tjaalton> I already commented the packaging bug
<tjaalton> breaks/replaces would be wrong, as the system would still have libEGL.so.1 from libglvnd
<tjaalton> libegl1 deb
<LocutusOfBorg> thanks
<seb128> Laney, thanks for the by team change review!
<Laney> np
<Laney> thanks for the change :>
<seb128> Laney, I was thinking also adding the 'implicit depends' info to the report, does that make sense to you? it would give some context for e.g libcdio ... but things changed there right? those used to be candidate but fail in update_excuses no?
<Laney> seb128: might get too noisy?
<Laney> you could maybe say 'breaks some other packages, see excuses'
<seb128> right, those lists are a bit long, that might be an option
<seb128> or maybe it's ok if that's a list space separate of source names without an entry for each arch?
<seb128> Laney, thanks for the input, I will try and see how the reports looks like
<juliank> Laney: Just saw the email with the instances without autopkgtests, are you looking into that by any chance?
<juliank> Oh I see ones from 9 hours ago, I guess spam filter ate the ones in between
<Laney> juliank: nop
<juliank> so many errors, aargh!
<juliank> are tests still running?
<juliank> the queues seem empty
<Laney> yes it looks ok
<Laney> are you talking about bos02?
<juliank> bos02 seemed to cause some errors last night
<juliank> also is there a bug in urllib3?
<juliank> ah but yes, these errors are all bos02
<Laney> maybe there was some overnight blip
<juliank> Traceback (most recent call last):
<juliank>   File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 377, in _make_request
<juliank>     httplib_response = conn.getresponse(buffering=True)
<juliank> TypeError: getresponse() got an unexpected keyword argument 'buffering'
<Laney> if those instances are stuck deleting, ask the ~IS vanguard to reset-state active && delete them
<juliank> hmm
<juliank> this is weird
<juliank> :D
<Laney> dunno what that is
<juliank> the errror is WARNING:root:instance adt-groovy-s390x-emboss-20200813-193914 (29072e49-ea49-40b1-97ff-5bf1283648ad) has no associated autopkgtest (auth_url: http://keystone.infra.bos02.scalingstack:5000/v2.0/)
<juliank> for a bunch of them
<Laney> they look stuck, it happens when the cloud has a sad sometimes
<Laney> go ask IS to intervene per ^
<Laney> perhaps that situation also tickles a bug in the openstack client tools :(
<juliank> I'll retry and look if it still happens
<Laney> cheers!
-queuebot:#ubuntu-release- Unapproved: accepted bind9-libs [source] (focal-proposed) [1:9.11.16+dfsg-3~ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted build-essential [source] (focal-proposed) [12.8ubuntu1.1]
-queuebot:#ubuntu-release- New binary: build-essential [amd64] (focal-proposed/main) [12.8ubuntu1.1] (core, i386-whitelist)
<waveform> LocutusOfBorg, thanks for the ping - taking a look
<doko> Laney: LO succeeded to build in the groovy test rebuild
<tjaalton> waveform: you probably shouldn't need to build libEGL etc on armhf, check why it does build them and disable by force if necessary
<waveform> tjaalton, indeed - it's building a brcm-specific EGL for use on the pi0-3 apparently (and the arm64 builds done't include them as the pi4 only supports the mesa drivers and the pi foundation only (officially) support arm64 on the pi4)
<tjaalton> ugh
<waveform> just digging into the cleanest way of dealing with this - apparently there are some vaguely important use-cases where the brcm-specific EGL is needed, but the library seems to build both libEGL and libbrcmEGL (+all the rest) so I'll try and excise the former and leave the latter
<tjaalton> so the worst-case scenario is that you rename the conflicting libs (to have a .1), then add diversions
<tjaalton> libGLESv2.so -> libGLESv2.so.2
-queuebot:#ubuntu-release- New binary: budgie-wallpapers [amd64] (groovy-proposed/universe) [20.10] (personal-fossfreedom, ubuntu-budgie)
<tjaalton> waveform: I think the entrypoint for the brcm-stuff is in libEGL/GLESv2, so looks like you can't avoid shipping them
<waveform> actually I'm not so sure about that ... just noticed libEGL.so has exactly the same size as libbrcmEGL.so which makes me ... suspicious - just digging into the CMake stuff
<waveform> ah yes, just compiled from the same source with different names below the comment "# recommended names to use to avoid conflicts with mesa libs" :)
<waveform> so, should be okay to exclude the "mesa-named" duplicates and just leave the brcm ones
<tjaalton> okay..
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (focal-proposed) [2.664.5]
-queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (bionic-proposed) [2.525.46]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.525.47]
<LocutusOfBorg> waveform, can you please ping back once you have a fix?
<waveform> LocutusOfBorg, will do
<LocutusOfBorg> so I can fix mythtv :D
-queuebot:#ubuntu-release- Unapproved: rejected intel-microcode [source] (bionic-proposed) [3.20191115.1ubuntu0.18.04.3]
<waveform> LocutusOfBorg, added a patch to LP: #1891613
<ubot5> Launchpad bug 1891613 in raspberrypi-userland (Ubuntu) "libraspberrypi0 not installable" [High,Confirmed] https://launchpad.net/bugs/1891613
-queuebot:#ubuntu-release- Builds: 42 entries have been added, updated or disabled
<LocutusOfBorg> waveform, sponsoring
-queuebot:#ubuntu-release- New binary: linux-signed-azure-4.15 [amd64] (bionic-proposed/main) [4.15.0-1093.103] (no packageset)
<vorlon> Laney, seb128: if you're comfortable with a skiptest on libreoffice, we can still cancel out this rebuild and revive the 6.4.5 binaries
<vorlon> but what the heck do we do with node-redis anyway, it regresses on arm64 with a no-change rebuild of nodejs
<Laney> vorlon: I only skiptested some other things which were waiting on this libreoffice
<Laney> let's see how your 6.4.4 pans out, if that fails too then I have some gcc-9 builds in progress which might (or might not) fare better
<rbalint> vorlon, i've just started reproducing node-redis, will see how it goes
<seb128> Laney, but then we still need to wait for days of libreoffice rdepends validating their autopkgtests, including retries because we know those are flaky
<vorlon> rbalint: bdmurray said he got it to work in canonistack, so maybe this is something that needs to be added to the big_test list instead of long_test?
<vorlon> we have individual test timeouts, which were maybe borderline before and succeed in a heftier environment
<rbalint> vorlon, sounds possible
<seb128> Laney, vorlon , I've a feeling it's going to take at least another week until we clear our a libreoffice rebuilds :/
<rbalint> vorlon, also if it passes locally we can just hint it
<bdmurray> speaking of node-redis I'll remove it from long_tests since that was an error
<vorlon> seb128: I hope not, 6.4.5 builds only need 19h and if the tests are /working/, that should only be another 100h
<vorlon> sorry, 10h ;)
<vorlon> bdmurray: do you want to go ahead and add it to big_tests at the same time and we'll see what happens?
<bdmurray> vorlon: okay
<seb128> vorlon, let's see on monday I guess
<Laney> seb128: libreoffice only has a few rdepends, it's not that bad
-queuebot:#ubuntu-release- New binary: haskell-gi-pango [ppc64el] (groovy-proposed/universe) [1.0.22-1build1] (no packageset)
<seb128> Laney, right, I guess it's ok when we don't have a backlog of 3 days on armhf as we had recently
-queuebot:#ubuntu-release- New binary: haskell-gi-pango [amd64] (groovy-proposed/universe) [1.0.22-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-pango [s390x] (groovy-proposed/universe) [1.0.22-1build1] (no packageset)
<rbalint> vorlon, bdmurray ok, then i don't try reproducing node-redis again, moving on to other packages
<bdmurray> vorlon: updated
<vorlon> tjaalton: fwiw livecd-rootfs 2.525.47 was accepted despite being built with wrong -v option, and there's no SRU tracking for the bug linked from the 2.525.46 changelog...
<bdmurray> LocutusOfBorg: juliank suggested another packaging change for bug 1886748 - moving libomp-9-dev from a Recommends to a Suggests of clang-9. Would that work for you?
<ubot5> bug 1886748 in ubuntu-release-upgrader (Ubuntu Focal) "upgrade from 18.04 to 20.04 fails to calculate if libomp5 is installed" [High,Confirmed] https://launchpad.net/bugs/1886748
<juliank> I feel like I want to have distribution upgrade hints for apt at some point
<juliank> but also this would be hard to hint :D
<juliank> I should just get a new state of the art solver done
-queuebot:#ubuntu-release- New binary: haskell-gi-pango [arm64] (groovy-proposed/universe) [1.0.22-1build1] (no packageset)
<vorlon> bdmurray: workers restarted with updated config, if you want to retry node-redis
 * Laney fixes .manifest on ancientminister to unbreak sync-mirrors
<bdmurray> vorlon: I've pushed the button
<Laney> no idea why it was only budgie triggering that
<vorlon> xnox: did you not have a git branch somewhere for the proposed grub preinst work?
<rbalint> ubuntu-archive, could you please demote rust-tokio-core do groovy-proposed due to LP: #1891679 to unblock other rust packages?
<ubot5> Launchpad bug 1891679 in rust-tokio-core (Ubuntu) " rust-tokio-core: FTBFS: build-dependency not installable: librust-scoped-tls-0.1+default-dev" [Undecided,New] https://launchpad.net/bugs/1891679
<rbalint> ubuntu-archive or i should ask for a batch later
<vorlon> rbalint: demote> no, but I'll remove it
<vorlon> the package build-depends on an obsolete version, so it's not going to come back without a sourceful fix - so I don't want this cluttering -proposed, I want it removed to leave the Debian maintainers to deal with it
<LocutusOfBorg> bdmurray, I don't understand to be honest, if it works, I'll be happy
<rbalint> vorlon, ack, thanks, would you be open to demotions for packages that can migrate in theory later>
<rbalint> ?
<vorlon> rbalint: yes
<vorlon> xnox: n/m, found the preinst mp, thanks
<vorlon> rbalint: yes
<doko> vorlon: tjaalton wants a SRU template for your pycurl SRU
<vorlon> fair
-queuebot:#ubuntu-release- Unapproved: gnome-shell (bionic-proposed/main) [3.28.4-0ubuntu18.04.3 => 3.28.4-0ubuntu18.04.4] (desktop-extra, mozilla, ubuntu-desktop)
<vorlon> tjaalton, doko: added
<xnox> vorlon:  i'm discussing it with debian maintainer, and we don't want preinst work.
<vorlon> xnox: why?
<xnox> vorlon:  adding checks in postinst, to check that devices exist before calling grub-install. Such that MBR and /boot never get out of sync.
<xnox> vorlon:  having newer modules in /usr/lib is ok (and like non-matching the ones in /boot)
<xnox> vorlon:  also it's my action to follow up on all that.
<vorlon> xnox: having them in /usr/lib allows for the possibility that other packages might call grub-install behind our back despite grub-pc not being configured
<xnox> vorlon:  apart from cloud-init, which we are the ones pushing to call grub-install, what else calls grub-install?
<xnox> other packages only call update-grub that regenerates grub.cfg, but doesn't update mbr/efi.
<xnox> (and i consider shim-signed/grub-* packages to be cooperating ones)
<vorlon> xnox: and if it's a non-interactive upgrade, your only choice in the postinst is to exit 1, which leaves the package unconfigured; don't we think that's worse that having it fail to unpack?
<vorlon> xnox: yeah and shim only calls grub-install for the efi target, so not affected.  Ok, if we expect nothing to call grub-install behind our backs, then that part is reasonable
<xnox> vorlon:  failing preinst will leave the system in a worse state, aborting upgrade transaction much earlier.
<xnox> (with a lot more packages unpacked, and not configured)
<vorlon> xnox: I don't see why this is a worse state
<vorlon> unpacked but not configured> do-release-upgrade attempts to clean this up
<xnox> vorlon:  if that's your agrument, surely it should be 'config' and not 'preinst'. and it will none-the-less duplicate a lot of the question logic, no?
<vorlon> xnox: config does not block the upgrade.
<vorlon> apt ignores non-zero exit values when invoking the config scripts in the pre- stage
<LocutusOfBorg> waveform, and it migrated, thanks for fixing so quickly
<xnox> amazing
<waveform> LocutusOfBorg, no prob - slightly embarrassed I didn't notice the armhf issue before! (spending too much time on arm64 :)
<xnox> vorlon:  i feel that postinst fixes are a must. preinst fixes are nice to have. in the context of non-interactive upgrades => postinst is what we must fix.
<vorlon> xnox: fair.  but we also need to fix the behavior of grub-install itself
<xnox> vorlon:  in terms of do-release-upgrade, i feel there might not even be any need to fix anything, becuase it is interactive, and the failed-devices debconf flow is asked.
<vorlon> the user might have set a non-interactive frontend for do-release-upgrade, I think?
<xnox> vorlon:  and yes, behaviour of grub-install itself is suboptimal, and needs to be fixed upstream. That is a separate task from maintainer scripts stuff.
<vorlon> xnox: it is a separate task, but also blocking for turning on 20.04 upgrades
<xnox> vorlon:  and what colin is fixing is not just "exit 1" but "do not attempt to call grub-install when devices are non-existant" meaning exit 1 is before attempting to bork the machines.
<xnox> with that fix alone, it would be enough to turn on upgrades. As postinst will fail non-interactively without borking things up.
<xnox> and interactively there is failed-devices flow to correctly upgrade.
<xnox> without a huge code dump of preinst changes or grub-install itself fixes.
<xnox> also i'm failing at not working =)
<xnox> vorlon:  i'd like to see postinst changes that colin is thinking off, to prevent calling grub-install on any devices, if any of the install-devices are missing.
<vorlon> that's fine
<vorlon> we still have the weird case in amazon where grub-install is called for a device that exists, then strangely fails
<xnox> (that seems to achieve what we desired with preinst, whilst keeping all that in postinst)
<vorlon> amazon?  azure
<xnox> azure yes.
<xnox> on a single serial which i am still debugging.
<vorlon> regardless, despite being uncommon, I'd like us to have grub-install itself robustified before turning on upgrades
<xnox> i have copies of what is in azure, and what we have locally, that do not match.
<vorlon> anyway, this can all wait until Monday
<xnox> it seems like an image got somehow missbuilt/missuploaded
<xnox> "I'd like us to have grub-install itself robustified before turning on upgrades" => ack.
<vorlon> I just was making sure we had a proper tracking bug for this (whose description / scope can be amended as appropriate) to make it clear to the release team what is blocking turning on upgrades
<xnox> ack
<xnox> vorlon:  it really does feel like "grub-install" was only ever meant as install, and was never meant to be "upgrade"
<rbalint> vorlon, rust-gtk was removed with 'broken with new dh-cargo', but it is now in testing in Debian again
<rbalint> vorlon, could you please resurrect it to groovy-proposed or is should get more confirmation that it would work?
<rbalint> vorlon, or i should upload it with build1 myself
<Laney> rbalint: you should be able to do the copy back to proposed yourself, just fyi - assuming no rebuid is needed vs the previous binaries
<Laney> bye o/
<rbalint> Laney, wow, thanks!
-queuebot:#ubuntu-release- New sync: rust-gtk (groovy-proposed/primary) [0.7.0-1]
-queuebot:#ubuntu-release- Packageset: Added redkite to ubuntustudio in groovy
<vorlon> rbalint: yeah, copy-package -b -e $version --force-same-destination -s groovy-proposed $srcpkg
<rbalint> vorlon, it worked, but i still need it to be accepted from NEW :-)
<rbalint> vorlon, so please accept it
-queuebot:#ubuntu-release- New binary: haskell-gi-pango [armhf] (groovy-proposed/universe) [1.0.22-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-pango [riscv64] (groovy-proposed/universe) [1.0.22-1build1] (no packageset)
<sergiodj> friendly ping to archive-admin re. the telegraf package that's sitting on the NEW queue.  thanks
-queuebot:#ubuntu-release- Unapproved: ceph (focal-proposed/main) [15.2.3-0ubuntu0.20.04.1 => 15.2.3-0ubuntu0.20.04.2] (desktop-core, ubuntu-server)
<LocutusOfBorg> please process haskell-gi-pango ^^
<rbalint> ubuntu-archive please remove predictprotein https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963927
<ubot5> Debian bug 963927 in predictprotein "predictprotein:Unusable, fails with: Assigning non-zero to $[ is no longer possible" [Serious,Open]
<rbalint> ubuntu-archive please demote rust-crossbeam to groovy-proposed , it is removed from testing, too, and blocks rust-crossbeam-utils
<bdmurray> vorlon: node-redis still failed
#ubuntu-release 2020-08-15
-queuebot:#ubuntu-release- New: accepted haskell-gi-pango [amd64] (groovy-proposed) [1.0.22-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-pango [armhf] (groovy-proposed) [1.0.22-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-pango [riscv64] (groovy-proposed) [1.0.22-1build1]
-queuebot:#ubuntu-release- New: rejected rust-gtk [sync] (groovy-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-pango [arm64] (groovy-proposed) [1.0.22-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-pango [s390x] (groovy-proposed) [1.0.22-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-pango [ppc64el] (groovy-proposed) [1.0.22-1build1]
<vorlon> rbalint: hmm I tried to accept rust-gtk and it was rejected instead; I don't see why, the reason would be in the email
<vorlon> rbalint: otoh I just did a copy and that worked
<vorlon> bdmurray: node-redis> ah, but the one I triggered passed and only took 16 minutes... so yay flaky tests
<vorlon> rbalint: rust-crossbeam: also requires sourceful update for compatibility with the new rust-crossbeam-utils, so removing rather than demoting
-queuebot:#ubuntu-release- Unapproved: accepted pycurl [source] (focal-proposed) [7.43.0.2-1ubuntu6]
-queuebot:#ubuntu-release- Unapproved: accepted python-babel [source] (focal-proposed) [2.6.0+dfsg.1-1ubuntu2.1]
-queuebot:#ubuntu-release- New binary: haskell-gi-gdkpixbuf [amd64] (groovy-proposed/universe) [2.0.23-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: pango1.0 [amd64] (groovy-proposed/main) [1.46.0-1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: pango1.0 [i386] (groovy-proposed/main) [1.46.0-1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: pango1.0 [s390x] (groovy-proposed/main) [1.46.0-1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: pango1.0 [ppc64el] (groovy-proposed/main) [1.46.0-1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: pango1.0 [armhf] (groovy-proposed/main) [1.46.0-1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: pango1.0 [arm64] (groovy-proposed/main) [1.46.0-1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: haskell-gi-gdkpixbuf [ppc64el] (groovy-proposed/universe) [2.0.23-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gdkpixbuf [s390x] (groovy-proposed/universe) [2.0.23-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gdkpixbuf [arm64] (groovy-proposed/universe) [2.0.23-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: pango1.0 [riscv64] (groovy-proposed/main) [1.46.0-1] (core, i386-whitelist)
<LocutusOfBorg> vorlon, Updating simpleburn introduces new bugs: #929381, #968313
<ubot5> bug 929381 in cgroup-lite (Ubuntu Precise) "init script fails to start" [High,Fix released] https://launchpad.net/bugs/929381
<ubot5> Error: Launchpad bug 968313 could not be found
<LocutusOfBorg> can we please kick it out?
<LocutusOfBorg> should be the only blocker for cdio/x264 transitions
-queuebot:#ubuntu-release- New binary: haskell-gi-gdkpixbuf [armhf] (groovy-proposed/universe) [2.0.23-1build1] (no packageset)
<LocutusOfBorg> please accept gi-gdkpixbuf ^^ (riscv64 is finishing the build)
<LocutusOfBorg> any ubuntu-archive, please kick python3-setuptools out from groovy, it broke the world https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968410
<ubot5> Debian bug 968410 in python3-setuptools "python3-setuptools: ModuleNotFoundError: No module named '_distutils_hack'" [Grave,Open]
<LocutusOfBorg> probably it is just a matter of shipping that file...
<LocutusOfBorg> doko, ^^
-queuebot:#ubuntu-release- New binary: haskell-gi-gdkpixbuf [riscv64] (groovy-proposed/universe) [2.0.23-1build1] (no packageset)
-queuebot:#ubuntu-release- New: accepted pango1.0 [amd64] (groovy-proposed) [1.46.0-1]
-queuebot:#ubuntu-release- New: accepted pango1.0 [armhf] (groovy-proposed) [1.46.0-1]
-queuebot:#ubuntu-release- New: accepted pango1.0 [ppc64el] (groovy-proposed) [1.46.0-1]
-queuebot:#ubuntu-release- New: accepted pango1.0 [s390x] (groovy-proposed) [1.46.0-1]
-queuebot:#ubuntu-release- New: accepted pango1.0 [arm64] (groovy-proposed) [1.46.0-1]
-queuebot:#ubuntu-release- New: accepted pango1.0 [riscv64] (groovy-proposed) [1.46.0-1]
-queuebot:#ubuntu-release- New: accepted pango1.0 [i386] (groovy-proposed) [1.46.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gdkpixbuf [amd64] (groovy-proposed) [2.0.23-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gdkpixbuf [armhf] (groovy-proposed) [2.0.23-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gdkpixbuf [riscv64] (groovy-proposed) [2.0.23-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gdkpixbuf [arm64] (groovy-proposed) [2.0.23-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gdkpixbuf [s390x] (groovy-proposed) [2.0.23-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gdkpixbuf [ppc64el] (groovy-proposed) [2.0.23-1build1]
<Laney> setuptools is gone
-queuebot:#ubuntu-release- New: accepted budgie-wallpapers [amd64] (groovy-proposed) [20.10]
<LocutusOfBorg> ð
-queuebot:#ubuntu-release- Unapproved: setuptools (focal-proposed/main) [45.2.0-1 => 49.3.1-2] (i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: rejected setuptools [source] (focal-proposed) [49.3.1-2]
-queuebot:#ubuntu-release- New binary: haskell-gi-gdk [amd64] (groovy-proposed/universe) [3.0.22-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gdk [ppc64el] (groovy-proposed/universe) [3.0.22-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gdk [s390x] (groovy-proposed/universe) [3.0.22-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gdk [arm64] (groovy-proposed/universe) [3.0.22-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: elastix [amd64] (groovy-proposed/universe) [4.9.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gdk [armhf] (groovy-proposed/universe) [3.0.22-1build1] (no packageset)
-queuebot:#ubuntu-release- New: accepted elastix [amd64] (groovy-proposed) [4.9.0-2]
-queuebot:#ubuntu-release- New binary: haskell-gi-gdk [riscv64] (groovy-proposed/universe) [3.0.22-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-expect [s390x] (groovy-proposed/universe) [0.0.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-expect [amd64] (groovy-proposed/universe) [0.0.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-expect [ppc64el] (groovy-proposed/universe) [0.0.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-expect [arm64] (groovy-proposed/universe) [0.0.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-expect [armhf] (groovy-proposed/universe) [0.0.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-expect [riscv64] (groovy-proposed/universe) [0.0.6-1] (no packageset)
<LocutusOfBorg> haskell-gi-gdk accept please?
-queuebot:#ubuntu-release- New binary: coinst [amd64] (groovy-proposed/universe) [1.9.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: coinst [ppc64el] (groovy-proposed/universe) [1.9.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: coinst [s390x] (groovy-proposed/universe) [1.9.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: coinst [arm64] (groovy-proposed/universe) [1.9.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: coinst [armhf] (groovy-proposed/universe) [1.9.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: eliom [s390x] (groovy-proposed/universe) [6.12.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: eliom [amd64] (groovy-proposed/universe) [6.12.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: eliom [ppc64el] (groovy-proposed/universe) [6.12.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: eliom [armhf] (groovy-proposed/universe) [6.12.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: eliom [arm64] (groovy-proposed/universe) [6.12.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: coinst [riscv64] (groovy-proposed/universe) [1.9.3-2] (no packageset)
<LocutusOfBorg> please accept them ^^ :)
<LocutusOfBorg> also haskell-gi-gdk
<vorlon> LocutusOfBorg: what do you mean, re: updating simpleburn?  Debian bug #929381 is reported against simpleburn 1.8.0-1, which is what we have
<ubot5> Debian bug 929381 in simpleburn "needs cdrecord binary which isn't in Debian" [Grave,Open] http://bugs.debian.org/929381
<vorlon> LocutusOfBorg: removed, regardless
<vorlon> LocutusOfBorg: what do we do about all the llvm-toolchain versions FTBFS and blocking llvm-toolchain-10?
<vorlon> hmm libreoffice/armhf doesn't appear to be segfaulting gcc, but it does seem to be taking multiple hours to get locks for pkgstripfiles :/
<LocutusOfBorg> vorlon, simpleburn has a FTBFS bug, #968313 (I copy-pasted from packages.qa.d.o) thanks for doing it!
<LocutusOfBorg> vorlon, llvm-toolchain-9 was FTBFS on ppc64el, I uploaded a fix around 5 minutes ago :p
<LocutusOfBorg> and I asked on #ubuntu-devel for the sphinx sadness
<LocutusOfBorg> for llvm-toolchain-8, will have a look maybe tomorrow, its something gcc-10 related
<LocutusOfBorg> maybe I'll force an old gcc there...
<LocutusOfBorg> coreycb, jamespage python-pbr sync?
<LocutusOfBorg> oh.. reverse-deps...
-queuebot:#ubuntu-release- New binary: eliom [riscv64] (groovy-proposed/universe) [6.12.1-3] (no packageset)
<vorlon> cancelling libreoffice/armhf build and restarting, hopefully this pkgstripfiles problem is a race condition we can dodge on the second time
-queuebot:#ubuntu-release- New binary: peony [s390x] (groovy-proposed/universe) [3.0.1-1] (ubuntukylin)
-queuebot:#ubuntu-release- New binary: peony [amd64] (groovy-proposed/universe) [3.0.1-1] (ubuntukylin)
-queuebot:#ubuntu-release- New binary: peony [ppc64el] (groovy-proposed/universe) [3.0.1-1] (ubuntukylin)
-queuebot:#ubuntu-release- New binary: peony [armhf] (groovy-proposed/universe) [3.0.1-1] (ubuntukylin)
-queuebot:#ubuntu-release- New binary: peony [arm64] (groovy-proposed/universe) [3.0.1-1] (ubuntukylin)
-queuebot:#ubuntu-release- New binary: flint [s390x] (groovy-proposed/universe) [2.6.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: flint [ppc64el] (groovy-proposed/universe) [2.6.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: flint [amd64] (groovy-proposed/universe) [2.6.3-1] (no packageset)
#ubuntu-release 2020-08-16
-queuebot:#ubuntu-release- New binary: flint [arm64] (groovy-proposed/universe) [2.6.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: flint [armhf] (groovy-proposed/universe) [2.6.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted flint [armhf] (groovy-proposed) [2.6.3-1]
-queuebot:#ubuntu-release- New: accepted eliom [riscv64] (groovy-proposed) [6.12.1-3]
-queuebot:#ubuntu-release- New: accepted flint [arm64] (groovy-proposed) [2.6.3-1]
-queuebot:#ubuntu-release- New: accepted flint [s390x] (groovy-proposed) [2.6.3-1]
-queuebot:#ubuntu-release- New: accepted peony [arm64] (groovy-proposed) [3.0.1-1]
-queuebot:#ubuntu-release- New: accepted peony [ppc64el] (groovy-proposed) [3.0.1-1]
-queuebot:#ubuntu-release- New: accepted flint [amd64] (groovy-proposed) [2.6.3-1]
-queuebot:#ubuntu-release- New: accepted peony [amd64] (groovy-proposed) [3.0.1-1]
-queuebot:#ubuntu-release- New: accepted peony [s390x] (groovy-proposed) [3.0.1-1]
-queuebot:#ubuntu-release- New: accepted flint [ppc64el] (groovy-proposed) [2.6.3-1]
-queuebot:#ubuntu-release- New: accepted peony [armhf] (groovy-proposed) [3.0.1-1]
-queuebot:#ubuntu-release- New: accepted coinst [arm64] (groovy-proposed) [1.9.3-2]
-queuebot:#ubuntu-release- New: accepted coinst [ppc64el] (groovy-proposed) [1.9.3-2]
-queuebot:#ubuntu-release- New: accepted coinst [s390x] (groovy-proposed) [1.9.3-2]
-queuebot:#ubuntu-release- New: accepted eliom [arm64] (groovy-proposed) [6.12.1-3]
-queuebot:#ubuntu-release- New: accepted eliom [ppc64el] (groovy-proposed) [6.12.1-3]
-queuebot:#ubuntu-release- New: accepted coinst [armhf] (groovy-proposed) [1.9.3-2]
-queuebot:#ubuntu-release- New: accepted eliom [amd64] (groovy-proposed) [6.12.1-3]
-queuebot:#ubuntu-release- New: accepted eliom [s390x] (groovy-proposed) [6.12.1-3]
-queuebot:#ubuntu-release- New: accepted coinst [riscv64] (groovy-proposed) [1.9.3-2]
-queuebot:#ubuntu-release- New: accepted eliom [armhf] (groovy-proposed) [6.12.1-3]
-queuebot:#ubuntu-release- New: accepted coinst [amd64] (groovy-proposed) [1.9.3-2]
-queuebot:#ubuntu-release- New: accepted ocaml-expect [arm64] (groovy-proposed) [0.0.6-1]
-queuebot:#ubuntu-release- New: accepted ocaml-expect [ppc64el] (groovy-proposed) [0.0.6-1]
-queuebot:#ubuntu-release- New: accepted ocaml-expect [s390x] (groovy-proposed) [0.0.6-1]
-queuebot:#ubuntu-release- New: accepted ocaml-expect [amd64] (groovy-proposed) [0.0.6-1]
-queuebot:#ubuntu-release- New: accepted ocaml-expect [riscv64] (groovy-proposed) [0.0.6-1]
-queuebot:#ubuntu-release- New: accepted ocaml-expect [armhf] (groovy-proposed) [0.0.6-1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gdk [amd64] (groovy-proposed) [3.0.22-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gdk [armhf] (groovy-proposed) [3.0.22-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gdk [riscv64] (groovy-proposed) [3.0.22-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gdk [arm64] (groovy-proposed) [3.0.22-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gdk [s390x] (groovy-proposed) [3.0.22-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gdk [ppc64el] (groovy-proposed) [3.0.22-1build1]
-queuebot:#ubuntu-release- New binary: nurpawiki [amd64] (groovy-proposed/universe) [1.2.3-11] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gdkx11 [s390x] (groovy-proposed/universe) [3.0.9-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: nurpawiki [s390x] (groovy-proposed/universe) [1.2.3-11] (no packageset)
-queuebot:#ubuntu-release- New binary: nurpawiki [ppc64el] (groovy-proposed/universe) [1.2.3-11] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gdkx11 [ppc64el] (groovy-proposed/universe) [3.0.9-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gdkx11 [amd64] (groovy-proposed/universe) [3.0.9-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: nurpawiki [armhf] (groovy-proposed/universe) [1.2.3-11] (no packageset)
-queuebot:#ubuntu-release- New binary: nurpawiki [arm64] (groovy-proposed/universe) [1.2.3-11] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gdkx11 [arm64] (groovy-proposed/universe) [3.0.9-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gdkx11 [armhf] (groovy-proposed/universe) [3.0.9-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: nurpawiki [riscv64] (groovy-proposed/universe) [1.2.3-11] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gtk [amd64] (groovy-proposed/universe) [3.0.33-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gtk [ppc64el] (groovy-proposed/universe) [3.0.33-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gtk [s390x] (groovy-proposed/universe) [3.0.33-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gdkx11 [riscv64] (groovy-proposed/universe) [3.0.9-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gtk [arm64] (groovy-proposed/universe) [3.0.33-1build1] (no packageset)
<Laney> I'm going to publish the 4.9 libreoffice, it has worked including libreoffice in bileto
<Laney> including autopkgtests*
<vorlon> Laney: wfm, thanks
<Laney> vorlon: â
<Laney> and I've re-uploaded 0ubuntu3 reverting the gcc-9 change to the same silo, to see what happens to the build/tests now
-queuebot:#ubuntu-release- New binary: ocamlviz [ppc64el] (groovy-proposed/universe) [1.01-4] (no packageset)
-queuebot:#ubuntu-release- New binary: ocamlviz [s390x] (groovy-proposed/universe) [1.01-4] (no packageset)
-queuebot:#ubuntu-release- New binary: ocamlviz [amd64] (groovy-proposed/universe) [1.01-4] (no packageset)
-queuebot:#ubuntu-release- New binary: ocamlviz [arm64] (groovy-proposed/universe) [1.01-4] (no packageset)
-queuebot:#ubuntu-release- New binary: ocamlviz [armhf] (groovy-proposed/universe) [1.01-4] (no packageset)
-queuebot:#ubuntu-release- New binary: ocamlviz [riscv64] (groovy-proposed/universe) [1.01-4] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure-4.15 [amd64] (bionic-proposed) [4.15.0-1093.103]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-189.219]
<LocutusOfBorg> vorlon, missing build on i386: libprotozero-dev (from 1.6.8-1build1)
<LocutusOfBorg> this is the last icu blocker
<LocutusOfBorg> ubuntu-archive ^^ please?
<vorlon> LocutusOfBorg: done
<vorlon> LocutusOfBorg: how did you identify this as a blocker, given that update_excuses wasn't mentioning qtlocation-opensource-src as a blocker for icu?
<vorlon> heh, only 2 autopkgtests running at all right now, and both are libreoffice ;)
-queuebot:#ubuntu-release- Packageset: Removed ocaml-ctypes from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed ocaml-dune from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed ocaml-integers from i386-whitelist in groovy
<Laney> Going to remove deepin-music/qtmpris on ppc64el
<vorlon> rolling back grcompiler
<vorlon> er, or not
<vorlon> (because Laney already did)
<vorlon> and protozero should actually have been building on i386 because qtlocation-opensource-src is in the i386 packageset; so copied back for building, and also ignoring build-dep satisfiability for qtlocation-opensource-rsc
-queuebot:#ubuntu-release- Packageset: Added protozero to i386-whitelist in groovy
<LocutusOfBorg> vorlon, I don't know, but it has been shown as blocker for one britney run
<vorlon> ok
<LocutusOfBorg> when I refreshed the page, it wasn't shown anymore
<LocutusOfBorg> but the binary was still shown as NBS...
<LocutusOfBorg> don't ask me why Britney changed the result on two runs, something I can't explain
<LocutusOfBorg> so, ready to migrate on next britney run?
<vorlon> I believe/hope so
<LocutusOfBorg> I prepared on bileto the haskell rebuilds
<LocutusOfBorg> so, I can publish once the current one migrates
<vorlon> \o/
<LocutusOfBorg> of course, accepting haskell-gi-gdkx11 and haskell-gi-gtk will allow something more to proceed :D
<LocutusOfBorg> (they can be accepted even if not all of them are built, they won't harm
<LocutusOfBorg> for llvm-10 and llvm-snapshot, we need a sphinx-related fix that is still in Debian new queue
<LocutusOfBorg> and for llvm-8 I'll have another look after sleep :p
-queuebot:#ubuntu-release- New binary: qgis [s390x] (groovy-proposed/universe) [3.10.9+dfsg-1ubuntu1] (no packageset)
<mwhudson> is britney just being slow or is it crashing?
<mwhudson> I: [2020-08-16T22:48:15+0000] - trying: icu
<mwhudson> I: [2020-08-16T22:48:16+0000] - skipped: icu (2, 256, 15)
<mwhudson> I: [2020-08-16T22:48:16+0000] -     got: 7577+0: a-10:a-6:a-6:i-2:p-7:r-7541:s-5
<mwhudson> <7500 source package names>
<mwhudson> this is not helpful :)
<mwhudson> hm something to do with gce-compute-image-packages
-queuebot:#ubuntu-release- New binary: qgis [ppc64el] (groovy-proposed/universe) [3.10.9+dfsg-1ubuntu1] (no packageset)
<mwhudson> ubuntu-archive halp
<RAOF> Hm?
<mwhudson> RAOF: i am a bit confused as to why britney is not migrating icu
<mwhudson> it seems to come down to gce-compute-image-packages and some binaries moving between source packages
