#ubuntu-release 2010-04-12
<slangasek> doko__: so the net effect of this is that ipv6 transitional addresses would only be used for connecting to IPv6-only sites?  that seems reasonable
<ScottK> Unfortunately the IETF consensus seems to be that breaking IPv4 NAT is a feature, not a bug.
<ScottK> So we get stuck trying to make it work in the real world.
<slangasek> well, as described, it doesn't *break* NAT; the only argument for making this change is that IPv6 transitional addresses are less reliable than established IPv4 NAT
<ScottK> Which I think is a fair statement.
<slangasek> that hasn't been my experience, FWIW - I find them equally reliable, with certain obvious benefits to being able to use a public address in the former case - but I'm ok with this change if others find that to be the case
<slangasek> (I had to think through it to assure myself that it wasn't going to make 6to4 and teredo /completely/ useless, since if someone has deployed either of those they've done so for a reason)
 * ScottK nods
<slangasek> cjwatson: you added a note to https://wiki.ubuntu.com/BetaProcess right after 8.04.1 asking for a u-d-a announcement about post-release plans, but I don't find anything in my mail history about this; what level of detail were you looking for, if you remember?
<cjwatson> hm, nothing in wetware memory ...
 * cjwatson searches the external memory store :-)
<cjwatson> 13:59 <mdz> this thread on -devel has gotten me wondering...
<cjwatson> 13:59 <mdz> did anyone tell the community about the 8.04.1 plan?
<cjwatson> 14:07 <cjwatson> hmm, I mentioned the team focusing on 8.04.1 in a public meeting, and the .1 team meetings were on the fridge, but I'm not seeing anything where the whole plan was laid out
<cjwatson> 14:10 <mdz> I think we should try to do better at that for the next LTS
<cjwatson> 14:10 <mdz> whatever our approach is
<cjwatson> 14:10 <mdz> it seems big enough (certainly in retrospect) to have warranted a -devel-announce email
<cjwatson> 14:27 <cjwatson> as at least a probably-good-enough placeholder, I've added a note to BetaProcess about it
<cjwatson> (private conversation on 2008-07-07; seems to be nothing secret though)
<slangasek> ok
<slangasek> are there any plans for 10.04.1 like there were for 8.04.1?
<cjwatson> and I think that the thread being referred to was https://lists.ubuntu.com/archives/ubuntu-devel/2008-July/025720.html and thread
<cjwatson> hmm, I haven't been told that there wasn't, and my understanding was that the 8.04 cycle was setting a pattern for future LTSes
<cjwatson> but I see that LucidReleaseSchedule doesn't have anything explicit about it
<slangasek> in terms of dedicating folks to work on post-release fixes?
<cjwatson> robbiew: ^- has this been discussed among the platform managers?
<slangasek> I mean, I've assumed there would be LTS point releases again staggered at roughly the halfway point of the cycle
<ttx> cjwatson: the slight drawback of using debian-installer/splash=false is that existing server installation preseeds will have to be modified to keep the "old" (as in pre-10.04) server boot behavior
<ttx> cjwatson: or am I understanding it wrong ?
<slangasek> ttx: isn't the server ISO setting that by default on the boot commandline?
<ttx> slangasek: I was thinking about netboot-ers
<slangasek> ah
<slangasek> then yeah
<ttx> I just saw the splash screen on my just-installed netbooted UEC setup :)
<slangasek> it's purty!
<ttx> (tbh I have to look very fast to see it)
<cjwatson> ttx: yes - I don't really see a way round that
<cjwatson> I think I suggested release-noting that in the bug, though I don't remember for sure
<cjwatson> in any case, preseeding has never been guaranteed to be stable from release to release
<ttx> cjwatson: that works for me, we just need to document that well.
<cjwatson> we don't break it gratuitously, but we've never hesitated to change it when we need to
<ttx> (togather with the Alt-F7 trick)
<ttx> cjwatson: The beta2 behavior has been working for me so far, I still have to debunk some spotty reports of failure (https://lists.ubuntu.com/archives/ubuntu-server/2010-April/004022.html)
<quadrispro> hello folks
<quadrispro> could anyone take a look at this? bug 561316
<ubottu> Launchpad bug 561316 in codelite "Sync codelite 2.5.2.4031~dfsg-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/561316
<mvo> pitti: what are the chances for a FFe for bug #45129 (diff http://bazaar.launchpad.net/~ubuntu-core-dev/update-manager/main/revision/1778) ? I'm trying currently to do a formal FFe, but LP won't let me :/
<ubottu> Launchpad bug 45129 in update-manager "update-manager should have per-package changelog locations (was: uses changelogs.ubuntu.com for all packages)" [Wishlist,Fix committed] https://launchpad.net/bugs/45129
<pitti> mvo: sub'ed -release and approved
<pitti> mvo: it's half a bug fix anyway
<mvo> pitti: nice, thanks!
<mvo> pitti: I felt so too, but wanted to check with you first
<pitti> thanks to you!
<lamont> slangasek: wanna kick another livecd-rootfs build on acorn, just to see?
<lamont> it's kinda disk abused atm, but that's just to see if I can make it fall over faster - so don't take this run as indicative of time needs
<ogra> lamont, archive is out of sync on armel atm
<ogra> (gnome-c-c needs to finish building and promotion)
<lamont> ogasawara: doesn't matter so much - acorn fell over
<slangasek> lamont: is acorn less over-fallen now?  Any use in another livefs try?
<lamont> slangasek: well, it'll either work or fall over..drives arrive in a day or 2
<slangasek> so doing another try doesn't tell you anything new :)
#ubuntu-release 2010-04-13
<ttx> cjwatson: I CCed you on the server boot testing thread... there is a worrying tendency on /some/ servers to not display anything at all on console (no login prompt). I'll have fader do another round making sure splash is disabled, but do you have any idea where it could come from ?
<slangasek> ttx: either plymouth hanging and failing to give back the console; or something preventing the 'filesystem' event from being emitted, blocking any of the gettys from starting
<ttx> slangasek: fader can ssh into them alright, fwiw
<slangasek> that leaves option 1)
<ttx> slangasek: looks like a display issue. Those servers pass all hw enablement tests, but that doesn't include a visual test
<slangasek> do VT switches work?
<ttx> slangasek: I'd say no, based on fader's limited description. I suggest we coordinate some time with him to clearly debug that
<ttx> I've not reproduced on my hardware
<ttx> slangasek: would anything be sensitive to the type of graphics card on the server ?
<slangasek> possible, but unlikely
<slangasek> it might be sensitive to the disk layout, or whether fsck was called during boot
<ttx> I'm pretty sure he runs the same test on the server that work and those that fail.
<slangasek> there's mounting evidence that fsck-on-boot breaks plymouth+mountall interaction quite badly; I still haven't had time to reproduce this, but need to in the next day or so
<slangasek> right
<slangasek> there might be a plain old race condition in there somewhere, too
<ttx> Will gather more data with fader and potentially ping one of you guys when we get stuck
<slangasek> ttx: in your local tests, are you booting w/o splash?
<ttx> in my tests, yes. Fader's tests all failed to get anything on VT7 yesterday, but he pxebooted the installer and got "splash" on the kernel line at the end
<ttx> I asked him to run without splash, but I don't think that will affect the lack on login prompt at the end, we had evidence of this issue elsewhere from someone trying out Beta2
<ttx> https://lists.ubuntu.com/archives/ubuntu-server/2010-April/004022.html
<ttx> That's why I asked to do some testing on the hw enablement servers to get confirmation that it fails or confidence that it works
<ttx> Let me sync with fader and get a proper bug report set up.
<ttx> At that point we are both blind :)
<ttx> slangasek: you might want to keep an eye on bug 557909, in case that's not already on your radar. Seem to be some race with LVM/mountall, I'm hitting it quite steadily on my workstation. Hitting M and mounting manually works.
<ubottu> Launchpad bug 557909 in devmapper "lucid hangs on boot because of device ownership" [Undecided,Confirmed] https://launchpad.net/bugs/557909
<ttx> bug 561390 seems to be the same LVM/mountall issue
<ubottu> Launchpad bug 561390 in mountall "LVM - /var failed to mount during boot" [Undecided,New] https://launchpad.net/bugs/561390
<slangasek> "I do an fsck on my root filesystem everytime, when booting (set by 'tune2fs -c 1')."
<slangasek> well, no wonder I could never reproduce that bug :P
<slangasek> (not the LVM/mountall one, a different one)
<ttx> heh
<ttx> the LVM thing is definitely a race, I win about half the time
<slangasek> the comments in 557909 make no sense
<slangasek> if you can reproduce this, can you grab a log of mountall --debug?
<ttx> slangasek: how do you do that ?
<slangasek> ttx: edit /etc/init/mountall.conf to add --debug and redirect output to a logfile under /dev
<ttx> ok
<ttx> I'll brb
<slangasek> huh, I guess technically we don't need the redirect anymore, you can just pick it up from /var/log/boot.log instead now \o/
<ttx> slangasek: log at chinstrap:~ttx/mountall.log
<ttx> slangasek: want it attached to that bug ?
<slangasek> probably to bug 561390
<ubottu> Launchpad bug 561390 in mountall "LVM - /var failed to mount during boot" [Undecided,New] https://launchpad.net/bugs/561390
<slangasek> the other one is mostly just noise
<ttx> yes
 * ttx can't seem to find back the error messages that were present in the log when he manually mounted /home
 * ttx investigates again
 * ttx grumbles and restarts
<ttx> slangasek: done, that was a lot more painful than expected, sorry
<slangasek> ttx: and /dev/cassini/cassini-home exists?
<slangasek> ttx: I think we need a udev log to go with this, but I'm not sure the right way to grab the log of the udev bits we need
<slangasek> oh, 554737 is awesome, plymouth and mountall are deadlocked because they're both in a blocking write
<slangasek> also: memory leaks
<ttx> slangasek: lrwxrwxrwx 1 root root 33 2010-04-13 12:37 /dev/cassini/cassini-home -> /dev/mapper/cassini-cassini--home
<NCommander> to any RM around: we're going to push a fix for OOO on ARM to a PPA (we're not 100% sure its going to work due the extreme build times involved). Is there an issue if we copy OOo from the devirtualized PPA to the main archive?
<pitti> NCommander: that's done with security all the time, should work
<NCommander> pitti: right, just wanted to clear it by RM since my PPA is going to be eating a buildd
<NCommander> pitti: alternatively, it might just be worth uploading to the archive properly since the OOo build for ARM is fairly stale and not supportable, so I can't see us being much worse off if we break it more (at least it builds in that case ;-))
<jdstrand> NCommander: if this is supposed to go to -security, be sure to build without -proposed and -updates. other than that, you mentioned it is not a virtual ppa, so it should be ok
<jdstrand> NCommander: also, if it goes to -security, you may want to communicate with a member of the security team ;)
<NCommander> jdstrand: thanks, just wanted to check that this was OK
<NCommander> jdstrand: its not for security
 * jdstrand nods
<jdstrand> NCommander: ubuntu-security-proposed and ubuntu-mozilla-security are two PPAs that we do this sort of thing with all the time
<jdstrand> NCommander: the only tricky part is when you do the pocket copy, everything goes to main, so you need to do a change-orverride on anything that shouldn't be in main
<jdstrand> NCommander: this is a manual process, so providing that list to the AA that does the pocket copy is a very nice thing to do :)
<lamont> so those ppa buildds will be right back.  just fyi
<ttx> slangasek, cjwatson: the "no login prompt" server bug is bug 546743
<ubottu> Launchpad bug 546743 in linux "Blank screen at first boot with ATI ES1000 and 10.04 server" [High,Confirmed] https://launchpad.net/bugs/546743
<ttx> all spottings of that issue so far involve ATi ES1000
<ttx> cjwatson: I was wondering if setting nomodeset for server on RC would make sense if we can't workaround this by any other way.
<ttx> that would defuse the "you broke my server boot for fancy graphics I don't care about" argument
<slangasek> NCommander: what's the point of using a PPA instead of doing the build in the archive directly, though?  Doesn't seem to save any build time, and costs archive admin time later to copy it
<NCommander> slangasek: the fix isn't fully tested due to three days of OOo build time. I'm personally not diffed either way, but there was concern that by doing an OOo upload, we can remove the working but stale binaries.
<slangasek> ah
<lamont> oh hai.  mucking about with ppc for a few minutes
<lamont> and ppc is back to the normal fun
#ubuntu-release 2010-04-14
<ScottK> slangasek: Thanks to seb128 syncing schroedinger at sabdfl's direction earlier today, we now need a MIR for orc.
<slangasek> ScottK: open an incomplete MIR bug, assign it to seb128?
<ScottK> Sure.
<ScottK> Bug #562735
<ubottu> Launchpad bug 562735 in orc "MIR to support new version of schroedinger in Lucid" [Undecided,New] https://launchpad.net/bugs/562735
<segler> hi, could somebody help me with a freeze exception? i created a bug report and added the necessary things, but nothing is happening and release is getting closer. https://bugs.launchpad.net/ubuntu/+source/rhythmbox-radio-browser/+bug/544416
<ubottu> Launchpad bug 544416 in rhythmbox-radio-browser "new upstream release" [Undecided,New]
<segler> hi, could somebody help me with a freeze exception? i created a bug report and added the necessary things, but nothing is happening and release is getting closer. https://bugs.launchpad.net/ubuntu/+source/rhythmbox-radio-browser/+bug/544416
<ubottu> Launchpad bug 544416 in rhythmbox-radio-browser "new upstream release" [Undecided,New]
<Riddell> slangasek, cjwatson: I don't seem to be able to commit to ~ubuntu-cdimage but https://code.edge.launchpad.net/~jr/debian-cd/ubuntu/+merge/23381 will bring in the new Kubuntu logo
<cjwatson> Riddell: bzr+ssh://antimony/srv/cdimage.ubuntu.com/bzr/debian-cd/ is the branch for commits
<cjwatson> the ~ubuntu-cdimage one is just a mirror
<cjwatson> feel free to commit to antimony
<Riddell> aah, thanks, will do
<segler> nobody responded, maybe i am at the wrong place, would somebody push me in the right direction?
<Riddell> segler: for gnomey stuff probably seb128 can point you in the right direction
<james_w> anyone have an opinion on the suitability of https://code.edge.launchpad.net/~arnegoetje/ubuntu/lucid/ttf-indic-fonts/merge-from-sid/+merge/23333 for this point in the release
<james_w> I'm not sure what's considered to be a new feature in a font packages
<lamont> slangasek: can I have a livecd-rootfs build attempt on acorn pls?
<nigelb> epiphany-extensions has a new upstream version.  it is possible to sync this from debian?  since the current epiphany-extensions doesn't work with the current epiphany-browser
<nigelb> slangasek, thoughts on ^?
<micahg> can I get an FFe ack on bug 461864
<ubottu> Launchpad bug 461864 in seamonkey "[FFe] Update Seamonkey to 2.0.x" [High,New] https://launchpad.net/bugs/461864
<slangasek> james_w: there's already been a FFe for the font stuff, bug #535582
<ubottu> Launchpad bug 535582 in ubuntu "FFE/UIFE: replace some font packages with ubuntu-desktop-fonts on the LiveCD" [Undecided,Confirmed] https://launchpad.net/bugs/535582
<slangasek> lamont: running
<slangasek> nigelb: epiphany-extensions> yes, that should be possible, please follow FFe process
<lamont> slangasek: either that works, or we hurt someone. :-D
<nigelb> slangasek, I'm unsure if we need to do it or not :(
<nigelb> it seems we're going to end up with some broken package anyway..
<slangasek> nigelb: why?
<nigelb> currently epiphany-extensions and epiphany-extensions-more are broken.
<nigelb> after the sync, epiphany-extensions-more would still remain broken, since debian doesn't have the new version yet
<slangasek> ah, ok.  anyway, the FreezeExceptionProcess page is supposed to be complete in its explanation of when an FFe is or isn't needed; what part should we make clearer?
<nigelb> its pretty clear.
<slangasek> micahg: where does seamonkey fall on the "decide what xulrunner revdeps we're supporting or not" list?
<micahg> slangasek: well, seamonkey has its own xul copy ATM
<slangasek> does that mean it avoided being on the radar?
<micahg> slangasek: well, upstream is entirely new and no one has had time to package it yet
<micahg> slangasek: it's been on my mind for months, but I've been busy porting other stuff
<slangasek> so you, at least, think we should keep it rather than drop it?
<micahg> slangasek: it seems there is an interest in it
<micahg> I had someone else wanting to make a seamonkey2 in universe which I already said no to
<slangasek> ScottK: ^^ you've voiced your concerns about release-maintainability of mozilla bits in universe; do you have an opinion on seamonkey?
<micahg> slangasek: I guess I should point out that sometime during the Lucid cycle we will have to jump to Seamonkey 2.1 which will be based on xulrunner-1.9.3
<micahg> slangasek: so, we'll need an SRU exception for new functionality if we keep it...
<slangasek> right; if we let it into lucid we should apply the same SRU/security policy as for other mozilla packages
<micahg> slangasek: does dropping an unnecessary option in an apache config require an FFe?
<slangasek> micahg: sounds like a cosmetic, low-urgency bugfix, so no; but we'll come for your head if it breaks something ;)
<micahg> slangasek: k, just wanted to know how urgently I need to get phpmyadmin sync'd from debian :)
<james_w> slangasek: aha, thanks
<james_w> slangasek: is the freeze expected to start at ~midnight UTC, or will I have chance to squeeze these in tomorrow morning?
<slangasek> james_w: midnight UTC; doesn't mean you can't try to squeeze things through tomorrow morning, just means they'll need a hand
<james_w> yeah, I'd prefer to save the extra work
<james_w> perhaps not quite in the spirit of it though :-)
<segler> i need a motu for uploading, but at #ubuntu-motu nobody is responding https://bugs.launchpad.net/ubuntu/+source/rhythmbox-radio-browser/+bug/544416 it is already approved
<ubottu> Launchpad bug 544416 in rhythmbox-radio-browser "new upstream release" [Wishlist,Confirmed]
<ScottK> slangasek: I worry about all the mozilla stuff.  Seamonkey probably less because aiui there aren't the same coordination requirements due to trademark restrictions.
<ScottK> slangasek: It probably makes sense to update and stay ~ in sync.
 * ScottK hasn't studied the matter in any detail.
<slangasek> ScottK: do you think it needs more study, or can micahg take that as an FFe?
<ScottK> slangasek: That was a barely informed opinion.  I'm unlikely to have more time today to give it more consideration.  If you think that's enough for an FFe, then please tell him to go ahead.
 * micahg is available for any questions :)
<micahg> slangasek: so, I guess you have the final call
<slangasek> micahg: go ahead; I'll follow up to the bug in a bit
<micahg> slangasek: ok, my plan is to have it in by Monday since it's unseeded
<ScottK> Any ideas why new builds aren't getting dispatched for powerpc, ia64, and sparc?
<slangasek> lamont: ^^?
<slangasek> lamont: also, the acorn build died; some error message about tax advise for pimps?
<slangasek> (I may be paraphrasing an error message that wasn't actually emitted)
#ubuntu-release 2010-04-15
<ScottK> slangasek: I'm reviewing the queue.  Some of it looks familiar....
<slangasek> familiar?
<lamont> slangasek: so...  acorn build failed, but acorn DIDN'T!!  this is progress.
<slangasek> ah, cool
<lamont> re build-queue, I expect we'll have that resolved once london is awake
<slangasek> I didn't bother looking at the log... :)
<slangasek> s/looking at/looking for/
<slangasek> yes, that seems to be the consensus
<lamont> right.  me neither.  just passing through before crashing.
<lamont> there was a change made this morning that is very co-incident to the cessation of builds
<lamont> so I've lobbed that grenade back to the involved, come wakey-wakey in london
 * lamont tries one thing before sleeping
 * ogra hugs lamont 
<ttx> slangasek/cjwatson: jjohansen investigated options for bug 546743
<ubottu> Launchpad bug 546743 in linux "Blank screen at first boot with ATI ES1000 and 10.04 server" [High,Confirmed] https://launchpad.net/bugs/546743
<ttx> jjohansen: could you detail them again ?
<jjohansen> options are kernel quirk, or we could set /etc/modprobe.d/radeon-kms.conf to have options radeon modeset=0
<ttx> jjohansen: would kernel quirk be limited to -server kernels ?
<jjohansen> no
<ttx> would it be limited to ES1000 ?
<jjohansen> well I would hope so it would be targeted at a specific match
<ttx> jjohansen: but you don't like this last option, as it means breaking the freeze, right
<jjohansen> yes it will require breaking kernel freeze it is the proper way to do it, but very late
<ttx> jjohansen: will apw update it anyway to fix the i830 kms issue ?
<jjohansen> ttx: maybe but this one won't have been tested
<ttx> The problem with /etc/modprobe.d/radeon-kms.conf is that it would break all radeon KMS iiuc, also I'm not sure that one is installed on servers
<ttx> another option is to play with server kernel boot options but that would affect everyone rather than just ES1000 users, and some people like to have big consoles (don't ask)
<jjohansen> ttx: kernel mode line could just set it for radeon
<jjohansen> radeon.modeset=0
<jjohansen> instead of nomodeset
<ttx> jjohansen: ok. That's still a little uglier, especially in update scenarios
<ttx> slangasek/cjwatson: deferring to you on this. I obviously prefer the inkernel fix, but I understand John's concerns as well
<jjohansen> ttx: yep
<slangasek> we certainly don't want to be disabling KMS for all radeon systems
<jjohansen> well I am against the in kernel fix at all until it is tested
<slangasek> then I think this is release notes material, documenting that users need to add the kernel option when booting
<slangasek> and we can try to fix it for the first post-release SRU
<ttx> jjohansen: fader can help in testing, he has quite a few affected boxes available in HW enablement
<jjohansen> ttx: okay, I will get him a kernel to test and we will get this in for the first SRU
<ttx> slangasek: note that it affects "certified" configs, even if that manual test is not part of the automated acceptation tests
<ttx> jjohansen: ok, I'll report suggested solution to management and see how well it flies
<ttx> slangasek, jjohansen: thanks !
<jjohansen> ttx: I'm sure not well
<ttx> jjohansen: we'll see :)
<apw> slangasek, the option nomodeset looks to be no longer working because of some module options X are installing and i am not sure why they are installing them at the moment
<slangasek> /etc/modprobe.d/radeon-kms.conf?
<apw> yeah those force kms on (there is an i915 one too)
<apw> and so to turn it off you have to use i915.nomodeset to undo it, nomodeset cannot do it
<apw> it is also what is stopping the i830 work quirking from working too
<apw> which is why it didn't get uploaded yesterday ... i only found that the setting wasn't -1 as it should be at midnight, and only foudn the overrides this morning
<slangasek> I think that's a mismerge from Debian
<apw> damn ... ok so for the quirks to work we'd need to upload the kernel bits and x...-intel
<apw> don't know if we want to do go that far or wait and sru it
<slangasek> uploading the X bits is not a problem, and should be done anyway even if the kernel has to be postponed
<apw> i can easily do the kernel bits for i830 etc
<slangasek> I'm comfortable uploading to drop those blacklist files
<mvo> I can test the fixes, I have the require HW
<slangasek> though I still need to get mountall off my plate first
<apw> the patches there got some testing last night by mvo, and he could retest today removing the file manually
<slangasek> since I've been fighting with that for 3h due to a change in bzr that made all my filesystems fail to mount at boot :/
<slangasek> mvo: for i830, or ES1000?
<apw> oh he is here ... mvo if you could comment out the contents of /etc/modprobe.d/i915-kms.conf
<apw> and redo the test you did last night for me
<apw> with no kernel command options
<mvo> sure
<apw> slangasek, what i can't be sure of getting is the dell bits fixed today, that is a tricky
<slangasek> mmk
<apw> if we don't get dell done do you still want the i915 blacklists uploading?
<slangasek> apw: well, I know from the bug log that rickspencer3 does
<ttx> slangasek: would you consider adding radeon.modeset=0 to server installs (in the same vein we remove "splash") to be a pre-release option ?
<apw> jjohansen, where we at with the radeon thing there
<slangasek> ttx: I'm not happy with that across the board, it means using a completely different code path for displays on server than desktop and may cause us unreproducibility grief
<apw> jjohansen, i have blacklist framework for radeon available if we know the PCI-id
<ttx> slangasek: ack
<slangasek> ttx: and it means having the installer guys make touchy changes to the installer the week before RC, for something which is just a workaround for a bug we plan to SRU anyway
 * apw pokes jjohansen 
<ttx> slangasek: (just checking) :)
<mvo> apw: win
<mvo> apw: works just fine now
<apw> mvo ... now if it had done that at 10 last night we'd have it in ... grrr
<mvo> :(
<apw> mvo, not your fault, a miss-merge of another package
<mvo> yeah, hope it can still make it, the diff is small and even though the machines are old, they are still in use
<slangasek> apw: has that also been regression-tested on non-i830 intel?
<ttx> apw: we can certainly get you a PCI-id if that's what it takes
<apw> slangasek, not as yet, now the positive side of it is working i want to test the negative
<slangasek> well, huh - just reproduced bug #533745 locally for the first time
<ubottu> Launchpad bug 533745 in sitecmd "link() - move $params to 3rd parameter" [Low,Fix released] https://launchpad.net/bugs/533745
<slangasek> great night for boot bugs, here
<apw> ttx could you get it for me yes
<apw> slangasek, would you prefer i try and blacklist this radeon one as well to save changes to the installer?
<ttx> apw: I don't have that HW, fader has it in the labs... I'm parsing existing logs to see if it shows
<apw> would mean re-uploading xorg-radeon as well
<apw> ttx whats the bug#
<ttx> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/546743
<ubottu> Launchpad bug 546743 in linux "Blank screen at first boot with ATI ES1000 and 10.04 server" [High,Confirmed]
<slangasek> apw: jj already expressed concern about uploading it untested; the X bits I'll upload for both regardless, I'll let the two of you sort out whether you want to push that change
<apw> jj yep, testing it well enough is the only concern from myside, positive and negative testing
<apw> slangasek, even
<slangasek> apw: well, how soon did you want to upload the kernel?  I don't think you're going to get the one half of that testing until morning in Boston
<apw> slangasek, yeah we could get the i915 tested and ready in a couple of hours, but the radeon would delay that till late here
<apw> and doing that means i have little or no time to work on the dell bug
<apw> sigh
 * ttx gets some coffee, sounds like a long day coming up
<slangasek> apw: work on the dell bug first, let radeon tend to itself?
 * apw is slightly worried that they are reinventing the wheel, making new patches for blacklisting when they already exist <- jjohansen 
<slangasek> who is?
<apw> john ...
<apw> i'll square it with him when i find him
<apw> slangasek, fyi there are two linux-meta-xxx updates outstanding pending builds ... linux-mvl-dove and linux-ec2
<slangasek> apw: linux-ec2 bins now accepted; processing dove as well
<apw> slangasek, oh had ec2 finished
<ogra> slangasek, the ubiquity change i talked about yesterday looks like: http://paste.ubuntu.com/414837/ (i'm still looking for the d-i equivalent, i forgot where thats set)
<slangasek> ogra: not in a position to review right now, sorry
<ogra> slangasek, i didnt expect you to, just wanted to show how trivial it is :)
<ogra> sorry that i didnt manage yesterday
<directhex> is an upload in order to make a package build on amd64 as well as i386, rather than i386-only, something that i should make for lucid?
<slangasek> directhex: generally welcomed, but will be weighed against things like build time and complexity of the change
<directhex> slangasek, i'm just running the test suite to make sure i didn't break anything
<directhex> yup, passed
<directhex> should i just make an upload & ping in here, or is a bug report preferred?
<slangasek> upload and ping
<slangasek> (what package?)
<directhex> slangasek, libflaim
 * slangasek nods
<directhex> just doing one more test build, then i need an i386 lucid pbuilder to make sure i didn't break things there
<directhex> bah, except "pbuilder create" is busted today
<directhex> sigh, 6 hours to try building it in a ppa instead
<slangasek> cjwatson: can queuebot come out and play?
<cjwatson> starting
<directhex> laney test-built for me on i386. just doing some lintian cleanup
<directhex>   Uploading libflaim_4.9.966-0ubuntu3_source.changes: done.
<slangasek> cjwatson: xserver-xorg-video-{intel,ati} in the queue are mine; could you review?
<slangasek> (I'm happy to explain why these changes are sane, if you have questions)
<apw> mvo, could you test the final patches for i830 here: http://people.canonical.com/~apw/master-lucid/ (with the modprobe.conf files missing)
<slangasek> seb128: hi, libdbusmenu is listed as an "upstream merge" - has the merge result been runtime-tested before upload?
<mvo> apw: let me do that now
<mvo> apw: hrm, filesystemcheck on the machine, so will take some minutes
<apw> mvo, i _hate_ that thing
 * mvo too
<seb128> slangasek, I've built and installed the update on my main work machine if that's what you are asking there, is an upstream merge any different of a patch in the debian dir?
<seb128> slangasek, it's working fine for me, I don't know if ted tested it too but I guess he did
<slangasek> seb128: if you've tested it, that's all I need to know, thanks
<seb128> slangasek, ok, yes I'm running it there and using the indicator and didn't notice any issue ;-)
<slangasek> seb128: in theory 'upstream merge' vs. 'cherry pick' doesn't mean anything; my real concern was the size of the patch, and whether the "upstream merge" wording might imply less rigorous testing
<seb128> slangasek, understable, thanks for checking ;-)
<slangasek> thanks for testing! :)
<cjwatson> slangasek: looking
<slangasek> thx
<slangasek> mvo: no bug # on this libubuntuone upload, why is this needed/wanted?
<seb128> slangasek, we discussed it on #ubuntu-desktop, because otherwise the music store loads flash which leads to bugs and crashes
<slangasek> heh, cute
<seb128> I've tested the update there, stored works fine
<seb128> store
<seb128> and rodrigo acked the change too
<cjwatson> slangasek: I accepted it anyway since it hardly matters that much, but it looks like a buglet that you didn't remove the /etc/modprobe.d/ directory in xserver-xorg-video-ati
<cjwatson> s/-ati/-radeon/
<slangasek> cjwatson: yeah, noticed that after I tagged/uploaded while I was preparing -intel
<cjwatson> both look fine, and I've verified the kernel defaults
 * cjwatson does a dist-upgrade with his dpkg upload by way of stress-testing
<mvo> apw: works fine the ~~i915 kernel
<apw> mvo thanks ... thats the patches as they would be in an upload, so thanks for testing
<apw> mvo, if you have any non-affect intel you could boot it on that would be a good data point too
 * apw has pushed the two remaining linux-meta-* variants now that the kernles are built and accepted
 * apw strokes queuebot -- perfect timing
<slangasek> I'm accepting those
<slangasek> and I've uploaded d-i for the dove ABI change
<slangasek> someone else should review / accept :)
 * cjwatson remembers to change kernel-version in the seeds for -21
<cjwatson> right, this dpkg looks good
 * ogra would like to upload flash-kernel, but it will break the images unless uboot-envtools gets approved (MIR bug 563394)
<ubottu> Launchpad bug 563394 in uboot-envtools "MIR uboot-envtools is needed for flash-kernel installer in omap" [Undecided,New] https://launchpad.net/bugs/563394
<cjwatson> d-i trivially ok, approved
<cjwatson> slangasek: you planning to change the seeds to match or shall I?
<slangasek> I can do it
<ogra> cjwatson, was that to me ?
<cjwatson> no
<slangasek> hmm, speaking of seeds
<slangasek> stgraber: did the seed reorg ever shake out with edubuntu?
<slangasek> task field on ubiquity-slideshow-ubuntu suggests that it did
<ttx> apw: fader is up now, if you need any info or test on the affected hw
<fader_> ttx, apw: you guys need PCI IDs from an affected system?
<apw> fader_, yes please
<fader_> apw: you want the output of "lspci -vnvn" or just the ID for the video card?
<apw> +                       { PCI_DEVICE(0x1002, 0x515e) },
<apw> +                       { PCI_DEVICE(0x1002, 0x515f) },
<apw> fader_, i was told it was those two that are affected, does that match
<fader_> apw: Let me take a look
<fader_> (It'll take me a moment as the systems are powered off and need to boot, etc.)
<fader_> apw: 1c:04.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02)
<fader_> (more to come)
<apw> fader_, whats the pci ids
<fader_> D'oh, sorry -- not yet caffeinated :(
<fader_> 1002:515e
<slangasek> pitti: do you need an MIR bug for a TeX macro package (feynmf)?
<pitti> slangasek: ah, I can review that quickly; these are usually harmless
<fader_> apw: All the Lenovo systems I've checked have had the same PCI ID... I'll have the info on the IBM in a few
<apw> ta
<pitti> slangasek: feynmf looks harmless, promoted; I wrote bug 563788 as a paper trail
<ubottu> Launchpad bug 563788 in feynmf "[MIR] feynmf" [Undecided,Fix released] https://launchpad.net/bugs/563788
<apw> fader_, did i miss the IBM results?
<fader_> apw: Sorry, having problems with that machine this morning.  I think I need Nafallo to stab its power button but he went out to lunch :(
<fader_> I've asked him to ping me ASAP
<apw> fader_, did i ask you to test a kerenl on those machines?
<apw> http://people.canonical.com/~apw/lp546743-lucid/
<fader_> apw: No, but I can
<apw> fader_,
<apw> you also need to disable config for radeon
<apw> /etc/modprobe.d/radeon-kms.conf needs its content commenting out
<apw> a dmesg from one booting that kernel would also be appreciated
<fader_> apw: Will do... okay if I attach the dmesg to the bug?
<apw> sure thing
<apw> or pastebin, or paper napkin :)
<fader_> apw: There doesn't seem to be an /etc/modprobe.d/radeon-kms.conf, at least on the first one of these I've looked at
<apw> fader_, ok then thats fine
<fader_> Cool
<apw> not sure _why_ there isn't one ... but hey
<fader_> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/546743/comments/15
<ubottu> Launchpad bug 546743 in linux "Blank screen at first boot with ATI ES1000 and 10.04 server" [High,In progress]
<apw> fader_, [    3.995143] [drm] radeon disabling kernel modesetting for known bad device.
<apw> thanks for the testing ... that looks good
<apw> just need to confirm that that those two id's are right
<fader_> apw: No problem.
<fader_> apw: The Lenovos all look to have the same one; I'll get data on the IBM as soon as I can
<jdstrand> from #ubuntu-devel:
<jdstrand> 08:43 < jdstrand> slangasek: I have a profile change to fix bug #517714 which  I, *ahem*, reintroduced just before freeze. ok to upload?
<ubottu> Launchpad bug 517714 in libvirt "[Lucid] Error starting domain: could not remove profile" [Critical,Triaged] https://launchpad.net/bugs/517714
<jdstrand> pitti: can you make this call? ^
<jdstrand> pitti: hi btw :)
<ttx> <apw> not sure _why_ there isn't one : because it's part of the xserver-xorg-video-radeon package, which is not installed on servers ?
<cjwatson> also Steve removed radeon-kms.conf in his recent upload
<pitti> jdstrand: looking
<jdstrand> pitti: basically, my little 'deny /dev/**' maneuver was, ummm, aggressive. 'deny' overrides any allows, so the stuff for /dev in 'base' got overridden
<pitti> jdstrand: this seems like a pure bug fix to me, though?
<pitti> jdstrand: i. e. I don't see that this would violate FF or something
<jdstrand> pitti: it is a totally pure bugfix. I introduced it in my last upload. profile change only-- no code changes
<pitti> jdstrand: so, please just upload it
<jdstrand> pitti: ah, I thought that everything had to go through you guys these days
<pitti> jdstrand: well, we need to review the uploaded packages in the queue
<jdstrand> pitti: can you accept it once I upload it? I'll ping you
<pitti> jdstrand: we regularly review the queue anyway, but sure
<jdstrand> pitti: ok thanks! the binaries are building locally. after testing I'll upload and ping
<jdstrand> pitti: uploaded. please process when convenient. thanks again :)
<ttx> ew
<pitti> jdstrand: done
<pitti> bbiab
 * cjwatson rebuilds server to cope with kernel ABI skew
<jdstrand> pitti: thanks! :)
<ScottK> pitti or cjwatson: Would you please rescore the pending ttf-indic-fonts build.  Until that gets published, people's upgrades are getting broken.
<cjwatson> doing
<ScottK> Thanks.
<cjwatson> yay for ridiculous build queue lengths
<cjwatson> done, 5 minutes
<fader_> apw: PCI ID on the ES1000 on the IBM system is 1002:515e
<fader_> Same as the Lenovos
<apw> fader_, i wonder what this 0x515f matches to
<fader_> apw: I don't have console access to that system but if it's useful I can ask Nafallo to plug up a KVM and watch the console for us
<fader_> apw: No idea, I haven't found any of our systems that have it :/
<apw> does that drm string show up?
<apw> in dmesg
<apw> 515e	ES1000	
<apw> 515f	ES1000
<apw> according to 'pci-ids'
<fader_> apw: not with the default kernel -- the relevant lines seem to be:
<fader_> [    4.631987] [drm] radeon defaulting to kernel modesetting.
<apw> ok so we are happy it does the right thing on an ES1000 at least
<fader_> [    4.631991] [drm] radeon kernel modesetting enabled.
<fader_> [    4.632075] radeon 0000:01:01.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
<fader_> [    4.634692] [drm] radeon: Initializing kernel modesetting.
<fader_> apw: Want me to try it with your new kernel?
<apw> yeah
<fader_> Roger wilco
<apw> i expect it to day disabled
<fader_> apw: [    3.646621] [drm] radeon disabling kernel modesetting for known bad device.
<ttx> slangasek: if you're still on mountall/lvm strange issues, you might want to include bug 563902 and bug 563916 to the mix
<ubottu> Launchpad bug 563902 in mountall "When snapshots exists, mountall will not mount the parent partition" [Undecided,New] https://launchpad.net/bugs/563902
<ubottu> Launchpad bug 563916 in mountall "[lucid] No prompt for [S]kip or [M]anual recovery on server boot" [Undecided,New] https://launchpad.net/bugs/563916
<ttx> slangasek: I'll prioritize/target for lucid, feel free to switch to a better package
<apw> fader_, most excellent
<fader_> apw: I'm at your beck and call if there's more I can do on this :)
 * ttx highfives apw and fader_ 
<bdrung> what do you think about this FFe request: 563940
<bdrung> bug #563940
<ubottu> Launchpad bug 563940 in ubuntu "ubuntu-wallpapers-extra freeze exception" [Undecided,New] https://launchpad.net/bugs/563940
<seb128> could somebody approve the light-themes update? it fixes buttons order which got screwed in yesterday's update
<ogra> pitti, you dont happen to be bored and in MIR approval mood ?
<pitti> ogra: no, but if it's urgent, I can do it :)
 * ogra has a tiny little package that looks for some MIR team member to care for it
<ogra> well, as urgent as the freeze approaching is ... not more than that though
<ogra> bug 563394
<ubottu> Launchpad bug 563394 in uboot-envtools "MIR uboot-envtools is needed for flash-kernel installer in omap" [Undecided,New] https://launchpad.net/bugs/563394
<pitti> ogra: ok, looking
<apw> slangasek, about ?
<apw> pitti, did steve tell you about the drm blacklists issues ?
<pitti> apw: I don't think so
<apw> pitti, ok, then it makes sense to talk to him about things
<apw> pitti, i assume he has gone to get some zz'
<seb128> pitti, did you see my ping about themes?
<pitti> seb128: erm, no?
<seb128> pitti, can you accept light-themes, the update from yesterday screwed the button orders
<pitti> sure, I'll review it
<seb128> pitti, before kwwii get killed because he screwed that
<seb128> pitti, danke
 * pitti also accepts all the kde-l10n stuff
<pitti> ogra: is that package actually useful on !arm?
<pitti> -ECHANNEL, -> #u-devel
<cjwatson> it would be good if somebody could review dpkg at some point
<cjwatson> ah, language packs incoming
 * cjwatson accepts a batch of them
 * apw wonders what time slangasek will be back with us
<cjwatson> somebody else should take over accepting language packs, to stop queuebot blowing up
<pitti> re
<pitti> (sorry, was @phone)
<pitti> cjwatson: yep, can do (dpkg/langpacks)
<pitti> cjwatson: I take it the fsync patch was tested already?
<cjwatson> so, bit of a saga there
<cjwatson> it's been upstream for a little while
<cjwatson> but it was busted, as I found when I merged and tested it
<cjwatson> so Guillem and I fixed it up between us, and Guillem hit it with some new tests
<cjwatson> I've done test dist-upgrades using it that exercised quite a bit
<elmo> is it a reasonable speed now? :-p
<cjwatson> and apw confirmed that its perf on ext4 is reasonable - slightly slower than before, but not the hour to unpack l-h
<elmo> and the fsync is to fix all the zero length bugs people were seeing previously?
<cjwatson> I've tested on ext3 and before/after speeds there were within noise, but that was expected
<cjwatson> right, the last vestiges of those
<apw> yep at worse 50% slower on a very slow machine otherwise avbout the
<apw> about the speed of a cache cold
<cjwatson> apw was testing a slightly older version, but the changes since then were bug fixes
<pitti> cjwatson: thanks (sorry, a bit slow to respond here now due to tbird)
<pitti> cjwatson: we obviously want to test it rather earlier than later
 * pitti bumps its build score
<pitti> with > 1600 i386 jobs we need some manual love here
<apw> i've uploaded a kernel package to cover the issues we are seeing with the KMS on a number of platforms.  slangasek is aware of the situation and i presume will handle it
<cjwatson> pitti: slow> shrug, I'm in the pub having dinner ;-)
<pitti> cjwatson: hm, laptop and beer don't mix well
<pitti> cjwatson: enjoy :)
<cjwatson> phone :)
<stgraber> slangasek: yep, it fixed edubuntu. Thanks !
<highvoltage> jdstrand: sorry, I made a mistake with the qimo upload of yesterday, could you perhaps let my new upload through? it's just an important type (s/DGM/GDM) that it fixes in a configuration file
<ScottK> highvoltage: Done
<mhall119> thanks ScottK
<highvoltage> ScottK: thanks!!!
<ScottK> pitti: I'd appreciate it if you could look at the apport hook in eclipse in queue (no rush).   I just fixed queuediff so that you can use it to look.
<highvoltage> slangasek: I'd appreciate it if you could approve the edubuntu-artwork package I uploaded so that it can get into tomorrow's daily build, functionality wise all our known bugs is fixed now so there shouldn't be any more until we get the final artwork from canonical's design team
<ScottK> highvoltage: I can take care of it.
<ScottK> highvoltage: Is it gray matter or grey matter?
<ScottK> It's one way in debian/changelog and the other in the package content.
<ScottK> highvoltage: OK, me research reveals the package content is in en_US, so I guess that's correct.
<ScottK> highvoltage: Accepted.
<highvoltage> ScottK: thanks!
<highvoltage> ScottK: ok we'll take it as a typo in the changelog then :)
<ScottK> Having lived in place where both US and UK English were spoken, I can never remember.
<highvoltage> 'gray' is real English right?
<highvoltage> and 'grey' is American?
<ScottK> No.  Other way around.  Apparently.
<highvoltage> heh, ok
<ScottK> http://www.greyorgray.com/
<ScottK> There's a web site for everything.
 * ScottK is out for several hours.  Have fun.
<ScottK> /away
<jdstrand> highvoltage: this should only be a bugfix upload, no? as such, just file a bug, rev the version, upload referencing the bug and someone from ubuntu-release will review
<jdstrand> highvoltage: or am I missing something?
<ScottK> jdstrand: I got it already
<highvoltage> jdstrand: ScottK sorted it out, thanks!
<jdstrand> ScottK: ok cool
 * jdstrand didn't read backscroll
<highvoltage> it's amazing how reactive and quick the release team is
<jdstrand> certainly better than I am ;)
<ScottK> Usually when I have the term reactive associated with me, it's not a good thing ....
<ScottK> See you later.
<highvoltage> I'm not sure if it's always this good but of all the teams I interacted with in the Lucid cycle the release team seems to work the most effeciently
<highvoltage> ciao ScottK
<slangasek> ttx: 563902> is the user trying to mount by UUID, which won't be unique, instead of by LV name, which will be unique?
<slangasek> ttx: bug #563916> well, that's a plymouth bug in the ubuntu-text theme; side effect of not using the ubuntu-logo splash theme, I doubt there's time to implement that for final
<ubottu> Launchpad bug 563916 in mountall "[lucid] No prompt for [S]kip or [M]anual recovery on server boot" [High,Confirmed] https://launchpad.net/bugs/563916
<slangasek> er - not ubuntu-text; rather, the 'details' (no 'splash')
<slangasek> apw: so, we didn't get the dell overheat fix?
<slangasek> apw: from scrollback, I didn't see anything regarding a positive test for 1002 515f, only for 515e - do you still think disabling KMS on this chip is the right thing to do?
#ubuntu-release 2010-04-16
<lamont> so then.  y'all now have 8^W7 buildds for armel.
<bdrung> am i allowed to upload a package with this fix: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578002 ?
<ubottu> Debian bug 578002 in dpkg-dev "dpkg-dev: Please add Bug-Ubuntu entry to DEP-3 template" [Wishlist,Open]
<bdrung> it's not RC critical, but the change is very small
<slangasek> bdrung: upload dpkg, or upload a package that sets Bug-Ubuntu?
<bdrung> slangasek: upload dpkg
<slangasek> bdrung: I'm disinclined to accept that, the buildds have quite a bit to keep them busy already and it's not RC critical
<bdrung> k
<bdrung> slangasek: then i ask again once the buildds idle ;)
<slangasek> bdrung: well, I don't think my answer will change closer to the release date
<bdrung> slangasek: then i have to find a severe dpkg bug ;)
 * slangasek hehs
<slangasek> ubuntuone-client in the queue has string changes - bug #539676, which I don't think was ever actually given an exception; so please don't accept it without a resolution there
<ubottu> Launchpad bug 539676 in ubuntuone-client "[Freeze Exception] Add instructional text to Ubuntu One Preferences application" [Medium,In progress] https://launchpad.net/bugs/539676
<pitti> slangasek: please let me know if you have further questions about the udev upload, as the diff is a bit scary (there was some code moved around, etc.)
<slangasek> pitti: ack - I've put off that review so far because it needs a bit of concentration to review properly, but I'll get to it "today"
<pitti> slangasek: I realize that it's quite a major change, but it's the first version where everyone said "it works"
<pitti> this thing has been driving me mad
<pitti> until about a week ago nobody complained
<pitti> and then we did a harmless upload, and things broke all over the place
<slangasek> until a week ago, nobody was testing CDs? :)
<pitti> turned out that there were two bugs leading to detecting too much due to uninit'ed memory and detecting too little due to ignored errors which just magically cancelled each other out most of the time
<slangasek> heh
<pitti> we did get some reports, but they were spurious and not really reproducible
<pitti> slangasek: the other day, Marjo mentioned broken audio CDs
<pitti> but yeah, CDs aren't that popular any more these days :)
<apw> slangasek, hi
<slangasek> apw: hiya
<slangasek> apw: so AIUI we have no test information for the 515f PCI ID, right?  Wouldn't the conservative move be to only change behavior for the PCI ID we've tested?
<apw> slangasek, on the second id, i had been given both as relevant by jjohansen so i included them, and my own lookup showed both applied to the same family of cards.  the ids are in a table so the risk of including both once one was tested code wise
<apw> as the failure was deemed so awful it seemed 'better' to inclue both, but i do concur your position is the more safe
<apw> i can make it so if you prefer the more minimal change
<slangasek> do you give it better than 50% odds that the other PCI ID with the same name is also broken without this change?
<apw> slangasek, actually i suspect its a coin toss, at 50%  i cannot tell from the original bug which id they have as it is not included, we know the one fixes all the ones we have ... so perhaps prudence says not
<slangasek> well, a coin toss is 50% - so if those are the odds that this will /help/ them, the odds that it will significantly regress instead are much lower; in which case, since we're guessing either way, I think the conservative assumption is to treat the two PCI IDs the same
<apw> that is essentially the position i was taking, if they don't need it they probabally won't notice
<apw> if they do need it, they will notice a lot
<apw> (won't notice that they got UMS instead)
<slangasek> right; the risk of regression is that this other chip actually works fine with KMS, but turning off KMS breaks X
<slangasek> accepted
<apw> sorry for the confusion
<slangasek> no confusion, just wanted to make sure we all know what we're in for with this chnage
<ttx> slangasek: fwiw the ES1000 is a server-oriented chipset, which kinda mitigates the risk.
<ttx> http://www.dvhardware.net/article4312.html
<slangasek> ah, alright
<ttx> though I suppose "thin clients" could be affected
<apw> slangasek, i see that ia64 won't start till the 18th
 * ScottK thinks doko__'s toolchain build perhaps ought to die an untimely death.
<doko__> ScottK: already asked yesterday to kill the hooker build
<ScottK> lamont: ^^^
<slangasek> ah, ia64 is tied up with a PPA build?
<seb128> somebody might want to do the sync on bug #563113
<ubottu> Launchpad bug 563113 in epiphany-extensions-more "epiphany-extensions uninstallable in lucid (epiphany 2.30 conflicts with epiphany-extensions 2.29)" [Undecided,Invalid] https://launchpad.net/bugs/563113
<pitti> ah yeah, it can hardly get any worse, syncing
<seb128> danke
<pitti> seb128: hm, the dependencies of e-extensions seem open enough to be installable
<seb128> epiphany-browser breaks << 2.30
<seb128> pitti, not sure what you mean there
<pitti> Depends: epiphany-browser (>= 2.29.5), epiphany-browser (<< 2.31)
<seb128> pitti, the abi version needs to match and it doesn't now, and the breaks used in epiphany doesn't allow to install e-e
<pitti> ah, I see
<seb128> pitti, well apt-cache show epiphany-browser | grep Breaks
<pitti> (done)
<seb128> pitti, danke
<directhex> src:indicator-application is bugged, which breaks banshee-community-extensions compilation (and generally has bad dependency information going on). I've attached a bunch of fixes to a debdiff on bug #564506 - it looks like tedg isn't online right now, so i can't go through him... and it's in main.
<ubottu> Launchpad bug 564506 in indicator-application "libappindicator-cil-dev's .pc file points to the wrong place" [Critical,In progress] https://launchpad.net/bugs/564506
<directhex> which steps should i take next to ensure the package is all shiny and happy in time for lucid?
<directhex> (i.e. should i be uploading random packages to main a fortnight before release?)
<ScottK> slangasek: I'd appreciate it if you'd review rootstock and sssd (absolutely no rush).
<lamont> doko__: asked where? (hooker build)
<doko__> lamont: #soyuz
<lamont> didn't see the request. :-(
<mvo> slangasek: hi, so â¦ here is a possilbe workaround for the mountall bug, details in #559582 on why it is needed, http://people.canonical.com/~mvo/tmp/initramfs-tools_0.92bubuntu74.debdiff what do you think
<slangasek> mvo: if that works reliably, yeah, go for it
<slangasek> (wow, libpng - of all things)
<cjwatson> that dependency needs to be architecture-specific, or it'll break ia64
<cjwatson> mvo: ^-
<cjwatson>    libc0.1 |   2.10.2-6 |      unstable | kfreebsd-amd64, kfreebsd-i386
<cjwatson>    libc0.3 |   2.10.2-5 |      unstable | hurd-i386
<cjwatson>      libc6 |   2.10.2-6 |      unstable | amd64, armel, hppa, i386, mips, mipsel, powerpc, s390, sparc
<cjwatson>    libc6.1 |   2.10.2-6 |      unstable | alpha, ia64
<ogra> wow, what a naming mess
<mvo> cjwatson: woah, thanks
<mvo> I wonder if I can abuse shlibs.local for this somehow
<slangasek> you could
<slangasek> but I think the hard-coded dep is better
<slangasek> because it avoids initramfs-tools-bin ending up later with a *too weak* dep
 * mvo nods
<lamont> on those occasions where it's been done, I've always seen the whole pile of the above, or been the one filing the bug telling them to fix it
<mvo> slangasek, cjwatson: could you please review http://people.canonical.com/~mvo/tmp/initramfs-tools_0.92bubuntu7.debdiff2 ?
<cjwatson> these days I think you can actually get away with using [arch] syntax in Depends fields, provided the package is architecture: any - dpkg-gencontrol expands it
<mvo> oh, cool
<cjwatson> also I don't think DEB_ARCH is defined
<mvo> let me try that
<cjwatson> oh, maybe cdbs defines it
<mvo> cjwatson: cdbs should do that, no?
<cjwatson> yeah, apparently so
<mvo> but let me try the [arch] in deiban/control, that is certainly more elegant
<cjwatson> as long as you don't accidentally use it in an architecture: all package; but then substvars wouldn't work in that context either
<mvo> cjwatson: ok, final one (I hope): http://people.canonical.com/~mvo/tmp/initramfs-tools_0.92bubuntu74.debdiff3
<james_w> oops, could someone reject upse please?
<james_w> oh, I can do it can't I
<james_w> was supposed to be ubuntu1
<cjwatson> mvo: LGTM
<cjwatson> oh, why the lower version on ia64?
<mvo> cjwatson: thanks, hrm, i looked at the wrong rmadison output
<mvo> cjwatson, slangasek: uploaded the workaround for the server upgrade issue, I tested it in kvm and before FAIL, after WORKS
<mvo> so should be good
<slangasek> ogra: KERNEL_IMG_REL=${KERNEL_IMG_REL/_*_armel.deb} - buggy; this is a /bin/sh script, not a bash script
<slangasek> ogra: rejecting rootstock as a result - please fix this to work under dash, and test before reuploading
<slangasek> (or drop that feature, if you prefer; I saw you discussed it with ScottK earlier)
<slangasek> erm
<slangasek> well, I was going to reject rootstock, but it looks like someone's accepted it then
<slangasek> ogra: ^^ but please fix and reupload anyway :)
<ogra> slangasek, hrm
<ogra> slangasek, are you ok with the rest ? i can fix that bit
<ogra> slangasek, oh, you let it through
<slangasek> no, someone else let it through, but it still has a bug
 * ogra was expecting a reject
<lamont> slangasek: care to help me understand how the glib2.0 upload of 4 hours ago got a sparc build record?
<pitti> ah, sweet; a lot of the old tetex-* dependencies are actually alternate ones
 * pitti verifies tetex-base and removes it as NBS
<james_w> pitti: yeah
<james_w> I think I squished all the troublesome ones
 * pitti checks the others
<james_w> checkrdepends could really do with telling you this
<cjwatson> I tried to fix it once but I got lost down the rabbit hole
<james_w> the only troublesome NBS are audacious and sugar from what I can see
<james_w> audacious has two packages that FTBFS against the new version
<james_w> and sugar is half-way upgraded to the new upstream
<doko__> slangasek, ubuntu-release: please reject the eglibc upload; one more patch coming
<pitti> doko__, slangasek: ^ done
<pitti> slangasek, ScottK: ok, confirmed that tetex-{bin,base,extra} NBS are all okay to remove, and removed \o/
<james_w> thanks pitti
<kirkland> slangasek: ping, re: https://bugs.edge.launchpad.net/ubuntu/+source/qemu-kvm/+bug/513273
<ubottu> Launchpad bug 513273 in vgabios "kvm with -vga std is broken since karmic" [High,In progress]
<kirkland> slangasek: we have a user who as regression tested vgabios against bochs
<kirkland> slangasek: which is the remaining thing you asked for
<kirkland> slangasek: i'm going to go ahead and upload vgabios again, and it can await your approval (again)
<kirkland> slangasek: feel free to reject it, if there's more you want tested
<cjwatson> ubiquity and hdparm both fix RC bugs
 * pitti looks at hdparm
<pitti> cjwatson: oh, thanks for fixing that
<cjwatson> there's a little bit of controversy in the second bug; I confess I don't entirely understand Jerone's objection
<cjwatson> so you might like to assess it somewhat independently
<cjwatson> I mean obviously I think I'm right O:-)
<pitti> ah, I only followed the first bug so far
<pitti> cjwatson: with the workaround/fix in hdparm, the linux task certainly should't be lucid/critical any more, right?
<cjwatson> I guess not
<cjwatson> you'd still be able to break it by running hdparm by hand
<pitti> right, that's why it looks more like a workaround
<pitti> but it should stop the linux task from stopping the release
<pitti> (especially since it's probably nontrivial to fix, and it might even be a problem in the firmware of those particular devices..)
<lamont> ogra: still around?
<ogra> lamont, yup
<lamont> ogra: I'm figuring I'll kill off huito and jambul (the last of the pegatrons) - did you want a mass giveback after that to catch the rest of haskell pain?  or?
<lamont> ogra: also, libgphoto2 is dying in doxygen on armel - infinite loop inside the app
<ogra> might make sense
 * ogra blames pitti ... he uploaded :P
<pitti> hm?
<pitti> oh, libgphoto2?
<ogra> yeah
<ogra> massive pain in aour rams butts
<ogra> *arms
<lamont> pitti: if you fixed it to not build all the arch-indep stuff on an arm...
<pitti> sounds possible
<cjwatson> pitti: oh, it's certainly an unashamed workaround
<pitti> cjwatson: it looks like you just remove the -B option, while Jeroen's change disables hdparm altogether (hdparm-functions has other bits); but I believe -B is the only thing we actually ship by default
<cjwatson> that was my assessment from reading the code
<cjwatson> double-checking wouldn't hurt
<pitti> cjwatson: it seems to be that the bug doesn't happen on that particular operation, but on the initial IDENTIFY DEVICE
<pitti> (incidentally that's very similar to the recent udisks-probe-ata-smart bug)
<pitti> cjwatson: so from what I can see, if an user would customize /etc/hdparm.conf to set other options than -B, they would again be done for firefire drives, too, and again break them?
<cjwatson> I think so
<pitti> (conversely, with Jeroen's variant you couldn't ever run custom hdparm commands on any firewire drive)
<cjwatson> though hdparm.conf can be disk-specific
<pitti> sounds like being between a rock and a hard place :(
<pitti> ah, it can?
<pitti> ok, then I prefer your fix indeed :)
<pitti> ah, right, these come in /dev/foo { } blocks
<cjwatson> such is my understanding
<cjwatson> a release note mightn't hurt
<lamont> ogra/pitti: if you wanna convince jocote's dchroot to not scream about mutex assertions, the chroot is current and has libgphoto build-deps.  Likewise, it's just a lucid chroot on a lucid system, to make things easier if you have either bbg3 or pegatron you control
 * lamont afk for a bit
<doko__> slangasek, ScottK: http://people.canonical.com/~doko/tmp/codecs.open.log
<ScottK> doko__: That's a longer list than I'd hoped.
<slangasek> lamont: glib2.0 build record> well, I have yet to figure out why we *don't* get build records for valgrind/armel and ltsp/armel, so I don't think I have much insight here
<slangasek> kirkland: vgabios> if it's regression-tested with all the revdeps, that's all I asked for; will gladly accept it this time around
<slangasek> doko__: codecs.open - thanks for gathering that data
<kirkland> slangasek: i'm happy with it
<doko__> slangasek: eglibc uploaded, will be away for the evening, reading backlog later
<lamont> slangasek: really...  interesting (glib2.0)
<lamont> https://bugs.edge.launchpad.net/soyuz/+bug/564759 <-- slangasek
<ubottu> Launchpad bug 564759 in soyuz "PaS says not to build glib2.0 on sparc, but it's built anyway" [Low,Triaged]
#ubuntu-release 2010-04-17
<slangasek> doko__: hrm, why does this eglibc diff appear to include a patch to *add* memcmp sse4 (a7f4cf5f1a6c0c9011c8dc0339cbe860fd272b6c)?
<slangasek> doko__: that doesn't look like a bugfix to me
<slangasek> hum, why has OOo/armel only been building for 10h?  I thought it had already started building before today, and gotten farther than that
<ScottK> slangasek: It did and then today got restarted on a different buildd.  I don't know why.
<slangasek> hmm
<slangasek> if someone could bump the build prio on libmsn/ia64, that would help with getting NBS fully cleaned out (lets us avoid kopete being rebuilt against the old lib)
<slangasek> actually
<slangasek> processing the NBS and leaving libmsn-dev uninstallable on ia64 also does that
<ScottK> slangasek: Should I be worrying about pinging about things like libperl-critic-perl MIR not done so other stuff won't build in Main?
<ScottK> BTW, I'm looking at lucas rebuild results so the stuff you're seeing in the queue or in sync requests from me is for that
<slangasek> ScottK: if you have the spare cycles to ping about those missing MIRs, yes please
<slangasek> so
<ScottK> OK.
<slangasek> if you use irssi with a properly-configured, SSL-secured proxy
<slangasek> don't upgrade to the security update
 * slangasek files bug #565182
<ubottu> Launchpad bug 565182 in irssi "security regression: SSL CN check breaks IRC proxy" [Undecided,New] https://launchpad.net/bugs/565182
<slangasek> jdstrand, kees, mdeslaur: I've subscribed ubuntu-security to the above; anything else I should do with it?  assign it to anyone in particular?
<slangasek> (patch will be sent shortly)
<slangasek> ScottK: portmap and irssi in the queue are both mine; care to review those?
<ScottK> No guarantees I'll feel qualified to decide, but I'll look.
<mdeslaur> slangasek: thanks, I'll assign it to jdstrand since he published the update, he can reassign it as necessary
<slangasek> mdeslaur: ok - fwiw, you can read what I'm typing, so I can vouch for the correctness of the fix ;)
<mdeslaur> slangasek: hehe :)
<ScottK> portmap OK.  Looking at irssi.
<ScottK> slangasek: You may wonder why we marked Bug #565180 as RC (high and milestoned) - Kubuntu has had a very poor reputation for translations in the last few years due to this kind of thing.  The distro can't afford to leave it unaddressed.
<ubottu> Launchpad bug 565180 in language-pack-kde-de "Translation error in Launchpad changes (KMail/kdepim)" [High,Triaged] https://launchpad.net/bugs/565180
<ScottK> slangasek: Why does define IRSSI_VERSION_TIME 1938 change in your irssi upload?
<slangasek> ScottK: it changed as a side-effect of doing a package build in the working tree
<ScottK> slangasek: RC bug cound it up by four for missing MIRs.
<ScottK> slangasek: OK.  Do we care?
<slangasek> about that change as a side effect?  I don't
<slangasek> if that's what you get as output of ./debian/rules build && ./debian/rules clean, IMHO that's what should get uploaded
<slangasek> missing MIRs> good, now they're documented
<slangasek> 565180> we should have time to fix that before the final langpack export
<ScottK> OK.  Fair enough.
<ScottK> Done
<slangasek> thanks!
<slangasek> 565180 is a little light on detail, why is the new string considered an error?  (And where does the upstream translation live?)
<ScottK> slangasek: Upstream translation lives in kdesvn.
<ScottK> slangasek: The agreement we had with dpm was that upstream strings wouldn't get changed.
<ScottK> (the alternative was we would forgo Ubuntu translations entirely and just use upstream's)
<ScottK> BTW, I just did my first "those are all cosmetic changes to the package, too late" rejection.
<slangasek> in kdesvn?
<slangasek> not in kdepim?
<ScottK> Sorry, KDE svn
<slangasek> didn't realize there was special handling for KDE upstream strings, ok
<slangasek> hum - in that case, how is it supposed to get into the distro?
<slangasek> does rosetta do a direct import from KDE svn?
<ScottK> We upload the KDE language packs and they get stripped
<slangasek> aha
<ScottK> We know from providing PPA uploads of new versions to users with translations that providing the KDE languauge packs directly works just fine.
<ScottK> We'd just lose the 'benifits' of Rosetta.
<slangasek> ScottK: the translation in the kde-l10n-de source package matches the one shown at https://translations.edge.launchpad.net/ubuntu/lucid/+source/kdepim/+pots/kmail/de/991/+translate
<ScottK> Hmmm.
<ScottK> Maybe it got changed upstream after our last update from there.
<ScottK> I'll see if I can get someone to look into it.
<ScottK> For the last two cycles we've had "stop using Rosetta so our translations get better" specs.
<slangasek> the string in language-pack-kde-de-base also matches
<ScottK> OK.
<ScottK> Let me put that in the bug and see what we can find out.
<slangasek> oh - echidnaman linked to the wrong string
 * slangasek just looked at the upstream bug
<ScottK> Ah
<ScottK> https://translations.edge.launchpad.net/ubuntu/lucid/+source/kdepim/+pots/kmail/de/1448/+translate
<slangasek> yep
<ScottK> This will be sufficient to cause the abandon Rosetta spec to get resurrected for the next UDS.
<ScottK> It's really all pain and no visible gain.
<ScottK> KDE already strips translations out by language so upstream has already done the most important part for us.
<slangasek> well, if the Kubuntu community's position is to not use rosetta for KDE translations in favor of using the upstream infrastructure/community, and upstream translations are already split into packages by language, it doesn't really seem to make sense to have KDE language packs
<ScottK> slangasek: I agree.
<ScottK> We got a lot of pushback.
<ScottK> I guess we'll decide again at UDS.
 * wgrant sighs.
<slangasek> perhaps the right compromise here is to continue importing strings and translations into rosetta, but to not strip them from kde-l10n-* at build-time, and not push them into langpacks?
<ScottK> Perhaps.
<slangasek> translation teams could still use rosetta for collaboration, but committing translations would have to be funneled via upstream
<ScottK> Part of the problem, as I understand it, is that KDE has some very specific standards for translations to get continuity across the workspace and Gnome doesn't follow them.
<ScottK> Since most Ubuntu translators have a Gnome background, they often do things that are wrong from a KDE perspective.
<ScottK> The times exporting stuff from Rosetta has been tried with KDE, the translations have been rejected due to low quality
<slangasek> ah.
<ScottK> Doesn't mean it can't work, but the history isn't good.
<ScottK> Given some of the historical sensitivities in this area the tolerance for error from Rosetta/Ubuntu translators is nil both in Kubuntu and KDE.
<ScottK> slangasek: Time for me to crash.  Good night and good luck.
<slangasek> ScottK: ok, 'night!
<hyperair> Are bugfix-only uploads allowed or do I need to file an FFe?
<Laney> allowed
 * ScottK is done clearing the queue.
<ScottK> The rest I'll leave for someone else.
<jdstrand> slangasek: re irssi> thanks, I'll take care of security releases. it seems you wrote this patch yourself-- did you send it upstream? (I don't see it in the upstream svn)
<jdstrand> slangasek: if not, I can get the patch to the right people
<ScottK> slangasek: Did you get a chance to get some traction on the Python open.codecs question?  If we can get some guidance on evaluating/fixing, I can try to mobilize some people.
<slangasek> jdstrand: nope, hadn't upstreamed it yet, appreciated if you would
<slangasek> ScottK: not yet, apparently my calendar was off and yesterday wasn't actually a 36-hour day like I had planned
<ScottK> Ah, no problem.
<slangasek> I'll hopefully get to it today, but have to tend the yard a bit first before I leave it to its own devices for 4 weeks
<slangasek> pitti: I'm not counting -en either! :)
<slangasek> pitti: es xh pt de bn fr hi
<ScottK> slangasek: Are you updating all the *-meta packages or was Xubuntu special?
<slangasek> ScottK: all of them; netbook, kubuntu already uploaded
<ScottK> OK.  I just accepted xubuntu
<slangasek> ta
<ScottK> Don't see the others yet.
<slangasek> unfortunately we still have one more font seed change pending, so there'll be another round of uploads yet; but these uploads seem to be required in order to let livecds build, so
<ScottK> OK.  I'll push them through as I see them....
<ScottK> There they are
<ScottK> Done.
<slangasek> ScottK: I think mythbuntu / ubuntustudio will also still need uploads; still running the ./update
<ScottK> OK.
<ScottK> I guess it's a good thing I went ahead and New'ed the split Khmer font pacakge.
<slangasek> the final upload is still waiting for ttf-takao-gothic, I think (or at least, a decision on same)
 * ScottK nods
<nhandler> Do you think we could squeeze in a ftbfs-fix for libgtk2-perl ?
<slangasek> there is generally room for ftbfs fixes, yes
<nhandler> slangasek: Will a sync request get processed? Or should we get the minimal patch applied in Ubuntu and uploaded, and then sync with Debian for 10.10 ?
<Laney> if it won't get processed by the AAs, you can upload it with the syncpackge script
<ScottK> nhandler: At this point a minimal fix for the FTBFS would be preferred.
<ScottK> nhandler: I did a number of these yesterday and uploaded with a build1 revision so the sync in Maverick is automatic.
<nhandler> ScottK: Have time to sponsor the patch? It is in main.
<ScottK> nhandler: Yes.
<nhandler> ScottK: Check out Bug #564070
<ubottu> Launchpad bug 564070 in libgtk2-perl "Please sync libgtk2-perl from Debian (fixes FTBFS)" [Wishlist,In progress] https://launchpad.net/bugs/564070
<ScottK> nhandler: -->#ubuntu-devel
<nhandler> k
<jdstrand> slangasek: done
<slangasek> jdstrand: thanks!
<slangasek> ScottK: {mythbuntu,ubuntustudio}-meta don't need updated
<slangasek> (apparently these don't derive from platform/desktop-common ?)
<ScottK> OK, well that simplifies things.
<ScottK> Weird.
<ScottK> That may be a larger bug that needs investigation.
<doko> slangasek: re-uploaded eglibc, the strcmp/memcpy fixes now confirmed, disabling the x86_64 memcpy in the series file
<ScottK> doko: Want me to reject the old one?
<doko> don't mind
<slangasek> doko: great, thanks - will pick that up shortly
<ScottK> Done
<slangasek> and accepted
<slangasek> ScottK, pitti: prepromoted the MIRs needed for getting packages built and up-to-date
<ScottK> slangasek: Sounds good.  I'll give them a manual retry after the next publisher run finishes since AFAIK automatic is still broken.
<slangasek> right
#ubuntu-release 2010-04-18
<ScottK> slangasek: If I went through pending sync requests would you have time to feed it to mass-sync.py?
<slangasek> if not now, then later, yes
<ScottK> OK.
 * ScottK will do that in a bit then.
<james_w> ScottK: if you have ubuntu-archive-tools available then checkout sync-helper.py if you haven't seen it yet.
<ajmitch> ScottK: thanks for chasing them up :)
<slangasek> ScottK: hmm, http://people.canonical.com/~ubuntu-archive/component-mismatches.txt shows that libtest-classapi-perl will also need an MIR for libppi-perl
<ScottK> slangasek: Wouldn't stun me.  I just looked at theones that are currently depwait.
 * slangasek nods
<ScottK> Please don't accept audacious.
<slangasek> ok
<slangasek> please do accept libgd-barcode-perl :)
<wgrant> I thought automatic depwait retrying was meant to be working now.
<ScottK> wgrant: I'll wait and see then.
 * ScottK looks
<ScottK> Too soon, queuediff doesn't pick it up yet.
<ScottK> Drama resolved re audacious
<slangasek> ScottK: do you know if anyone is working on the kde-l10n-sv ftbfs?
<ScottK> slangasek: I think it needs to be removed because upstream isn't supporting the language, but I'm not sure.
<ScottK> I'll check
<slangasek> ok, thanks
<ScottK> Accepted
<ScottK> wgrant: Unless someone pushed retry I don't know about, your thesis about automatic retry working again is confirmed: https://launchpad.net/ubuntu/+source/eximdoc4/4.71-1/+build/1422567
<wgrant> ScottK: Great.
<slangasek> crashes in seahorse are the worst
<slangasek> no, I'm not sending my gpg passphrase to launchpad, kthx
<ScottK> You could make a test key with a different passphrase ...
<ScottK> Then throw it away
<slangasek> it's only reproducible after protracted use
<ScottK> Oh.
<ScottK> Nevermind
<ScottK> slangasek: The Perl MIR situation appears to have layers.  See Bug #565681
<ubottu> Launchpad bug 565681 in libtext-diff-perl "MIR needed for libtext-diff-perl to build libfile-findrule-perl" [High,New] https://launchpad.net/bugs/565681
<ScottK> Also Bug #522211
<ubottu> Launchpad bug 522211 in libtest-classapi-perl "[MIR] libtest-classapi-perl" [High,New] https://launchpad.net/bugs/522211
 * ScottK is lost in a doc-base wilderness.
<slangasek> ScottK: ok, also promoted
<slangasek> and it looks like germinate is failing on cocoplum for some reason (tasks not getting updated for the ttf-kacst -> ttf-kacst-one switch)
<slangasek> oh, there we are; ttf-kacst-one recommends the ttf-kacst package that was meant to be going away
 * ScottK looks
<slangasek> already self-accepted
<ScottK> OK.
<ScottK> No wonder I didn't see it.
<slangasek> you're welcome to review anyway, but it's a trivial recommends->suggests change that's blocking all CD builds, so
<ScottK> Rignt.  No need.
<ScottK> If the CD build works, you win.
<ScottK> BTW, the one pending Universe upload is mine, so if you'd accept it when you have a moment, I'd appreciate it.
 * ScottK was packaging a new upstream for Debian and had a series of "WTF was I thinking" moments as he updated.
<ScottK> Is sync-source default to testing for Lucid?
<ScottK> (wiki says it defaults to unstable, but I'm guessing that's old)
<ScottK> slangasek: Assuming the answer to the above question is yes, please run http://paste.debian.net/69517/ through mass-sync (which is actually what I guess I was asking about)
<slangasek> mass-sync> running
<slangasek> ScottK: ['[NOT Updating - Modified] jarjar_1.0+dfsg-1ubuntu1 (vs 1.0+dfsg-2)\r\n']
<slangasek> And libppi-perl fails with...  libtest-classapi-perl: Depends: libclass-inspector-perl but it is not installable
<slangasek> which is, at last, the bottom of the pile
<slangasek> cjwatson: does gfxboot-theme-ubuntu need another translation-updating upload?
<slangasek> ev: has wubi been updated to pull in current translations?
<slangasek> libclass-inspector-perl also promoted now
<ogra> hmm, i see some serious OOM issues on my x86 laptop, i know mdz saw that on thursday and thought it was evolution related, i also see chromium, rhythmbox and gnome-session hitting OOM ... this is with a 4G machine, no swap and pae kernel
<ogra> i wonder if we have a kernel bug here
<ogra> (it didnt do that until last update)
<ogra> funnily top/htop dont show any excessive ram usage
<ogra> but it just heppended again with a new tab in chromium
 * ogra confirms bug 563879
<ubottu> Launchpad bug 563879 in evolution-data-server "evolution-data-server consumes massive amounts of memory, invokes OOM killer" [Undecided,Confirmed] https://launchpad.net/bugs/563879
<ev> slangasek: on it now
<ev> slangasek: done
<ev> the next CD build will have updated Wubi translations
<slangasek> great, thanks!
<pitti> slangasek: ah, I ignored "xh", too, since nowadays it's coverage is almost negligible
<pitti> slangasek: accepting the two ttf-kacst{,-one} uploads, they look fine and were discussed in that FFE bug
<ScottK> slangasek: If you have a chance to run it again, the jarjar sync is good  (I forgot the -f), so "sync 565173 -f" if you (or another archive admin) would please.
<ScottK> pitti: ^^^
<ScottK> If you could throw that at mass-sync, I'd appreciate it.
 * ScottK runs off again....
<ScottK> Please don't accept xpad.  The current upload does an Ubuntu specific switch to v3 source format and I've written the uploader to ask if they just did that or they have some indication that Debian plans to switch too.
<ScottK> Question is resolved, so I accepted it.
<ScottK> pitti: Please see https://bugs.launchpad.net/ubuntu/+source/libperl-critic-perl/+bug/523242/comments/4 and promote libperl-critic-perl again.
<ubottu> Launchpad bug 523242 in libperl-critic-perl "[MIR] libperl-critic-perl" [High,New]
<slangasek> ScottK: jarjar sunc
<ScottK> slangasek: Thanks.
<slangasek> and libperl-critic-perl repromoted, heh
<ScottK> Thanks too.
<slangasek> oh good, I made OOo FTBFs everywhere. <grumble>
<slangasek> well, it's a one-liner fix
<slangasek> this debian/rules file needs to die a flaming, crunchy death
<slangasek> ironically, I think that build would have succeeded *only* on armel...
<ScottK> slangasek: FTBFS everywhere is a win for archive consistency.
<slangasek> ah; and now that libperl-critic-perl is actually built, it's uncovered 10 more deps in need of promotion \o/
<doko_> openoffice.org (universe)?
<slangasek> queuebot is just confused, I think
<doko_> slangasek: clang needs llvm ...
<doko_> slangasek: I'd like to rebuild packages in main, which are statically linked against libc6. not sure, which these are, I know of binutils(-static) and bash(-static) at least. ok to upload?
<slangasek> doko_: is this to have them in sync for release, to fix specific issues, or for some other reason?
<doko_> slangasek: 2.7 final was a FFe, but they won't release before our final release. the upload fixes two regressions compared to 2.6. both clang and llvm-gcc-4.2 require the new version as a b-d
<slangasek> sorry, I was referring to the -static rebuilds with that question
<doko_> there's no code landing in main, except llvm and llvm-dev, openjdk-6-jre-zero goes to universe
<doko_> ahh
<doko_> well, there are two wrong-code bugs fixed in memcpy/strcmp. they are found in the binaries, but no, I don't know if these trigger, and I don't have the Core iX hardware
<doko_> but if we don't find problems, we can do these as sru's as well
<slangasek> doko_: I think that's a good enough reason to upload, really, I just wanted to make sure I understood what the reason was - please go ahead
<doko_> slangasek: any idea which packages use static binaries as well?
<slangasek> no, sorry
<slangasek> I think you should upload the ones you've identified already, and we can do a more thorough search for SRU
<doko_> ok
#ubuntu-release 2011-04-11
<cjwatson> archive.ubuntu.com mirroring seems to be busted; I've notified #is on internal IRC, although I'm not expecting anyone to be around right now
<cjwatson> apparently pending onsite sysadmin in the UK, so mirrors are probably not going to update until the morning
<ogasawara> cjwatson: I just uploaded the kernel
<slangasek> doko: lucas has done an archive test rebuild for me to check out the impact of bug #750585 on the archive; it looks like this breaks biarch packages, which I should have thought of.  Do you think it's reasonable for the gcc-multilib metapackage to own a symlink of /usr/include/asm to /usr/include/x86_64-linux-gnu/asm?
<ubot4> Launchpad bug 750585 in linux (Ubuntu Oneiric) (and 2 other projects) "[FFe] support for making linux-libc-dev coinstallable under multiarch (affects: 1) (heat: 582)" [Undecided,Fix committed] https://launchpad.net/bugs/750585
<cjwatson> ogasawara: great, thanks
<pitti> cjwatson: good morning; recovered from the late-night shift?
<cjwatson> I think so
<cjwatson> coffee cures many things
<cjwatson> I need a holiday though
 * pitti looks at the clock, looks like freeze time?
<pitti> not that we could build CDs right now, due to the mirror breakage, but at least we can switch to controlled mode
 * pitti asks IS
<chrisccoulson> we're not unfreezing again before release are we? i'm slightly confused with the lack of RC ;)
<pitti> chrisccoulson: right
 * slangasek waves
<pitti> hey slangasek
<slangasek> hi there!
<slangasek> pitti, cjwatson: eglibc needs an upload at some point before release for bug #750585 to make it buildable again; should I upload this now?
<ubot4> Launchpad bug 750585 in newlib (Ubuntu Oneiric) (and 14 other projects) "[FFe] support for making linux-libc-dev coinstallable under multiarch (affects: 1) (heat: 14)" [Undecided,New] https://launchpad.net/bugs/750585
<cjwatson> slangasek: does this need to land after linux has finished building on all architectures?
<pitti> slangasek: will that even build in time for arm?
<slangasek> cjwatson: no, the eglibc patch is written to be safe before and after the multiarch dir switch
<slangasek> pitti: it's about a 6hour build for arm
<slangasek> and the next six hours are your guys' department not mine ;)
<slangasek> sorry, 7 h
<slangasek> newlib, klibc also need uploads but there's obviously much less of an impact on image building (klibc: 13min build on armel)
<pitti> seems ok to me, the buildds are still quite busy, though
<cjwatson> the armel buildds are thoroughly backed up, but I'm guessing that's a mass give-back of some kind?
<slangasek> hum, is there?
<pitti> cjwatson: it's still the archive rebuild test
<cjwatson> oh, it wasn't clear in the UI
<slangasek> ah; that shouldn't compete with main archive builds, should it?
<cjwatson> at any rate, some of the stuff they're building is in universe, so I think is OK to be preempted if we need it
<cjwatson> yeah, our main builds should win
<slangasek> so: yes to eglibc upload?
<cjwatson> in fact our builds should win in general
<cjwatson> yes
<slangasek> uploading
 * cjwatson wants a maximally-buildable beta-2
<pitti> cjwatson: FYI, I got the main NBS sorted out yesterday (just waiting on archive catch-up), working on universe now
<pitti> yay libpoppler porting
<slangasek> eglibc, newlib, klibc all uploaded
<slangasek> and gcc-defaults.  I'll give http://people.debian.org/~lucas/logs/2011/04/11/res.ubuntu.amd64.new-failures a thorough review in the morning, but these seem to be all either biarch packages (fixed already via gcc-multilib) or random noise
<slangasek> right, launchpad's not yelling at me, so time for me to grab some shut-eye
<slangasek> talk to you in a few hours :)
<ev> what group membership is required to target bugs to O?
<pitti> I had expected core-dev
<micahg_> should be the same as anything else
<pitti> at some point this should be fixed to "the same set of people who can upload the package"
<micahg_> core-dev or motu depends on main or universe
<micahg_> is bug 751038 worth trying to get in?
<ubot4> Launchpad bug 751038 in tex-common (Ubuntu) "/usr/sbin/update-language-def: line 779: printf: missing unicode digit for \u (affects: 3) (heat: 20)" [Low,Triaged] https://launchpad.net/bugs/751038
<ev> pitti: doesn't appear to be the case. I can only nominate ubiquity bugs for O.
<pitti> accepting pidgin, FTBFS fix
<pitti> rejecting life, FTBFSes still (sorry, dput'ed the wrong .changes)
<didrocks> bamf/nux/unity uploaded. Compiz still need some testing but will come shortly
<pitti> thanks didrocks, I'll handhold them
<didrocks> thanks pitti :)
<pitti> didrocks: do they have proper build-deps?
<didrocks> pitti: yeah, should be ok
<pitti> i. e. can we accept them in any order, or does it need waiting?
<didrocks> no no, I tend to be strict on that :)
 * pitti hugs didrocks
<didrocks> so unity should build-dep on new nux
 * didrocks hugs pitti back
<pitti> ^ rejected, packaging bug
<pitti> (see #u-devel)
<pitti> accepting nux/bamf/unity as discussed on last release meeting
<pitti> I'm off for lunch
<didrocks> pitti: compiz ready in 5 minutes, just doing some final tests
<didrocks> pitti: and compiz uploaded!
<pitti> didrocks: ^ :)
<didrocks> pitti: thanks :)
<pitti> ScottK, cjwatson: I'd like to sync flightgear 2.0.0 from Debian; seems in our autosync we caught simgear 2.0.0, but have flightgear 1.9.1 still (which is now depending on NBS simgear1.9.1)
<ScottK> pitti: Sounds reasonable.  I'd go for it.
<cjwatson> fine by me
<pitti> accepting ubuntu-mono; two beta-2 targetted bugs, and looks safe
<pitti> accepting gconf; no-op on i386/amd64, and unbreaks armel build
<pitti> s
<pitti> ogra_: I see the alsa-lib upload for bug 746023; does it also require a pulseaudio upload? do they depend on each other?
<ubot4> Launchpad bug 746023 in pulseaudio (Ubuntu Natty) (and 3 other projects) "No sound on omap4 (affects: 2) (heat: 14)" [High,Triaged] https://launchpad.net/bugs/746023
<ogra_> pulse depends on the config to be in place
<ogra_> we need the config in any way while the pulse patches are still eing tested
<ogra_> *being
<pitti> ok, thanks; looked like that, but want to make sure to not break anything at this point
<ogra_> you wont, luke is very careful :)
<ScottK> pitti: The python2.7 upload in queue fixes Bug #755616 (even though it's not mentioned in the changelog).  It's a 7+ hour build on armel, but it seems like something we want fixed.  I didn't do more than look at the diff, but it seems like a logical change.
<ubot4> Launchpad bug 755616 in python2.7 (Ubuntu) "Python curses is not linked to libncursesw (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/755616
<pitti> ScottK: I was trying to avoid it right now, until the buildds have caught up, as it doesn't seem critical for the beta-2 images? or is it?
<ScottK> I guess it's not critical for beta2.
<ScottK> I think we definitely want it before release.
<pitti> *nod*
<ScottK> Tactically I'm not sure if it's better to go ahead or not.
<ScottK> I'm OK with either way.
<pitti> I'd like to wait at least 2 hours for i386 to catch up
<pitti> otherwise we keep having uninstallability due to langpacks
<ScottK> OK.
 * ogra_ would like images too on armel ... 7200 packages in the queue, sniff
<pitti> ogra_: that's just the test rebuild (mostly)
<ogra_> yeah, i know
<pitti> they yield to any "real" upload
<ogra_> doesnt help much if only big packages are already building though
<ogra_> if the buildds are busy queue priority sadly doesnt help a lot
<ScottK> That's when you need lamont around to shoot the annoying build in the head.
<ScottK> chrisccoulson: The difference this time isn't that we are lacking an RC.  The difference is we aren't pretending to have one.
<ogra_> heh, yeah
<chrisccoulson> ScottK - thanks ;)
<chrisccoulson> i guess that RC should normally be what we intend to ship ;)
<ScottK> That's the usual definition.
<chrisccoulson> (like with firefox. in fact, i just uploaded a new tarball for that because people kept getting confused that the ~rc2 build we had was actually the final release)
<Riddell> kubuntu smoke testing all good with yesterdays images
<jibel> ubuntu desktop i386/amd64 smoketest passed
<jibel> wubi install and upgrade passed
<jibel> ubuntu desktop upgrade passed
<pitti> jibel: wubi> yippie
<cjwatson> excellent
<cjwatson> same partition as Windows, or different?
<cjwatson> (mind you I've already had confirmation of both cases)
<jibel> cjwatson, same partition, I'm trying different atm.
 * cjwatson nods
<jibel> on alternate I have a problem with partman. When a partition already exists and the user accepts the defaults, the installer refuses to continue with 'No root filesystem'. There's no 'guided partitioning'  option too.
<cjwatson> jibel: you need to explicitly select a partition to mount on /
<cjwatson> it is intentional that the defaults do not overwrite your disk
 * pitti really isn't happy about the linphone FTBFS fix he just uploaded, but it's the only approach that works and doesn't require major reengineering
<jibel> cjwatson, agree but wasn't there 'guided partitioning' and 'resize existing partition' options directly from the main menu, it's gone ?
<jibel> on a fresh driver, I have to create all the partitions manually.
<jibel> cjwatson, anyway, even with manual partitioning the installation fails with libnotify4 (>= 0.7.0) is not installable
<cjwatson> jibel: well, that last is not an installer bug, it's just inconsistent archive syndrome
<cjwatson> jibel: resizing is only offered sometimes and depends on the circumstances
<cjwatson> jibel: guided partitioning should usually be offered, but there are some constraints; for example, if the only disk also contains the installation medium, it won't be offered.  I'd need to see logs (preferably with DEBCONF_DEBUG=developer) to make sure.
<cjwatson> hmm, something does seem to be wrong though
<cjwatson> whoa!
<cjwatson> who ate partman-auto?
<pitti> "ate" == "lost upload"?
<cjwatson> I'm not sure, but it's missing from the CD
<cjwatson> that would be causing jibel's problem
<cjwatson> jibel: thanks for spotting that; I'll sort it out
<ScottK> pitti or cjwatson: I just marked Bug #757427 critical is it looks to me like the root of 4 armel FTBFS in Main this morning.
<ubot4> Launchpad bug 757427 in gconf (Ubuntu) (and 1 other project) "gconftool-2 segfaults on arm (affects: 1) (heat: 8)" [Critical,Confirmed] https://launchpad.net/bugs/757427
<pitti> ScottK: I thought the recent gconf upload was supposed to fix that
<ScottK> Maybe it's archive skew then.
<ScottK> They all failed today though.
<pitti> no, the changelog didn't mention the bug
<jibel> cjwatson, on wubi installed from a French Windows 7, I get this bug 742558
<pitti> I'll close it manually
<ubot4> Launchpad bug 742558 in ubiquity (Ubuntu Natty) (and 3 other projects) ""Keep default keyboard layout ..." dialog is confusing (affects: 2) (dups: 1) (heat: 229)" [High,Fix released] https://launchpad.net/bugs/742558
<cjwatson> jibel: in fact, it's just a rather unusual casualty of the mirror system falling over last night - I'll schedule a rebuild
<pitti> ScottK: thanks for pointing out
<cjwatson> jibel: separate bug, please
<ScottK> pitti: So I should retry those builds?
<jibel> k
<pitti> ScottK: hang on, checking publicatino
<ScottK> OK.
<ScottK> BTW, no point in retrying compiz on armel until kde4libs finishes and is published.
<pitti>     gconf2 | 2.32.2-0ubuntu1 |         natty | armel
<pitti>     gconf2 | 2.32.2-0ubuntu2 |         natty | amd64, i386, powerpc
<pitti> meh, not yet
<ScottK> OK.
<cjwatson> jibel: (with logs, so that I can get the same kernel args, since I don't have French Windows)
<pitti> ScottK: it's in accepted, so we can retry in one ohur
<pitti> hour, too
<ScottK> pitti: Great.  The only other new failures were due to slangasek's biarch problem.
<ScottK> (alsa-lib and klibc)
<ScottK> Unity was archive skew, I already retried it.
<pitti> CD cron jobs on manual; with the current churn there's not much point in auto builds
<ScottK> Getting close on draining the language packs out of i386.
<pitti> yes, and an hour for ppc to catch up
<pitti> hm, seems the libx264 transition failed on powerpc, looks we'll need another set of uploads there
<cjwatson> sorry for the short notice, but I'd appreciate a MIR team member having a look at bug 757600
<ubot4> Launchpad bug 757600 in grub-gfxpayload-lists (Ubuntu) "[MIR] grub-gfxpayload-lists (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/757600
<cjwatson> it's my oversight that that wasn't done earlier
<pitti> asked in #u-devel
<cjwatson> thanks
<cjwatson> should be really quick
<cjwatson> I think I'll make grub-pc recommend it
<cjwatson> or I suppose it could just be a dependency, why muck about
<pitti> oh, x264 FTBFSed on powerpc, which explains why it didn't catch the transitional uploads
<ScottK> pitti: Any objection to Bug 757540?  It seems to me very much the Ubuntu thing to do to provide the correct font for someone's language.
<ubot4> Launchpad bug 757540 in ttf-kacst-one (Ubuntu) "Missing many Glyphs to support Uyghur (Uighur) Language (affects: 1) (heat: 10)" [Undecided,In progress] https://launchpad.net/bugs/757540
<ScottK> AnAnt says he's tested it in Uyghur and it works correctly.
<pitti> ScottK: it's installed by default, so my biggest worry is the deb size delta; otherwise no objection
<ScottK> OK.  I'll check on that.
<ScottK> FYI, I checked Universe/Multiverse armel build failure 4/7 and later for the gconf problem and only found one (mutter) which I retried.
<ScottK> Not sure if that was far enough back or not.
<jibel> wubi fresh install and upgrade from Maverick on different partition than Windows passed \o/
<jdstrand> skaet: I didn't follow up with you, but understand the hardy desktop eol email is going out today
<skaet> jdstrand,  yes
<jdstrand> skaet: I may not understand all that is going on, but I don't see a reason to stagger eol announcements-- there is nothing to do aiui (IS will do some stuff a few months after the eol, but beyond that, nothing)
<jdstrand> skaet: am I missing something?
<jdstrand> (nothing to do beyond the email)
<skaet> jdstrand, there's some coordination with the OEM teams involved
<cjwatson> jibel: cool
<jdstrand> skaet: I see. I think this might be a good time to restate my opinion that LTS eol announcements should happen 2-3 months prior to eol, in addition to the 1 month
<skaet> jstrand,  yes, I think its a topic we need to talk through a bit at UDS.
<skaet> jdstrand, problem wasn't the email, but what had to happen a month from the email.
 * jdstrand nods
<skaet> jibel,  cjwatson,  re: WUBI again - \o/
<jdstrand> skaet: also, I have no idea what oem has to do, but there are not insignificant support costs for the security team with delaying EOL announcements (I think I said this on friday). I realize it is already done at this point, but going forward I think our team should be consulted if the eol will be delayed
<skaet> jdstrand, will do.   My assumption was since hardy server is still going to be supported, there was still hardy tracking that had to be done by the security team.
<jdstrand> skaet: that is true-- but we will issue security updates for desktop up to the day of eol. those may cause extra work
<jdstrand> they may not, it depends on what floats in
<skaet> jdstrand, understand.   Agree will consult with you next time if the date looks like its going to need to move.
<jdstrand> skaet: thanks
<ScottK> pitti: It just occured to me that you might want to use the new "Not Automatic" feature for -proposed too so people can enable proposed and just install the package they are after to test.
<pitti> ScottK: that's in natty?
<pitti> that's interesting for the "plz test me" emails indeed
<ScottK> pitti: Yes.  It's activated for natty-backports.
<pitti> for the record, syncing vdr; current version doesn't build and is v4l1 only (which linux 2.6.38 dropped); sid version got ported to v4l2, confirmed to build on natty
<ScottK> (not that I can do live fire testing yet)
<pitti> (ubuntu changes not required any more)
<ScottK> pitti: AFAIK, all you need to do is ask someone like wgrant to enable it for natty-proposed.
<pitti> interesting; I had expected this to be configured in apt (default pin priorities)
<ScottK> It's in the packages.gz.
<ScottK> Apt in Natty knows about this.
<pitti> ScottK: btw, gconf/armel is in , so you can give back the failed builds
<pitti> bbl, dinner
<ScottK> Did.  They seem to be doing well.
<ScottK> If I remember wrong about the not-automatic thing, I'm sure wgrant or mvo will correct me.
<pitti> cjwatson, ScottK: python2.7 doesn't build arch:all with versioned dependencies to arch: any packages, so I think accepting it now to make use of the (soon to be) idle buildds would work
<ScottK> Sounds good to me.
<pitti> cjwatson: for coordination,  I accepted the ones from the queue which looked safe and fixed beta-2 RC bugs; I'm planning to start the full set of image builds over night when I'm back from Taekwondo, around 2130 UTC; sounds ok to you?
<pitti> skaet ^
<cjwatson> um
<pitti> provided that the armel kernel has finished by then
<cjwatson> there are still a few translation uploads to go (in progress) and a lot of open bugs
<cjwatson> the armel kernel won't be close to finished by then, by my calculations
<cjwatson> I think I looked it up and it was going to be somewhere in the small hours UTC
<ScottK> gnome-games failed for non gconf reasons.  Someone who knows about GIR might want to look https://launchpadlibrarian.net/69045260/buildlog_ubuntu-natty-armel.gnome-games_1%3A2.32.1-0ubuntu5_FAILEDTOBUILD.txt.gz
<pitti> I'm not saying that these are necessarily the last ones
<skaet> pitti,  cjwatson,  can we get the non armel ones started, so i386/amd64 testing can start?   or are there some dependencies I'm not aware of?
<cjwatson> can we just let cron do it tomorrow?
<pitti> but I'd at least have desktops with all the updates from today
<cjwatson> skaet: certainly can't do it right now, there's grub2 being built, ubiquity on its way, debian-installer and gfxboot-theme-ubuntu to come, and that's just what I know about
<pitti> cjwatson: personally I'm not a huge fan of the cron'ed ones right now, as they won't check for the armel kernel, and are also spread out over the day
<skaet> cjwatson,  thanks.
<cjwatson> pitti: so I suppose overnight makes some sense, but I think it's going to need to be a couple of hours later than that
<pitti> I'd at least use the night hours to build the images which have stabilized by then, so that we can do testing tomorrow morning
<pitti> cjwatson: I'm planning to stay up late anyway, so that sounds fine
<pitti> perhaps best to just check again when I'm back; if you are already asleep, I'll just check the queues/archive, if not we'll sync up?
<cjwatson> I don't expect to be around much this evening
<slangasek> pitti: is this something you'd like me to track and kick off images when things are ready?
<pitti> slangasek: I'm still trying to find that out; I'm reviewing ubiquity, d-i, and gfxboot-theme-ubuntu right now, those are the three that Colin mentioned
<slangasek> ok
 * cjwatson -> gone
 * slangasek waves
<pitti> cjwatson: bye, have a nice evening!
<pitti> slangasek: so I think we should build desktops and alternates after these three are in, and u/kubuntu/kubuntu-mobile/headless preinstalled once the armel kernel has finished (https://launchpad.net/ubuntu/+source/linux/2.6.38-8.42/+buildjob/2440470)
<pitti> so that we have a reasonably current set of images for more detailled smoketesting
<pitti> need to go, back in some 3 hours
<stgraber> is bug 752393 something that we want fixed for beta2 ? (I don't think it's critical and would like to have someone review the fix as I'm not too familiar with lsb ;))
<ubot4> Launchpad bug 752393 in lsb (Ubuntu) "lsb init scripts show line buffering problems on bootup (affects: 1) (heat: 8)" [Medium,Confirmed] https://launchpad.net/bugs/752393
<ScottK> stgraber: I think we definitely want it for final and lsb is a quick build, so I'd be inclined to take it for beta2.
<stgraber> ScottK: do you feel like reviewing the patch or prefer someone else to look at it ?
<ScottK> I'd prefer if cjwatson or slangasek reviewed it.  Please go ahead and upload so that they can review it in the queue.
<stgraber> ok, thanks
<skaet> stgraber, have gone in and explicitly targetted it to Natty as well.   Will leave it to someone more knowledgable to review.
<skaet> ScottK,  cjwatson's off for the night,  so it will probably need to be slangasek if we want to get it into beta2 at this point.
<ScottK> OK.
<ScottK> pitt could review it too, I know he's coming back later.
<stgraber> skaet, ScottK: uploaded
<slangasek> stgraber, skaet, ScottK: reviewing
<slangasek> stgraber: why is the plymouth buffering code inside the check for log_use_fancy_output && $TPUT xenl?  doesn't the same issue apply when this is not set?
<stgraber> slangasek: the non-fancy output didn't seem to use "echo -n" or similar so it shouldn't be affected by the buffering issue
<stgraber> I'm not saying the output will be pretty but it's not going to have some upstart output mixed in at least
<slangasek> right, ok
<slangasek> stgraber: there's a small window between when log_end_msg calls log_daemon_msg again, and when it prints its own output, where other messages could be printed.  I guess we're ignoring this for now?
<slangasek> stgraber: the whole thing seems a workaround, vs. cjwatson's suggestion to use the plymouth protocol natively
<stgraber> slangasek: unless you have an easy way of avoiding it, I'd just go with the current workaround
<slangasek> not an easy one, no :)
<stgraber> ideally both lsb and upstart scripts should go through plymouth for that kind of logging, but that'd need a bit more changes to some core components to get done
<slangasek> and you've tested booting with this code before upload, right?
<stgraber> yep, I tried booting that code with and without the fancy output and SpamapS who reported the issue tested it too
<stgraber> for Oneiric we should really try to get some proper logging at boot time, which ideally would catch all lsb and upstart events (that's including the time where upstart doesn't talk over dbus) but it doesn't seem like a trivial thing to do
<slangasek> oh, another small buglet... if plymouth has gone away between log_daemon_msg and log_end_msg, you never print $LOG_DAEMON_MSG anywhere... but that's scarcely worse than printing it to a different place
<slangasek> so, accepted
<stgraber> currently I have a completely random boot.log on my machine, 9 out of 10 times, dbus starts so late that plymouth-upstart-bridge doesn't get any event to log so I end up with only the lsb output being logged :)
<stgraber> slangasek: thanks
<pitti> re
<skaet> slangasek, pitti, - why is evolution being updated after freeze?  anyone know which bug this associated with?
<slangasek> haven't looked, let's see
<pitti> skaet: doesn't look like it's critical for beta-2
<pitti> but I'm just catching up on the last 3 hours
<skaet> fair 'nuf.  :)
<seb128> hey skaet
<pitti> right now, nothing in the queue looks particularly urgent to me
<skaet> seb128,  what's up?
<pitti> https://launchpad.net/ubuntu/+source/linux/2.6.38-8.42/+buildjob/2440470 is still busy for a couple of more hours (armel)
<seb128> skaet, we got quite some people today confused by the schedule, it would be nice to clarify when beta2 should be out and if selected fixes will go in between beta2 and natty
<seb128> skaet, there was at least 5 people asking about that today from different teams
<pitti> hm, why is euca still uninstallable..
<pitti> ah, python-psutil
<pitti> fixed
<skaet> seb128,  hmm... broadcast to u-d?
<seb128> skaet, or clarify on https://wiki.ubuntu.com/NattyReleaseSchedule, like it doesn't have an "beta2 is out" or an "hard freeze"
<pitti> slangasek, skaet: I think now would be a good time to build new i386/amd64 images; I can set a trigger for armel when the kernel finishes building; WDYT?
<skaet> heh,  NattyReleaseSchedule has beta2 as 4/14...  but I can add redundancy and add hard freeze
<pitti> I don't expect these to be the beta2 ones, but we currently have a sane archive AFAICS
<skaet> pitti,  +1 from me,  if the packages cjwatson flagged are in.
<pitti> python-psutil still needs a publisher run for server, I'll queue that accordingly
<pitti> skaet: yes
<seb128> skaet, well some updates will go in between beta2 and natty no?
<seb128> skaet, so when would be the real hard freeze for natty?
<slangasek> pitti: yes, looks good to me
<skaet> seb128 bug fixes only.
<seb128> skaet, right, well the schedule doesn't make clear what is the slot for those fixes
<slangasek> seb128: we're already in the hard freeze for natty; the archive is frozen, nothing goes in between now and release except by the hand of the release team
<seb128> skaet, that's what people were mostly asking today
<ScottK> Did they read the u-d-a message that explained all this?
<seb128> slangasek, well"BetaFreeze" points to https://wiki.ubuntu.com/BetaFreeze which states "Once the BetaRelease is shipped, we roll back to FeatureFreeze and UserInterfaceFreeze status. "
<pitti> desktop/DVDs started for all flavours
<seb128> slangasek, that got the u1 team confused at least
<seb128> ScottK, which one?
<pitti> alternates/server triggered on wait-for-package python-psutil_0.1.3-1ubuntu1
<ScottK> seb128: I was thinking of this one, but after re-reading it, it's less clear than I remembered: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2011-February/000823.html
 * skaet looking back in the archives and figuring a bit of overcomunicating is now appropriate. 
<seb128> ScottK, it was also a while ago
<seb128> there was no recent email
<pitti> slangasek: do you know if it's safe to start several wait-for-package's in parallel?
<slangasek> pitti: they may get a little confused when trying to each trigger their own mirror sync, but I think it's still safe
<ScottK> The more detailed discussion that I was thinking of was only on -release.  https://lists.ubuntu.com/archives/ubuntu-release/2011-March/000184.html
<pitti> slangasek: well, I think I'll just wait with triggering the armel builds; the server ones will start in an hour, and I'll still be awake by then
<pitti> slangasek: but good to know in general
<pitti> (bbl)
<ScottK> I thought there was a more detailed recent mail, but I can't find it.
<skaet> ScottK,  I thought I sent one out as well - but am not spotting it in the archives.
<ScottK> pitti, slangasek: Shouldn't we wait for python2.7 on armel or is it safe to assume that finishes before the kernel?
<skaet> so,  will do.
<skaet> thanks for flagging seb128
<slangasek> ScottK: the kernel is a ~24h build that's only 17 hours in, I'm pretty sure we're clear there
<ScottK> OK
<slangasek> but double-checking
<slangasek> ah, python2.7 took 7h12m last time on armel
<seb128> skaet, you're welcome
<slangasek> pitti: ^^ so python2.7 may be the limiting factor for armel builds
<slangasek> (might be - by a hair - so we should wait for both)
<ScottK> slangasek: Also kde4libs just finished a few minutes ago on armel, so any Kubuntu images spun before the next publisher will be out of date.
<slangasek> we're waiting before building any arm images though, aren't we?
<ScottK> Oh, right.
<ScottK> Sorry.  Too many moving parts.
<slangasek> no worries
 * ScottK pushed dhcp3 right through.
<pitti> ScottK, slangasek: I don't think the new python2.7 is important to have on the next armel images, but sure, we can wait for it
<slangasek> pitti: arm images take long enough to build that I think waiting 1 hour is probably appropriate
<slangasek> (since kernel and python probably land less than 1h apart)
<pitti> *nod*
<mvo> (note about the software-center debdiff, the submit_{review,report,usefulness} is actually a symlink in the tar, still it shows up multiple times in the diff, its the same script called with different personalities)
<pitti> http://cdimage.ubuntu.com/daily-live/20110411.1/
<pitti> there, hot off the press
<pitti> skaet: would you be able to add the images to the iso tracker as they trickle in?
<skaet> pitti,  sure.  What order should they be coming in?
<pitti> skaet: I just posted ubuntu desktop; k desktop will follow in a few minutes, xubuntu building now, then mythbuntu, kubuntu-mobile, ubuntu dvd, edubuntu dvd, kubuntu dvd
<skaet> pitti,  ok,  sounds good.   will check in that sequence.
<pitti> skaet: I just started building alternates: ubuntu kubuntu xubuntu ubuntu-server ubuntustudio
<pitti> for some reason wait-for-package fooled me, should have triggered 15 minutes ago already
<slangasek> doko: bugger, why does g++-multilib not depend on gcc-multilib?  gcc-4.[56] will still FTBFS because this is only fixed for gcc-multilib and they build-depend on g++-multilib
<slangasek> doko: so gcc-defaults will need another upload before release - do you want me to add the same compat symlink to g++-multilib, or add a g++->gcc dep?
<pitti> slangasek, skaet: starting python/linux triggered pipeline for armel now
<pitti> wait-for-package -a armel /python2.7_2.7.1-5ubuntu2 && wait-for-package -a armel linux-image-2.6.38-8-omap_2.6.38-8.42 && buildlive ubuntu-netbook daily-preinstalled && (for-project ubuntu-netbook cron.daily-preinstalled &) && echo kubuntu preinstalled && buildlive kubuntu daily-preinstalled && (for-project kubuntu cron.daily-preinstalled &) && echo kubuntu-mobile preinstalled && buildlive
<pitti> kubuntu-mobile daily-preinstalled && (for-project kubuntu-mobile cron.daily-preinstalled &) && echo headless preinstalled && buildlive ubuntu-headless daily-preinstalled && for-project ubuntu-headless cron.daily-preinstalled
<skaet> pitti,  ack
<pitti> I expect this to trigger in some two hours
<slangasek> right, thanks
<pitti> if something gets in between just kill the wait-for-package process, and then the next one
<pitti> with that, good night!
<pitti> skaet: alternates/desktops are trickling in, btw
<ogra_> pitti, you rock, sleep well
<pitti> but I can add the remaining ones to the tracker in about 8 hours
<skaet> pitti, thanks!   sleep well.
<pitti> if skaet doesn't beat me to it :)
 * skaet will go check it now....
<pitti> {k,x,myth}buntu-desktop should be there now
<jibel> skaet, it looks like natty-desktop-amd64+mac.iso is there too but not on the tracker
<skaet> jibel,  looking into it now
<SpamapS> I have a NEW package I'd like to upload to universe.. a tiny wordpress plugin to make wordpress work w/ drizzle. Do I need an ACK from the release team?
<doko> slangasek: well, nobody did notice before ...  g++-multilib should depend on gcc-multilib
<skaet> jibel, natty-dekstop-amd64+mac.iso now added.
<slangasek> doko: ok, uploading now, thanks for confirming
<skaet> jibel,  ubuntu desktop,  alternate,  kubuntu desktop, alternate all posted.
#ubuntu-release 2011-04-12
<wgrant> ScottK, pitti: It's not quite that easy, I'm afraid. At the moment it's hard-coded to backports, but that will probably change in the next few months as we refactor for derivative distros.
<skaet> slangasek, breaking for dinner.  back on in an hour or so...
<slangasek> skaet: ok, bon appetit :)
<SpamapS> so, bug #753924 causes ph5p-fpm to fail to install every time. Should I make this a zero-day SRU?
<ubot4> Launchpad bug 753924 in php5 (Ubuntu) "package php5-fpm 5.3.5-1ubuntu6 failed to install/upgrade: Ð¿Ð¾Ð´Ð¿ÑÐ¾ÑÐµÑÑ ÑÑÑÐ°Ð½Ð¾Ð²Ð»ÐµÐ½ ÑÑÐµÐ½Ð°ÑÐ¸Ð¹ post-installation Ð²Ð¾Ð·Ð²ÑÐ°ÑÐ¸Ð» ÐºÐ¾Ð´ Ð¾ÑÐ¸Ð±ÐºÐ¸ 1 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/753924
<SpamapS> aw n/m looks like zul fixed it a month ago. ;)
<SpamapS> actually.. no.. looks like the fix was ineffective
<slangasek> SpamapS: new packages should follow the FFe process, yes.  bug #753924, I think there's probably room for that post-beta2 if you can have a fix ready to go by then
<ubot4> Launchpad bug 753924 in php5 (Debian) (and 1 other project) "package php5-fpm 5.3.5-1ubuntu6 failed to install/upgrade: Ð¿Ð¾Ð´Ð¿ÑÐ¾ÑÐµÑÑ ÑÑÑÐ°Ð½Ð¾Ð²Ð»ÐµÐ½ ÑÑÐµÐ½Ð°ÑÐ¸Ð¹ post-installation Ð²Ð¾Ð·Ð²ÑÐ°ÑÐ¸Ð» ÐºÐ¾Ð´ Ð¾ÑÐ¸Ð±ÐºÐ¸ 1 (affects: 1) (heat: 6)" [Unknown,Unknown] https://launchpad.net/bugs/753924
<SpamapS> slangasek: alright. ty on both answers. :)
<Daviey> Hi, would someone be able to approve eucalyptus - i'd quite like it to be in the next ISO spin.  Thanks.
<Daviey> SpamapS, it seems still quite early to be thinking about zero day SRU's, no?
<SpamapS> Daviey: well the wording of the email about the freezes suggested there are no more days where the archive is opened for anything except fixes "requested by the release team".. but maybe I read it wrong.
<SpamapS> yeah I read it wrong
<SpamapS> 4/14 - 4/21 should be open for important fixes
<Daviey> https://lists.ubuntu.com/archives/ubuntu-release/2011-April/000190.html
<Daviey> SpamapS, Fixes for universe (php5-fqm) should still be able to be uploaded until 26th... but perhaps sooner might be better.. :)
<SpamapS> php5-fpm is universe?
<skaet> slangasek,  looks like the daily's weren't disabled....
<SpamapS> ooohhhhh
<SpamapS> how can bin packages from php5 be in universe?
 * SpamapS always thought the whole thing goes into main when the source goes in
<micahg_> SpamapS: binary demotion
<micahg_> SpamapS: it's common for transitional packages
<SpamapS> php5-fpm is not transitional
<SpamapS> its quite possibly the most popular way to run php at the moment
<Daviey> SpamapS, Ah, scrub that - the source is in main.. Sorry for that!
<SpamapS> Daviey: but I can see why you'd say that since the binary itself is in universe
<micahg_> SpamapS: I think you just have to ask if you want it per https://wiki.ubuntu.com/MainInclusionProcess note 2
<slangasek> skaet: are they disabled now or do you need me to do it?
<skaet> slangasek, need you to please.
<skaet> also,  xubuntu, mythbuntu didn't seem to build.
<slangasek> skaet: dailies are disabled and I didn't do it
<slangasek> checking on xubuntu
<slangasek> I see xubuntu 20110411.1 alternate built, 20110411 desktop looks like a build failure
 * skaet nods
<skaet> yes,  xubuntu alternate posted already.
<slangasek> ah, mirror sync issue at the time of the CD build; retriggering after I check on mythbuntu
<slangasek> same problem
<slangasek> ok, kicking off the ISO builds for both - shouldn't need to respin the livefs for this issue
<skaet> coolio
<ScottK> SpamapS: Yes.  Yes you do.
<skaet> slangasek,  can you see if edubuntu dvd is same problem (mirror synch)  it appears to have failed as well.
<slangasek> I don't see an edubuntu build log for today
<slangasek> did kubuntu dvd already finish?
<skaet> kubuntu dvd doesn't have images
<skaet> was just checking
<slangasek> xubuntu, mythbuntu successfully built btw
<skaet> order was ubuntu, edubuntu, kubuntu for dvd...
<skaet> re xubuntu and mythbuntu - cool.
 * skaet posting
<slangasek> right, I don't see any pending jobs for edubuntu or kubuntu DVDs, and they're definitely not there; firing them off again
<skaet> slangasek,  thanks.
<skaet> all livecd's now posted (u, ku, xu, myth, ku-mobile) buntu
<skaet> all alternates now posted (u, ku, xu, u-server, u-studio)
<ScottK> slangasek: I just sponsored an xserver-xorg-video-intel upload.  It fixes a major corruption problem with KDE on Sandybridge video systems.  Two independent testers have verified it on KDE and Sarvatt verified no regressions in Ubuntu.  It would be really nice to get it in and it's a quick build too.
<slangasek> ScottK: I'm afraid I'm on the way out the door so I won't be able to review it for about an hour
<slangasek> skaet: ^^ does that sound ok to you?  if you need me to review when I get back I can
<ScottK> slangasek: I think that's fine.  You're still likely to be the first reviewer to show up.
<ScottK> It's a +2 lines patch, BTW.
<ScottK> (from upstream)
<skaet> slangasek,  if you could that would be appreciated.
 * skaet just checked, and it looks like we're still waiting for python2.7 to build before kicking off the arm images....
<slangasek> looks like edubuntu builds are failing with some sort of grub-related problem
<slangasek> Setting up grub-gfxpayload-lists (0.1) ...
<slangasek> /usr/sbin/update-grub-gfxpayload: 4: cannot create /boot/grub/gfxblacklist.txt.new: Directory nonexistent
<stgraber> slangasek: oh, /me hopes it's not in the LTSP chroot build part ...
<slangasek> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/natty/edubuntu-dvd/20110412/livecd-20110412-i386.out
<slangasek> not sure how to tell at a glance if it's in chroot-building
<stgraber> as ltsp is never mentioned in the whole log, it's safe to assume that's really the livefs failing and not the LTSP chroot
<stgraber> LTSP chroot would have been really weird as we aren't supposed to have grub in there
 * slangasek idly wonders if this intel driver fix also addresses the occasional screen corruption he's seen
<slangasek> stgraber: ok, well, hmm.  why is this only failing on edubuntu?  is grub-gfxpayload-lists edubuntu-specific?
<slangasek> ScottK, skaet: xserver-xorg-video-intel accepted; doesn't reset our waiting for armel thankfully :)
<stgraber> slangasek: did we get any successful livefs build since cjwatson added grub-gfxpayload-lists as a depend of grub-pc this morning ?
<skaet> slangasek,  thanks.  so the armel waiting on python is still pending? ...
<slangasek> stgraber: we certainly had a number of image builds done and I didn't notice any mails about livefs build failures...
<slangasek> skaet: looks like python2.7 is done on armel and publishing this hour
<skaet> slangasek,  thanks.   edubuntu's dvd still in progress too, from the looks of it.
<slangasek> skaet: no, edubuntu dvd builds failed, see above
 * skaet looking more carefully...   sigh.
<stgraber> hmm, can't think of anything weird we do with grub in Edubuntu ...
<stgraber> slangasek: what's the magic involved when two packages depend on each other to determine which is the first to get configured ?
<stgraber> slangasek: I see that grub-pc depends on grub-gfxpayload-lists which depends on grub-pc
<slangasek> stgraber: dpkg looks first for a package with no postinst
<slangasek> if both or neither have a postinst, it draws lots
 * stgraber wonders if both grub-pc and grub-gfxpayload-lists have postinst ...
<stgraber> ok, so grub-pc has a postinst that amongst other things seem to create /boot/grub and grub-gfxpayload-lists' postinst calls /usr/sbin/update-grub-gfxpayload which writes the blacklist into /boot/grub
<slangasek> yeah.  I'm guessing it was an oversight to create this circular dep
<stgraber> slangasek: while you are around, can you have a quick look at: https://bugs.launchpad.net/ubuntu/+source/pam/+bug/745532/+attachment/2021342/+files/bug745532.diff that's to fix bug 745532 (pam upgrade error when gdm isn't running) ?
<ubot4> stgraber: Error: Bug #745532 is private.
<ubot4> Launchpad bug 745532 in pam (Ubuntu Oneiric) (and 2 other projects) "fails to restart (not running) gdm on maverick->natty upgrade (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/745532
<ScottK> slangasek: Thanks for taking care of xserver-xorg-video-intel .
<stgraber> with upstart not returning anything on status, I didn't find any better way than using grep to get the current status :(
<slangasek> ScottK: no problem
<slangasek> stgraber: I think better form would be: if $idl status | grep -q stop/waiting; then
<stgraber> indeed, updating with that
<slangasek> I'm wondering if invoke-rc.d is wrong here, however
<slangasek> if 'invoke-rc.d $service reload' is not meant to return an error for a non-running service, we should fix invoke-rc.d
<slangasek> policy is mute
<slangasek> so yeah, let's go with your patch, at least for now
<slangasek> I would probably do s/skipping/no reload needed/, personally
<stgraber> ok, changed to "no reload needed" and uploaded
<ScottK> slangasek: Looking at https://launchpad.net/ubuntu/+source/dhcp3/3.1.3-2ubuntu7 I'm thinking dhcp3 source ought to be removed.
<slangasek> it has been removed from Debian (pre-squeeze release).  Want to file a pro forma bug?
<ScottK> OK.
<ScottK> slangasek: Bug #758357
<ubot4> Launchpad bug 758357 in dhcp3 (Ubuntu) "Please remove dhcp3 source from Natty (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/758357
<ScottK> slangasek: Do you think pam should go in before Beta 2?
<slangasek> ScottK: no strong opinion; it might be something we want in the archive at beta release for upgrades, otherwise it's probably something to accept opportunistically
<ScottK> OK.  It looks fine to me, I guess I'll leave it for if someone needs a publisher run.
<skaet> edubuntu dvd posted
<micahg_> I'm assuming we can remove universe packages up to final universe freeze?
<ScottK> minus however long it takes to get an archive admin's attention to do it, yes.
<slangasek> kubuntu dvd built && posted
<skaet> unbuntu-netbook built and posted
<pitti> Good morning
<pitti> skaet: hey
<pitti> how bad is it?
<skaet> heya pitti,  not too bad,  so far.
<pitti> nice, my double wait-for-package armel builds triggered fine
<skaet> armel are still emerging...
<pitti> I'll add them to the tracker then
<pitti> they all finished building
<pitti> edubuntu dvd apparently failed
<skaet> I'm not seeing netboot images though.   can you check that they've been started?
<pitti> skaet: hm, we don't have cronjobs for any netboot "images" as such
<skaet> pitti, hmm... they show up in the dailies,  so something's building them.
<skaet> pitti, probably best to wait until cjwatson's online and talk it through with him.
<skaet> other than that,  I'm keeping my fingers crossed when I wake up we don't have too many new bugs.  ;)
<pitti> skaet: well, d-i builds them, yes, but they aren't ISOs
<skaet> upgrades aren't iso's either ;)
 * skaet is fuzzy brained though at this point,  so will leave you to it, and get some zzz's.
<pitti> skaet: so I guess there's some magic to create "beta-2" in http://archive.ubuntu.com/ubuntu/dists/natty/main/installer-amd64/
<skaet> probably...   also,  edubuntu dvd was kicked off again by slangasek,  and there's dvd images in the iso tester.
<pitti> ah, so that probably just killed mine, good
<pitti> skaet: so we have something to play with now, and I'll review the upload queue for more beta-2 RC bug fixes
<pitti> so that we might have another round of CD builds tonight?
<skaet> pitti,  yeah, review for the opportunistic fixes, and we'll see what the testing shows us.
<skaet> on the positive side - I upgraded my 10.10 clean wubi system, and it booted up nicely into 11.04 for the first time through that path,  so I was smiling tonight.
<pitti> all arm images posted
<jibel> pitti, netboot from 11-Apr-2011 19:03 is good to add to the tracker ?
<pitti> jibel: I hope so, I'll add it
<jibel> pitti, nm I'm on it.
<pitti> ah, thanks
<pitti> ok, I reviewed/accepted everything which is either obviously safe or urgent for beta2
<pitti> the remaining uploads should wait until after b2 IMHO
<Daviey> Do we have a guess when the next spin is due?
<pitti> Daviey: pretty much "when we need it"
<pitti> Daviey: do you need any of the virtinst etc. packages that were accepted an hour ago on the server images?
<Daviey> pitti: Yeah, i wondered if he knew of something on the horizon that might be enough.
<pitti> "he"?
<pitti> Daviey: but the current server isos should be fine
<pitti> for an initial test, anyway
<Daviey> pitti: More curious to enable hggdh to QA Eucalyptus.
<Daviey> It doesn't jusify a respin.
<cjwatson> skaet: netboot images are built by uploads of the debian-installer packages.  FYI
<cjwatson> did anyone resolve the grub-gfxpayload-lists issue I see in backscroll?
<ev> are we too late in the game for beta-2 stuff? Or would any accepted uploads require a respin?
<cjwatson> the obvious solution to that seems to be to have grub-gfxpayload-lists.postinst mkdir -p /boot/grub
<cjwatson> I'm happy with the circular dep part of it
<pitti> ev: right now we plan to do another respin this evening, and accept important or safe stuff over the day
<ev> yay
<ev> I have safe stuff ;)
<ev> but I'll hold off for a bit just in case any more ubiquity bugs get fixed
<pitti> cjwatson: not that I have seen
<cjwatson> uploaded a fix
<cjwatson> ta
<ogra_> pitti, i didnt get any tracker notification for headless armel builds, but they seem to exist on cdimage
<pitti> ogra_: they do exist in the tracker as well
<ogra_> hmm, weird
 * ogra_ checks, i thought i subscribed
<ScottK> Accepted kubuntu-meta.
<ScottK> And now I'm off for the day.
<ogra_> pitti, oops, sorry, i was actually not subscribed
<pitti> ScottK: thanks
<pitti> ogra_: ah, at least that explains it
<pitti> I think http://people.canonical.com/~ubuntu-archive/nbs.html is about as far as we can realistically get
<pitti> x264 is FTBFS on powerpc, and I already tried to build lipsia and odin against libdcmtk2-dev, they fail horribly on other things
<pitti> so I'm inclined to just declare lipsia/odin broken and remove the libdcmtk1 stuff
<pitti> I pinged siretart about whether he's interested in x264 on powerpc, but if not, I'd just declare it broken as well
<jibel> Riddell, bug 758614 I haven't found any useful information in the logs. I can replay the installation if needed and provide additional infos.
<ubot4> Launchpad bug 758614 in ubiquity (Ubuntu Natty) (and 1 other project) "Kubuntu Wubi - Black screen during stage 2 (affects: 1) (heat: 6)" [High,Confirmed] https://launchpad.net/bugs/758614
<Riddell> jibel: hmm, I don't even know enough about the wubi process to know what should be going on during that
<cjwatson> Riddell: "stage 2" of wubi is just ubiquity
<jibel> Riddell, I don't think it's wubi, it's more like the session not starting before launching the installer.
<cjwatson> with a load of preseeding
<skaet> morning all
<Riddell> happy Tuesday
<skaet> :)
<charlie-tca> Good morning, skaet
<jibel> Hi skaet
<seb128> hey skaet
<skaet> hi jibel, charlie-tca, any particularily nasty bugs showing up from the testing so far?
<skaet> hi seb128 :)
<jibel> skaet, nothing exciting. 2 ubiquity bugs with Wubi, translations/strings issues, and a grub failure on amd64+mac
<skaet> jibel,  nothing exciting == good.  ;)
<skaet> thanks
<jibel> skaet, I've added a report on qa.u.c to tracker the state of the builds the bugs filed during the release.
<jibel> http://reports.qa.ubuntu.com/reports/isotesting/natty/opened.html
 * skaet hugs jibel
<skaet> thanks!   That should make the final cross checks and documentation easier.   :)
<jibel> the first page 'image list' takes the images available from cdimages and the build logs and match it with the results on the tracker
<jibel> so you'll see images that are published on cdimage but not published on the tracker.
<charlie-tca> skaet: upgrade Xubuntu maverick to natty pulls in all of gnome
<jibel> like natty-server-powerpc.iso for example
<charlie-tca> gives me the option to use any ubuntu or xubuntu session at login
<jibel> charlie-tca, that's a dependency issue that mrpouit needs to fix.
<charlie-tca> I know, but that doesn't make it less nasty
<Riddell> jibel: where do I download wubi from?
<jibel> Riddell, it's on the iso
<jibel> mount the iso and wubi.exe is at the root of the iso
<Riddell> so I have to burn the ISO, boot up windows and run wubi from there?
<jibel> Riddell, to go faster mount the iso, and copy wubi.exe and the iso to windows
<Riddell> ok
<jibel> Riddell, then run wubi.exe --isopath=natty-desktop-amd64.iso or the arch you're running.
<jibel> or burn a cd
<cjwatson> jibel: I hope you *occasionally* test from a burned CD; the code paths aren't the same when you run from an ISO image on disk
<cjwatson> could somebody review console-setup?  in order for that fix to be effective, it will need to land in the archive so that we can incorporate it into the next ubiquity upload
<jibel> cjwatson, yes, but once I've validated that the CD is ok I use the isopath method, which is faster than burning a cd for each test.
<cjwatson> ok
<pitti> cjwatson: doing now (sorry, had a two-hour mumble debug session)
<pitti> cjwatson: accepted
<cjwatson> no problem, thanks
<ev> can someone let migration-assistant through? I'd like to get that into the ubiquity upload as well
<pitti> ev: yep, I'm running through the queue now
<ev> yay
<ev> thanks
<pitti> jibel, skaet, cjwatson: I think tonight we should regenerate all images to pick up today's bug fixes; do you have a preferred time when to start this? (I thought around 2000 UTC)
<pitti> GrueMaster, ogra_: WDYT about the current armel images? do you want another build tonight?
<GrueMaster> pitti: what bug fixes affect armel?
<cjwatson> the python-apt one, according to ogra
<cjwatson> GrueMaster: ^-
<pitti> GrueMaster: not the gfxboot ones, and not the installer ones; there were some fixes in the desktop, but none which break the installation
<pitti> python-apt is bug 758732
<ubot4> Launchpad bug 758732 in python-apt (Ubuntu Natty) (and 1 other project) "enable_component() does not enable components for deb-src lines (affects: 1) (heat: 8)" [Medium,Fix released] https://launchpad.net/bugs/758732
<GrueMaster> Well, let me get some testing in so we can catch any criticals.  I haven't had fresh working images in a week.
<GrueMaster> that bug is very low.
<pitti> so if the prebuilt images have a wrong apt sources.list, you might want that
<GrueMaster> Not sure why it is marked as medium.
<pitti> GrueMaster: yeah, I'm asking as we need to weigh the nontrivial hours of building and mandays of testing against the fixes
<GrueMaster> Having no deb-src for universe is not enough of a reason to regenerate.
<GrueMaster> Right now I am seeing a bug where oem-config fails to start on the headless images.  Higher priority.
<pitti> hm, haven't see the report for that one yet
<GrueMaster> I should be able to do enough testing between now and 2000UTC to determine what else needs critical fixes before we respin armel.
<GrueMaster> Just filed.
<pitti> right
<GrueMaster> bug 758858
<ubot4> Launchpad bug 758858 in ubiquity (Ubuntu) "oem-config fails to start on headless images (affects: 1) (heat: 8)" [High,New] https://launchpad.net/bugs/758858
<pitti> GrueMaster: so we'll rebuild after these get fixes, not time-based
<GrueMaster> That would be much better for me.
<pitti> 2000 for desktop/alternates/DVDs just seems  like a good time to pick up ev's/cjwatson's/mvo's fixed from the day
<GrueMaster> As long as I have new images by this time tomorrow, I can get them tested.  I'm in US-PST.
<cjwatson> GrueMaster: 758858> can you try booting the first time round with 'debug-oem-config' on the kernel command line, instead of running oem-config-firstboot a second time?
<cjwatson> GrueMaster: the log is full of stuff that indicates that the debconf database is already locked by something else, and I don't know if that's related to the way you did your debug run or not
<GrueMaster> I tried that yesterday with the same results.  Unfortunately I had to get something else tested and didn't get a chance to file a bug.
<cjwatson> I think we'll get a more useful log if you use debug-oem-config to put it in debug mode right from the start
<cjwatson> GrueMaster: sure, it will still *fail*, but it will produce a more useful log
<GrueMaster> I'll try again on a clean image.
<cjwatson> the current logs don't have anything actionable
<pitti> ev: ^
<ev> much appreciated
<GrueMaster> cjwatson: I added debug-oem-config and the log doesn't appear any different from launching it manually (other than I have no console using this method).
<GrueMaster> Is there a different log to look at?
<cjwatson> /var/log/oem-config.log should be the right one
<cjwatson> can I see it?
<cjwatson> (also, to be perfectly honest, I need ARM people to be debugging installer problems on ARM, as a general rule ...)
<GrueMaster> http://paste.ubuntu.com/593172/
<cjwatson> I can try but success is far from guaranteed
<cjwatson> hmmm
<cjwatson> odd multiplicity of log entries there, but as you say, no different
<cjwatson> I guess I need a way to reproduce this on i386, or else an ARM person needs to debug this
<GrueMaster> Looks like each run just appends new output.  There should be 3 runs in that log.
<GrueMaster> I've pinged ogra.
<pitti> I'm off for about 1 h for my Ubuntu Dev Week talk about PyGI
<ogra_> pitti, i discovered a jasper bug with the netbook image so i would like a rebuild once i uploaded the fix
<GrueMaster> ogra_: rebuild is planned,but let's get as many bugs as possible before you trigger the rebuild.
<ogra_> GrueMaster, indeed
<ogra_> cjwatson, on the headless image i'm calling a chrooted debconf-communicate from initramfs to preseed the debian-installer/framebuffer value, could it be that i miss some black magic to have it remove the lock ?
<ogra_> (thats the only idea i have for the above)
<cjwatson> simply exiting should be enough
<ogra_> hmm, k
<ogra_> there is nothing else that could touch debconf, weird
<cjwatson> getting an strace might be worthwhile, in case it's oem-config trying to recursively claim the lock itself
<cjwatson> (strace -f -s 1024, at least)
<cjwatson> and also of course check for other running processes
<Laney> Is adding a new meta package to a (universe) source package OK at this stage in the cycle?
<lamont> skaet: doko: ogra_: pitti: so, do I reject bug 67544, or just mark it incomplete?  (we're going to actually need some binaries to bootstrap from that run on ubuntu...)
<ubot4> Launchpad bug 67544 in fpc (Debian) (and 5 other projects) "Bootstrapping needed for fpc for armel (heat: 13)" [Unknown,Fix released] https://launchpad.net/bugs/67544
<skaet> pitti, before starting the images,  have you done "Modify debian-cd/CONF.sh to set OFFICIAL "
<skaet> lamont,  if you're needing binaries to bootstrap (effectively waiting for input from reporter sort of thing) then incomplete seems like the right state
<ogra_> can someone let jasper-initramfs in ? diff is at http://paste.ubuntu.com/593206/ i need it on the next netbook image
<cjwatson> skaet: that was already done for beta 1, and wasn't undone
<cjwatson> (I checked yesterday, remembering last time ...)
<skaet> cjwatson,  :)
 * highvoltage starts upgrade testing for Edubuntu Desktop i386/amd64
<jbicha> we're in hard beta freeze now?
<skaet> jbicha, yes
<skaet> jbicha, is there a specific fix you're trying to get in?
<jbicha> yes, fixing bug 426215 would make the Ubuntu Help better as we could link directly to Software Center
<ubot4> Launchpad bug 426215 in software-center (Ubuntu) (and 1 other project) "[UIF exception] apt:package-name isn't handled by the Store when appropriate (affects: 5) (heat: 30)" [Wishlist,Fix released] https://launchpad.net/bugs/426215
<jbicha> I can ask again Friday though, right?
<ev> doing the ubiquity release dance now
<ev> ^ if someone could let that through, I'd appreciate it
<skaet> jbicha,  yes, please ask as soon as we get the beta images published.
<highvoltage> virt-manager's scale option ftw! http://people.ubuntu.com/~jonathan/files/natty/testing.png
 * skaet goes to get some lunch,  biab
<ogra> cjwatson, strace data attached to bug 758858 ... i see a lot of EBADF errors
<ubot4> Launchpad bug 758858 in ubiquity (Ubuntu) "oem-config fails to start on headless images (affects: 1) (heat: 8)" [High,New] https://launchpad.net/bugs/758858
<pitti> ev: looking
<pitti> ogra: jasper-initramfs accepted; so you want all armel rebuilds for that (also kubuntu)? (<- GrueMaster)
<ogra_> pitti, for that one i dont need kubuntu, but for the python-apt one
<pitti> ogra_: so, full rebuild tonight?
<ogra_> the jasper-initramfs change is only for omap4 netbook
<ogra_> yeah, we are still trying to find the cause for bug 758858  though
<ubot4> Launchpad bug 758858 in ubiquity (Ubuntu) "oem-config fails to start on headless images (affects: 1) (heat: 8)" [High,New] https://launchpad.net/bugs/758858
<pitti> ogra_: right
<pitti> ogra_: I'll monitor that then and do rebuilds once that's fixed
<pitti> ogra_: if it doesn't get fixed by, say, 2200 UTC, do you still want rebuilds for the other fixes?
<ogra_> pitti, yeah, theoretically the non headless rebuilds could happen now, lets see what GrueMaster thinks about that
<pitti> ogra_: we still need the jasper-initramfs build/publication, no?
<ogra_> and headless is so fast to test that we could still roll it tomorrow worst case
<pitti> *nod*
<ogra_> yeah, it needs to be on the images
<pitti> anyway, I need some food, bbl
<GrueMaster> I haven't hit any criticals on the non-headless images yet.  Haven't looked at kubuntu though.
<ogra_> GrueMaster, well, the jasper fix is for unity-2d only (the PPA icon)
<ogra_> theoretically we wouldnt need to rebuild kubuntu (unless there are heavy bugs you will find)
<GrueMaster> understood.  Just specifying what *needs* rerolling immediately vs later tonight.
<GrueMaster> the plan earlier was to reroll all armel to pick up other bug fixes.  I want to test (and hopefully fix) as much as possible before that happens.
<ogra_> right
<slangasek> ^^ ecj is a fix for an armel ftbfs, and for ecj1 being unusable due to multiarch; it's a dep of the gcj jdk and of eucalyptus so it impacts dvds and server images
<slangasek> (but is not beta-critical)
<ogra_> cjwatson, backing out your fix for bug #746020 makes headless work
<ubot4> Launchpad bug 746020 in ubiquity (Ubuntu) "ubiquity crashed with ValueError in command(): invalid literal for int() with base 10: '' (affects: 3) (dups: 2) (heat: 28)" [Low,Fix released] https://launchpad.net/bugs/746020
<stgraber> skaet: how critical is LTSP for beta2 ?
<skaet> stgraber,  can you give me the bug number?
<stgraber> skaet: there's a bug that seems to affect ubuntu alternate 32bit/64bit + edubuntu 32bit/64bit. Not sure where it comes from yet, debugging it now.
<stgraber> skaet: don't have one yet
<skaet> stgraber,  how does it manifest?
<stgraber> patrickmw: can you file one anyway ?
<stgraber> skaet: install LTSP from alternate or test it in Edubuntu => won't boot
<stgraber> as in, the thin client won't boot. The server is fine AFAIK
<patrickmw> stgraber, yes.  did you determine the best package to file the bug against?
<stgraber> patrickmw: just file it against ubuntu for now and assign to me please
<skaet> stgraber,  interesting.   Let me have a couple of discussions.   Sounds like something we can document around if necessary, but I'll see if I hear a dissenting opinion.
<patrickmw> stgraber, ok
<skaet> stgraber,  thanks for flagging.
<stgraber> skaet: I should have the issue reproduced here in 10-15 minutes, then it shouldn't be long to figure out what broke and give you more information.
<skaet> stgraber,  cool,  thanks!
<ogra_> skaet, root cause for bug 758858 found, but i dont really know how to solve it, seems its caused by a fix for another bug
<ubot4> Launchpad bug 758858 in ubiquity (Ubuntu Natty) (and 1 other project) "oem-config fails to start on headless images (affects: 1) (heat: 8)" [High,Confirmed] https://launchpad.net/bugs/758858
<ogra_> i just did a succsessfull headless install here
<stgraber> patrickmw: reproduced the bug
<patrickmw> stgraber, you will have a bug id in a few
<stgraber> and identified the problem
<stgraber> it's some kernel packaging (I guess) that makes the files 600 instead of 644
<stgraber> so now the tftp process can't read the kernel and initrd
<stgraber> skaet, highvoltage: ^
<skaet> stgraber, ack
<skaet> ogra_,  glad you know root cause,  guess we'll go ahead with builds, and if you can figure a workaround/resolution by tomorrow morning your time, work with pitti to incorporate it.  Doesn't look likely we'll get a fix tonight then.
<patrickmw> stgraber, bug 759115, I assume you will be changed the package its assigned to
<ubot4> Launchpad bug 759115 in ubuntu-meta (Ubuntu) "ltsp thin client kernel error - Could not find kernel image: vmlinuz (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/759115
<ogra_> skaet, well, cjwatson wrote the original fix, i would like to get some input from him
<skaet> ogra_,  understandable.
<ogra_> skaet, but a full install test of headless takes around 10min (plus another 10 for dd'ing the image to SD) so we can be late with that
<stgraber> skaet: not totally sure how to fix the ltsp issue ... I could do a hack in LTSP to chmod the files when copying the kernels, but that definitely changed since beta1, so I'd be interested to know why the kernel is now only readable by root
<skaet> stgraber, I was about to suggest going onto u-kernel and asking, but I see that bjf has just joined here,  so wondering if word has spread ;)
<highvoltage> stgraber: I guess there would be a feature freeze bug for it if it was done on purpose?
<stgraber> bjf: hey, any idea why kernel and initrd is now 600 instead of 644 ? that's breaking ltsp :)
<ogra_> stgraber,   [ Kees Cook ]
<ogra_>   * [Config] packaging: adjust perms on vmlinuz as well
<ogra_> from 2.6.38-8.40
<stgraber> doh, security ... should have thought of it
<ogra_> talk to kees
<ogra_> :)
<highvoltage> eek, I seemed to have forgotten about https://bugs.launchpad.net/ubuntu/+source/edubuntu-artwork/+bug/746028 since the last beta
<ubot4> Launchpad bug 746028 in edubuntu-artwork (Ubuntu) "Edubuntu Wallpapers are not updated on upgrade to Natty (affects: 1) (heat: 493)" [Wishlist,Confirmed]
 * skaet had noticed that last night, when scrubbing techoverview and was a bit surprised it was still there.... 
<highvoltage> skaet: could I still fix that after the beta release is done?
<skaet> highvoltage,  depends when after.   ;)   Its localized scope though, so bug fix on friday would be fine.
<ogra_> didnt you write 21st would be upload deadline ?
<ogra_> :)
<highvoltage> skaet: ok, I'll prepare and test a fix in the meantime, so if there's a window for uploading, I'll be ready for it
<pitti> highvoltage: upload when ready; in the worst case, it'll be in teh archive for upgrading, and in the best case we do a respin and it's in
<pitti> I don't see a problem with accepting it
<highvoltage> pitti: thanks!
<stgraber> pitti: I'll be uploading a new upstream version of LTSP soon to fix the LTSP bug affecting alternate. It's going to be including my fix + a ntpdate race condition fix + translation update + gentoo specifc delta. I'll add that to bug 759115
<ubot4> Launchpad bug 759115 in ubuntu-meta (Ubuntu) "ltsp thin client kernel error - Could not find kernel image: vmlinuz (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/759115
<cjwatson> ogra_: hmm
<ogra_> :(
<cjwatson> ogra_: I wonder if I put that code in the wrong place
<pitti> stgraber: ah, good; so we'll wait for that with the respin of alternates in any case
<ogra_> cjwatson, we also verified that it worked before the code was added, the 0402 image works, from 03 on it fails ... i find it a bit odd that only the debconf frontend seems to cause it
<cjwatson> ogra_: I have a good guess, just reading code
<ogra_> k
<cjwatson> yeah, I can fix this
<ogra_> \o/
<cjwatson> thanks for that investigation, that's exactly what I needed
<ogra_> :)
<cjwatson> anything else in ubiquity known to need urgent fixing?
<ogra_> well, ev just did an upload, i guess he already covered most
<cjwatson> stgraber: http://paste.ubuntu.com/593284/
<cjwatson> (#ubuntu-devel from five days ago)
<stgraber> cjwatson: yeah, I don't really like the idea of changing permissions on the kernel less than a month before release ...
<stgraber> pitti: ok, ltsp is on its way (5.2.7). Let me know if you have any question regarding the changes (and I'll either try to answer or nag the one who commited it :))
<cjwatson> ogra_: the big pile of EBADF is actually harmless - it's just that Unix has no way to say "close all fds" or "close all fds apart from these ones"
<cjwatson> it's an omission from the interface
<ogra_> ah
<cjwatson> the best you can do if you want that is to iterate up to some plausible maximum
<highvoltage> jibel, skaet: I see you tested ubuntu upgrades. could you confirm that the ubuntu wallpapers changed to the new ones after upgrade? I suspect that the edubuntu wallpaper bug might be present in ubuntu as well and since the wallpapers are quite similar, it might have gone unnoticed
<ogra_> well, that strace was truncated anyway
<ogra_> the second one actually showed some more info
<cjwatson> yeah, I read it
<cjwatson> it matches your diagnosis, indeed
<GrueMaster> I haven't found any critical fix-for-beta2 issues on the armel images.  respin when oem-config is fixed and ready.  :P
<ogra_> (and jasper is promoted)
<skaet> highvoltage,  the difference between the 10.10 and 11.04 is subtle,  and I think it was applied, so didn't open specific bug.
<skaet> however,  as you say,  its subtle, so I could be wrong here.
<stgraber> highvoltage: can you easily tell if a wallpaper is natty or not ? if so, come in my office, I have a freshly upgraded system :)
<highvoltage> I can if I see both, the new one has more orange diagonally
<highvoltage> skaet: I just checked stgraber's machine. the bug is present on ubuntu too
<highvoltage> skaet: so people who upgrade their ubuntu machines will see the old wallpaper on gdm and in their session
<stgraber> skaet: on the machine I just showed to highvoltage I have a different background for gdm (that was used on 10.10) and a user session that was never used (so first login being 11.04)
<pitti> stgraber: how much testing did this get? the changes look reasonable, but too much to review every single one just by eye
<stgraber> pitti: it got released a good 10 minutes ago. The changes themselves have been tested by their authors and I tried my chmod on a buggy natty machine to make sure it works.
<highvoltage> stgraber: yeah if that user logged in before, it would've gotten the old background. that bug doesn't affect new users.
<highvoltage> stgraber: the new caching stuff was done by didrocks, so I'll poke him when he's online again and take the liberty of subscribing him to that bug
<stgraber> highvoltage: ok, so it's just very very visible with edubuntu ;)
<pitti> stgraber: so yes, if you want that in instead of a focussed chmod bug fix, fine for me
<stgraber> pitti: yeah, I prefer having a non patched LTSP release whenever possible, we already have enough ubuntu specific stuff upstream.
<pitti> stgraber: accepted
<stgraber> that ntp fix is going to avoid a lot of bug reports too (would have been sru material). As I saw a few thin clients being out of date by a few years and having (surprisingly) SSL issues ...
<stgraber> pitti: thanks
<skaet> highvoltage,  thanks for letting me know.
<pitti> thanks cjwatson,  ubiquity accepted
<cjwatson> np
<pitti> ogra_: so we'll wait for ubiquity 2.6.4 for new armel images?
<pitti> ogra_: jasper-initramfs is in; blocking on anything else?
<ogra_> pitti, nope, go for it as soon as ubiquity is done
<pitti> ack
<pitti> so, ubiquity 2.6.4 for armel, fixed bamf for desktops, ltsp for alternates/dvds
<pitti> skaet: ^ aware of anything else
<skaet> pitti,  those are the main ones.
<skaet> the wallpaper issue for edubuntu/ubuntu on upgrades is cosmetic, and we can document around it.
<highvoltage> skaet: yep. at least it's not very noticable on Ubuntu (no one even noticed it until now) and on Edubuntu we can just post instructions on how to fix it post-upgrade
 * skaet nods
<pitti> highvoltage: I'm fine with queuing edubuntu DVDs last, this will give you another couple of hours to get them uploaded
<stgraber> pitti: we'll need an edubuntu rebuild for LTSP anyway
<pitti> right, I was going to (see above)
<highvoltage> pitti: great
<pitti> pitti | so, ubiquity 2.6.4 for armel, fixed bamf for desktops, ltsp for alternates/dvds
<stgraber> pitti: ah right, I was thinking of another ltsp issue affecting edubuntu: bug 759080 :)
<ubot4> Launchpad bug 759080 in ubuntu "DHCP Server is not installed with Edubuntu LTSP Installer (affects: 1) (heat: 6)" [High,Confirmed] https://launchpad.net/bugs/759080
<pitti> stgraber: oh, will that need another upload?
<stgraber> which was caused by bad timing on building the edubuntu candidate
<stgraber> pitti: nope, it was just caused by Edubuntu building when isc-dhcp wasn't entirely published yet (only amd64 was)
<pitti> ah, just saw the bug, fine
<slangasek> well, the new xserver-xorg-video-intel doesn't fix the corruption I was seeing, but I can see the effects of the patch when I switch desktops
<jibel> slangasek, what type of corruption do you see ? do you have a bug number ?
<slangasek> jibel: haven't filed it yet; with metacity, my window borders sometimes stick around when they shouldn't
<slangasek> so if I alt+tab between windows, I get lines on the foreground window where the window decorations from the previous window are
<jibel> slangasek, this type of thing https://launchpadlibrarian.net/68593683/problem1.png ?
<slangasek> hmm, I haven't seen that
<slangasek> that looks like a different sort of corruption
<slangasek> let's screenshot, shall we
<pitti> slangasek: most likely bug 740387
<ubot4> Launchpad bug 740387 in xserver-xorg-video-intel (Ubuntu Natty) (and 4 other projects) "graphical corruption with multiple drivers and classic desktop (affects: 8) (dups: 1) (heat: 50)" [Undecided,Invalid] https://launchpad.net/bugs/740387
<pitti> could you compare?
<pitti> slangasek: that more likely affects the window interior not being refreshed properly, though
<pitti> https://launchpadlibrarian.net/67005944/example2.png
<slangasek> yeah, I've seen some of that, but only when flipping desktops I think
<slangasek> and that /does/ seem to be gone with the latest driver upload
<pitti> hm, it's not a driver problem
<pitti> slangasek: so perhaps you do have a different issue then
<slangasek> it may be specific to gnome-terminal, actually
<slangasek> at least, firefox doesn't show the problem
<slangasek> oh, no, also affects gimp
<slangasek> um am I going senile, or has the screenshot button disappeared from gimp?
<pitti> slangasek: works here
<pitti> well, the menu
<pitti> the thing that disappeared is the "fetch from scanner" menu entry
<slangasek> which menu do you see it in? :)
<slangasek> oh, there it is
<pitti> File -> Create -> Screen photo...
<pitti> (loosely translated from German)
<pitti> accepting bamf
<slangasek> pitti: bug #759203, w/ screenshot
<ubot4> Launchpad bug 759203 in metacity (Ubuntu) "alt+tab window cycling leaves window borders drawn across windows (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/759203
<pitti> ah, haven't seen that one yet
<pitti> of course it's possible that this is another symptom of the xdamage bug
<slangasek> xdamage?
<pitti> hm, seems two wait-for-packages don't like each other, the second one crashes on the lock file
<pitti> slangasek: bug 740387
<ubot4> Launchpad bug 740387 in xserver-xorg-video-intel (Ubuntu Natty) (and 4 other projects) "graphical corruption with multiple drivers and classic desktop (affects: 8) (dups: 1) (heat: 50)" [Undecided,Invalid] https://launchpad.net/bugs/740387
<pitti> it got introduced with a metacity patch for unity-2d, but that caused this regression
<slangasek> ok
<pitti> would be interesting to try without that patch to see whether it fixes it
<pitti> debian/patches/16-capture-before-unmap
<slangasek> let's see
<slangasek> pitti: debian/patches/17-workspace-switcher-cycle.patch doesn't apply cleanly without 16-capture-before-unmap; how to resolve?
<pitti> slangasek: just disable it as well, it was added in the same uplaod as 16-capture
<pitti> slangasek, skaet: I just started http://people.canonical.com/~pitti/scripts/buildqueue.txt
<pitti> which has the triggers we discussed above (pacakges are all uploaded)
<pitti> alternates should start in ~ 30 minutes, desktops and armels in 90
<skaet> thanks pitti!
<skaet> will keep an eye on it in that sequence.
<pitti> highvoltage: you still have some 4 hours (perhaps more) before edubuntu will start, in case you want to update the pictures
<pitti> skaet: thanks
<skaet> jibel,  ^^  I'm going to be marking the images as rebuilding.
<pitti> so unless you need something else from me, I'd rather go to bed now and get up relatively early for more handholding
<pitti> I don't see much I could do right now except for waiting
<pitti> skaet: do you have access to antimony?
<jibel> skaet, k
<skaet> pitti,  yup,  thats where I was checking last night.
<skaet> pitti,  sleep well.   I'll publish them as they emerge, and ping slangasek if I see problems.
<pitti> skaet: right, so you can check "ps aux|grep cdimage" what it's doing ATM
<pitti> meh, the wait-for-packages trip on each other, needs some more handholding; I'll wait at least until the alternates start
 * skaet nods
<pitti> ah, alternates started
<pitti> bamf and ubiquity finished building on armel, so these builds will start in an hour
<pitti> skaet: if one of the wait-for-packages dies again, feel free to restart the pipeline as in http://people.canonical.com/~pitti/scripts/buildqueue.txt
<pitti> (but do it in screen)
 * SpamapS threatens pitti with kryptonite if he doesn't retire to the fortress of solitude soon
<pitti> slangasek can certainly help you with that
 * pitti yells "Geordi, maximum power to the kryptonite shield!"
<skaet> pitti,  :)   Yup,  can handle (as long as things don't break in unexpected ways ... )
<pitti> thanks
<pitti> so, good night everyone!
<skaet> sleep well pitti,   and thanks!
<pitti> skaet: meh -- this isn't working, we can't have multiple wait-for-packages
<pitti> seems ubuntustudio and server failed, and the running w-f-ps failed again
<pitti> skaet: I restarted ustudio and server builds
<pitti> skaet: would you mind running the armel and live pipelines in about 45 mins?
<pitti> ah well, I'll just use sleep instead of w-f-p
<pitti> done
<pitti> ok, off for real now, promised :)
<skaet> lol
<skaet> ok  will start the armel and live pipelines in about an hour.
<skaet> s/hour/45 minutes/
<cjwatson> pitti said he used 'sleep', which suggests to me that he has it set up to trigger
<cjwatson> so I don't think you need to
<cjwatson> there are two 'sleep 3600' processes on antimony
 * skaet nods 
<ScottK> pitti: On the off chance you're up and looking for something to do, there's that KDE SRU for Maverick that would love to take advantage of the empty buildds ...
#ubuntu-release 2011-04-13
<SudoKing> :)
<skaet> ubuntu desktop ( amd64, amd64+mac, i386, powerpc) posted - 20110412 image
<doko> lamont: still http://people.canonical.com/~doko/tmp/fpc-armel-mav-stage2/ from Sep 2010
<skaet>  Riddell, ScottK - kubuntu desktop (amd64, amd64+mac, i386, powerpc) posted - 20110413 image
<skaet> ogra_, GrueMaster,  ubuntu netbook pre-installed (omap3, omap4) posted - 20110413 image
<skaet> Riddell, ScottK,  kubuntu-mobile daily-live (i386) posted
<skaet> slangasek, around?
<skaet> looks like there's been some failures with xubuntu, mythbuntu on the desktop images.
<skaet> after the dvd's finish, I'll try kicking them off again to see what's happening.   Haven't seen any error messages though.   Is there som log location I can look?
<skaet> also,  doesn't look like the alternates have triggered....hmm...
<charlie-tca> I got an email earlier about a file lock causing a fail to build
<charlie-tca> but I deleted it already
<charlie-tca> skaet: I don't know if this helps, but this is where cjwatson has me look when I tell him by images did not build
<charlie-tca> http://people.canonical.com/~ubuntu-archive/cd-build-logs/xubuntu/natty/daily-live-20110413.log
<skaet> thanks charlie-tca
 * skaet looking
<charlie-tca> There are several things towards the end
<skaet> charlie-tca, yeah those failures to fetch files and has sum mismatches look suspicious.
<skaet> I suspect this will be a learning exercise for me :-/
<charlie-tca> Hoping they didn't. sometimes it just means you have to release a lock and tell it to run aagt
<skaet> As soon as the dvd images finish off,  I'll try them individually and see what happens from a command line perspective.
<charlie-tca> again, but I am not very good at reading these things, either.
<skaet> thanks for pointing me to the logs though... :)
<charlie-tca> You are welcome
<charlie-tca> I don't get to help you very often
<skaet> mythbuntu desktop (amd64, i386) - posted 20110413 image
<skaet> ubuntu dvd (i386, amd64) posted
<skaet> 20110413 image
<stgraber> skaet: any news on alternte ?
<stgraber> *alternate
<skaet> stgraber,  they don't seem to have been triggered,  am going in and trying them manually now.
<skaet> package they were waiting for is in the pool, so, ... fingers crossed.
<stgraber> ok. I don't think I'll still be around to test them tonight but will test LTSP first thing tomorrow morning (eastern time)
<skaet> kubuntu desktop arm (preinstalled omap, omap4) posted - 20110413
<stgraber> seems like alternates are ready too
<skaet> ubuntu alternate (i386, amd64, amd64+mac, powerpc) posted - image 20110413
<skaet> stgraber,  yup
<skaet> just came off the builds
<skaet> kubuntu dvd (i386, amd64) posted - 20110413
<skaet> kubuntu mobile (omap, omap4) posted 20110413
<lamont> doko_: I'll see if that does any better for me.
<skaet> ubuntu headless (omap3, omap4) posted - 20110413
<skaet> GrueMaster, ogra_ - that should be all the arm images available now.
<skaet> ubuntu-server (i386, amd64) posted  - 20110413
<lamont> skaet: we're hard-frozen the next couple days, yes?
<skaet> lamont, yes
<skaet> lamont,  what's pending?
<lamont> ok.  on the off chance these bits actually build, I'll wait for the unfreeze before I bounce around the arm chroot tarball to bootstrap fpc
<lamont> also, I'll build a fresh tarball tomorrow and then make it the current tarball once we unfreeze
<skaet> cool,  thanks.   window may open on Thursday,   depends on how this set of builds looks.
<lamont> thereby making the dist-upgrade step a no-op for the first few minutes
<lamont> doko_: same error.
<lamont> skaet: so I can skip that part :(
 * skaet nods
<skaet> ubuntu studio (amd64, i386) posted - 20110413
<lamont> skaet: so in the unlikely event that the current archive proves to be useless for building packages, let me know,eh?
<lamont> (highly unlikely, I warrant)
<lamont> anyway, sleep for this one
<skaet> lamont,  will do.  (me thinking sleep too is a good idea)
<skaet> pitti, cjwatson, jibel,  all images except xubuntu daily live are posted now.   langasek has that building now.
<slangasek> xubuntu live posted
<pitti> Good yawning
<pitti> skaet, slangasek: excellent
<pitti> hm, edubutu DVD on cardamon failed to build
<ScottK> pitti: I'm about to go to sleep myself, but if you can squeeze that KDE SRU in, I'll be around in a few hours to keep an eye on it and manage any retries due to archive skew.
<pitti> ScottK: KDE SRU> right, was planning on looking at that today, now that the urgent uploads are settled
<pitti> hmm, mythbuntu uploads in the queue?
<ScottK> Great.  Thanks.
<pitti> the mythtv upload looks relevant, accepting that (fixing oversizedness)
<pitti> I pinged superm1 about the other ones
<pitti> skaet: did superm1 happen to talk to you about the mythbuntu related uploads?
<mvo> in case someone wonders, main-all in the auto-upgrade-tester looks pretty good, the only failure left is bug #655533 - likewise-open I was not able to reproduce in a clean vm, so its something that is installed along with it
<ubot4> Launchpad bug 655533 in likewise-open (Ubuntu Natty) (and 1 other project) "[master] package likewise-open 5.4.0.42111-2ubuntu2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 (affects: 4) (heat: 20)" [High,Confirmed] https://launchpad.net/bugs/655533
<ev> fix for 759401 incoming
<Daviey> mvo: Eucalyptus passed ok?
<mvo> Daviey: I don't think its installed on this image, the algorithm is greedy so if euca caused more removals than it added it will be rejected from the image. I can add a profile for this or manually add it, probably a good fit for the server-tasks image
<mvo> Daviey: what packages/metapackage should I install? eucalythus-cloud?
<Daviey> mvo: Odd... i thought you identified a regression some months ago.
<Daviey> mvo: It probably needs two different scenarios tbh.. one being eucalyptus-cloud eucalyptus-cc eucalyptus-walrus eucalyptus-sc
<Daviey> the other being eucalyptus-nc
<mvo> Daviey: some of euca is installed on the python-all image, but not much afaict
<mvo> ok, let me add that, we got a new disk so there is plenty of space to fill with tests :)
<Daviey> mvo, w00t
<pitti> for the record, I switched two buildds to manual for urgent natty builds, so that I can keep the rest busy with SRUs
<mvo> Daviey: the eucalyptus-nc one has just this additional package? and the other 4 euca packages (just to ensure I get the profile right)?
<Daviey> mvo, Yeah... the -nc package is the individual nodes - and normally exists on it's own.  The other scenario is all the components on the same machine (minus -nc).
<ev> ^ right, so the stitch is that all CDs with ubiquity will exhibit that bug, but it's non-fatal.  The error message will show but the install should complete successfully.
<pitti> ev: hm, I wonder why that didn't come up in the testing since Monday
<ev> pitti: it broke with a change from yesterday
<ev> my fault for testing syntax but not the whole thing in the context of a full install
<ev> apols
<pitti> jibel: hm, do we have time for a respin/test?
<pitti> maybe not the DVDs (we can document that), but at least the desktops?
<pitti> ev: on xubuntu etc. as well, I take it?
<ev> correct
<pitti> ev: kubuntu as well? (since this does some gnome-keyring bits)
<ev> anything with ubiquity, though oem-config is unaffected since it exits that function immediately
<ev> correct, kubuntu as well
<jibel> pitti, which images ? all or only ubiquity based images ?
<pitti> I accept it for now to let it buildl
<pitti> jibel: yes, all desktop images (not alternate/server/etc.)
<pitti> nor the preinstalled armel ones
<jibel> pitti, okay, only desktop i386 and powerpc are well covered yet.
<pitti> jibel: ok, scheduling a rebuild then
<jibel> I'm marking desktop images as rebuilding
<pitti> we need a mythbuntu respin anyway, so at least for that it doesn't matter
<pitti> jibel: thanks
<ev> pitti: thanks
<mvo> Daviey: euca-nc just upgraded successfully, euca-cloud is still running, it should show up tomorrow on the regular qa dashboard page
<Daviey> mvo, Well that is odd.. i was expecting a failure :P
<Daviey> mvo, I appreciate that, thanks.
<Daviey> mvo, Is there any way i can get the result as soon as it comes in, instead of waiting for tomorrow?
<mvo> Daviey: sure, here is the raw log of euca-nc http://people.canonical.com/~mvo/tmp/euca-nc-mav-natty-upgrade.log
<mvo> Daviey: its based on the minimal server image (just ubuntu-minimal,standard plus euca)
<Daviey> mvo, That is great - thanks.
<mvo> Daviey: it has a FAILED for the debsums_lite test, but that is expected, I disabled this test on the real upgrade tester as the locale bits always fail
<Daviey> ah
<mvo> Daviey: here is the other one http://people.canonical.com/~mvo/tmp/euca-cloud-mav-natty-upgrade.log
<Daviey> thanks mvo, big help.
<mvo> yw
<pitti> jibel: I'm queueing new desktop and DVD builds now, once ubiquity has published, shoudl start in about 15 minutes
<pitti> jibel: I will rebuild DVDs as well; we can then decide whether or not to add them to the tracker
<pitti> i. e. whether we have time to test them, or use the current images with the bad error message
<jibel> pitti, current DVD builds are untested, when will the new builds be available ?
<Riddell> pitti: new kubuntu too?
<pitti> jibel: hm, perhaps 4 hours or so?
<pitti> Riddell: ev said it affects Kubuntu as well, yes
<jibel> pitti, ok.
<pitti> jibel_, all: new Ubuntu desktops posted (20110413)
<pitti> jibel_: FYI, I marked the DVDs as rebuilding as well, they only got 1 test in total
<pitti> (which revealed the very bug that got fixed now)
<pitti> Kubuntu images should land in the next ~ 10 minutes; I'm off for lunch and will add them when I get back, unless someone beats me to it
<pitti> ah, already trickling in, adding now
<pitti> Riddell, all: http://cdimage.ubuntu.com/kubuntu/daily-live/20110413.1/ added to tracker
<ogra_> netbook preinstalled omap4 doesnt look good
 * ogra_ prays its a bad SD or some such
<jibel> what's the ETA for xubuntu desktop images ?
<pitti> re
<pitti> jibel: should be there now, I'll catch up on adding
<jibel> pitti, I added them. thanks
<pitti> jibel: http://cdimage.ubuntu.com/xubuntu/daily-live/20110413.2/
<pitti> ah
<pitti> mythbuntu added
<pitti> kubuntu-mobile i386 added
<pitti> jibel: ubuntu DVD is building now, FYI
<jibel> pitti, why there's no livefs-build log and cd-build log for xubuntu 20110413.2 on http://people.canonical.com/~ubuntu-archive/{cd-build-logs,livefs-build-logs}/xubuntu/natty/ ?
<pitti> jibel: hm, I'm not sure, their mirroring might lag a bit?
<pitti> jibel: CD build log does exist: http://people.canonical.com/~ubuntu-archive/cd-build-logs/xubuntu/natty/daily-live-20110413.2.log
<cjwatson> mirroring is hourly
<ogra> phew, seems it was a bad dd write
<jibel> ah okay, thanks
<ogra> hmm, do we have a trigger for update-gconf-defaults ?
 * ogra doesnt want to use a postinst if he can solve the issue with one trigger line
<highvoltage> like everyone should!
<ogra> highvoltage, well, only if the respective trigger exists :)
<Daviey> Can we consider the current iso a candidate yet?  Has anyone expressed a need for a respin affecting server?
<cjwatson> I've not seen one yet
<pitti> neither have I
<pitti> Daviey: IOW, with the information currently available, "yes"
<Daviey> groovy, thanks.
<stgraber> what's the ETA for Edubuntu ?
<ogra> all ubuntu armel images look good
<ogra> (minor issues that can be fixed before final)
<ogra> pitti, hmm,. the tracker is weird, it shows "Ubuntu ARM Preinstalled" as well as "Ubuntu Netbook Preinstalled" for armel, i think there is some duplication
<pitti> ogra: right, the ubuntu netbook armel+... should be dropped, right?
<pitti> ogra: at least our publishign scripts expects "ubuntu arm preinstalled"
<ogra> thats weird
<ogra> given we never use the arch name as flavour
<pitti> we can also drop ubuntu ARM preinstalled
<ogra> flavour should be headless or netbook
<pitti> I'm not sure who added it
<ogra> let me see where the mail link gets me
<cjwatson> apparently it needs care to change at the iso.qa side
<pitti> but yes, anything which brings some more consistency into the naming schema is greatly appreciated
<cjwatson> the last time I tried it broke some bit of Tobin's workfloww
<ogra> Ubuntu ARM Preinstalled omap4
<cjwatson> see discussion on this channel before beta-1
<cjwatson> and #ubuntu-testing
<ogra> well, we definitely shouldnt use the arch in the flavour description
<ogra> but "ubuntu arm preinstalled" is what the tracker uses atm
<ogra> shoudl be s/arm/headless/ or s/arm/netbook/ imho
<ogra> anyway, to report my results at the right place i guess i have to use "Ubuntu ARM Preinstalled" atm
<stgraber> pitti: any guess as to when Edubuntu will be done rebuilding ?
<jibel> cjwatson, I updated the tracker last week, and moved the iso path matching logic to the database. Now the names of the products are less tightly linked and we can change them without breaking the paths to the isos.
<jibel> which means no more hardcoded product name in the tracker code.
<stgraber> jibel: yeah !
<cjwatson> aha
<jibel> and that should work for dot releases too
<stgraber> jibel: bug 148944 should have made it easier to watch cdimage and improve the guessing logic. But that's been around for a while and that part of the code was probably the biggest issue of the tracker ;) thnaks for fixing it
<ubot4> Launchpad bug 148944 in ubuntu-cdimage "File list on cdimage for the Ubuntu QA Tracker" [Undecided,Confirmed] https://launchpad.net/bugs/148944
<pitti> stgraber: it should start in about 15 minutes, ETA 1 h
<stgraber> pitti: ok, thanks
<pitti> oh oh, do I smell a rebuild there? ^ ogra
<pitti> jibel: ubuntu dvd posted
<ogra> pitti, nope, only fixes for the bugs i found
<ogra> nothing thats serious
<skaet> morning all,   just went through the backscroll.    Looks like a bit more rebuilding was needed.... but all seems under control now (arm rebuilds being the question).
<ogra> if we get a rebuild i'd love to have them in, but its also fine post beta
<pitti> hey skaet
<skaet> hey pitti,   busy morning for you looks like.
<pitti> ogra: the description fix seems trivial, the sources.list bug a bit harder to fix on upgrade
<pitti> skaet: heh, yes :)
<ogra> pitti, yes, the fixes both need to be in at image build time
<ogra> anyway, all armel images seem good to go as they are atm
<jibel> skaet, there's no ec2 on the tracker?
<skaet> jibel,  haven't heard from smoser about them yet.
<jibel> skaet, k
<skaet> thanks for the reminder - will go ping...
<smoser> well, uec images dont build right now :-(
<smoser> working on that fix
<skaet> smoser,  ok,  good luck.
<pitti> kubuntu DVDs posted
<pitti> Riddell, jibel ^
<Riddell> yay
<ogra_> stgraber, your python-apt fix doesnt seem to work
<stgraber> ogra_: hmm, that seems weird. Worked fine with both commented and non-commented line here. Currently in a meeting, can you pastebin your sources.list before and after your run your script ?
<ogra_> thats a bit tricky since its run in initramfs, but i'll try my best
<ogra_> in any case the python-apt package is the latest and the sources.list looks exactly like what i filed on the bug
<smoser> i need someone from the release team to acl https://launchpad.net/ubuntu/natty/+queue?queue_state=1&queue_text=cloud-init
<pitti> (done FTR)
<stgraber> ogra_: I'm wondering if that may be a ports vs archive kind of issue. I'm updating my pandaboard now so I'll have a good test environment. Should have more this afternoon.
<GrueMaster> In my testing of the source.list, I found that software-properties-gtk seems to work properly as far as commenting or uncommenting the sources.list entries.  There may be something missing in the setup to the function call.
<smoser> ok. build of uec images is now polling, waiting for grub-legacy-ec2 at 0.6.1-0ubuntu7 to get into archive and will build 20110413.1 when it arrives.
<pitti> stgraber: edubuntu DVDs posted
<pitti> http://cdimage.ubuntu.com/edubuntu/dvd/20110413.1/ (still syncing, though)
<pitti> rebuilding mythbuntu now to fix oversizedness
<pitti> then we are done
 * skaet crosses fingers ....;)
<stgraber> ogra_: ok, I reproduced the issue on my pandaboard. Looking at python-apt now to fix it. It's very likely a different issue though giving the same result :(
<stgraber> highvoltage: ^ (in case you missed it, edubuntu is ready for testing)
<stgraber> mvo: so we have another python-apt upload scheduled before final right ?
<stgraber> ogra_: ok, the issue is that python-apt is considering these sources.list entries as invalid or non-official (for some reason), so really a completely different bug
<ogra_> stgraber, weird, since it considers the deb ones valid
<stgraber> ogra_: yeah, I'm currently adding some debug to it so it logs why each line is being skipped
<highvoltage> stgraber: I'm rsyncing those images so long, but I might only be able to test them tonight
<pitti> mythbuntu posted
<pitti> skaet: all images built and posted now, I'm not aware of necessary rebuilds ATM
<skaet> pitti, excellent!  thanks.
<jibel> Woohoo no more rebuilds, thanks!
<jibel> we can start testing then ?
<jibel> j/k
 * pitti hugs jibel
<stgraber> mvo: ping
<stgraber> mvo: I'd need someone who's familiar with python-apt's templates ;) I'm pretty sure that's ogra_'s issue
<stgraber> mvo: if I read the Ubuntu template correctly it says that for != i386 and != amd64, we must use http://ports.ubuntu.com/ubuntu-ports/ to have it marked as an "official" entry in sources.list
<stgraber> mvo: what I can't find is how to update the template to say that it's fine using archive.ubuntu.com on != i386 and != amd64 for deb-src entries
<stgraber> ogra_: ^ that's why I didn't get the issue on amd64 btw
<ogra_> ah
<stgraber> ogra_: if I use "deb-src http://ports.ubuntu.com/ubuntu-ports" instead of archive, then python-apt works properly
<ogra_> well, i didnt add a.u.c there its a default coming from somewhere in the image build process
<stgraber> I'm not sure if we want whatever adds a.u.c to be changed to use p.u.c or if we want python-apt to be modified to accept a.u.c as a valid deb-src source on ports architectures
<ogra_> well, a.u.c is totally valid for sources
<stgraber> ogra_: I closed your old bug report again as that issue is fixed and opened a new one: bug 760035
<ubot4> Launchpad bug 760035 in python-apt (Ubuntu) "Ubuntu.info template doesn't allow deb-src lines using archive.ubuntu.com on ports architectures (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/760035
<stgraber> mvo: ^
<mvo> oh, indeed
<mvo> thanks for this one
<stgraber> mvo: just looking at the template, it's not obvious if there's a non-hackish way of overriding for source entries. I guess "source" could be considered as an architecture but it doesn't look like it's at the moment
<mvo> stgraber: yeah, I think that is a valid approach
<pitti> skaet: do you need me for anything else? if not, I'd toddle off to Taekwondo
<skaet> pitti,  looks like UbuntuStudio is having problems
<skaet> build dependencies,  in discussion on u-testing now
<skaet> s/build/install/
<skaet> sigh
<superm1> i was working with pitti to get amd64 mythbuntu cd's down in size, just committed some seed changes to make the on media pool smaller.  can someone queue a rebuild?
<skaet> pitti,  you want me to?  or will you?  re:  mythbuntu?
<pitti> skaet: if you can?
<skaet> pitti,  sure.
<pitti> superm1: ah, just "ship"? that shouldn't need publisher runs
<pitti> skaet: http://cdimage.ubuntu.com/ubuntustudio/daily/20110413/report.html <- eek
<superm1> pitti, well ship-live, but yeah, i wasn't sure if it needed publisher run or not
<pitti> I bet it's trying to pull in libavcodec
<pitti> superm1: I don't think so, only for live
<skaet> superm1, pitti - have kicked it off,  but if its not needed,  will not post.
<pitti> skaet: these aren't refelected on http://people.canonical.com/~ubuntu-archive/testing/natty_probs.html, so I guess it's due to libavcodec
<pitti> skaet: the rebuild is needed, we just don't need a publisher run after the seed change
<skaet> pitti,  thanks for the explanation.  :)
 * pitti waves good bye then; I'll check in again when I'm back in ~ 3.5 h
<cjwatson> debootstrap upload (appearing shortly) isn't needed for beta-2
 * skaet thanks cjwatson for that qualification ;)
<skaet> ScottL,  around?
<jibel> ScottL, ubuntu-studio is broken, bug 760008
<ubot4> Launchpad bug 760008 in debian-installer (Ubuntu) "amd_64 studio install fails (affects: 1) (heat: 6)" [Undecided,Confirmed] https://launchpad.net/bugs/760008
<jibel> there's a dependency of ubuntustudio-desktop on hal which is not satisfied.
<cjwatson> the libavcodec stuff might go away once the other is fixed ...
<cjwatson> we at least tried to work around that at the seed level
<cjwatson> (ubuntustudio.natty r1254)
<cjwatson> though, hmm, the metapackages don't look right
<cjwatson> I'm going out, will have a look when I get back if nobody else has
<scott-work> hi, project lead for ubuntu studio here
<scott-work> how much more time do we have to test images for beta 2
<scott-work> ?
<charlie-tca> scott-work: <jibel> there's a dependency of ubuntustudio-desktop on hal which is not satisfied.
<stgraber> skaet: ltsp alternate amd64 is broken due to yesterday's fix (and me assuming that chmod -f would always return 0 ...). I don't think we can/want to fix that for beta2. I have a one line fix that I'm going to push upstream now and once again release a new upstream and upload.
<charlie-tca> Trying to get all the tests done today. Beta 2 release is tomorrow
<charlie-tca> scott-work: bug 760008
<ubot4> Launchpad bug 760008 in debian-installer (Ubuntu Natty) (and 1 other project) "amd_64 studio install fails (affects: 1) (heat: 8)" [High,Triaged] https://launchpad.net/bugs/760008
<stgraber> skaet: bug 759965
<ubot4> Launchpad bug 759965 in ltsp "ltsp installation fails on Build LTSP chroot step (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/759965
<stgraber> patrickmw: ^
<skaet> stgraber,  ok,  so I'm clear.  we'll be documenting it, rather than trying for another set of images?
<skaet> or are we going for a fresh set of images?
<stgraber> skaet: I don't know what else you have pending and how critical it's to have LTSP work on amd64 for beta2
<skaet> stgraber,  is it only on amd64?
<stgraber> skaet: yep, i386 is fine
<stgraber> I fixed the bug manually in my VM and am continuing the install with the fix, just to make sure nothing else breaks with LTSP on 64bit. Should have that done in the next 5 minutes or so
<stgraber> if that's fine, I already have a new ltsp release ready to be pushed on my laptop with the one-line fix
<skaet> stgraber,  get the fix ready,  and I'll do some asking.   which amd64 images will need respinning.
<highvoltage> stgraber: is the workaround big? would be nice to have it in the beta2 release notes along with the problem note
<highvoltage> (or at least have it in the bug report it's linked to)
<stgraber> highvoltage: workaround is "wait for it to fail in the installer", chroot to /target, modify /usr/sbin/ltsp-update-kernels, look for chmod line, add || true, restart installer step
<stgraber> highvoltage: that's really quite hackish :)
<stgraber> skaet: AFAIK, only ubuntu alternate amd64 would need respinning. Edubuntu also ships LTSP but shouldn't be affected as we ship i386 LTSP on our amd64 DVD
<skaet> superm1,  jibel  mythbuntu (i386, amd64) posted - 20110413.3
<highvoltage> stgraber: indeed.
<skaet> stgraber,   ok,  will start getting it ubuntu alternate amd64 queued up for when you give the signal.
<stgraber> skaet: ok, my ltsp 64bit install just finished and works fine with my fix. I'll have the new package uploaded in the next 5 minutes
<stgraber> hehe, first time I release a new upstream LTSP with a diff of just one line ;)
<stgraber> well, technically, 6 chars ;)
<stgraber> debdiff for ltsp 5.2.7-0ubuntu1 to 5.2.8-0ubuntu1: http://paste.ubuntu.com/593691/
<stgraber> (it's uploaded)
<scott-work> charlie-tca:   forgive my ignorance, is this just a matter of removing the dependency on hal?
<scott-work> charlie-tca: would we be able to delay the beta 2 release for ubuntu studio ?  i don't think the studio team would mind, but i realize it might make it difficult for others
<mvo> http://people.canonical.com/~mvo/automatic-upgrade-testing/current/ <- woah, mostly green (white), amazing. main-all also has a amazing runtime
<superm1> skaet, yay, finally no longer oversized! :)
<superm1> it's still weird that amd64 is 50mb bigger, but not a big deal anymore
<skaet> superm1,  yay!
<stgraber> pitti, slangasek: Can one of you review that ltsp upload ?
<stgraber> or anyone else who has that power :)
<skaet> stgraber,  am looking for one of the archive admins to see if they can help... pitti and cjwatson are offline right now.
<seb128> skaet, what do you need exactly?
<jdstrand> I am here
<jdstrand> seb128: ^
<seb128> ok, I'm here as well ;-)
<jdstrand> seb128: skaet pinged me privately. I've got it. thanks!
<seb128> ok
<jibel> skaet, ^ scott-work> charlie-tca: would we be able to delay the beta 2 release for ubuntu studio ?  i don't think the studio team would mind, but i realize it might make it difficult for others
<charlie-tca> I misseed that
<charlie-tca> Sorry, must have been fighting with screen-reader then
<charlie-tca> jibel: glad you caught that!
<skaet> jibel,  scott-work,  charlie-tca;  depends on degree of holding up.  We have some flex.
<skaet> but not a lot
<charlie-tca> I seem to be a go-between
<skaet> thanks for flagging jibel,  am bouncing between too many windows today.
<charlie-tca> He asked when the images needed to be tested by. I tried to answer and told him about the bug
<skaet> charlie-tca, what's the outlook on a fix?  and the time for retest?
<charlie-tca> I don t know
<charlie-tca> I think he just has to remove the dependency on hal from the seed, doesn't he?
<charlie-tca> I don't know if anything in -studio actually requires hal, but I don't think so
<highvoltage> stgraber: 84% at 68KB/s, 1:57:14 est.
<charlie-tca> We don't actually have anyone available that can authorize any changes to the image right now.
<scott-work> charlie-tca: sorry, my webchat dropped the connection, if you responded earlier i missed it
<charlie-tca> scott-work: As far as I know, yes, it is simply removing the hal dependency
<charlie-tca> I don't believe you have anything requiring it, do you?
<scott-work> charlie-tca: righty-o, i don't believe so, but i would like to check with luke or persia first to make sure there's nothing i'm missing
<charlie-tca> We were just talking ablut you
<scott-work> charlie-tca: about me?
<stgraber> highvoltage: I started another transfer in the mean time (rsync against ubuntu DVD that I already had around), 37s remaining
<charlie-tca> scott-work: yup
<charlie-tca> scott-work: <skaet> charlie-tca, what's the outlook on a fix?  and the time for retest?
<scott-work> charlie-tca: if luke is amenable we can update the seeds tonight i would expect
<charlie-tca> scott-work: hal was moved from main to universe
<charlie-tca> skaet: ^ ^
<scott-work> but i believe luke is currently asleep, i usually try to catch him aroud five hours from now
<jibel> skaet, smoser what's the news about ec2 ? anything ready for testing or is it still building ?
<skaet> charlie-tca, scott-work,  how long to retest once the images are biuldt.
<jibel> skaet, ~ 40mn for an arch
<skaet> jibel, thanks.
<charlie-tca> fast connections help; mine are about 45 minutes each test
<skaet> jibel, re: smoser should speak for himself, but the impression I've gotten is that the bug fix was found, and they're building.   Should be going up in a few hours, but I haven't seen any further details about an actual ETA.  :(
<smoser> probably 7 hours-ish from 17:55:15 +0000
<smoser> (that was start time)
<smoser> so another 4.5 hours probalby. they're being published.
<jibel> smoser, thanks
<skaet> scott-work,  as soon as you have a fix ready, ping me or pitti (depending on the time ;) ),  and if we can generate images and you can get them tested in time, we'll include them.  Otherwise they'll need to go out after the announce.
<scott-work> skaet: copy that
<stgraber> skaet: any ETA on the alternate rebuild (if we're still rebuilding ubuntu alternate amd64) ?
<skaet> stgraber,  waiting for the publisher to land the updates into the archive,  then willl kick it off.
<stgraber> ok, cool. I probably won't have time to test it before I leave the office but will do so when I get back home (probably 10-11pm EDT). Only takes me ~20 minutes to test LTSP.
<cjwatson> charlie-tca: how about I just do it?
<cjwatson> would that be dreadful?
<charlie-tca> It's up to scott-work, I don't have anything to do with studio
<cjwatson> 'bzr blame' says that that seed entry dates from a 2006 commit by mdz
<cjwatson> which was just comment removal actually
<scott-work> cjwatson: if you want to remove the hal dependency i wouldn't view that as dreadful at all :)
<Daviey> Does anyone here have an VMWare-ESX setup?
<cjwatson> and before that, back to revision 1 when I imported the Ubuntu seeds from the wiki
<cjwatson> so it doesn't look like it was ever explicitly added for ubuntustudio
<cjwatson> scott-work: OK, I'm going to go ahead and seek forgiveness rather than permission then
<charlie-tca> Teach me to answer questions here, huh?
<stgraber> Daviey: that can be arranged. I no longer have access to it but I'm still in a building where we have one ;) (highvoltage has access)
<stgraber> Daviey: VMWare ESXi 4.1 enterprise plus IIRC
<cjwatson> heh
<Daviey> stgraber, Well i wouldn't want to get you in trouble, but would you be able to do the server test case for that?
<stgraber> highvoltage: ^ can you start a server install on verdi ?
<highvoltage> stgraber: maybe mjeanson would do it :)
<highvoltage> well, I wouldn't mind either...
<Daviey> highvoltage, \o/
<Daviey> highvoltage, http://iso.qa.ubuntu.com/qatracker/result/5442/267
<stgraber> highvoltage: rdesktop to cooper.appsrv.sherb.rlnx.com, open VMWare vsphere, connect to verdi.dev.sherb.rlnx.com as root (the vcenter seems to be down)
<stgraber> highvoltage: it's access to the same shared directory as chopin, so you'd just need to wget the image to chopin's shared directory first
<highvoltage> Daviey: 64bit or 32bit?
<Daviey> highvoltage, either|both :)
<Daviey> I'm a bad man, because i care more about amd64.
<highvoltage> I'll start with amd64 then
<cjwatson> so this ubuntustudio-meta change is going to be kind of guesswork; it's hard to test in advance
<cjwatson> I can try
<cjwatson> (and I'm probably best-placed to fix this particular category of bug, in all honesty)
<skaet> cjwatson,  thank you.  (and I agree.... )
<cjwatson> I've removed hal, and rejigged the Task-Seeds fields to match the STRUCTURE inheritance - the ffmpeg-common seed was what was supposed to make all those libavcodec dependencies behave consistently
<cjwatson> regenerating ubuntustudio-meta based on that now
<pitti> charlie-tca, scott-work: why do you think it's the hal dependency?
<pitti> are we talking about the ustudio uninstallability here?
<pitti> http://cdimage.ubuntu.com/ubuntustudio/daily/20110413/report.html doesn't look like it would be due to hal, as that would reflect on http://people.canonical.com/~ubuntu-archive/testing/natty_probs.html as well
<charlie-tca> pitti: yes, since the error was hal unavailabl
<pitti> my first suspicion would be that it's because something tries to pull in libavcodec?
<cjwatson> see above
<cjwatson> I suspect it may well be that and that hal is just a casualty
<pitti> aah
<cjwatson> but if anything in ubuntustudio-desktop needed hal, shouldn't it be an explicit dependency?
<charlie-tca> bug 760008
<ubot4> Launchpad bug 760008 in ubuntustudio-meta (Ubuntu Natty) (and 1 other project) "amd_64 studio install fails (affects: 1) (heat: 8)" [High,Triaged] https://launchpad.net/bugs/760008
<cjwatson> when I went through bzr blame, it looked like it was just left over from ancient Ubuntu seed entries
<pitti> cjwatson: ideally yes; a lot of old packages still just assume that it's there unfortuantely
<cjwatson> oh
<cjwatson> do you think I should put it back then?
<pitti> the ones which could need it would  have a libhal1 dependency, though
<cjwatson> I can check germinate output for that
<pitti> cjwatson: no idea, I'm afraid; I know that e. g. pitivi still can use it for some features, but it's usually not critical
<pitti> a good test is to start the main things in u-studio and then check if "hald" is running
<pitti> as it's triggered via dbus-activation, this should tell whether anything needs it
<cjwatson> is libhal1 a reliable test?
<cjwatson> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntustudio.natty/rdepends/hal/libhal1 says that the only thing pulling it onto images is hal itself
<pitti> cjwatson: positively reliable, but not negatively
<pitti> i. e. you can also talk to hal directly via dbus
<cjwatson> ah
<pitti> (which is usually what python programs do)
<cjwatson> OK, I'll revert that seed change then
<pitti> I certainly hope it's just cruft, but I can't really tell without actually examining the programs
<pitti> my preferred fix for this would certainly be to explicitly add hal dependencies
<pitti> it's not something that should be seeded; but I realize that it's a little late for that in natty
<cjwatson> OK, reverted with a mini-essay in the commit log
<cjwatson> and generating ubuntustudio-meta again
<stgraber> pitti: "grep -r hal /" then filter out the false positives :)
<pitti> stgraber: and org.freedesktop.Hal
<pitti> stgraber: actually, that or a dependency to libhal1 should be quite sufficient
<pitti> programs either use libhal1 or open a d-bus connection to org.fd.Hal
 * pitti wonders how often we need to stab this beast before it's dead for good
 * skaet keeps looking to see if ltsp_5.2.8 has landed.... grrr not there yet.
 * charlie-tca tried to kill it again
<stgraber> pitti: on my laptop (so, mostly standard ubuntu), I get: libnet-dbus-perl, pitivi, pm-utils, python-apport, checkbox, gnome-power-manager and virt-manager
<Riddell> skaet: it presumably won't get in until this publisher run has finished
<stgraber> pitti: I can easily run the same check on studio to check the difference if that helps
<skaet> RIddell, yup, waiting for the publisher run started over an hour ago to finish....
<pitti> stgraber: e. g. pm-utils has a fallback if /sys doesn't work (mostly for BSD right now)
<pitti> stgraber: python-apport?!?
<pitti> stgraber: ah, haha! it's an example stack trace in the test cases :)
<pitti> guess when I wrote that code..
<pitti> stgraber: I'm just afraid I can't modernize that, because of course udev, udisks, upower etc. never crash!
<pitti> *cough*
<stgraber> pitti: yeah right :)
<pitti> stgraber: but anyway, I doubt that merely having hal installed causes any problems; it won't even start by default
<pitti> I don't think we should rip it out that lalte
<pitti> "late"
<stgraber> yeah, that's the kind of things you usually want done before Feature Freeze, so you have enough time to find and fix whatever breaks
<pitti> cjwatson: just to ensure that I understand http://launchpadlibrarian.net/69309093/ubuntustudio-meta_0.83_source.changes, will that install alternative dependencies which lead to not pulling in libavcodec?
<scott-work> pitti: blender was uninstallable i believe due to libavcodec
<skaet> pitti, cjwatson, stgraber - ARCHES='amd64' for-project ubuntu cron.daily kicked off
<ScottK> pitti: Not that it's relevant for Ubuntu Studio, but we do have a problem in KDE where if hal is present, KDE solid will start it and use a mixture of data from it and upower with unfortunate results.  So there are cases where installing it can cause problems.
<cjwatson> pitti: so libavcodec is odd
<cjwatson> (and friends)
<cjwatson> pitti: there are a bunch of libfooN, and then a bunch of libfoo-extra-N
<cjwatson> pitti: they conflict - you have to consistently select one set or the other
<cjwatson> pitti: normally, we use libfooN; but a few things in ubuntustudio need libfoo-extra-N, so ubuntustudio needs to consistently select that throughout
<pitti> and libavcodec-extra-52 is sufficiently patent-free to allow it on media?
<cjwatson> pitti: convincing the package management toolchain to do that is most easily done by seeding the lot further down
<pitti> or do we basically ignore the libavcodec patent issue on u-studio?
<cjwatson> I *think* the latter
<pitti> it makes sense as we don't press CDs for that, anyway
<cjwatson> because we've shipped libavcodec52 before, and we avoid even that for Ubuntu
<pitti> cjwatson: thanks for the heads-up
<pitti> I'd like to accept shared-mime-info and xdg-utils (translation updates only), objections?
<pitti> erm, xdg-user-dirs
<pitti> mostly as an opportunistic improvements for any rebuild we might need to maek
<cjwatson> I don't mind
<pitti> cjwatson: what is lxc? do we need the debootstrap upload for b2 for anything?
<cjwatson> 18:50 <cjwatson> debootstrap upload (appearing shortly) isn't needed for beta-2
<pitti> thansk
<skaet> jibel, stgraber,  ubuntu alternate amd64 posted  (ltsp fix)
<cjwatson> lxc => containers.  the bug in question has been worked around in lxc already, but fixing it properly in debootstrap is IMO the right thing to do
<scott-work> pitti, cjwatson, charlie-tca, skaet :  i am going home, if you need me for any ubuntu studio issues you can reach me at ScottL in about 30 minutes
<cjwatson> scott-work: ok, it'll need retesting after metapackage lands and CDs rebuild
<scott-work> cjwatson: aye
<highvoltage> Daviey: this is just creepy :) http://irc.jonathancarter.org/files/dump/esxi-aubergine.png
<cjwatson> off for a bit
<Daviey> highvoltage, Sorry, i don't follow.
<highvoltage> Daviey: it failed :( ubuntu-standard is installed and the virtual kernel not, I'm *quite* sure I chose install minimal server from gfxboot, but I'll double-check now just to be sure
<Daviey> highvoltage, oh dear... thanks.
<stgraber> skaet: downloading
<highvoltage> Daviey: an aubergine debian-installer with a windows task bar? maybe it's just me then
<Daviey> highvoltage, OIC :)
<highvoltage> this time d-i seems to get confused when I enter my password
<highvoltage> I get a blue screen then a red screen telling me my password is blank and when I press enter it doesn't give me a chance to go back
<highvoltage> (eventually it worked, weird)
<Daviey> highvoltage, yeah, i noticed on error it seems to present traditional blue.
<Daviey> I'm not sure we need to fiddle with the colours anymore this cycle :)
<pitti> skaet: want me to set up a triggered rebuild for ubuntustudio, or want to kick it off yourself?
<pitti> bbiab
<skaet> pitti,  i'm fine with kicking it off, once things are ready.   What should I be triggering on?
 * skaet likes to be able to see directly when its done.... ;)
<highvoltage> Daviey: this time it did ok, but it's oversized (>500M)
<Daviey> highvoltage, yeah... someone else found that on KVM... technically it's failed the test case - can you mark it so?
<Daviey> I think we are OK with it (i think maverick released with the same)
<Daviey> highvoltage, really appreciate your help with this.
<Daviey> highvoltage, RoAkSoAx is raising a bug for it as we speak.
<highvoltage> Daviey: I just finished filing a bug for it
<highvoltage> https://bugs.launchpad.net/ubuntu/+bug/760288
<ubot4> Launchpad bug 760288 in ubuntu "JeOS is oversized (affects: 1) (heat: 6)" [Undecided,New]
<Daviey> highvoltage, ah perfect, thanks
<pitti> skaet: when ubuntustudio-meta 0.83 binaries are available on antimony, i. e. wait-for-package ubuntustudio-desktop_0.83
<skaet> pitti,  yup that's what I was looking to know.:)
<pitti> skaet: cool; then I think I'll head bedwards :)
<pitti> skaet: btw, on TechOverview do you actually like the sections which just say "Shotwell has been updated to 0.9.1."?
<pitti> TBH I think we should remove them; version numbers aren't very interesting IMHO
<skaet> pitti, well some folks care about versions (kernel folk for instance ;) )
<Daviey> skaet, When do you need TechOverview done by?
<skaet> pitti,  I'll get the known bugs put into the tech overview tonight,  and if you could take a pass in the morning to sanity (delete the uninteresting ones) that would be great.
<skaet> Daviey,  EOD today...
<pitti> skaet: sounds great
<pitti> beta-2 will be a nice bday present tomorrow \o/
<Daviey> skaet, great... now - 5 hours. ;)
<pitti> so, good night everyone!
<skaet> Daviey,  today being 3/13.
<skaet> Daviey,  yup.
<skaet> sleep well pitti
<Daviey> jolly good.
#ubuntu-release 2011-04-14
<slangasek> cjwatson: mea culpa; I'm finishing up the rebuild check of packages broken by the linux-libc-dev change, and found one that's still outstanding after the biarch fix - rootskel ftbfs because klcc isn't patched for the include path.  I'll prep a klibc upload today.
<cjwatson> ah, I thought we'd done that one
<cjwatson> no worries, as long as it's fixed for final
<stgraber> skaet: can you publish the new amd64 alternate for mac as well ? the current one had 0 testers, so it won't hurt putting the new one on the tracker and the LTSP bug also affects the mac variant
<stgraber> skaet: I won't be able to test it though
<slangasek> cjwatson: I fixed the ftbfs in klibc itself... didn't remember klibc had its own cc
<ScottK> Is the publisher on manual?
<ScottK> https://launchpad.net/ubuntu/+source/kde4libs/4:4.5.5-0ubuntu2/+buildjob/2444873 didn't get published like I was expecting.
<cjwatson> slangasek: ah, doh, right
<ScottK> Actually I wonder if the web U/I has lost it's connection to soyuz?  Both of the current powerpc buils are shown in the web U/I as still unpacking packages after half an hour.
<ScottK> That seems unlikely.
<Ampelbein> ScottK: there are some networking issues with LP currentl
<ScottK> Ampelbein: Thanks. I just saw on #ubuntu-devel.
<skaet> stgraber,  will look into amd64+mac tonight after dinner.
<stgraber> skaet: ok
 * skaet -> dinner,  biab
<stgraber> skaet: we seem to have a big problem with edubuntu 32bit
<stgraber> skaet: running a dist-uprade in the live environment shows 963 pending updates
<stgraber> skaet: so our 32bit live environment is completely out of date
<stgraber> cjwatson: ^
<cjwatson> what do the logs look like?
<stgraber> looking at the livefs build logs now
<stgraber> yeah, 32bit livefs failed to build ...
<stgraber> doh, it's been building with ltsp 5.2.7, not 5.2.8
<cjwatson> 5.2.8 was a recent upload - is that just a matter of kicking off an Edubuntu image rebuild?
 * stgraber thinks
<stgraber> 5.2.8 fixes an amd64 issue so it shouldn't break the build of edubuntu 32bit
<cjwatson> amd64 seems to have already built successfully
<stgraber> but it fails at exactly the same place as the 64bit issue I fixed earlier
<cjwatson> does it need to be rebuilt for this?
<stgraber> yeah, amd64 doesn't have ltsp
<cjwatson> (http://people.canonical.com/~ubuntu-archive/livefs-build-logs/natty/edubuntu-dvd/latest/livecd-20110413.1-amd64.out)
<stgraber> it just gets the most recent ltsp chroot generate at the end of the i386 build
<cjwatson> ok, so we could (if you think it's needed) rebuild just i386
<stgraber> we'd need to rebuild both if we want the ltsp chroot to be the same on both builds
<stgraber> basically i386 builds the livefs, then the ltsp chroot
<stgraber> amd64 builds the livefs and then includes the i386 chroot built a bit earlier
<stgraber> so a rebuild of Edubuntu i386 and amd64 "should" fix the issue
<cjwatson> skaet: were you going to build ubuntustudio?  I don't see any wait-for-package processes on antimony
<cjwatson> oh, she's off to dinner
<cjwatson> I'll do it then
<stgraber> if we can start one now, it should finish soon enough that I can still test both before going to bed
<cjwatson> stgraber: ok - Ubuntu Studio is first in line, but I'll do Edubuntu right afterwards
<stgraber> ok, I'll be watching the livefs build logs to make sure we don't have it happening again ...
<stgraber> shouldn't I receive an e-mail when a livefs fails to build or is that only for cd build failures ?
<cjwatson> you should already.  I'm surprised you didn't
<cjwatson> IIRC I saw it by mail and assumed you would also have seen it
<stgraber> it's been a while I haven't received any e-mail for livefs/dvd build failures
<cjwatson> ah, I think it's because it's set to the edubuntu-dvd project
<cjwatson> and notify-addresses only knows about edubuntu
<cjwatson> fixed, I think
<stgraber> ok, let's hope we won't have a chance to test it with the next build :)
<cjwatson> (should also fix kubuntu-dvd notifications)
<stgraber> ok, I marked them as being rebuilt on the tracker
<cjwatson> bunch of uninstallables in the new ubuntustudio images, so specifically *not* posting them yet
<cjwatson> skaet: ^-
<cjwatson> wonder what I broke
<GrueMaster> Kubuntu Mobile armel+omap3 is a fail.  The image is supposed tohave two partitions - boot & rootfs.  It only has the rootfs.  I am grafting it on to a headless image, but I need to mark it as a fail.
<cjwatson> oh, bah, ubuntustudio didn't build due to LP breakage
<GrueMaster> Looks like Kubuntu Mobile armel+omap4 is a failure also.
<smoser> http://uec-images.ubuntu.com/server/natty/20110413.1/ is available now (ec2 images) someone could populate the tracker maybe ?
<smoser> skaet, ?
<smoser> cjwatson,
<cjwatson> sure
<cjwatson> smoser: done
<Daviey> skaet, ec2 testing is currently blocked, but should be started in ~6 hours from now.
 * Daviey goes to bed. nn all. o/
<highvoltage> night Daviey
<cjwatson> Edubuntu DVD builds broke for the same reason as Ubuntu Studio - LP networking problems
<cjwatson> but the livefs builds worked, and those are the long bits, so that doesn't need to be redone
<stgraber> cjwatson: e-mails work properly btw :)
<stgraber> cjwatson: ah, good to know i386 livefs succeeded, I'm still waiting for the remaining part of the log to appear on people.c.c
<skaet> cjwatson, hmm.. just checked.  and yeah don't see them updated.
<skaet> should I just restart the ubuntu studio off?
 * skaet goes through the backscroll.... :P
<cjwatson> no, no point
<cjwatson> waiting to hear that LP networking's been fixed
<cjwatson> http://identi.ca/launchpadstatus
<cjwatson> hm, seems to indicate it should be better
<skaet> hmm, try and see?
<cjwatson> I'm checking other things first
<skaet> ok,  will wait for your signal.
<cjwatson> it does look a bit happier.  I'll retry
<skaet> cjwatson,  cool.
<cjwatson> not happy enough.
<cjwatson> I'd suggest leaving it until the outage notice disappears from the #is topic
<skaet> hmm... yeah just got the email.
<cjwatson> can you take over builds then?
<skaet> cjwatson,  yeah  I'll check back periodically through the evening til I go to bed.
<skaet> #is has agreed to post here when the dead hardware switch has been replaced
<skaet> images to be built are:  ubuntu-studio,  edubuntu,  and ??
<cjwatson> that's all, AFAIK
<cjwatson> for-project ubuntustudio cron.daily; for-project edubuntu cron.dvd
<cjwatson> don't run buildlive
 * skaet nods
<skaet> will do, when I get the signal the builds are working again.
<skaet> sleep well.   talk to you on the flip side.
<stgraber> skaet: any news on the rebuilds ?
<ScottK> stgraber: I think still waiting to hear the networking issues are resolved and things can be tried again.
<skaet> stgraber,  checked an 30 minutes ago, and hardware switch being worked on,  no ETA yet.
<skaet> stgraber,  charlieS agreed to post here when issue is resolved.
<stgraber> skaet: what time are you planning to release beta2 ? (won't be staying online much longer and I'd really like to have a working beta2 for Edubuntu)
<skaet> stgraber, understand.   Its looking like afternoon in US at this point, but there are some other web publishing issues that may play into it.
<skaet> I suggest going to bed now,  and checking early if pitti/cjwatson was able to get a build made,  I'll be calling it a night soon myself.
<stgraber> skaet: ok. My guess is that from the time Edubuntu appears on cdimage to the point where I have both of them tested, I need around 3-4 hours (40mins per install + rsync time)
 * skaet nods.  good to know.   
<stgraber> ok, I'll try to wakeup early tomorrow to start rsyncing the new images so I have them downloaded when I get to the office, then I should be able to have them tested before lunch time.
<stgraber> good night everyone
<skaet> cjwatson, pitti, all,   still no ETA on the broken switch being fixed.   Will leave it to you to kick off the edubuntu/ubuntu-studio builds as soon as its back to working.
 * skaet --> zzz
<GrueMaster> Well, that would explain why I can't file a bug.
<cinerama> hi guys, the cdimage mirrors boxes are getting a bit tight on disk space -- can something be cleaned up there?
<pitti> Good morning
<pitti> meh, what's up with bzr?
<pitti> cinerama: will have a look
<cinerama> pitti: thanks!
<pitti> the ubuntustudio images failed to build with some weird bzr errors, and my cron jobs failed the same way
<pitti> ah, saw scrollback
<pitti> bzr at least works locally, and identica says it should be back up, trying a studio build now
<pitti> meh, not back enough
<pitti> cinerama: I cleaned up a bit, but as always this will only be temporary
<cinerama> pitti: understood.  thanks for having a look at it
<mvo> pitti: just to confirm, today is the day where we won't move packages between main and universe anymore, right? just asking for the command-not-found data extraction (that contains the component)
<pitti> mvo: ideally yes
<pitti> mvo: but http://people.canonical.com/~ubuntu-archive/component-mismatches.txt still has some new issues
 * mvo looks
<pitti> lxc is from just a day or two before, and openjade1.3 popped up a while ago
<mvo> ok, so I better wait a additional day or so, the list is really small
<pitti> mvo: I did some cleanup now, and asked in #u-devel about lxc, so it should get smaller soon
<mvo> thanks!
<pitti> ??
<pitti> seems this is fallout from the LP outage, https://launchpad.net/ubuntu/natty/+queue?queue_state=1 is fine
<pitti> skaet: I updated https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview and corrected/streamlined it a bit
<pitti> YAY!
<pitti> http://cdimage.ubuntu.com/ubuntustudio/daily/20110414.3/
<pitti> it built, and http://cdimage.ubuntu.com/ubuntustudio/daily/20110414.3/report.html is empty
<pitti> running for-project edubuntu cron.dvd now
<pitti> who tests ubuntustudio usually?
<jibel> pitti, I'll do
<pitti> great
<jibel> I'll start i386 in ~27 seconds
<kamstrup> Can I get some feedback on https://bugs.launchpad.net/ubuntu-translations/+bug/754424 as we need to get translators churning asap if we want it in
<ubot4> Launchpad bug 754424 in unity-place-applications (Ubuntu) (and 5 other projects) "Dash: only returns first 5â6 "available to download" results; misleading because many more are in the Software Centre (affects: 2) (heat: 16)" [Undecided,In progress]
<elmo> hi, LP should be recovered
<elmo> skaet: cjwatson pitti ^--
<elmo> and most of the other stuff that was affected by the network clusterfuck
<pitti> thanks elmo
<pitti> elmo: indeed, my most recent image builds succeeded \o/
<pitti> right in time for today's beta :)
<pitti> ScottL, stgraber: http://cdimage.ubuntu.com/edubuntu/dvd/20110414.2/
<jibel> pitti, default installation of ubuntustudio succeeded on i386 and amd64. I'm now trying with all softwares selected.
<pitti> yay
<pitti> I'll start pre-publishing now, so that this has time to mirror
<pitti> (that doesn't affect studio/edubuntu etc.)
<pitti> ScottL, stgraber: they both have ltsp 5.2.8, so are current
<bdrung> can anyone look at the FFe request for audacity (bug #759314)?
<ubot4> Launchpad bug 759314 in audacity (Ubuntu) "[FFe] Merge audacity 1.3.13-1 (universe) from Debian unstable (main) (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/759314
<bdrung> pitti: ^
<pitti> https://launchpadlibrarian.net/69181174/upstream-changes has string changes, UI changes, lots of changes in general, so it's not the thing I can sign off lightheartedly
<pitti> this woudl then at least need some thorough testing (also upgrades), etc.
<bdrung> pitti: should i upload it to my ppa for easier testing?
<pitti> bdrung: if you have some people who want to test it, that sounds good
<pitti> cjwatson: do we need a cron job for building source CDs?
<bdrung> pitti: i haven't someone (just me)
<pitti> what amount of testing did you give it on current natty?
<cjwatson> pitti: cron.source, it's just not in the crontab - kicked off by hand
<cjwatson> (running)
<pitti> ah, thanks
<bdrung> pitti: launching, ffmpeg/lame import/export, project editing with labels, multiple export, playback, various effects
<pitti> ah, GrueMaster is testing kubuntu-mobile armel? nice
<pitti> I'm off for lunch and some errands, back in an hour; if something bad happens, please call my mobile
<stgraber> pitti: thanks, downloading
<ScottL> pitti, actually i'm ubuntu studio, not edubuntu ;)
<ScottL> thanks for starting the testing jibel for ubuntu studio :)
<jibel> ScottL, you're welcome. I've tested a default installation, and with all the software selected, and various partition schemes. it's ok. You should probably do deeper testing of studio itself.
<ScottL> we shall, jibel, thanks again :)
<pitti> ScottL: whoops, sorry :)
<ScottL> pitti, np :)
 * pitti rubs his hands -- http://people.canonical.com/~ubuntu-archive/component-mismatches.txt and http://people.canonical.com/~ubuntu-archive/nbs.html done
<pitti> opensp b-deps on openjade1.3 | openjade, the latter of which is in main, so all fine
<jussi> Good afternoon wonderful release peoples
<pitti> GrueMaster: how is kubuntu mobile armel going? should we publish this?
<pitti> hey jussi
<jussi> Im wanting to follow up on the possibility of bug 760456
<ubot4> Launchpad bug 760456 in ubuntu "Freeze exception for sync of a new package from debian (Openerp-web) (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/760456
<pitti> jussi: this seems low barrier indeed; however, this should at least get a test whether the current debian version builds on current natty
<jussi> pitti: sure, how do we test that ?
<pitti> jussi: download the source from Debian (pull-debian-source from ubuntu-dev-scripts), build it (will probably need some build deps which it will point out), install the .debs, and give them a quick test
<jussi> pitti: right, Ill either do it myself or try find someone who can. thank you for the info. if that is successful, what do I need ot do then?
<pitti> jussi: just confirm on the bug
<jussi> ok :)
<pitti> the rest will be done by RM/archive admins
<jussi> excellent, thanks you.
<jussi> pitti: should we be taking it from unstable or testing?
<jussi> (its pretty much the same afaik)
<pitti> jussi: unstable is fine
<pitti> unless there is a specific reason to take the testing one, if sid's got broken recently, or requires dependencies that aren't in natty, etc.
<jussi> pitti: shadeslayer has been a superstar and built the package now, it built fine, log is on the bug. (thanks shadeslayer)
<shadeslayer> it was nothing ... *blush*
<pitti> great!
<jussi> pitti: Ive just tested the package and it works fine :)
<jussi> double checks ftw :)
<GrueMaster> pitti: kubuntu-mobile armel is not ready for publishing in my opinion.  It is not bootable as it sits.  I did manage to get it booting, but I had to graft it onto an SD card with kubuntu-desktop already flashed, then make several hacks on top of that.
<ScottK> "Tech preview"
<pitti> ok, so I'll leave it out from beta-2
<GrueMaster> I don't know really how to mark it as fail, as it is mainly an image build issue.
<pitti> and we just keep them as dailies?
<GrueMaster> Sounds reasonable.
<pitti> cjwatson: what's the trick to produce netboot/natty/beta-2 ?
<cjwatson> manual - I can do it
<pitti> thanks
<cjwatson> on cocoplum, it's just manual copying *while* the publisher isn't running
<cjwatson> er, wrong emphasis there but you get the idea
<pitti> right
<cjwatson> on antimony, it's manual page editing
<cjwatson> I never bothered scripting it because so much of it was irregular and it wasn't very hard anyway
<cjwatson> what's the timing like?  I'd like to go out nowish to sort out a problem with my car
<cjwatson> (plus it's lunchtime in whatever odd personal timezone I've ended up in)
<pitti> cjwatson: I have all images prepared on antimony, currently archiving the beta-1 images to old-images/
<pitti> I'd like to do the sync soon, since it takes ages wit so many dvds
<pitti> cjwatson: but we can do the netboot thing afterwards, and sync again
<pitti> so no hurry
 * pitti puts it on the list
<stgraber> the edubuntu-live upload above is quite critical for Edubuntu so we'd appreciate it if it can go through as soon as beta2 is released so we can get it on the first daily build for testing
<pitti> stgraber: I'm happy to review/accept it now
<stgraber> pitti: would be great, thanks
<cjwatson> well, I could cheat on cocoplum
<pitti> cjwatson: it's not critical path, so please have lunch first
<cjwatson> as long as there's adequate time, I can edit stuff in the temporary dists tree
<skaet> good morning all
<pitti> hey skaet
<skaet> heya pitti,  glad to wake up and see life is sane again ;)
<cjwatson> oh, in fact the publisher's nearly done anyway ...
<skaet> s/life/network/
<skaet> :)
<pitti> skaet: heh, yeah; took some more attempts this morning, but it's all good; ubuntustudio and edubuntu images are up and look good in testing
<skaet> thanks pitti,  :)
 * skaet will go off and have a good look at qa tester, and see if there are any new gems waiting...
<pitti> skaet: I had a good editing session on TechOverview as well
<skaet> pitti:  excellent!
<pitti> cjwatson: .manifest now only has natty beta-2 (and of course lucid/maverick/etc.), that's right?
<cjwatson> yep
<cjwatson> in fact, you'll want to move that to .manifest.full and trim out everything but natty from .manifest, for quicker mirror probing
<pitti> ack
<pitti> so that won't cause the mirrors to drop maverick etc.?
<cjwatson> as in BetaProcess
<cjwatson> no
<stgraber> skaet: rsync is really slow today, still waiting for edubuntu i386 to download here ...
<cjwatson> it just changes what the prober reports
<pitti> done (also HEADER etc. mangling)
<pitti> skaet: when do you plan to release?
<skaet> stgraber,  ok.
<pitti> skaet: I need an hour or two leeway to get the images published to cdimage.u.c.
<pitti> skaet: can I start doing that?
<skaet> pitti,  need to get together with the web team and see what the world looks like from their perspective.
<cjwatson> beta-2 netboot stuff in place now
<pitti> skaet: ok; I have everything staged up, now just need to push the sync button
<pitti> cjwatson: thanks, crossing from list then
<cjwatson> (links on archive.u.c should be valid shortly)
<skaet> before publishing to cdimage,  want to talk to the jibel and the other leads, and makes sure the images are good.
<skaet> will get back to you in half an hour.
<pitti> skaet: ack, thanks
<cjwatson> out for a bit, then
<ogra_> cant we drop the second -headless- from the name ?
<ogra_> it looks so ugly
<ogra_> or the first one ... no matter which, but twice seems odd
<ogra_> (since they are published manually anyway)
<ScottK> pitti: One of the fixes in kdebase-workspace for maverick-proposed missed a spot.  Fix is in the queue.  Also it turns out we need to rebuild on of the third party widgets.   That's also inqueue.  I'd appreciate it if you would accept them.
<skaet> pitti,  was talking with jibel, and I think there are too many problems with the powerpc images at this point, and not enough testing on them, so please pull them from release.
<skaet> I'm waiting to get the results in for the server images, and make sure the amd64+mac ones are sane.
<skaet> Looks like the flavor images are good,  but want to give edubuntu/ubuntu-studio a bit more time to shake them a bit.
<skaet> stgraber, ScottL,  ^^
<skaet> scott-work, ^^
<pitti> skaet: all the powerpc images? or just the u or k ones?
<scott-work> skaet: yes, i just mentioned about twenty minutes ago on #ubuntustudio-devel that i would like to test these images till even though jibel has as well
<scott-work> s/till/still
<stgraber> skaet: I should have all of Edubuntu tested within the next 15-20 minutes (last image is currently installing)
<pitti> skaet: ah, no powerpc images for beta-2 right now anyway (we don't routinely publish them anyway it seems)
<pitti> skaet: amd64+mac isn't currently part of the release either
<pitti> skaet: if we want to release them, we can, but I'd really like to start syncing out the others, as the DVDs take ages
<ScottK> I thought we published them when tested and working.
<ScottK> That just doesn't happen very often.
<skaet> :/
<stgraber> skaet: Edubuntu is fine, both images fully tested now
<skaet> stgraber,  sweet.  :)
<c10ud> hello, i have a question: there's python-papyon (it should be in main, used by empathy and emesene (universe)) that currently had important fixes. is there a deadline to propose a ffe? current version is 0.5.4, next version is still unreleased, we're testing hard the changes along with the admins. next will be 0.5.5, less than 10 very tiny diffs from 0.5.4 and they're all bugfix. i'm not really into the ubuntu/debian process but does that mean th
<c10ud> e package cannot be updated anymore?
<ScottK> If it's just bug fixes and the diffs are small enough to be reviewable it might still get in.
<skaet> c10ud,  if its purely for bug fixes (as your post indicates),  go ahead and propose the ffe,  we'll look at scope of impact and make a decision.
<skaet> :)
<c10ud> great, now my only problem is to a) make the mantainer release the updated package b) get a debian developer to package it because the current mantainer is facing a longstanding illness
<c10ud> supposing i want to wait till the last available day, which day would it be for main? and for universe?
<charlie-tca> skaet: workaround for Xubuntu pulling in all of gnome is install xfce4-indicator-plugin before upgrading
<charlie-tca> I just ran a Xubuntu 10.10 to natty upgrade and did not pull gnome in
<pitti> skaet: sorry, got disconnected for a bit, I might have lost some messages
<pitti> skaet: last I got from you is 17:37:48       skaet | stgraber,  sweet.  :)
<seb128> pitti, nothing addressed to you since that
<skaet> pitti,  that's the last I've posted.
<charlie-tca> skaet: release notes checked
<skaet> thanks charlie-tca :)
<ScottK> pitti: Did you get my message about updated sru candidates for Maverick?
<pitti> seb128, skaet: thanks
<pitti> ScottK: yep, got it; will do now
<ScottK> pitti: Thanks.
<ScottK> skaet: Are you OK if we go ahead and start to review/accept stuff from the queue (i.e. confident no more respins are needed)?
<skaet> ScottK,  yup.   Images we have now,  are the ones we're going with.
<skaet> lets start to get the queues going again.
<ScottK> Thanks.
<Riddell> I'm going out for a few hours, ScottK if the release happens you might want to find someone to put it onto kubuntu.org
<ScottK> OK.
<ScottK> No ryankca either.
<ScottK> Oh, not here.
<pitti> oh? ^
<pitti> well, I guess the images are pretty much done now, so we can probably flush, but we haven't gotten the official go yet
<cjwatson> 17:38 <skaet> ScottK,  yup.   Images we have now,  are the ones we're going with.
<cjwatson> 17:38 <skaet> lets start to get the queues going again.
<cjwatson> doesn't count?
 * ScottK thought it did.
<pitti> ah
<pitti> cjwatson: that was exactly in the window of my DSL reconnect, sorry
<pitti> uh, that was before, seems I reconnected again, wth
<pitti> thanks
<pitti> skaet: starting the cdimage mirroring then
<pitti> skaet: do we want to publish amd64+mac?
<pitti> (it's not currently, but I can add them)
<skaet> pitti,  still waiting for the input on it.
<skaet> pitti,  still waiting for input on uec as well.
<skaet> pitti,  can you cross check against my email?
<pitti> skaet: that looked fine to me
<skaet> ok,  lets get the publishing for all except amd64+mac, and uec started.    As info comes in, we'll decide
<pitti> ack
 * cjwatson fixes bug 760089, for the non-Ubuntu folks
<ubot4> Launchpad bug 760089 in debian-installer (Ubuntu Natty) (and 2 other projects) "background color of d-i is purple on the kubuntu alternate images (affects: 1) (heat: 8)" [Medium,Invalid] https://launchpad.net/bugs/760089
 * charlie-tca thanks cjwatson for that fix
<GrueMaster> cjwatson: Will this also fix the ubuntu-headless image?  Bug 747229.
<ubot4> Launchpad bug 747229 in ubiquity (Ubuntu Natty) (and 1 other project) "weird color change during oem-config debconf package removal step in serial installs (affects: 1) (heat: 8)" [Medium,New] https://launchpad.net/bugs/747229
<cjwatson> GrueMaster: doesn't seem obviously related, no
<GrueMaster> Thought it might, as we still use d-i through oem-config-debconf.
<cjwatson> right, but it's not what I fixed.
<cjwatson> besides, you're an Ubuntu flavour, so no change ...
<GrueMaster> Well, what we have now is fugly and hard on the eyes.  https://launchpadlibrarian.net/67888128/package-removal.png
<GrueMaster> But I guess ogra will find a fix.
<skaet> pitti,  +1 on the uec,  testing's been done per Daviey,  we just need to get the iso tracker in synch with what actually happened.
<pitti> cool
<cjwatson> GrueMaster: no dispute that it's ugly, but I doubt I can fix it
<cjwatson> (time-wise)
<pitti> skaet: so smoser should publish them?
<cjwatson> somebody on the ARM team needs to address that
<smoser> make things public, right?
<skaet> smoser,  can you confirm you're publishing them and ec2.
<skaet> yup
<smoser> k
<smoser> process started.
<skaet> :)
 * skaet now heads off to lurk on u-testing and see if chad's got some data on amd64+mac.
<stgraber> cjwatson, pitti: Will Edubuntu get a daily build tonight ? (I want to have bug 760673 tested ASAP)
<ubot4> Launchpad bug 760673 in edubuntu-live (Ubuntu Natty) (and 1 other project) "Edubuntu's casper-bottom script uses wrong path and gets run at image build time (affects: 1) (heat: 8)" [Critical,Fix released] https://launchpad.net/bugs/760673
<pitti> stgraber: can do
<stgraber> pitti: would be appreciated, thanks
<pitti> cron jobs back on
<pitti> slangasek: do you want to review u-boot-linaro?
<slangasek> pitti: I uploaded it, so probably not :)
<pitti> ah, ok
<smoser> http://uec-images.ubuntu.com/releases/11.04/beta-2/ is alive now.
<pitti> skaet: did you already ask IS for the mirror prober, or want me to?
<skaet> pitti,  please ask.  I haven't yet
 * skaet still scrubbing announce material to prep for web team
<pitti> ack
<skaet> stgraber:  what's the path you want used for edubeta this time around?  http://edubuntu.org/2011-04-14/edubuntu-1104-beta-2-released
 * skaet just finished cleaning up the kubuntu one...
<skaet> s/edubeta/ edubuntu beta/ ... sigh.
<skaet> or should I just leave it as a generic reference to the edubuntu site?
<stgraber> skaet: we'll have a blog entry at http://www.edubuntu.org/2011-04-14/edubuntu-1104-beta-2-released (just created a blank one now) but it's going to contain almost the same thing as the announcement. So you can just link to http://www.edubuntu.org
<skaet> cool.  done.
<stgraber> thanks
<skaet> pitti,  http://releases.ubuntu.com/natty/  doesn't seem to have i386 image for alternate install CD
<skaet> can you check it out?
<pitti> skaet: will do (on the phone right now)
<skaet> thanks!
<pitti> ah, I know; i386 and amd64 have two different version numbers
<pitti> at least the tracker says so
 * skaet nods
<skaet> we had to spin amd64 to pick up the ltsp change
<pitti> missing i386 alternate added, syncing out now
<pitti> skaet: ah, fortunately the actual .iso got synced already, it was just the .html stuff missing
<pitti> so that's quick
<skaet> :)
<skaet> good oh.
<pitti> hm, or maybe not; it was missing from the manifest
<pitti> skaet: so, let's give them another hour or so to catch up, and then ask #is to run the mirror prober again?
<skaet> sounds good.
<skaet> pitti,  please add ubuntu alternate/desktop amd64+mac,  and kubuntu alternate/desktop amd64+mac.   Testers are comforatable they'll be usable.
<ScottK> ^^^ opendkim is my upload, so I'd appreciate someone else accepting it.
<slangasek> ScottK: I'll trade you opendkim for klibc :)
<ScottK> Not fair.
<ScottK> I'll look, but no promised I'm comfortable having an opinion on it.
<ScottK> promised/promises
<slangasek> it's a small patch, fixes the rootskell ftbfs... if you don't mind reviewing perl
<ScottK> I do, but I'll look anyway.
<ScottK> Feel free to say "Universe isn't frozen yet, accept" on mine.
<ScottK> klibc was fine.
<slangasek> ah, it even said it was universe, didn't it? Ok, accepting
<ScottK> And I said it was bugfix only right in debian/changelog .....
<ScottK> So what can go wrong?
<slangasek> ;)
<highvoltage> have /win 2
<Riddell> evening, what did I miss?
<ScottK> Archive is open again for accepting stuff after review.
<ScottK> No release announcement yet.
<micahg> it's funny, the release was announced on identi.ca 6 hours ago :)
<skaet> cjwatson,  can you check if the ubuntu alternate/desktop amd64+mac,  and kubuntu alternate/desktop amd64+mac have been added.    Haven't heard back yet from pitti.
<pitti> skaet: just back from dinner
<charlie-tca> micahg: anyone can announce it there, but that doesn't make it real
<pitti> I'm currently looking at it, but it seems to require some more effort
<pitti> ah, it's the iso tracker version numbers being wrong again
<skaet> pitti,  thanks.
<pitti> skaet: but I just publish them to cdimage, not to releases
 * cjwatson will leave it to pitti, since he's here
<pitti> syncing out
<pitti> skaet: I'll update TechOverview accordingly
<skaet> pitti,  thanks.
<pitti> done
<pitti> skaet: http://cdimage.ubuntu.com/kubuntu/releases/natty/beta-2/
<pitti> http://cdimage.ubuntu.com/releases/natty/beta-2/ done as well
<pitti> skaet: ^
<pitti> skaet: I already checked all links in TechOverview ealier, so aside from the mirror prober they are all go
<skaet> piiti,  thanks!   :)
<pitti> skaet: do you need anythign else from me?
<skaet> pitti,  I think we're good,  I'll just finish going through the checklist as soon as the announce is sent out.
<pitti> skaet: cool; good luck with the finishing touches!
<lamont> skaet: I'm guessing the release announcement means you'd like the faster build times that fresh chroots will give you, yes?
<skaet> :)
<skaet> indeed.
<skaet> cjwatson, can you approve ubuntu-devel-announce?
<jbicha> looking for a sponsor for bug 426215
<ubot4> Launchpad bug 426215 in software-center (Ubuntu) (and 1 other project) "[UIF exception] apt:package-name isn't handled by the Store when appropriate (affects: 5) (heat: 30)" [Wishlist,Fix released] https://launchpad.net/bugs/426215
<ScottK> python3-defaults is mine as well, so I'd appreciate a review.  The patch is reviewed by POX (dh_python3 developer) and committed to the Debian VCS.
 * skaet --> dinner and errands.    Back on later. 
#ubuntu-release 2011-04-15
<kirkland> i have a byobu with a healthy set of good bug fixes;  any chance of getting such an upload accepted?
<slangasek> a healthy set of bug fixes at this stage is a small one... is it small? :)
<slangasek> ScottK: python3-defaults accepted
<kirkland> slangasek: hmm, well, it fixes 11 separate bugs of varying sizes;  none of which I'd call "large";  the most critical one is probably that dpkg-diversion you helped me with;  i suppose i could cherry pick a couple
<kirkland> slangasek: no big deal if you said "no way jose"
<kirkland> slangasek: but I'm comfortable with them, and i'd rather people not suffer from these bugs for all of 11.04
<slangasek> kirkland: 11 bugs is a bit on the high end, but you can upload it to the queue for review
<kirkland> slangasek: thanks, that's fair
<kirkland> slangasek: okay, sent to the queue for review
<Daviey> kirkland, pro tip - don't raise bugs for your fixes.. makes the medicine go down easier :P
<kirkland> Daviey: heh, i doubt it ;-)
<ScottK> slangasek: Thanks.
<jibel> ogra_, there are some untested arm/omap images on the tracker, what's their status ? http://iso.qa.ubuntu.com/qatracker/build/all/untested
<jibel> ogra_, kubuntu mobile failed according to GrueMaster's comment, but I can't find a bug associated with it.
<ogra_> jibel, netbook is a duplicated entry, its the same as "Ubuntu ARM"
<ogra_> for kubuntu ask GrueMaster, dunno which ones he tested
<ogra_> but i think he said it was a complete fail across the board
<cjwatson> skaet: looks like somebody had already done it
<jibel> ogra_, yes, I don't know why Ubuntu ARM has been reset.
<jibel> for Kubuntu GrueMaster> kubuntu-mobile armel is not ready for publishing in my opinion.  It is not bootable as it sits.
<jibel> no news since this comment. I'll check with GrueMaster
<cjwatson> I've created all the milestones for oneiric based on OneiricReleaseSchedule
<doko> cjwatson: about bug 735020 ... I could prepare an upload in a PPA enabling these bits, but otoh, I could have the ppa upload disabling the bits, and enabling them in the distro.
<ubot4> Launchpad bug 735020 in eglibc (Ubuntu) "Ubuntu 11.04: Support AMD Bulldozer processor - glibc (memset) (affects: 1) (heat: 128)" [Undecided,Fix released] https://launchpad.net/bugs/735020
<cjwatson> doko: correctness should trump performance, IMO - that bug is about performance, whereas the other one was actually causing wrong behaviour.  (though if there's a smaller hammer that would fix the flash bug, I wouldn't object.)
<doko> ok, building the performance version in the ubuntu-toolchain-r ppa
<ev> pitti: could I have your eyes on 759804 whenever you have a chance?
<ev> err bug 759804
<ubot4> Launchpad bug 759804 in ubiquity (Ubuntu) (and 1 other project) "Installation of -pae kernel happens after jockey -C, causing removal of built DKMS modules (affects: 2) (heat: 14)" [High,New] https://launchpad.net/bugs/759804
<pitti> ev: I'm about to log off, my train station is coming soon
<pitti> ev: will do later when I'm back online
<ev> pitti: sure thing, whenever works for you :)
<ev> thanks
<skaet> cjwatson,  thanks for creating those milestoned.   :0
<skaet> :) even
<cjwatson> I've moved foundations-y bugs from the beta-2 milestone to final.  Please could somebody do the same with other bugs where appropriate?
<cjwatson> (and a review of console-setup from the queue would be lovely)
<skaet> cjwatson,  will do
<skaet> for the bug moving,   not sure what you mean by review of the console-setup, so will leave that for someone else.
<cjwatson> skaet: just like any of the other reviews of uploads to the queue.
<skaet> cjwatson,  can you go in and disable beta-2 milestone?
<cjwatson> skaet: done
<skaet> thanks
<tgardner> skaet, who should I annoy to get the linux-ti-omap4 kernel approved?
<cjwatson> tgardner: queuebot annoys us about it alreay
<cjwatson> +d
<cjwatson> I'll do it once I've finished with this sync run
<tgardner> cjwatson, thanks
<stgraber> ogra: I'm guessing bug 760035 should be targeted for release and made slightly more important, right ?
<ubot4> Launchpad bug 760035 in python-apt (Ubuntu) "Ubuntu.info template doesn't allow deb-src lines using archive.ubuntu.com on ports architectures (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/760035
<ogra> yes, please
<stgraber> ok, done
<ogra> thx
<GrueMaster> jibel: Morning.  Kubuntu-mobile is an incomplete image.  It has no boot partition for eithr omap3 or omap4 images.  Aside from that, they also do not boot into their gui environments.  No bugs were filed, as I wouldn't know what to file a bug against.
<cjwatson> skaet: if I take bug 736743 off the agenda, will it return?  this is unlikely to be fixed for natty, and I don't think it's RC
<ubot4> Launchpad bug 736743 in grub2 (Ubuntu) "environment block not implemented on btrfs (affects: 6) (heat: 155)" [Wishlist,Triaged] https://launchpad.net/bugs/736743
<skaet> cjwatson,  if its unlikely to be fixed, better it be surfaced now.
<cjwatson> I don't understand, sorry
<cjwatson> what does surfaced mean in this context?
<skaet> I'd rather it be given a status that indicates it isn't being fixed.  (wishlist)
<cjwatson> that's the status it already has
<cjwatson> it's triaged, wishlist, not targeted to natty
<cjwatson> the only reason it ended up on the agenda was that it came up in iso testing
<skaet> thanks,  needed to understand that bit of context (iso testing triggering it)
<cjwatson> well, at least that's the only reason I can see
<skaet> Have gone in and targetted it to be considered in Oneiric.
<cjwatson> ok, I'll remove it from the agenda then
<skaet> thanks
<cjwatson> (it's still not High for Oneiric, though, it's still Wishlist. :-) )
<skaet> heh,  ok,  should I update the bug to task it to Natty, and put in an explicit won't fix to make it clear?
<cjwatson> I don't see a need - most bugs aren't explicitly targeted
<cjwatson> targeting to oneiric is clear enough, I think
<GrueMaster> Can we fix the release image naming process for armel images prior to final?  Every release so far has had duplications in the names.  I.e. ubuntu-headless-11.04-beta2-preinstalled-headless-armel+omap4.img.gz
<cjwatson> GrueMaster: can you file a bug on the ubuntu-cdimage project for that, please?
<GrueMaster> Will do.
<cjwatson> it should be doable, but I have no time for it today (and on holiday Mon, Tue)
<GrueMaster> Ok, Bug 761915 filed.
<ubot4> Launchpad bug 761915 in ubuntu-cdimage "Name redundancy in the armel release image names (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/761915
<skaet> cjwatson,  GrueMaster +1 on getting those names cleaned up.
<GrueMaster> I'm not even sure why they get changed that way anyways.  The natty-desktop-,arch> and natty-server-<arch> end up as ubuntu-<release version>-desktop-<arch> and ubuntu-<release version>-server-<arch> without the extra desktop or server nominclature.
<cjwatson> GrueMaster: I know why, it should be fixable by me next week
<cjwatson> desktop is just 'ubuntu' as far as cdimage is concerned, and ubuntu-server is special-cased (as ubuntu-headless can be)
<cjwatson> actually, if we're going to spend time talking about it, I'll just fix it now.
<cjwatson> or maybe not, will take longer than the five minutes I have.  It actually looks like it's a bug in publish-image-set.py, so reassigning
<GrueMaster> I filed a bug for kubuntu-mobile armel images and marked them both as failed in the tracker for completeness.  I would have filed the bug earlier, but lp wasn't working for me yesterday or Wednesday night when I tested them.
<Riddell> cjwatson: how does cdimage/www/simple/kubuntu/HEADER.html get generated?
<cjwatson> Riddell: by hand
<slangasek> um, why did I just get mail saying I uploaded sea-defender when I didn't?
<ScottK> slangasek: Apparently LP thinks you did: https://launchpad.net/ubuntu/+source/sea-defender/0.9-2
<ScottK> Perhaps an accidentally misattributed sync request.
<slangasek> yeah, that seems to be the case
<slangasek> oh
<slangasek> no, it's not misattributed at all \o/
<slangasek> well, it sorta is... I filed a ftbfs bug on sea-defender, tjaalton turned it into a sync request :)
<hyperair> hi. regarding bug #760902, do i need a FFe for that?
<ubot4> Launchpad bug 760902 in banshee (Ubuntu) "Banshee's Library Watcher should be disabled by default in Ubuntu 11.04 (affects: 2) (heat: 12)" [Wishlist,Incomplete] https://launchpad.net/bugs/760902
<hyperair> to summarize, the library watcher isn't polished enough, so it would be better to disable it by default (and let users enable it if they want to)
<hyperair> for some context, it was previously enabled, and distropatched by didrocks, who agrees that we should disable it by default
#ubuntu-release 2011-04-16
<ScottK> slangasek: I can't accept chromium-browser and it's got some security fixes in it, so would you please accept it?
<ScottK> Package accept page times out reliably for me on that one.
<slangasek> done
<ScottK> slangasek: Thanks.
<bdrung> can someone accept lintian?
<bdrung> i don't want that waiting too long lets lintian run into this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522441
<ubot4> Debian bug 522441 in file "file: misreported gzip-compressed files" [Normal,Open]
<ScottK> bdrung: Done.
<bdrung> ScottK: thanks. i hope that it build this time.
<ScottK> Me too.
<bdrung> ScottK: this is just my fifth try ;)
<ScottK> ;-)
<bdrung> the question is: what comes after pkgbinarymangler and amd64 vs i386?
<bdrung> ScottK: can you accept audacity too?
<ScottK> bdrung: No.  Due to Bug #745799
<ubot4> Launchpad bug 745799 in launchpad "DistroSeries:+queue Timeout accepting packages (affects: 1) (heat: 13)" [Critical,Triaged] https://launchpad.net/bugs/745799
<bdrung> ScottK: \o/ lintian built!
<ScottK> Congratulations.
<iulian> ScottK: Uh, that is indeed a nasty bug.
<ScottK> It is.  It comes and goes for vague and varied SQL reasons.
<iulian> Uhmm.
<ScottK> slangasek: Would you please accept audacity.  The LP page times out for me.
<slangasek> accepting
<ScottK> Thanks.
<ScottK> bdrung: ^^^
<iulian> ScottK: Does that happen only to you?
<ScottK> iulian: The Canonical archive-admins can use their command line access so it doesn't come up.
<ScottK> I'm limited to the Soyuz U/I in LP.
#ubuntu-release 2011-04-17
<skaet_> all, beta-2 milestoned bugs have now been moved to 11.04, natty-updates or oneiric.  FYI.
<iulian> salome looks good to me ^^.  Please let it in.
 * iulian yawns.
 * iulian is going to make a cup of tea.
<bdrung> Do i need a FFe for ubuntu-dev-tools?
<ScottK> If it's got new features, yes.
<kirkland> if someone could push byobu 3.32 through to natty, i'd be much obliged
<kirkland> asap, please
#ubuntu-release 2012-04-09
<cjwatson> right, I think that's enough cross-build hacking for tonight
<cjwatson> (db4.8, insserv, dpkg, shadow, iproute, doxygen, and gperf are all cross-build fixes, mostly for problems on http://people.linaro.org/~wookey/buildd/precise/sbuild-ma/status.html)
<micahg> cjwatson: if you
 * micahg fishes for infinity
 * ScottK starts reviewing the queue.
<ScottK> OK.  Did the ones I think I understand.  Left a few for whoever's up next.
<micahg> infinity: cjwatson: unping
<Laney> FYI, it's very possible that I won't be online this week: going to a caravan which may not have mobile signal to sustain internet.
<tumbleweed> Laney: enjoy
<Laney> tumbleweed: http://www.bbc.co.uk/weather/2649463 â hmm :P
<stgraber> Laney: isn't that the usual UK weather? :)
<tumbleweed> and I thought we'd been having cold weather
<Laney> it is a sterotypical british seaside holiday
 * Laney heads off
<Laney> have a good week, and remember to NACK hard
<ScottK> Reviewing qt4-x11.
<ScottK> And pushing out unseeded stuff.
<ScottK> Now nfs-utils.
 * ScottK will review networkmanagement once it gets diffy.
<jdstrand> skaet: hi! fyi, with all the MIRs going on, I took the liberty of adjusting the package mappings spreadsheet for of the 'unknown' ones in http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/rls-p-tracking-bugs.html
<skaet> thanks jdstrand.  :)
<jdstrand> skaet: I didn't do all of them or anything, but thought I'd mention it so you could prease whatever buttons to apply the spreadsheet to that page
<jdstrand> press
<skaet> :)
 * skaet ^ wondering who's just done the accepts...
<skaet> jdstrand, new version of the spreadsheet has been uploaded,   should be showing up on reports this afternoon.
<ScottK> skaet: Did you see the mails on the release team list about the pad?
 * skaet looking
<ScottK> skaet: I did the Universe ones.
<ScottK> Since Unseeded Universe isn't frozen yet, I thought we didn't need to discuss them.
<ScottK> The fact that they need approval at all is an artifact of LPs limitations and not policy.
<skaet> thanks ScottK for handling.   agree in general,  just wasn't sure if banshee-community-extensions was seeded or not (cli-mono)
<ScottK> cli-mono is an uploading packageset, not a seed for a flavor.
<skaet> ok,  all good then.
<skaet> re: pad
<skaet> yes,  I encounter this as well.
<skaet> seems to have been happening for at least a month,  I encounter it on the ubuntu-release pad as well.
<ScottK> I think it makes the use we've planned for it quite problematic
<ScottK> You can check the pad and still not know if you've really checked it or not.
<jbicha> it's that Ubuntu SSO proxy they put in front of the pad, I think I've had the timeout problem for months
<skaet> I guess I've gotten into the habbit of clicking refresh on it.    Although I agree its not ideal (by a long shot)
<skaet> thanks jbicha,  that would explain it.   Do you know if there's an RT ticket about it?
<jbicha> skaet: I haven't submitted an rt ticket and rt's not public
<bjf> slangasek: when you pocket copied the kernel packages for me last week, everything seems to have gone to universe instead of main
<jdstrand> skaet: thanks
<skaet> ScottK,  timeout behaviour has been tweeked by the sysadmins,  let them know in #canonical-sysadmin if its still misbehaving for you.
<ScottK> skaet: Thanks.
 * ScottK looks at akonadi.
<skaet> https://blueprints.launchpad.net/ubuntu/+spec/other-q-prior-release-feedback
 * ScottK looks at calligra.
<Riddell> jings ScottK, you're on the ball today :)
<ScottK> :-)
<ScottK> Waiting for the diff.
<slangasek> skaet: so I've rejected the update-notifier with the broken source package build; but I've also seen that update-notifier-common is one of the packages leaving stale conffiles around on upgrade from lucid, per https://jenkins.qa.ubuntu.com/view/Precise%20Upgrade%20Testing%20Dashboard/job/precise-upgrade-lucid-desktop/ARCH=amd64,LTS=lts,PROFILE=ubuntu,label=upgrade-test/lastSuccessfulBuild/artifact/lts-ubuntu-amd64/obsolete_conffiles.lo
<slangasek> skaet: so if it's alright with you, I'll fix that and include both changes when reuploading
<ScottK> +1
<infinity> slangasek: Sounds reasonable to me.
 * infinity goes back to pretending he's not here today.
<slangasek> :)
<infinity> I have a sneaking suspicion, I'll be working non-stop from tomorrow until the end of the month, I figure I'll gorge myself on leftover ham and enjoy the holiday. :P
<skaet> slangasek,  sounds good to me as well.
 * skaet thinks leftovers sound like a good idea....    lunch time.
<slangasek> ok, update-notifier 0.119ubuntu4 uploaded
<bjf> slangasek: did you see my earlier msg?
<slangasek> bjf: don't think so; had a power outage here
<bjf> slangasek: when you pocket copied the kernel packages for me last week, everything seems to have gone to universe instead of main
<slangasek> oh, grr
<slangasek> I rather expected the magic script in ubuntu-archive-tools to take care of that for me
<slangasek> bjf: remind me which suite we were in? oneiric?
<bjf> slangasek: yes, oneiric
<slangasek> and it was linux, linux-meta, and linux-backport-which?
 * ScottK looks at update-notifier.
<bjf> slangasek: bug 974368 has complete list in comment #2
<ubot2> Launchpad bug 974368 in linux "linux: 3.0.0-19.32 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/974368
<slangasek> whoa, why is launchpad offering to let me download the full comment instead of letting me look at it in the browser? :P
<slangasek> bjf: promoted the three source packages to main with all binaries (after checking that they're all in main in oneiric-updates)
<bjf> slangasek: thanks
<ScottK> Much better.
<cnd> skaet, following up from last week, I tracked down the crasher to xserver-xorg-input-synaptics bug 974017
<ubot2> Launchpad bug 974017 in xserver-xorg-input-synaptics "Crash when touching Apple trackpad with 11 fingers" [Medium,In progress] https://launchpad.net/bugs/974017
<cnd> I've attached a patch that fixes the issue
<cnd> I don't know what the process is for getting this handled right now
<cnd> in the frozen archive, but not release frozen, state
<cnd> do I just upload it and someone on the release team will review?
<cjwatson> slangasek: magic script> it should be able to do so after I get queue override API exposed
<ScottK> cnd: Yes.
<infinity> cnd: 11 fingers?
<cnd> ok
<cnd> infinity, yes...
<cjwatson> slangasek: but, no interface for it just now
<slangasek> cjwatson: gotcha
<cnd> infinity, I use my nose for testing :)
 * infinity snorts.
<slangasek> oh, I thought that was a contrived example when someone asked about it :)
<slangasek> infinity: since you're declining to go away, do you want to review my eglibc merge proposal that I subscribed you to? ;)
<cjwatson> cnd: there's a story about Mozart like that ...
<cnd> slangasek, the use of a puppy paw was contrived, but the real issue wasn't :)
<infinity> slangasek: Do you need it in today?  Cause I still have eglibc things to fix when I'm back to work anyway.
<cnd> cjwatson, that he used his nose?
<slangasek> infinity: no, I'm just trying to give you added incentive to make yourself scarce ;)
<cjwatson> the story goes that Mozart and Handel challenged each other to write something that the other couldn't play
<infinity> slangasek: Har.
<infinity> slangasek: Running away, then.
<cnd> cjwatson, hmm, interesting..
<cjwatson> when Handel attempted Mozart's offering, he found that at one point it required 11 fingers
<cjwatson> so declared it impossible
<cjwatson> to prove him wrong, Mozart sat down to play, and when he got to the offending passage, he pecked the extra note with his nose
<cnd> heh
<cjwatson> I suspect the story is apocryphal :-)
<cnd> that would be physically hard to do even by itself
<cnd> the length of keys is only so long
<cjwatson> it would indeed
<cjwatson> pointy nose, maybe
<cnd> or you'd have to turn your head sideways
<micahg> will the final ISOs be affected by -security uploads?
<hallyn> hi - just pushed a workaround for non-accelerated qemu.  not sure if i need to beg for that here?
<cjwatson> micahg: by default, and unless we agree otherwise and go to some lengths to make sure of it, yes
<micahg> cjwatson: so, pushing security issues to -security before release is an option (where we don't care if it's on the ISO or not?
<jdstrand> micahg: in the past we have just queued them up in our various ppas for 0-day updates
<jdstrand> micahg: (where it didn't make sense to push earlier)
<micahg> jdstrand: yes, I"m aware, but was wondering if we have the option to push out to -security during that last week for stuff that doesn't matter if it makes it on the ISO (and we don't want to risk breaking the ISOs)
<slangasek> micahg: I think you may have misread - packages pushed to -security *will* be seen by the ISO building scripts
<jdstrand> micahg: we could if we knew there wouldn't be a respin, but we usually don't which is why we need to coordinate. bottom line, when generating isos they pull from -security
<slangasek> so "doesn't matter and don't want to risk" != "push to -security"
<micahg> slangasek: ah, yes, I did :)
<micahg> that's too bad :(
<jdstrand> micahg: is there a particular problem you are trying to solve are is this purely for understanding?
<jdstrand> s/are/or/
<cjwatson> the problem with hacking things to avoid building from -security is that there's a non-trivial risk of building images that never get security updates on installed systems as a result
<cjwatson> I wouldn't want to try it
<micahg> jdstrand: well, wÃ©ve got the Firefox release 2 days before precise release (no idea how bad the CVEs are), with the frequency of recent chromium releases, therÃ©s bound to be one or 2 after final freeze
<micahg> cjwatson: that's fine, therÃ©s a good chance it won't make a difference
<micahg> err..rather, wouldn't be necessary in any event
<jdstrand> micahg: you are saying you expect 1 or 2 firefox updates between now and precise release?
<micahg> jdstrand: for Firefox, therÃ©s the planned release on Apr 24
 * jdstrand didn't understand the chromium reference
<micahg> jdstrand: probably 1 or 2 chromium updates after thursday
<jdstrand> micahg: I guess there are isos with chromium on them you are worried about?
<micahg> jdstrand: yes, mythbuntu and lubuntu :)
<micahg> jdstrand: I"m more concerned with not updating the release than the ISOs, keeping the ISOs up to date for CVEs is a losing game
<jdstrand> micahg: I see. well, for firefox it seems easy enough-- we publish firefox with a -2 for precise only on release day (people running precise just have to wait)
<jdstrand> (thems the breaks)
<jdstrand> micahg: for chromium-- it you could stage in proposed I guess and have the people responsible for testing comment on if they want it in a respin. if all do, then you can do it, if not, they wait for a 0 day
<jdstrand> and by 'do it', I mean do a pocket copy
<micahg> jdstrand: ok, sounds good, after Final Freeze, I"ll do precise just like that stable releases for Chromium
<micahg> well, save the final copy to -security :)
 * jdstrand nods
<cjwatson> staging in -proposed is fine, yes
<hallyn> stgraber: an lxc including your fix has been pushed (waiting approval) to archive, fwiw
<stgraber> hallyn: cool, thanks
<hallyn> hm, does Unapproved mean rejected?
<hallyn> stgraber: ^ then again maybe not
<skaet> hallyn,   Unapproved means its been loaded to the unapproved queue.
<skaet> you'll see Unapproved: accepted or Unapproved: rejected after its been reviewed.  :)
<hallyn> skaet: ok, thanks.  it sounded scary :)
<skaet> :)
<ScottK> Looking at update-notifier
<ScottK> slangasek: In update-notifier, was moving the removal of /etc/update-motd.d/20-cpu-checker to later in the postinst intentional?  It's not mentioned in debian/changelog.
<slangasek> ScottK: yeah, it's to avoid needlessly calling it again in the trigger case
<ScottK> OK.  Thanks.  Accepting.
<slangasek> ScottK: thanks
<ajmitch> for libsamplerate, I'd like to sync it to fix #969957 which bit me on upgrade, however the changelog says it has hardening build flags, should this get an FFe?
<ajmitch> debdiff of the change at http://paste.ubuntu.com/922496/
<joshuahoover> can someone look at this sru for oneiric? bug #869920 ...it's fixed in p already
<ubot2> Launchpad bug 869920 in ubuntuone-client "Files in new UDFs are not uploaded due to filtering" [High,Confirmed] https://launchpad.net/bugs/869920
<micahg> joshuahoover: someone just needs to propose a merge into the oneiric-proposed branch and it'll go into the sponsorship queue or add a debdiff and subscribe ubuntu-sponsors
<joshuahoover> micahg: ah, ok, thanks :)
<micahg> cjwatson: would it be worth making an autogenerated lubuntu packageset since it's an official flavor (and to make it easier to keep track of what failures/uploads affects what images)
<micahg> oh, and can someone review/release chromium please :)
<infinity> micahg: Grr, thanks to the tarball-in-tarball packaging, that's completely unreviewable from the UI.
 * infinity downloads...
<micahg> infinity: yeah, I would love to get rid of that, but don't have the time right now, maybe for Q
<Laney> ajmitch: yes we ask for it for that, but it should be easy to approve
<infinity> ajmitch: Looks fine to me.
<ajmitch> right, thought I'd clarify since "I suppose so" wasn't very definite :)
<infinity> ajmitch: Don't need FFe bugs, per se, just approval.
<ScottK> infinity: Thanks to being unseeded universe, it's  not frozen.
<infinity> ScottK: Oh, there's also that.
<ScottK> Makes it much easier.
<ajmitch> infinity: righto, will sync then
<infinity> (Looks fine regardless)
<infinity> And it doesn't hurt to ask for reviews. :P
<ScottK> Never hurts to ask.  Sometimes hurts to do them though.
<infinity> Heh.
<ScottK> Actually I was wrong.  It's in the Mythbuntu packageset anyway.
<infinity> ajmitch: Just remind me what it was when you sync, so I can accept.  I have a short memory.
<ScottK> Looking at network-manager-pptp.
<ajmitch> infinity: libsamplerate has been synced, queuebot should pick it up soon
<ajmitch> there we go
<infinity> micahg: FWIW, your debian/rules is broken when run by hand.
<micahg> infinity: awesome :)
<infinity> micahg: (It uses DEB_BUILD_ARCH, but never sets it, which I assume works under dpkg-buildpackage)
 * micahg thought that was one of the guaranteed var
<infinity> Anyhow, only throws warnings in the case I cared about (debian/rules patch), but it was entertaining to see it claim my arch was unsupported.
<infinity> micahg: Nothing is guaranteed when you run it by hand. :P
<infinity> micahg: Note that I said "outside of dpkg-buildpackage"
<infinity> Or, implied it.
<ScottK> infinity: Except the interface with the package build systsem is debian/rules, so assuming dpgk-buildpackage is a bug.
<infinity> ScottK: I agree.
<infinity> I often use debian/rules clean/build/binary directly for testing purposes.
 * ScottK too.
<infinity> Though, I'm also in the "if it works on the buildds, it's only a minor bug".
<infinity> camp...
<micahg> infinity: I assume it works on teh buildds otherwise we'd never get a successful arm* build :)
<infinity> Or amd64, in this case. :P
<infinity> But yes, debian/rules being canonical is one of the reasons for backing out dpkg-buildpackage setting CFLAGS and moving to dpkg-buildflags, for instance.
<infinity> Behaviour shouldn't change because you use a different wrapper (or none at all).
<micahg> infinity: ok, but FTR, I didn't write most of that file :)
<infinity> Didn't imply that you did.
<infinity> Merely that it's your problem now. ;)
<infinity> I believe that's known as the "neener neener" principle.
<micahg> really, it's not my problem, but I have quite got the person's who's problem it is to accept responsibility yet :)
<micahg> *haven't
<infinity> I'm sticking with my neener.
<infinity> Holy crap, I just realized that compose+^+2 gives me Â².
<infinity> neenerÂ²!
<infinity> I'm a bit embarrassed about that, given that I've been using VT terminals with compose keys since high school.
<infinity> Though, that's probably a more recent extension.
<ScottK> BTW, someone may want to look into another amd64 builder.  amd64 has fallen significantly behind i386 in the rebuild.
<infinity> I can rebalance.
<ScottK> Can you resurrect rothera?
<infinity> rothera's dead for good.
<ScottK> Oh.
<infinity> They're replacing it rather than fixing it.
<ScottK> That's dead all right.
<infinity> Should see about bouncing nasl and shedir, though.
<micahg> infinity: let me see if we can steal back the lpia builder again, it was supposed to go back for the weekend, but that never happened
<infinity> micahg: Meh, rebuild's only a couple more days anyway, I'll just snag a random machine.
<infinity> Actually, they're not that far out of whack.
<infinity> ARM's going to beat them both. :P
<micahg> infinity: yeah, but I figure with the lpia builder, i386 will finish 2 days ahead, then you can throw roseapple at the amd64 builds
<infinity> Or you could just give the lpia one to amd64. :P
<infinity> That would make slightly more sense.
<infinity> Oh.
<infinity> But molybdenum's 32-bit.
<infinity> Nevermind.
<infinity> Derp.
<infinity> I can give roseapple to adm64 now.
<infinity> micahg: If I bounce molybdenum to i386, can you take responsibility for watching for security uploads needing it?
<micahg> infinity: yeah, can you flip rothera to lpia, that should take care of that issue (at least where I can see if therÃ©s something needed)
<infinity> Ahh, I may as well just do that semi-permanently.
<infinity> Until IS kills it.
<micahg> right, we only need this for a few more days anyways :)
<infinity> Sure, but I mean we can just keep rothera there as a placeholder, and bounce $some_other_machine when security builds are needed. :P
<micahg> infinity: yes, exactly :)
<infinity> There.  Done.
<cjwatson> micahg: sure, if the DMB tells me that's OK
<micahg> cjwatson: for the packageset?
<micahg> cjwatson: it doesn't have to grant upload rights at present
 * micahg forgets if that toggle was ever implemented or not
 * infinity still loves the 11-finger touchpad bug.
<micahg> infinity: so, getting back to my chromium upload :)
<infinity> micahg: Yeah, I'm doing others while yours diffs. :P
<infinity> -rw-rw-r-- 1 adconrad adconrad 643232 Apr  9 16:59 chrome.diff
<infinity> ...
<micahg> infinity: what needs to happen also is I need to take an axe to that .orig tarball
 * infinity sighs and has a glance.
<infinity>  121 files changed, 3828 insertions(+), 1654 deletions(-)
<infinity> This seems like one of those plug my nose and pray reviews.
 * micahg kinds gave up on reviewing the upstream changes
<infinity> Naughty.
<micahg> we push major versions and there isn't any hope of manually patching
<ajmitch> you just hope that upstream knows what they're doing?
<micahg> infinity: I will start looking more closely during Final freeze though :)
<micahg> ajmitch: well, that's almost irrelevant, we have a small test suite we run the SRUs through before theÃ½re released to the wild
<cjwatson> micahg: mm, ok, I can do an autogenerated packageset with no upload rights.  mail me a reminder?
<micahg> cjwatson: sure, thanks
<cjwatson> reminds me, I need to sort out the bug in distroseries initialisation miscreating packagesets before we open Q
<cjwatson> and figure out if there's any damage from that left in the precise data
#ubuntu-release 2012-04-10
<micahg> infinity: can you give back the armhf chroot failures for the rebuild?
<rsalveti> infinity: finally got xbmc to work! had it building since yesterday, but the tinyxml replacement (patch from debian) is still lacking one method, that broke the support when using GLES
<rsalveti> infinity: I'm forwarding the fixes first to the debian maintainer, so he can review it, then I should have the proper debdiff in place probably tomorrow/wednesday
<rsalveti> also have the extra functions for jockey to support the sgx driver, waiting one fix to land at nvidia-common tomorrow
<rsalveti> (nvidia-common in theory should be graphics-card-common)
<infinity> micahg: We have some?
<infinity> micahg: I think cjwatson had some API magic to hunt those down.
<micahg> infinity: nasl was still hosed, I got hloeung to fix it a couple hours ago
<infinity> Err, not "still", then, "newly".
<infinity> Cause it was fine after thedac recovered it.
<micahg> ok, well, it tripped again then :)
<infinity> Disconcerting.
<micahg> infinity: oh, and I stole roseapple back for a chromium build
<infinity> Pff.  Impatient.
<micahg> infinity: no, I needed the RAM :)
<micahg> gcc-4.5 + chromium on natty + i386 = FTBFS
<infinity> Oh.
<infinity> Special.
<micahg> lucid on the same builder was fine
<micahg> actually, it could be binutils as I think it's linking where it runs out of memory
<infinity> Build with -gstabs
<infinity> I assume you're already using the other linker flag to make it be less grumpy.
<micahg> yeah, I think that's in the gyp config
<pitti> hm, is the bot down?
<infinity> Doesn't seem to be connected.
<infinity> So, that's a yes. :P
<pitti> I reviewed a bunch of stuff in unapproved, and uploaded apport, but nothing did appear here
<pitti> ah
<infinity> stgraber: queubot's a sad panda.
<micahg> infinity: you can take roseapple back if you like
<pitti> I'd appreciate if someone could review my apport and cups-filters uploads
<pitti> ttf-dejavu as well (but that still needs to get diffy)
 * pitti leaves a "do not accept" comment for cobbler in the pad
<pitti> Daviey: ^ distro-info is in universe ATM
<micahg> pitti: bug 964008
<ubot2> Launchpad bug 964008 in shunit2 "[MIR] distro-info, distro-info-data, and shunit2" [Undecided,Fix committed] https://launchpad.net/bugs/964008
<pitti> micahg: ah, thanks
<pitti> ack, accepting/promoting then
<stgraber> infinity: fixed
 * Daviey goes home, i'm not needed :)
<stgraber> pitti: looking at your uploads now
<stgraber> pitti: ttf-dejavu is good to go
<micahg> pitti: can you please copy {lucid, maverick, natty}/chromium-browser from ubuntu-security-proposed to -proposed?
<pitti> stgraber: will you accept, or are you not in the archive-admin team yet?
<stgraber> pitti: I'm not in archive-admin, so you'll need to do the accepting
<pitti> stgraber: accepted, thanks for the review
<pitti> micahg: running
<stgraber> pitti: apport is good to go too
<micahg> pitti: once that finishes, can you copy maverick only to -security and -updates (want to do it before it gets too late, it's almost the 11th somewhere :))
<pitti> micahg: you mean the version that I just copied from the PPA?
<pitti> micahg: why copy it to -proposed in the first place then?
<micahg> pitti: yes
<micahg> pitti: that's the SRU approval that it has to go through -proposed :)
<stgraber> pitti: and cups-filters is good too
<pitti> stgraber: cheers
<pitti> micahg: hm, I don't quite understand the purpose of this then, but if that's been discussed, fine with me :)
<pitti> micahg: so, to double-check, you want 18.0.1025.151~r130497-0ubuntu0.10.10.1 (which is in the PPA, I am currently copying to -proposed) to -updates as well?
<micahg> pitti: that's how I understood the original approval :), I just looked for proof and couldn't find it :)
<micahg> pitti: yes, and -security
<infinity> There's zero point in putting it in proposed if you're doing updates and security at the same time...
<pitti> yes, that's what I meant
<infinity> proposed only makes sense if you intend to let it get tested.
<micahg> I did test it :), I am looking for what was said now
<infinity> I meant "get it more broadly tested", smartass. ;)
<apw> whats written as process does not always make sense in the real world
<infinity> apw: Which is why I defiantly wipe with my left hand and eat with my right.
<infinity> (was that my out loud voice?)
<apw> [fully outside]
<micahg> ok, now I wonder if my mind invented that, I can't seem to find any record of the requirement of -proposed
<pitti> micahg: all done, as our meticulous queuebot documented :)
 * micahg will ask jdstrand in the morning
<micahg> pitti: excellent, thanks
<micahg> ok, herÃ©s what it is, as infinity said basically :), https://wiki.ubuntu.com/SecurityTeam/PublicationNotes#Chromium_Browser
<micahg> or at least implied as such
<stgraber> pitti: can you approve epoptes please?
<infinity> micahg: Yeah, see, assuming a full (binary+source copy) from the PPA, and also assuming that you're the only person testing, the in-between -proposed step is pointless paperwork.
<infinity> micahg: If there was a "cooking time" in proposed, where other testers got involved, that would be different, but there intentionally appears not to be.
<pitti> or if it was copying the source only
<pitti> stgraber: done
<infinity> micahg: So, having tested the binaries, you've tested the binaries, I don't care where you downloaded them from when you did.
<micahg> infinity: well, sometimes I just don't get to it and then it has bake time
<stgraber> pitti: thanks
<infinity> pitti: Yeah, hence why I specified source+binaries.
<micahg> infinity: but as today is Maverick's EOL, I didn't want to push it out too late :)
<infinity> ;)
<micahg> lest someone accuse me of updating an EOL release
<infinity> You could have celebrated maverick's EOL by not pushing updates for it at all. :P
 * apw raises a glass to the mighty MM
<pitti> oh, is it already?
<micahg> infinity: I get to do that too :)
<infinity> pitti: 10.10.10 + 18
<pitti> oh, indeed
<pitti> plus a leap day :)
<micahg> infinity: bug 972840
<ubot2> Launchpad bug 972840 in thunderbird "Thunderbird 11 stable release migration" [Undecided,In progress] https://launchpad.net/bugs/972840
<infinity> Time flies when you're... Doing whatever we do.
<Daviey> oh dear, i still have some Maverick machines.. can we not EOL it until tomorrow? :)
<pitti> rm maverick.tar.gz
<infinity> Daviey: It's not going to archive to old-releases that quickly, we're slack.
<pitti> Farewell, Meerkat
 * Daviey can feel secure for a little longer.
 * infinity notes that, in practice, it's probably a bad idea to technically EOL (though, clearly, it's officially EOL today) an in-between release until the next LTS is out.
<infinity> I don't feel the urge to pile on to the upgrade path confusion, even if we do get it all flawlessly right.
<micahg> infinity: well, seemingly the people still on lucid want to stay there until the LTS
<infinity> (That said, time to get the wheels in motion to have it copies to old-releases and make sure update-manager DTRT, etc)
<nigelb> micahg: yes. yes. :)
<infinity> micahg: No, but people on Maverick are on, well, Maverick, and things sometimes go a little pear-shaped when we archive releases.
<micahg> infinity: yes, well, they have an upgrade path :)
<infinity> (Not an excuse for us not making sure we do it right, just saying I'm more comfy with the maverick->natty->oneiric->precise path happening entirely on archive.u.c for now)
<infinity> micahg: Don't forget that maverick-updates is part of that upgrade path.
<micahg> infinity: well, yes, maybe we should starting blinking warning at people before their release is EOL
<micahg> pitti: you copied the wrong package to -updates/security
 * micahg should pay attention to queuebot
<micahg> .151 is the one that needs to go
<pitti> pitti | micahg: so, to double-check, you want 18.0.1025.151~r130497-0ubuntu0.10.10.1 (which is in the PPA, I am currently copying to -proposed) to -updates as well?
<micahg> [02:44] -queuebot/#ubuntu-release- Unapproved: chromium-browser (maverick-security/universe) [18.0.1025.142~r129054-0ubuntu0.10.10.1 => 18.0.1025.142~r129054-0ubuntu0.10.10.1] (no packageset) (sync)
<micahg> [02:44] -queuebot/#ubuntu-release- Unapproved: chromium-browser (maverick-updates/universe) [18.0.1025.142~r129054-0ubuntu0.10.10.1 => 18.0.1025.142~r129054-0ubuntu0.10.10.1] (no packageset) (sync)
<pitti> micahg: oh, so sru-release apparently did not yet catch the new one; there was a previous 18.0 in -proposed apparently?
<micahg> yes
<micahg> these updates have been one right after the next
<pitti> meh, since when does that need a publisher
<pitti> micahg: so, I'll wait a bit for the publisher to run
<micahg> ok, Ãm not really worried as I haven't had an update totally blow up except for one :) (but this version .142 has been tested in multiple releases already without  major issue)
<pitti> micahg: hm, publisher shoudl be running now, and still doesn't show 151; I'll re-try in 30 mins, going to supermarket now
<micahg> pitti: ok, hopefully Ãll be asleep when you return :)
<stgraber> ^ ltsp should be a very easy review, just converting a dangling symlink into a file
<pitti> stgraber: done
<pitti> can someone please review lightdm? grave security issue
<pitti> micahg: ^ FYI
<tseliot> hi, can anybody reject my last upload of nvidia-common, please?
<tseliot> pitti: ^
<pitti> tseliot: *zap*
<tseliot> pitti: thanks, it's ok to approve my new upload now, as previously discussed via email
<pitti> tseliot: thanks, LGTM
<tseliot> pitti: thanks again
<gord> hey guys, any chance we can get some form of ack on https://bugs.launchpad.net/ayatana-design/+bug/839480 ? ffe needed for the release
<ubot2> Launchpad bug 839480 in ayatana-design "[FFe, UIFe] Dash - When the Dash is open and there is a maximised app in the background, the top bar background should not disappear" [Critical,Fix committed]
<pitti> I just tried to see what this is about, but the description isn't sufficient for me to understand it
<pitti> the panel looks no different to me, regardless of whether I have a maximized app or not
<pitti> oh, I guess that's the thing you want to change
<pitti> consistency is for the weak?
<gord> hrm hold on, maybe the bug got targeted to the wrong branch accidentally, let me properly check
<pitti> infinity: Debian finally packaged py3cairo with a few fixes (undistributable files, splitting out docs, more modern packaging)
<pitti> infinity: I verified that the Debian package builds and works, and it has zero rdepends in precise
<pitti> infinity: I'd like to sync it; want a bug/debdiff for review, or JFDI?
<infinity> pitti: Is the diff even remotely readable?
<pitti> readable yes, but not that small
<infinity> pitti: Heh.  How about debdiffing the debs instead?
<pitti> http://paste.ubuntu.com/923080/
<infinity> pitti: Make sure they end up with the same files installed, etc.
<pitti> infinity: binary diff: http://paste.ubuntu.com/923081/
<infinity> pitti: It's not like python packaging is particularly magical.  If it's right, it's right.
<pitti> i. e. no surprise except that the new -doc package doesn't exist in our packaging
<infinity> pitti: Yeah, that looks sane.
<cjwatson> pitti: FWIW you can just temporarily hack sru-release to search for Pending rather than Published, for the sort of problem you had with chromium-browser
<pitti> cjwatson: oh, of course; thanks
<gord> pitti, okay i checked, so the best way to see the difference is to open the dash on a workspace with no windows on it, you'll see your wallpaper behind the panel, move to a workspace with a maximised window, open the dash, you'll see no wallpaper behind your panel
<infinity> pitti: Accepted, and napping.
<pitti> infinity: cheers, and good night
<Riddell> chrisccoulson: ping
<Riddell> are you happy for me to accept esteid-browser-plugin now?
<chrisccoulson> Riddell, no. i sent an e-mail to Q-FUNK and had no response so far, and i haven't checked if it addressed my technical concerns either
<chrisccoulson> uploading a firefox extension implies a commitment from me to maintain it for 5 years, which i'm not willing to do
<Riddell> chrisccoulson: he's uploaded a version he says is fixed now
<Riddell> and can't it go in universe?
<infinity> Riddell: Even in universe, it has a commitment, since we rev firefox with new majors every 3 days.
<infinity> Riddell: It's why we blacklist all mozilla extensions from Debian.
<infinity> Riddell: Cause that's saner than having them all break two weeks after release.
<infinity> Riddell: I mean, it's not that we overtly make a commitment, but it's silly to ship software we know we're going to intentionally break, without the uploader at least somewhat committing to unbreaking it.
<chrisccoulson> Riddell, it still pollutes the main window global JS scope in firefox, which means it would even be rejected from addons.mozilla.org
<chrisccoulson> we can't accept things that the firefox addon reviewers wouldn't accept
<chrisccoulson> although, that still doesn't address the maintenance issue either
<chrisccoulson> firefox extensions belong on addons.mozilla.org. they don't belong in the ubuntu archive ;)
<Riddell> well you could argue that is a breakage in the design of firefox then but they're not known for wanting to work in the normal linux distro way
<Riddell> I'll reject it and tell qfunk to make you happy first
<chrisccoulson> thanks
<chrisccoulson> he's going to have a hard time making me happy today ;)
<stgraber> tseliot: speaking of nvidia-common. Did you have a chance to look at bug 976779?
<ubot2> Launchpad bug 976779 in nvidia-common "hybrid-detect changes file in /usr" [Undecided,New] https://launchpad.net/bugs/976779
<tseliot> stgraber: that's definitely doable. I don't see a problem with your approach
<cjwatson> I've created a Lubuntu package set, as discussed
<pitti> erk, automatic langpack updates coming in; I guess I'll accept them wholesale
<doko> pitti: could you have a look at python2.7? just the version bump
<pitti> doko: currently reading the diff :)
<cjwatson> slangasek: you should install gnome-common on the machine where you build update-notifier source packages
<pitti> ^ this fixes a couple of FTBFS in precise, see recent ML discussion
<pitti> I'd appreciate a review
<stgraber> pitti: lightdm looks good
<stgraber> (glib is still pending diff)
<pitti> stgraber: cheers
<Riddell> debfx: spammer!
<ScottK> nasl  is going nuts again
<ScottK> cjwatson: I think nasl needs shut down again
<pitti> debfx: your kdeplasma-addons upload removes debian/patches/kubuntu_fix_qreal_float.diff, is that intended?
<debfx> pitti: yes, the patch wasn't applied anymore in the package as it's included upstream
<pitti> debfx: ok, thanks
<ogra_> geez, cant we exclude the kde langpacks from queuebot like we do with the other ones ?
<ogra_> or is there any particular reason to have them all listed
 * pitti plays more whack-a-langpack
<cjwatson> ScottK: manualed
<cjwatson> and I've asked for it to be fixed
 * cjwatson trawls through the failures list again
<debfx> </kdespam>
<cjwatson> incidentally, the fix to -proposed publishing was rolled out this morning
<stgraber> pitti: hmm, glib's diff is a bit confusing, containing a bunch of timestamp bump making it pretty long and the change initially seemed to affect gwin32 instead of gversionmacros, though re-reading carefuly, it looks fine :)
<pitti> stgraber: yes, you need to look twice on the file headers in the patch; when I looked at it first, I fell into the same trap
<stgraber> pitti: anyway, marked as ok on the pad, feel free to accept
<pitti> stgraber: cheers, done
<cjwatson> ScottK: nasl is building stuff successfully again, and lp-shell is currently busy retrying everything
 * stgraber just uploaded a no change rebuild of gst-plugins-bad0.10 for bug 964926
<ubot2> Launchpad bug 964926 in cheese "Cheese can't find vp8enc" [Undecided,Incomplete] https://launchpad.net/bugs/964926
<stgraber> I confirmed that fix to work on a test netbook
<stgraber> though it then hangs because of bug 966294
<ubot2> Launchpad bug 966294 in ubiquity "Ubiquity loops forever from ubiquity_webcam_play" [High,Confirmed] https://launchpad.net/bugs/966294
<stgraber> but that's another problem I'm still looking into ;)
<cjwatson> grr, it's exploded again
<cjwatson> right, whack-a-moled
<rsalveti> nvidia-common had a chroot problem with it's builder: https://launchpad.net/ubuntu/+source/nvidia-common/1:0.2.44/+build/3394505
<rsalveti> anyone looking at that already?
<cjwatson> rsalveti: I'll sort it out, thans
<cjwatson> thanks
<cjwatson> that builder is already disabled and I gave back everything it failed in the test rebuild, but I need to do the main archive now
<rsalveti> cjwatson: ok, thanks!
<cjwatson> rsalveti: all done
<rsalveti> cjwatson: thanks
<gord> hey again, any news on https://bugs.launchpad.net/ayatana-design/+bug/839480 ?
<ubot2> Launchpad bug 839480 in ayatana-design "[FFe, UIFe] Dash - When the Dash is open and there is a maximised app in the background, the top bar background should not disappear" [Critical,Fix committed]
<didrocks> gord: I pinged pitti and jbicha on it
<pitti> gord: well, I'm still not quite clear what this is about
<pitti> right now it's quite consistent
<pitti> so the proposal is to make it behave _differently_ depending on whether or not you have a fullscreen window?
<jbicha> pitti: I agree that I don't understand why maximizing a window should matter when the Dash is opened
<gord> right now, if you have a maximised application and open the dash, you can see the wallpaper behind panel, which looks odd. really all it does is make it so you can't see the wallpaper
<jbicha> gord: but doesn't it look odd to have the wallpaper showing where the menubar is in all cases?
<zul> Daviey:  bug #978033
<ubot2> Launchpad bug 978033 in swift "FFE for swift 1.4.8" [Undecided,New] https://launchpad.net/bugs/978033
<pitti> jbicha +1
<pitti> gord: I see it when I have three non-maximized windows
<pitti> so if it's wrong for a maximized window, why isn't it wrong for the other cases then? the panel looks identical in all cases
<gord> jibel, no, the issue is that when you don't have maximised windows, your windows are "complete" so to speak, they have their own titlebars and such. when you have a maximised window, the title bar is the panel, so it looks odd when you have a maximised window with the dash open
<pitti> I don't particularly object to changing the behaviour, I just wonder why it needs to be so inconsistent
<jbicha> I think quite a few people wonder why the menu bar isn't the colored translucency like the launcher, but having it opaque gray unless the Dash is open and no apps are maximized seems odd & arbitrary
<jbicha> oh it's a different gray too when the Dash is open with a maximized window
<gord> if you open the dash without a maximised window, its just coloured transparent, its only when you have a window maximised that a layer of gray is added
<gord> anyway, i'm not the guy to be talking to for this ;) its a design decision, just want to make sure we don't have to revert out a good branch because of a lack of ffe
<pitti> gord: jbicha and I followed up in the bug
<gord> awesome, thanks :)
 * skaet starts in on EOL checklist for 10.10
<skaet> mvo, http://changelogs.ubuntu.com/meta-release, can you update maverick to Supported: 0
<mvo> sure
<mvo> doing that now
<skaet> thanks mvo.  :)
<cjwatson> skaet: before you get too deeply into that, did you see the discussion here earlier about not EOLing maverick too enthusiastically until precise is out?
<knome> anybody know why the xubuntu alternate images went oversize?
<mvo> skaet, cjwatson: uh, should I undo my action?
<skaet> cjwatson,  no missed that.
<cjwatson> http://irclogs.ubuntu.com/2012/04/10/%23ubuntu-release.html#t07:53
<cjwatson> mvo: no, I think that's OK as it is, the main thing is that we probably shouldn't rush to move it off archive
<mvo> aha, ok
<cjwatson> because maverick was an anomalously early relase
<cjwatson> *release
<cjwatson> knome: your job to investigate that kind of thing :)
<cjwatson> (you plural anyway)
<mvo> all updated now
<skaet> cjwatson,  it won't be moved off for archive for several months,  due to standing OEM request, so we should be fine.
<cjwatson> right
<cjwatson> fair enough
<skaet> thanks for flagging cjwatson.
 * skaet gets back to her checklist ;)
<knome> cjwatson, well, we didn't do any changes, and a quick comparing in file list didn't show anything obvious...
<knome> i was just wondering if somebody knew
<doko> did cjwatson loose his piece of bread?
<cjwatson> doko: ...?
<pitti> hey skaet
<skaet> hiya pitti
<doko> cjwatson, ohh, I assume you don't know Asterix in Switzerland ...
<cjwatson> I know Asterix, but not in Switzerland, and the English translation is quite a bit different
<cjwatson> oh, I see, google reveals all
<doko> =)
<cjwatson> still not desperately sure I get the joke :)
<cjwatson> oh, "flagging"?
<doko> cjwatson, ohh, I read flogger ;)
<cjwatson> that explains it :)
<slangasek> cjwatson: ah?  what's the impact of not having gnome-common installed?
<cjwatson> slangasek: have a look at the configure diff, and the build log (search for GNOME_COMMON_INIT)
<cjwatson> slangasek: I think in practice it happens to be harmless, but I don't think leaving unexpanded macros in configure for uploaded packages is a good idea anyway
<slangasek> ah, heh
<pitti> stgraber: http://launchpadlibrarian.net/101053108/isc-dhcp_4.1.ESV-R4-0ubuntu4_4.1.ESV-R4-0ubuntu5.diff.gz looks a bit weird -- no semicolon after the "onetry = 0"?
<stgraber> pitti: hmm, good catch, something went wrong ... let me re-generate that patch and re-upload...
<stgraber> pitti: strangely enough that package actually built and worked, I've tested it from my ppa
<pitti> stgraber: hm, perhaps the log_info() stuff is a macro which just happens to deal with that
<stgraber> pitti: please reject, pushing a new one now (didn't test build, just added the missing semicolon)
<pitti> stgraber: done
<pitti> could someone please have a look at apport in the queue? I uploaded it, so can't self-review
<stgraber> pitti: I'll take a look
<pitti> stgraber: there is no new test for the apt cache part, the existing tests cover that pretty well (that was refactoring, not a bug fix)
<pitti> the other bug has tests (quite a lot for a single-digit fix, in fact)
<stgraber> pitti: the refactoring looks sane, the bugfix as well and the test changes are a bit difficult to check as there's a missing chunk at the middle of the diff but from the bits that are in the diff, it looks good
<pitti> stgraber: thanks for the review
 * pitti goes to review a bunch of ktp-* stuff
<skaet> Daviey,  can you do the review on maas-enlist?   like to get it in today if its reasonable.
<Daviey> skaet: ack
<pitti> skaet: we currently keep track of accepted stuff in http://pad.ubuntu.com/ubuntu-frozen-archive
<pitti> skaet: I guess we can clean that up every day? or do you want to keep this?
<pitti> (or is it ok to not record accepted packages there in the first place?)
<skaet> pitti,  its ok not to record accepted packages,   since they'll be in the archive.
<pitti> ok, so that pad is only for questionable stuff, or for putting "blockers" on packages
<skaet> yes,  and making sure if something's been lingering for over a day that someone looks at it.
<skaet> (maas-enlist) for instance
<pitti> ack, that makes it easier
<pitti> I clean up the "recently accepted" stuff
<skaet> thanks pitti.
<skaet> everyone on release team should feel free to edit it, and pose questions there as needed.
<pitti> Riddell: ktp-text-ui has a considerable chunk of fixes and no bug links; are you ok with that new version?
<pitti> I don't feel comfortable with rubber-stamping this myself TBH
<pitti> Riddell: OOI, what was the decision for 12.04? telepathy or not?
<pitti> ok, I'm through with ktp-*, the others look good
 * pitti takes a deep breath and accepts LibO
<pitti> better get this built ASAP
<skaet> slangasek,  whoopsie-daisy - can you take a look at it?  (it seems to be adding features as well as bug fixes,  and I can't seem to see bug 973687 which the changelog refs.).
<cjwatson> why was that uploaded to precise rather than precise-proposed?
<Daviey> <-- will take swift.
<cjwatson> should've been a textbook case for -proposed, I thought
<pitti> cjwatson: uh -- "fail"
<slangasek> skaet: looking
<slangasek> ev: ^^ what's bug #973687?  Referenced in the whoopsie-daisy changelog, and none of us have access to it
<ev> slangasek: added ubuntu-release to that bug
<slangasek> ta
 * Daviey wonders if that bug really needs to be private.
<Daviey> oh wait, i read the comment.
<Riddell> pitti: kopete, kde-telepathy is moved to universe I think
<slangasek> skaet: whoopsie features look to be in the backend/ directory, which we don't ship in the package; looks sane to me, shall I accept?
<skaet> slangasek,  sure,  and thanks.
<slangasek> ev: why did you add dpkg-dev to the build-depends, btw?  That's build-essential
<ev> I hadn't thought to check
<slangasek> I didn't see any other changes in the code that require dpkg-dev either
<slangasek> but it's harmless, so accepted
<skaet> unity-mail is referencing bug 976459
<ubot2> Launchpad bug 976459 in unity-mail "Please upload unity-mail 0.92.2" [Undecided,In progress] https://launchpad.net/bugs/976459
<ev> slangasek: dpkg-parsechangelog in the Makefile
<slangasek> ah
<slangasek> well anyway :)
<slangasek> right, there it is; apparently my brain slid right over that line :P
<ev> that's okay, my brain slid right past that obviously being a part of the core system :-P
<ev> huh, FTBFS, yet it worked fine on my local machine
 * ev digs
<skaet> infinity,  could you take a look at isc-dhcp?   be nice to get this one in today as well.
 * skaet thinks it looks fine, but based on discussion in bug, not sure its resolved after smoser's last comments.
<smoser> infinity, ping me if you want. and i think stgraber had a hold on it.
<ev> so we've agreed in #security to drop cron.daily/whoopsie as apport actually handles this at a more frequent interval (7 days rather than 14)
<ev> presumably I want to do something like: dpkg-maintscript-helper rm_conffile /etc/cron.daily/whoopsie 0.1.25 whoopsie -- "$@"
<ev> correct?
<cjwatson> use a .maintscript file (man dh_installdeb)
<cjwatson> and don't bother including the package name (the 'whoopsie' argument at the end)
<ev> nice!
<ev> indeed, defaults to that
<ev> cheers
<cjwatson> so 'rm_conffile /etc/cron.daily/whoopsie 0.1.25' in debian/whoopsie.maintscript and Pre-Depends: ${misc:Pre-Depends}
<cjwatson> grr, http://lintian.ubuntuwire.org/tags/preinst-uses-dpkg-maintscript-helper-without-predepends.html has gone non-empty again
 * cjwatson whacks some more moles
<infinity> skaet / smoser: Looks rather straightforward, just hard to tell what the 1-line patch does without some (more) context.
<cjwatson> brltty and horizon fix the two chunks of stuff on http://lintian.ubuntuwire.org/tags/preinst-uses-dpkg-maintscript-helper-without-predepends.html
<cjwatson> I've copied debian-installer to lucid-updates, but I'm deliberately not doing the manual procedure for copying its custom upload piece right now, because I'm testing a speculation that using the PackageCopyJob mechanism for that (which we started doing since the last time we investigated all this) might Just Work
<cjwatson> if it doesn't, I'll start trying to construct an LP test case
<infinity> cjwatson: Would be kinda nice if that could all happen magically.
<cjwatson> yay, the precise proposed->release tracker works again
<infinity> cjwatson: The cruft-tracking for d-i bits is annoying. :/
<cjwatson> infinity: yep, the reason I'm testing this was that I read through all the code I could find on the subject and my conclusion was "huh, it looks as though that should work already"
<cjwatson> infinity: it's also the last remaining reason for archive admins to need lp_publish access
<cjwatson> if this works, I intend to ask IS to take that away from us
 * infinity sniffs.
<cjwatson> I know, but I'll really be a lot happier once I don't have to worry about shells I leave running all the time having unrestricted write access to the archive
<cjwatson> if we need to stop the publisher we can ask ops for that
<cjwatson> libwacom in -proposed looks good, copying to release
<cjwatson> (I mean, it's built, and nobody told us it needed any special staging)
 * skaet nods
<SpamapS> I am going to sponsor an upload of openssl for precise.. should I upload that to precise-proposed ?
<SpamapS> its for bug 968753
<ubot2> Launchpad bug 968753 in openssl "ssh crashed with SIGSEGV" [High,Triaged] https://launchpad.net/bugs/968753
<SpamapS> or should I just go right into release pocket and wait for release team to wave it through?
<infinity> SpamapS: I'll let cjwatson field that one, it's his baby (and he might want the patch in Debian too).
<infinity> Also, reading that patch reminds me that I really dislike x86 assembly.
<cjwatson> SpamapS: Just precise is fine.
<cjwatson> Hm, Debian has a new version, wonder what's in it
<infinity> cjwatson: Candy.
<cjwatson> We should do a merge from Debian instead.
<cjwatson> 1.0.1-3/1.0.1-4 fixed this.
<infinity> cjwatson: And a remarkably predictable RNG!
<cjwatson> And included a signature algorithms change which might correspond to what I pulled from upstream
<SpamapS> cjwatson: so merge rather than explicit patch?
<stgraber> infinity: I updated bug 974284
<ubot2> Launchpad bug 974284 in isc-dhcp "invoking dhclient3 with -1 causes issue if no dhcp server available" [High,Confirmed] https://launchpad.net/bugs/974284
<infinity> stgraber: Oh man, I haven't been paying attention.  "static-networking" isn't static entries? ;)
<infinity> THAT'S NOT CONFUSING AT ALL.
<stgraber> hehe
<infinity> stgraber: Hrm.  Your comment and smoser's don't actually match, despite your "that is what I implemented" confirmation. :P
<infinity> stgraber: He said "exit failure, *but* fork a retry loop", but you claim you're exiting *or* forking, depending on success.
<stgraber> oh right
<infinity> stgraber: Is his actually doable?  I haven't looked at dhclient.
<stgraber> it's doable but you don't want to do it
<stgraber> as it'll configure the IP at some random point without triggering the post-up scripts
<infinity> Oh, right.  We're talking about ifupdown here.
<smoser> stgraber, well...
<cjwatson> SpamapS: I think so.  Want me to look at it?
<smoser> i dont know.
<infinity> Yeah.  Bad idea to return failure to ifupdown and then do it anyway. :P
<smoser> i'd rather have a network interface up, and no scripts have been run
<smoser> then no scripts have been run and no network up
<infinity> smoser: It messes up ifupdown state completely.
<infinity> smoser: It'll think the interface is down.
<smoser> wel...
<stgraber> and you won't get your services started as static-network-up won't be emited then
<smoser> that was the case up until right before 11.10
<SpamapS> cjwatson: you seem to be more familiar, and will need to look at it anyway, so yes I think thats the best course of action.
<infinity> A total rethink with callbacks or something could solve that, but that's not small.
<stgraber> or anything using net-device-up
<smoser> stgraber, thats fine, really.
<smoser> ssh will be up
<smoser> so you can get to the system and fix it.
<smoser> as opposed to dead
<cjwatson> OK.  The patch for TLS 1.2 problems in Debian is a strict subset of the one we're currently carrying
<smoser> that was my thought process  in suggesting that.
<smoser> i'm confused as to what you're saying you changed, though.
<cjwatson> And the VPAES fix is identical to the one posted in the Ubuntu bug
<stgraber> what I changed is that in the past if "dhclient -1" failed to reach a dhcp server on renewal, it'd exit for good
<slangasek> cjwatson: blah, did I miss the dpkg pre-dep on brltty?
<stgraber> now if it got an initial lease and forks in the background, it won't ever die and will always try to get a new lease
<smoser> ah. ok.
<smoser> so the case that we're still screwed in is the power fail recovery.
<infinity> Yeah.
<smoser> so you fixed the "dhcp server dropped off the network"
<infinity> But now dhclient's behaviour matches ifupdown's state, for better or worse...
<cjwatson> slangasek: 'fraid so
<slangasek> :/
<stgraber> smoser: mostly taking care of comment $1
<cjwatson> slangasek: brltty had it but not brltty-x11
<stgraber> smoser: #1
<slangasek> cjwatson: ahh, ok
<smoser> stgraber, right. but no comment 0
<slangasek> that's because brltty-x11 was an afterthought :P
<smoser> :)
<smoser> i think comment zero is less important... but its really still quite severe.
<cjwatson> in practice brltty-x11 Depends: brltty Pre-Depends: dpkg would have almost certainly sorted it out, but not provably
<smoser> we're carrying a change in behavior in ubuntu versus just about everything else.
<stgraber> no we don't
<stgraber> debian merged our change
<smoser> oh wow. well, that kind of sucks.
<infinity> Give interfaces a new keyword (sketchy-dhcp yes) that switches from calling dhclient with -1 to not? :P
<stgraber> infinity: or simply do:
<stgraber> iface eth0 inet manual
<stgraber>     up dhclient eth0
<stgraber> :)
<infinity> ;)
<infinity> But yeah, I dunno.  I can see how the current (including the patch in the queue) behaviour may feel like least surprise.
<infinity> That said, it's not what "other OSes do".
<stgraber> well, install Network Manager then :)
<infinity> "Least surprise" to a programmer isn't always "least surprise" to a user.
<cjwatson> slangasek: remind me what the UDD bug# is for "I overwrote the importer's idea of what's current and now it refuses to touch anything"?
<stgraber> NM will detect dhcp failure and retry, running all its hooks and everything properly, but that's quite easy for it to do it right as it's a daemon
<cjwatson> slangasek: I remember you commented on that recently
<slangasek> cjwatson: bug #714622
<ubot2> Launchpad bug 714622 in udd "import fails when lp branch has been push --overwrite'n" [High,Confirmed] https://launchpad.net/bugs/714622
<cjwatson> thanks
<smoser> stgraber, so.. i guess i'm ok with the fix as it is.
<infinity> stgraber: I don't see any particular reason why ifupdown can't fork and background an 'ifup ethN' that blocks on dhclient doing something useful.
<cjwatson> slangasek: do you know what the consequences of requeue_package.py --full are?  does it result in losing history from the Debian branch or anything like that?
<smoser> and your suggested work around is not really that bad, i don't think.
<infinity> stgraber: But that's totally out of scope for right now. :P
<slangasek> cjwatson: no idea... I'm not even sure where the source for the importer is
<cjwatson> lp:udd
<slangasek> oh, well
<slangasek> guess I coulda brute-forced it
<slangasek> :)
<stgraber> infinity: well, we'd at least need to get ifupdown's definition of interface state somewhat saner first :)
<cjwatson>     parser.add_option("--full", dest="full", action="store_true",
<cjwatson>             help="Also remove the revids: DANGEROUS")
<stgraber> infinity: currently it's basically "mark it up as soon as you call ifup" and it doesn't have any kind of state besides up and undefined :)
<infinity> stgraber: It just needs "upping" and "downing" states.
<infinity> stgraber: But yeah.  Lots of re-engineering.  I wonder if it shouldn't just be scrapped sometimes.
<stgraber> infinity: well, 0.7 is starting to look pretty good, then the problem is all the plugins doing weird things and all the copy/paste around them...
<ogasawara> skaet: I've got the kernel ready for upload, just want to re-confirm it's ok to do so.
<ogasawara> skaet: It does contain 7 bug fixes we felt were important to make the release, I've summarized as follows to hopefully help with review and approval in the queue:
<ogasawara> skaet: bug 977246 - Patches add the Hyper-V KVP daemon to the linux-tools package.  Positive test feedback received.
<ubot2> Launchpad bug 977246 in linux "linux: Add Hyper-V KVP daemon tools" [Undecided,Fix committed] https://launchpad.net/bugs/977246
<ogasawara> skaet: bug 948360 - Patch allow alsamixer to be fully functional on affected hardware. Positive test feedback received.
<ubot2> Launchpad bug 948360 in linux "[Gigabyte GA-H61M-S2PV, ALC887] No sound with on-board ALC887 sound" [Medium,In progress] https://launchpad.net/bugs/948360
<ogasawara> skaet: bug 919281 - Patch adds dm-mirror and dm-raid to the md-modules udeb thus allowing server installas for fakeraid controllers. Confirmed the modules now exist in the md-modules udeb, need this to land in a daily iso for installation test confirmation.
<ubot2> Launchpad bug 919281 in linux "devmapper kernel modules missing from precise server cd" [Critical,Fix committed] https://launchpad.net/bugs/919281
<ogasawara> skaet: bug 974403 - Patches remove dangling symlink in the linux-headers package.  Positive test feedback received.
<ubot2> Launchpad bug 974403 in linux "linux-headers has erroneous asm link" [Undecided,Fix committed] https://launchpad.net/bugs/974403
<ogasawara> skaet: bug 974982 - Patch fixes a regression introduced in upstream stable kernel v3.2.14 which renders a system unbootable in pvops mode. Positive test feedback received.
<ubot2> Launchpad bug 974982 in linux "pvops NULL pointer dereference oops in latest precise kernel" [Medium,Fix committed] https://launchpad.net/bugs/974982
<ogasawara> skaet: bug 974090 - Patch fixes an invalid mixer nid value which results in fixing a broken volume slider on a machine hoping to be certified.  Postive test confirmation received.
<ubot2> Launchpad bug 974090 in linux "ALSA: HDA: Virtual master gets wrong dB values on some Realtek codecs" [Medium,In progress] https://launchpad.net/bugs/974090
<ogasawara> skaet: bug 944772 - Patches allow proper system shutdown.  Positive test feedback received.
<ubot2> Launchpad bug 944772 in linux "shutdown does not work" [Medium,Confirmed] https://launchpad.net/bugs/944772
<skaet> ogasawara, thanks,   please upload to -proposed at this point.
<stgraber> infinity: NM recently got bond, vlan and bridging support added so I guess they'll try to push it for server use. Which wouldn't be completely bad if it had a decent cli interface and could read /etc/network/interfaces as a "legacy" source. But I suspect a lot of people being completely opposed to that just because it's NM :)
<ogasawara> skaet: ack, will do.  It is an ABI bumper, so it we'll see uploads for linux-backports-modules and linux-meta as well once the kernel has finished building.  I'll make sure they go to -proposed as well.
<slangasek> ev: nack on this whoopsie update, we already fixed apport to *only* remove files from /var/crash that don't match the whoopsie extensions
<slangasek> ev: so that would need to be sorted first
<slangasek> ev: this was done for bug #957102
<ubot2> Launchpad bug 957102 in apport "apport's cron job will delete whoopsie stamp files" [Undecided,Fix released] https://launchpad.net/bugs/957102
<ev> slangasek: http://paste.ubuntu.com/923741/
<ev> tl;dr, that's not my understanding of that find command
<slangasek> ev: hah, doh
<slangasek> you're right
<slangasek> s/nack/ack/
<ev> well, mdeslaur is right. I'm just along for the ride.
<ev> yay
<ev> here's hoping this one fares slightly better on the buildds
<slangasek> fooey, empathy, gwibber both out of sync in the archive right now... shoulda been to -proposed?
<rbasak> cyphermox: ^^. I've no idea of the procedure now.
<seb128> slangasek, it would help to have a  list of sources that create out of sync issues ;-)
<slangasek> seb128: isn't that every package you upload? ;-P
<slangasek> I thought it was part of the desktop team package guidelines :-)
<seb128> slangasek, I though so, but when I asked pitti why glib didn't go through proposed today he told me glib didn't have out of sync issues :p
<seb128> slangasek, I'm puzzled since ;-)
<slangasek> heh
<cyphermox> rbasak: just let the release team review the upload
<seb128> cyphermox, did you fix the libical armel ftbfs as well?
<cyphermox> seb128: oops
<cyphermox> well, that's something to fix then ;)
 * rbasak hides
<seb128> cyphermox, it has your name on it now! ahaha ;-)
 * seb128 hides
<cyphermox> ahaha :)
<cyphermox> and to think it was one I was avoiding on purpose. I blame rbasak!
<seb128> cyphermox, joke aside do you want to look at the testsuit on armel issue?
<seb128> I'm happy for somebody else to pick it up ;-)
<cyphermox> sure, I'm looking now
<seb128> cyphermox, thanks
<cyphermox> I'll give it a quick shot, in case I can figure it out
<cjwatson> seb128: it's fairly easy to check, look for mixed Architecture: any/all binaries which have exact versioned dependencies on each other
<cjwatson> that pretty much finds most of them
<seb128> cjwatson, source:Version should be replaced by upstream:Version or something ;-)
<cjwatson> seb128: doesn't always work, and requires guessing the next point at which compatibility will break
<seb128> cjwatson, yeah, I guess the real fix is to keep the arch all binaries available for other archs until the rebuilds are done
<cjwatson> They are
<cjwatson> But it doesn't work right in both directions, and apt etc. doesn't quite do the right thing with those
<infinity> seb128: They are.  But it needs some apt mangling to DTRT for end-users, and some buildd-mangling to DTOP (do the opposite thing) for buildds and dep-waits.
<cjwatson> OK, debian-installer-images auto-copying doesn't work even in the new world order
<infinity> That is, I want end-users to just get "the latest combination that works" (mvo was looking at this last week), while on the buildd side, I need to jam some code in to do more intelligent dep-waiting instead of hard-failing (or building against old versions).
<infinity> cjwatson: Boo.
<cjwatson> It was worth a shot
<seb128> infinity, we should just kill arch all binaries :p that would reduce the number of stupid binaries added for 150k of translations that got stripped in langpacks anyway in Ubuntu and fix those issues ;-)
<infinity> :P
<cjwatson> Because obviously nobody uses arch all binaries for anything other than translations. :-P
<infinity> Our current "solution" in soyuz also blatantly ignores the hilarious case where i386 is the arch that fails to build.
<infinity> Thankfully, that's fairly rare.  Ish.
<seb128> cjwatson, well, "libgtk-3-common_3.4.0-0ubuntu5_all.deb (139.1 KiB)"
<seb128> is the most frequent case we run into
<seb128> we = desktop
<seb128> if that was not for debian I would have merged that back in the lib
<cjwatson> desktop != rest of world ;-)
<infinity> seb128: There are other reasons I need to fix the buildd dep-wait code anyway, and it'll fix the gtk3 pain in the process.
<infinity> seb128: But, for now, staging gtk uploads in proposed isn't world-ending, I hope.  Sure beats the previous status quo.
<seb128> infinity, if it makes ogra stop looking at me at every gtk upload because it breaks armel for a day that's great ;-)
<infinity> That would be a pleasant side-effect.
<infinity> But I could just ask Oli to stop looking at you.
<infinity> I know Germans make you nervous. ;)
<seb128> infinity, you say that because you were not around when I almost broke launchpad before a 4 days w.e and made cjwatson stress on a end of week ;-)
<ogra_> seb128, you are sooo behind ... i only look at you for armhf uploads nowadays :)
<seb128> infinity, I did upload gtk to proposed thursday, that just hit a published bug on the way :p
<seb128> ogra_, arm* same difference ;-)
 * ogra_ would also accept some good sponsored sunglasses to hide the looks ;)
<infinity> seb128: Exposing bugs is good.  Just stop doing it before long weekends. ;)
<seb128> hehe
<cjwatson> seb128: that bug's fixed now
<seb128> cjwatson, thanks for that ;-)
<cjwatson> and you only *almost* broke it anyway :)
 * infinity wonders why nasl is manual *after* it seems to have been cleaned up...
<infinity> Or, so the build history would imply.
<cjwatson> It broke again.
<cjwatson> Almost straight away.
<infinity> cjwatson: Oh.  And those were given back, I guess.
<infinity> cjwatson: Unlike the ones in the history...
<cjwatson> Yes, I mass-retried everything that broke.
<cjwatson> I think it worked for a build or two before it fell over again.
<infinity> And yet, we've seen this on other machines.
<infinity> Which makes it hard to blame nasl, as much as I'd like to.
<infinity> I kinda want to just blame natty/armel, scream "la la la, we're upgrading to precise/armhf" and not try debugging it.
<infinity> But maybe if nasl can be made to reproduce it more easily for some reason, we could get a shell on it and see.
<slangasek> uhoh, why are ligatures broken for me in firefox?
<infinity> slangasek: Even after you restart the browser?
<slangasek> no, restarting browsers is painful :)
<infinity> slangasek: They exploded for me on upgrade, but I haven't restarted yet.
<infinity> And I'm just used to everything in mozilla UIs exploding when you upgrade them.
<infinity> XUL isn't friendly about that sort of thing.
<slangasek> I'm used to xul breaking; this is specifically ligatures, which is a strange sort of thing to break due to a missing .js file
<infinity> Yeah, I saw the same thing.
<infinity> I suppose I should see if restarting makes it happy.
<infinity> But.
<slangasek> alright, restarting to see
<micahg> cjwatson: would that mass retry explain why 4 year old hppa builds were being retried?
<cjwatson> micahg: Yes
<infinity> cjwatson: You didn't limit it to a release? :P
<cjwatson> I didn't worry desperately about excluding old ones; they were in the "Chroot problem" state, they had a current source publication, and can_be_retried was True
<slangasek> infinity: yeah, restart cleared it up for me; fiddlesticks
<cjwatson> oh and the distroseries they were attached to wasn't Obsolete
<infinity> slangasek: You were hoping for a broken browser?
<infinity> cjwatson: So, this bzip issue isn't new: https://launchpadlibrarian.net/80339115/buildlog_ubuntu-oneiric-armel.setools_3.3.6.ds-7.2ubuntu3_CHROOTWAIT.txt.gz
<slangasek> infinity: I was hoping things hadn't gotten so bad that upgrades now cause letters to go missing from the running browser
<infinity> cjwatson: It may just seem "worse" now because we finally have the buildd power to do mass-rebuilds on ARM.
<cjwatson> Fun
<cjwatson> slangasek: it's the first sign of incipient zalgo
<slangasek> heh
<cjwatson> The <center> cannot hold
 * infinity groans.
<seb128> infinity, what are the chances that bug #929219 gets fixed for precise?
<ubot2> Launchpad bug 929219 in glibc "chromium-browser, gvfsd-http and others using eglibc crash with SIGSEGV in __nscd_get_mapping() or gethostbyname2_r()" [Medium,Confirmed] https://launchpad.net/bugs/929219
<seb128> infinity, I just saw it mentioned in some user discussions about precise
<seb128> infinity, there is a "potential fix" on http://sourceware.org/bugzilla/attachment.cgi?id=6307&action=diff
<infinity> seb128: I'm doing a glibc upload this week (in the next couple of days), I just need to be able to reliably reproduce that bug so I can be sure one of the proposed fixes actually fixes it.
<seb128> infinity, ok, good to know ;-)
<infinity> Screw reliably.  I need to be able to reproduce the bug, full stop.
<infinity> Maybe I'll install a few VMs until chaos does me a favour and makes it stop working for me.
<seb128> infinity, or trust the other distro,upstream testers, throw the potential fix in if it seems theoretically correct and see if users are happy ;-)
<infinity> Yeah.  That's my second option.
<micahg> infinity: I've also seemingly "reproduced" this with and without nscd installed
<infinity> Or, rather, I'll read the patches over and make sure they appear to do no harm and fix what they claim to fix.
<infinity> But that doesn't necessarily translate to "fixing chrome".
<infinity> micahg: Yeah, I've tried both with and without, as the bug log wasn't clear to me which was meant to be the problem.
<infinity> micahg: Turns out that neither is.  or both.
<infinity> Or something.
<infinity> seb128: I'm probably going to have to go with the fixing it blind option, given how intermittent it is, even for people who CAN reproduce it, but that means it needs to pass my anal-retentive logical audit instead, cause it's a bit late for me to just be shoving something into libc willy-nilly.
<ogasawara> when someone has a moment, could I get the linux-3.2.0-23.36 kernel approved in the queue?
<slangasek> ogasawara: looking
<ogasawara> slangasek: thanks.  I posted a summary of fixes earlier for skaet in hopes it would help when reviewing.
<slangasek> posted in the channel?
<ogasawara> slangasek: yep
<ogasawara> slangasek: lemme copy and paste again
<slangasek> nah, I've got it
<ogasawara> ack
<slangasek> no need to make everyone else's scrollback longer ;)
<ogasawara> hehe
<cjwatson> looks fine to me FWIW, but slangasek had already taken the baton
 * cjwatson accepts some unseeded universe stuff
<tumbleweed> thanks
<cjwatson> (that was a duplicate)
<slangasek> ogasawara, cjwatson: yep, accepted
<ogasawara> slangasek: thanks!
<cjwatson> qemu-kvm looks fine, accepted
<cjwatson> uploading openssl merge as discussed earlier
<cjwatson> libvirt looks fine, accepted
<cjwatson> libical looks fine, accepted
<cjwatson> brasero looks fine, accepted
<cjwatson> (allegedly.  timeouts)
<cyphermox> cjwatson: thanks. as for the ical ftbfs, I'm currently trying to install precise on my board so that I can test things
<infinity> cyphermox: There's always scheat.
<cjwatson> accepted libdbusmenu and mobile-broadband-provider-info
<cyphermox> infinity: yeah, but I should update it anyway :)
 * infinity notes that it fails on arches that all happen to have unsigned chars, and is curious if that's a coincidence.
 * infinity looks for gcc cast warnings in the build log.
<cyphermox> infinity: if you find it this quickly you're my hero.
<cyphermox> infinity: what I wanted to test was what is in the debian bug -- that it might be observable because of DST or not.
<infinity> This test suite output is unreadable...
<slangasek> is it an eye test suite?
<cyphermox> infinity: look at the very start of the tests
<ScottK> cjwatson: Thanks (just now got back on line) re nasl failures.
<slangasek> that's pronounced "nasal", right?
<slangasek> (nasl, velr, glottl, palatl...)
<cjwatson> Goes with arwoof, thematically.
<infinity> cyphermox: I'll leave it to you to decipher, cause I apparently have other things to do.  Or, so my TODO list claims.
<cyphermox> np. did anything jump out?
<infinity> cyphermox: But I'd still put good money on it relating to char signedness.  Maybe someone using chars for pointer arithmetic, or something equally evil.
<cyphermox> k
<infinity> cyphermox: (The part in the build log where it looks like someone might be stuffing chars at free() could be a hint)
 * ScottK looks at kdesdk and akonadi.
<slangasek> sigh, why does bzr bd -S no longer work on the plymouth branch?
 * skaet ^ accepted deja-dup,  mythbuntu-common
<ScottK> skaet: depreciated/deprecated (re the wubi bug) - just in case you're reusing the verbiage somewhere else.
<skaet> ScottK, :)  ta.
<doko> infinity, I'm reassigning roseapple to i386 for the python2.7 build (give it back)
<doko> done, and it's amd64 again
<infinity> doko: mmkay.
<infinity> doko: Fails with i386 kernels? :/
<doko> infinity, no, timeout in the db tests, which are time consuming. didn't have any issues with these in the past
<Daviey> ^^ please can that be accepted, trivial typo.
<cjwatson> Daviey: accepted
<Daviey> thanks
<slangasek> cjwatson: ok, so speaking of whether that udd option would break anything... do you know why the plymouth branch has just had an old version auto-merged on top of it?
<zul> can someone accept swift as well its been acked by a release manager please
<infinity> zul: Looking.
<cjwatson> slangasek: no, and slightly scared to pull to find out
<cjwatson> the web interface is timing out
<slangasek> cjwatson: alright; I'm doing the only sensible thing then and push --overwriting :P
<cjwatson> slangasek: that's pretty special
<cjwatson> slangasek: might be worth asking maxb/james_w
<cjwatson> looks like it's trying to make precise look like oneiric (aka the last version in the archive)
<slangasek> yeah; it did that effectively
<slangasek> which is the problem :)
<slangasek> that version was already tagged
<doko> infinity, slangasek: build did succeed, so I assume vernadsky has a latent disk issue too
<doko> python2.7
<maxb> slangasek: oh, was it requeued with --full?
<slangasek> I don't know
<maxb> that would sort of make sense if it was
<slangasek> what I asked for is "please make what's already in the branches authoritative for UDD"
<cjwatson> hmm, zh_CN image build failure due to whoopsie
 * cjwatson doubts ev is around at this hour
 * infinity lunches before tackling the ubiquity diff.
#ubuntu-release 2012-04-11
<cjwatson> I don't think the whoopsie failure in the Chinese edition build is a regression, or, if it is, it's a regression due to something subtle like configuration order moving around (which does indeed seem to have happened).  I've filed the root cause as bug 978502.
<ubot2> Launchpad bug 978502 in whoopsie-daisy "whoopsie.postinst crashes silently if /var/crash is missing" [High,New] https://launchpad.net/bugs/978502
<cjwatson> I'd fix it myself but the branch is set up so that only ev can write to it.
<infinity> Good thing the archive is still authoritative? ;)
<cjwatson> I think it's probably not that urgent.
<cjwatson> If it causes more build failures overnight, I'll kick them in the morning.
<cjwatson> doko_: Do you have any suggestions for things to try for bug 941676?  I can reproduce it easily enough on davis.
<ubot2> Launchpad bug 941676 in ppl "ppl ftbfs in precise on powerpc" [Medium,Confirmed] https://launchpad.net/bugs/941676
<infinity> cjwatson: Could it be temporarily worked around with s/-g/-gstabs/ on PPC?  That sometimes lowers memory abuse enough to squeak by.
<infinity> cjwatson: (Not that that addresses the underlying issue)
<cjwatson> I'll try that.  -O0 seems to help too.
<cjwatson> -O1, jury's still out, but it's at well over a gig and rising.
<cjwatson> There are probably multiple problems since in the current failure log on LP the OOM is at link time, not at compile time.
<infinity> gstabs could still magically solve al of those.
<infinity> But it's a bit disconcerting.
<infinity> And odd that it's only on the one package...
<hallyn> say, bug 978456, qemu-common .deb has been released, but a user is unable to get it through apt-get update of qemu-kvm?
<ubot2> Launchpad bug 978456 in qemu-kvm "Unavailable dependency for qemu-kvm 1.0+noroms-0ubuntu12 " [Undecided,Incomplete] https://launchpad.net/bugs/978456
<infinity> The error he's seeing from apt would be nice.
<hallyn> hm, it does show '
<hallyn> E: Unable to correct problems, you have held broken packages.'
<infinity> Oh, I didn't even see that in the original.
<hallyn> yeah i glossed over it the first time
<hallyn> is there a way to get the list of broken packages?
<infinity> If he actually has something held, "dpkg -l | grep ^h" will show it, but apt overloads that word, and it can just mean that something's being held back due to resolver issues.
<infinity> I can confirm, however, that the archive is fine (his mirror might not be).
<infinity> But my local mirror finds the latest _all.deb just dandily, and lets me install qemu.
<hallyn> ditto
<hallyn> ok i'll just point out that line to him - thanks
<infinity> Anyhow, he didn't give policy output for the arch all package, only the arch any.
<infinity> Would be a good place to start.
<infinity> I'm fairly sure it's just transient mirror lag.
<hallyn> what do you mean by policy output for the arch all package?
<infinity> He showed the output of "apt-cache policy qemu-kvm", but not "apt-cache policy qemu-common".
<hallyn> qemu-common?
<hallyn> ok
<hallyn> thanks
<infinity> amd64 and i386 were published 4 (four!) hours apart, I'm positive it was archive/mirror skew.
<infinity> You can probably just copy and paste my above line and close the bug. :P
<hallyn> infinity: :)  that'd be fun, but i'd just replied.  hopefully he'll close it out in the morning.
<infinity> cjwatson: Oh, I was thinking of adding a supported-upgrades seed to platform.*, that would carry transitional packages that match the criteria of "used to be in main in the last LTS" and "still depend on things in main now".
<infinity> cjwatson: Start said file blank on each post-LTS release, and let it collect cruft between LTS and LTS.
<infinity> cjwatson: (Things like the openoffice.org transitional packages belong there until Q, for instance, but I'm sure there are dozens more)
<Daviey> infinity: i thought they were caught at opportunities when merging "Keep until Foo release".
<infinity> Daviey: Things get demoted all the time, though I appreciate the theory. :P
<infinity> Daviey: But the upshot of having it in its own seed it also that the cruft is easily found post-LTS-release.
<infinity> Instead of having it sprinkled all over.
<infinity> Empty seed, watch component-mismatches list 150 binaries, profit.
<astraljava> Where are the question-marks?
<infinity> astraljava: *blink*
<astraljava> http://knowyourmeme.com/memes/profit
<infinity> See, "where are the underpants" would have made more sense.
<astraljava> Yeah but I know where they are. Lots of 'em.
<cjwatson> infinity: makes some kind of sense, yeah.  They're scattered all over the place right now.
<smoser> i just uploaded tgt, would appredciate a review. i believe everything is fairly straight foreward
<smoser> http://paste.ubuntu.com/924272/
<infinity> smoser: Accepted.
<micahg> pitti: why was libreoffice not uploaded to -proposed?
<micahg> pitti: precise-proposed I mean :)
<micahg> would avoid questions like bug 978499
<ubot2> Launchpad bug 978499 in libreoffice "AMD64 build of libreoffice 3.5.2-2ubuntu1 missing libreoffice-common" [Undecided,Invalid] https://launchpad.net/bugs/978499
<infinity> micahg: But libreoffice builds so quickly, what are the chances of a skew of more than one cyc... Oh.
<micahg> infinity: ;)
 * micahg thinks he should start using -proposed for chromium
<infinity> Does chromium have any/all skew?
<micahg> infinity: yes, the l10n package
<infinity> Recommends: chromium-browser-l10n
<infinity> It's not versioned.
<infinity> Oh, it is in the other direction.
<micahg> right :)
<infinity> Then yeah, probably should.
<ogasawara> infinity: k, uploaded lbm and linux-meta.  If I could get you to approve them in the queue that would be much appreciated :)
<infinity> Except that it also depends on half the world (as does libreoffice), so you really have to watch what else is in proposed.
<infinity> At least, until we get something britney-like going.
<ogasawara> infinity: they're only ABI bumps and nothing else
<infinity> ogasawara: I dunno.  Can I trust you?
<ogasawara> infinity: probably not, but I'll buy you a beer
<infinity> ogasawara: Sold.
<micahg> infinity: yes, but I think everything it uses has proper symbols files, so it should be irrelevant
<ogasawara> hehe
<infinity> micahg: Eh?
<micahg> well, almost everything
<infinity> micahg: How do "proper symbols files" relate?
<micahg> infinity: properly versioned dependencies
<infinity> micahg: If you build against libfooX 1.3 with symbols and shlibs that demand >= 1.3, and only 1.2 is in q-release, when we copy your package, boom.
<infinity> micahg: That's the danger without britney.
<infinity> micahg: The archive currently has no method except human intervention to prevent that sort of oops.
<micahg> infinity: yes, sorry, I forgot the second part, most of the depends are from lucid :)
<infinity> micahg: Nothing's changed in your dependencies' shlibs since lucid?
<micahg> but yes, library transitions would affect it
<infinity> (I don't believe you)
<infinity> This isn't about transitions, but minor ABI additions.
<infinity> One added symbol to a library in proposed that we reject, and everything build against it is garbage.
<infinity> s/build/built/
<micahg> well, in that case, versioned depends are wrong anyways
<infinity> No.. Versioned deps are right.
<infinity> But soyuz makes no attempt to check them.
<infinity> Pocket copies have no safety net.
<infinity> We just take bits from A, and shove them in B.
<micahg> no, I mean if ABI additions break the binaries, they should depend on that version :)
<infinity> ...
<micahg> *unused ABI additions
<infinity> They would.
<infinity> Ergo, uninstallable packages.
<astraljava> What's the actual date when the first release candidates are built? I acknowledge that it might still change, but the planned one at this time?
<skaet> astraljava, 19th is when release candidate window starts.   we get the last translations earlier that week.
<astraljava> skaet: Ok, I somehow had an earlier date in mind, then looked at the release schedule, and was puzzled. Thanks for confirming!
<skaet> astraljava,  ideally we'd like any image after the 12th to potentially be releasable, but we'll be picking up those last sets of translation.
<astraljava> skaet: Understood. I'm asking because I'm writing to our mailing lists for assistance in ISO testing, so some hard facts won't hurt. :) Thanks for the info!
<slangasek> ^ the plymouth one includes a couple of useful fixes
<pitti> micahg: libo> we absolutely should have sent it to -proposed indeed; failure on the human end, I'm afraid :/
<tjaalton> do bugfix releases need to go through here first before uploading?
<stgraber> no
<stgraber> just upload, it'll show up in the queue and someone from -release will look at the diff
<tjaalton> ok, thanks
<tjaalton> right
<cjwatson> flushing precise-proposed into precise now
<cjwatson> I haven't copied linux-lowlatency yet, since linux-meta-lowlatency still needs to come
<doko> pitti, please have a look at the openjdk-6 upload
<cjwatson> accepted whoopsie-daisy
<tjaalton> i uploaded sssd 1.8.2 bugfix release to the queue
<tjaalton> it should be moved to main for precise, dunno why that hasn't been done yet
<tjaalton> the MIR is bug 903752
<ubot2> Launchpad bug 903752 in tevent "[MIR] sssd" [Undecided,Confirmed] https://launchpad.net/bugs/903752
<tjaalton> I'll add the apparmor profile in another upload, shouldn't be too hard to create
 * cjwatson scores up git to get autopoint (hence world) installable again on armel and powerpc
 * pitti reviews some more packages; but I can't do gvfs, as I uploaded that myself
 * Riddell looks at gvfs
<stgraber> pitti: gvfs looks good
<pitti> doko: currently reviewing openjdk-6; new fonts-ipafont-mincho build dep is in universe
<pitti> doko: dropping debian/patches/6897553.patch is intended? the changelog doesn't mention it
<pitti> and gcc-lto.diff
<pitti> stgraber, Riddell: thanks
<Riddell> stgraber: I got there first!
<stgraber> Riddell: hehe :)
<pitti> ooh our poor buildds
<doko> pitti: yes, 6897553.patch is included upstream, gcc-lto.diff was just an experimental patch, I'll write a MIR for the fonts package, should be harmless
<pitti> doko: ack
<doko> pitti: now bug 978813
<ubot2> Launchpad bug 978813 in fonts-ipafont "[MIR] fonts-ipafont used by the OpenJDK fontconfig" [Undecided,New] https://launchpad.net/bugs/978813
<cjwatson> respinning Ubuntu desktop (x86), preinstalled Wubi images, Edubuntu DVD, and Lubuntu desktop, to deal with whoopsie-induced build failures
<jdstrand> tjaalton: re sshd and main> it needs to be seeded somewhere, then it'll show up on a list of things for an archive admin to fix
<jdstrand> tjaalton: s/sshd/sssd/
<tjaalton> jdstrand: oh
<cjwatson> seeded or depended upon
 * jdstrand nods
<Daviey> or recommended.
<tjaalton> options, options.. :)
<tjaalton> so I guess sssd should go in the 'supported' seed
<tjaalton> oh it's split..
<tjaalton> looks like the structure has changed a lot since intrepid, which is what the wikipage shows
<mdeslaur> Is it too late to upload gnutls26 and puppet security updates?
<ScottK> wgrant: Is there something wrong with diff generation?  strigi was uploaded an hour ago, but still doesn't have a diff.
 * ogra_ hugs the approver
<jelmer> the samba4 package in debian has been updated for a security bug fix, but the upload contains two other bugfixes as well
<jelmer> is there any chance I can just sync that, or should I prepare a new upload that just includes the security fix?
<Riddell> jelmer: bug fixes are good to have
<jelmer> Riddell: even if they're not strictly critical?
 * cjwatson wonders if he's nearing the end of the installer translation sync yet
<Riddell> jelmer: I'm afraid I'm behind on the release team e-mails so I'm not sure exactly what is being accepted but I don't think it's critical only yet
<jelmer> Riddell: I'll check - thanks!
<ScottK> Looks like we need to do a quick sword transition due to a missed ABI break.  Only three rdepends.  Can someone due the binary new after I do the sync?
<ScottK> I'm still doing a test rebuild, just to make sure.
<ScottK> (only three packages)
<cjwatson> yes
<ScottK> OK.  Thanks.
<mdeslaur> liferea upload restores indicator support broken by late liferea precise upload ^
<stgraber> mdeslaur: right, I remember seeing that bug, I'll take a look once the diff has been generated by LP
<stgraber> right, looks sane
<stgraber> can an archive-admin let liferea through please?
<pitti> I wonder why LP doesn't generate a strigi diff
<knome> cjwatson, https://bugs.launchpad.net/ubuntu/+source/xubuntu-meta/+bug/977568
<ubot2> Launchpad bug 977568 in xubuntu-meta "Xubuntu nightly ISOs are missing the PAE kernel" [Undecided,New]
<cjwatson> knome: 10mins
<knome> cjwatson, np, i'm afk too ->
<pitti> stgraber: done
<stgraber> pitti: thanks
<pitti> cjwatson: i18n day :)
<doko> pitti, the ipa-fonts package is now promoted
<pitti> doko: ack
<cjwatson> pitti: yeah, non-langpack freeze tomorrow
<skaet> as is final freeze....
<ScottK> cjwatson: The sword sync is accepted.  Due to the huge armel and powerpc backlog, it might be worth rescoring it to get it built soon.  I've also uploaded the reverse-build-depends with a versioned build-dep on libsword-dev so they can be accepted anytime without fear of misbuild.
<cjwatson> ScottK: I see somebody's rescored them already
<ScottK> Ah.  Excellent.
<ogra_> slangasek, oh, i finally found the pvr driver binaries, seems the source went to restricted but the binaries are in universe
<ogra_> http://ports.ubuntu.com/pool/universe/p/pvr-omap4/ ...
<ogra_> intrestingly they dont seem to be in any Packages file
<cjwatson> I think I'm finished with installer translation updates now
<cjwatson> except for maybe another one to ubiquity
<phillw> cjwatson: will the powerpc builds be in the 'extra' push daily iso builds tomorrow?
<cjwatson> I don't know what you mean by extra push, but daily builds take whatever's in the archive at the time
<phillw> cjwatson: I was told earlier that it was planned to do a suite of regression checks from tomorrows isos?
<infinity> ogra_: I disagree with the "not in any packages files"...
<infinity>  pvr-omap4 | 1.7.10.0.1.21-0ubuntu1 | precise/restricted | source
<infinity>  pvr-omap4 | 1.7.10.0.1.21-0ubuntu1 | precise/universe | armhf
<infinity> pvr-omap4-dbg | 1.7.10.0.1.21-0ubuntu1 | precise/universe | armhf
<infinity> pvr-omap4-dev | 1.7.10.0.1.21-0ubuntu1 | precise/universe | armhf
<cjwatson> well, daily builds take whatever's in the archive at the time
<phillw> cjwatson: okies, thanks
<ogra_> infinity, well, apt-cache search doesnt find it here on a brandnew armhf chroot
<ogra_> root@localhost:/root/compiz-0.9.7.6# apt-cache madison pvr-omap4
<ogra_> N: Unable to locate package pvr-omap4
<infinity> ogra_: A fresh chroot that doesn't have universe? :P
<ogra_> GAH !
<ogra_> it has multiverse and restricted in the sources.list though :P
<ogra_> ah, now my madison agrees with yours
<seb128> ^ that glib upload a gdbus patch which is non "trivial" but comes from upstream git and fix a bug which can be seen as a security issue (a bit borderline, it's allows at least to disconnect dbus client by sending some messages on the bus)
<seb128> i.e would be good to have it in precise
<infinity> ogra_: rmadison is your friend.
<ogra_> i know ... but she doesnt like me if i dont feed her the right config :P
<seb128> I've used proposed to avoid issues like bug #978124
<ubot2> Launchpad bug 978124 in glib2.0 "upgrading to 12.04 beta2 not completed due to problem with packet skype:386" [Undecided,Invalid] https://launchpad.net/bugs/978124
<ScottK> php5 in 'core' just feels wrong (not questioning it, my reaction).
<slangasek> ogra_: right, I changed the override for the binaries, so that should take effect soon-ish
<ogra_> slangasek, thx
<ScottK> Rejected my xiphos upload because we'll probably sync the newer one from Debian instead.
<ScottK> cjwatson: All the sword binaries are done now.
<cjwatson> yep, was just looking
<cjwatson> will punt the rdeps through later
<cjwatson> have to go out now
<cjwatson> (or you can punt them through whenever)
<ScottK> I'll take care of them.  Thanks.
<ScottK> ^^^ was me.
 * ScottK did calligra
<infinity> (I did the others)
<skaet> infinity,  was wanting to talk about the openjdk-6 before it got approved (it was on the pad)
<infinity> skaet: Oh, erk.  Didn't check the pad.
<infinity> (Am I the only one who finds looking in yet another place before checking the queue to be cumbersome?)
<slangasek> no; but it is the agreed procedure, there needs to be some way to coordinate
<infinity> slangasek: Not claiming I'm above the law here, just that I forgot to look. :P
 * skaet would like a way to signal a block for discussion on a package, right on the queue itself ideally, but we don't have that capability, let alone logging.  :P
<slangasek> infinity: then "no" :)
<infinity> skaet: We can reject.
<infinity> skaet: It's not ideal, as it sends a grumpy email, but... It takes things out of the queue.
<infinity> skaet: And the grumpy email would have led doko to come argue his case. ;)
<skaet> infinity,   not sure that's the right semantics, though.
<doko> ?
<skaet> and we still need a way of signaling that discussion is needed before somethings go through.
<infinity> (See?  He pops up like a groundhog when you mention him)
<skaet> :)
<Riddell> ScottK: hmm no strigi in unapproved
<ScottK> Riddell: Odd.  I see it on https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=
<Riddell> oh typo
 * infinity giggles at dirspec's "diff".
<infinity> More RC->release progressions should be like that (just bumping the version number).
<slangasek> skaet: so what was the question regarding openjdk, since it's no longer shown on the pad?
<slangasek> (better to have that discussion now than not at all)
<skaet> slangasek,  its in the history,  but basically neither of the bugs associated with it seemed critical, and there seemed to be a lot of changes that I'm not sure we really need.
<skaet> at this late state
<slangasek> I have yet to find this history button on the etherpad
<skaet> http://pad.ubuntu.com/ep/pad/view/ubuntu-frozen-archive/latest
<infinity> The bugs-must-be-RC thing doesn't come into effect until (checks) tomorrow.
<infinity> Perhaps that's part of why I didn't think to coordinate my review with the pad and others.
<slangasek> skaet: thanks
<skaet> infinity,  yes, but swallowing a system change like openjdk this late before final freeze is risky for regression potential
<slangasek> skaet: fwiw, I think the "also, should be -proposed" should be grounds for immediate reject, since it requires a reupload no matter what
<skaet> slangasek, fair enough,  I'll be more vigorous on the REJECT for those ones.   We still need an effective way of communicating "hold it" for discussion.
<slangasek> yes, I agree
<infinity> I'll watch the pad more carefully.
<slangasek> but I'm afraid it's not realistic to expect it to be 100% effective
<slangasek> so we should take other precautions as well IMHO :)
<infinity> But I do still think that if you think it shouldn't be accepted, the answer is rejecting.
<infinity> We can always fish it out of rejected and accept it if further discussion proves the rejecter was wrong.
 * ScottK is looking at calligra again.
<ScottK>  ... if the diff ever shows up.
<infinity> I think the appservers are on holidays.  I've been diffing the old skool way.
<skaet> slangasek,  feel free to elaborate on the other precautions... ;)
<ScottK> infinity: If you want a break for a lol: https://bugs.php.net/bug.php?id=54547
<slangasek> skaet: just the above - be liberal in what we reject :)
<infinity> ScottK: That's just a side-effect of loose typing.
<ScottK> Charles Manson was also a side effect of insanity.
<infinity> ScottK: (funny, sure, but I chalk bugs like that up to users not understanding)
<ScottK> Isn't the point of php not to have to understand?
<infinity> Maybe.
<ScottK> Outsource all your security issues to upstream.
<slangasek> the checking for INT_MAX overflow with a float was winnar though
<slangasek> why do we have php in main, again?
<skaet> slangasek,  partman-auto has me a bit worried, given all the things that are being pulled in.   Who's reviewing it?
<infinity> slangasek: Yes, *that* one's special.
<slangasek> skaet: well, let me have a look
<infinity> I can look.
<slangasek> infinity: also, I think in PHP's case that's better described as promiscuous typing
<infinity> Looks mostly like translations, and arches/subarches we don't ship.
<skaet>  Adjust default partition sizes for Ubuntu.
<slangasek> skaet: that's the documentation of the remaining changes relative to Debian, not a list of things changed in this version
<slangasek> though, it does appear we're pulling in some changes to default sizes from upstream
<infinity> We are, yes.
<slangasek> cjwatson, infinity: this partman-auto upstream pull introduces some changes to recipes for armhf, and some changes to minimum sizes for various recipes; how tested are these?
<slangasek> +  * Bump minimum root partition size to 900MiB in the home
<slangasek> +    recipe.
<slangasek> +    This will allow installing the standard task and leave room for
<slangasek> +    and extra kernel package in later life of the machine
<slangasek> +    Closes: #528914
<slangasek> +  * Adapt minimum sizes for /var and / in the multi recipe:
<infinity> We had no partman-auto recipes for armhf before, so I'm not sure adding them hurts. :P
<slangasek> +    /var must cope with about 150MiB downloads and has 125MiB data
<slangasek> +    for the standard task install
<slangasek> +    / has about 150MiB installed and should cope with an
<slangasek> +    extra kernel at least
<slangasek> +  * Adapt minimum size for / in the atomic recipe, to 900MiB
<slangasek> +    Same rationale than above.
<slangasek> infinity: isn't there an arch-indep fallback?
<slangasek> i.e., I'm not sure adding them *doesn't* hurt, which is the relevant criterion at the moment :)
<infinity> Oh, perhaps.
<infinity> GrueMaster: Opinion?  You're probably one of the 2 people that uses partman-auto on armhf.
<GrueMaster> Not since pre-Beta 2.
<infinity> slangasek: The default minimums for the generic cases don't sound like a big deal to me, but it is perhaps a bit late.
<slangasek> so the above changelog (from version 94) gives the rationale for the bumps to the minimum sizes... the rationale is sound, and it's unlikely that Ubuntu's requirements are smaller than Debian's, but I'd like cjwatson's thoughts
<GrueMaster> infinity: mahmoh and pgraner would be the people to talk about partman-auto on arm.
<infinity> skaet: BTW, speaking of scary last-minute uploads that will make you hate me, there's a very real possibility that I may have to upload every compiler in the archive over the weekend.
<infinity> skaet: When you've recovered from the heart attack that last line induced, we can chat about it. ;)
<skaet> infinity - please give me the why's please...
<doko> infinity, skaet: honestly not needed. can be done post-release as well
<infinity> doko: Ugh.  Please no.
<slangasek> skaet: bikeshedding about the ELF linker path to be used in the armhf port
<slangasek> (upstream bikeshedding)
<infinity> doko: For two reasons. A) it requires a manual bootstrap, and B) it means people might build third-party binaries with our released compiler that produce incorrect headers.
<skaet> will it require the kernels be updated as well?
<slangasek> no
<doko> infinity, why a manual bootstrap?
<slangasek> and if the kernel team tries to argue otherwise, tell them no ;)
<infinity> doko: Moving the PI needs a glibc/gcc bootstrap loop to fix.
<infinity> Turns out I've done this a few times in the last year.
<infinity> slangasek: I've just had that argument with apw in private. ;)
<infinity> (It's not exactly a difficult bootstrap, but it's not just "change the source and upload" either)
<doko> still don't see why this needs to be a manual bootstrap. get a symlink into libc6, then build gcc.
<infinity> Then glibc.
<infinity> So, two glibc uploads.
<infinity> Which is a bootstrap.  Or, you can do it properly as a bootstrap, and then upload once.
<doko> well, put it into a low cost package like gcc-defaults first, or base files, then you'll have only one glibc upload
<infinity> *sigh*
<infinity> Like I said, it's not a complicated bootstrap, but it's a bootstrap.
<infinity> It involves doing non-standard things to get from A to B.
<infinity> Either way.
<infinity> If we can avoid it, I don't want to ship a compiler that produces "incorrect" binaries.
<slangasek> however, the preferred approach is still to get upstream to agree with us about correctness :P
<slangasek> instead of letting obstinate bikeshedding prevail
<infinity> Yeah, but I don't see it happening, following the thread.
<skaet> How large is the change?   anything else being dragged in?
<infinity> People seem much fonder of /lib/ld-uniqueid.so.3
<infinity> skaet: No, that's it.
<infinity> skaet: It's 1-line, if I just change that path, a bit more if I pull in upstream's revised linker patch (which can wait until Q, if it makes people nervous).
<infinity> (By "a bit more", I mean "5 or 6 lines")
<infinity> Tiny either way, and only ARM.
<apw> infinity, is there any reason tehy won't just chose another random name after you change it?
<skaet> infinity,  if its only arm and 1 line,  why can't we do it now before final freeze, and do a zero change rebuild of the kenrel.
<slangasek> apw: the theory is that the outcome of this call is an upstream commit
<slangasek> so if they change it again locally, we just accuse them of contributing upstream
<slangasek> skaet: because we don't *know* what the one line will be
<slangasek> this is a standardization question
<slangasek> not a technical-bugfix question
<skaet> slangasek, understood. thanks.
<doko> infinity, wait until it's decided ...
<infinity> doko: I thought that bit was obvious.
<ScottK> Is there any way the unity-team/staging PPA could be taught not to build for powerpc.  I'm reasonably certain they don't care about the arch and builds from that PPA are regularly blocking archive builds.
<slangasek> no; it's part and parcel of having a non-virtualized PPA
<skaet> infinity,  would want to know more about the contents of the revised linker patch.   Default should be for Q for that one, unless someone comes up with compelling reason why we can't live with what we have for now.   Possibly consider as part of a 12.04.1 plans.
<infinity> skaet: Nah, what we have is fine, it just misses some weird corner cases.
<skaet> infinity,  would it be possible to time the compiler change to go in as part of week 1 upload and synch up to the kernel changes going in then?
<slangasek> well, it means 12.04 is not binary-compatible with other distributions, or with 12.10
<infinity> (Not changing patches also means it's literally a 1-line fix to every compiler in the archive, which is much easier to swallow)
<slangasek> oh, or if you just mean the bigger upstream fix, yeah
<infinity> Yeah, sorry, I just meant the larger patch.
<infinity> skaet: I really don't want our release compiler to produce incompatible binaries with the world.
<infinity> skaet: If we have to, we have to, depending on how things work out time-wise.
<doko> ohh, then I'll have another fix for an ICE too
<infinity> skaet: But I'll also point out here that if a no-change rebuild of a compiler is too scary 1.5 weeks before release, then we can't really ever update it post-release, where it will get way less testing. :P
<infinity> doko: Trying to slide patches in with this won't help. ;)
<skaet> infinity,  if its just a rebuild of the compiler with that one line change,  concern level drops a bit.   Just don't like releasing with a kernel that isn't matching our compiler (although I understand it shouldn't matter in theory).
<slangasek> we really should stop hedging about this kernel sync non-problem
<slangasek> if making this change has any impact on the kernel, that's a serious kernel bug
<infinity> Or a serious toolchain bug.
<slangasek> and would cause problems after release as well
<infinity> Either way, the bug doesn't exist.
<micahg> slangasek: there's a flag on the PPAs that can be set to stop them from building on powerpc if the unity team doesn't need it
<slangasek> micahg: really?
<micahg> slangasek: yes
<slangasek> is that new?
<infinity> Yeah.
<skaet> infinity, so we're waiting on an discussion in progress right now or something else?    If it doesn't resolve this weekend,  what's the fall back?
<slangasek> mmk
<infinity> skaet: The fall back is "do nothing".
<slangasek> micahg: who has access to set that bit?
<doko> right, but apparently the unity team did opt in to build on powerpc
<micahg> slangasek: webops
<slangasek> ah
<infinity> skaet: (And fix it in updates, and suck up the fact that we shipped a broken compiler)
<slangasek> ScottK: ^^ so the unity team think they want powerpc, I guess you'd have to argue the case to the ppa owner
<infinity> skaet: But lots of us have a vested interest in this being solved on Friday.
 * skaet nods
 * infinity is tempted to build a gcc/glibc pair for every linker path that's been so far proposed, and just upload the right one after the meeting on Friday.
<infinity> Alternately, I could not think about it until Friday, and go do other useful things.
<infinity> Which sounds less stressful.
<skaet> dobey,  can you give some background on that nice big set of ubuntuone-* packages that have just landed in the unapproved -release queue?
<infinity> skaet: If they're like the one I approved earlier, they're just version bumps to a final and pretty release number.
<dobey> skaet: final release of ubuntuone projects to align with ubuntu final freeze
<dobey> infinity: some of them have a few changes
 * infinity is reviewing.
<infinity> dobey: Yeah, I'm accepting the ones without changes first, and reviewing the rest. ;)
<dobey> infinity: makes sense. i uploaded the ones without changes first :)
<dobey> and now, only 2 more to get uploaded
<ogasawara> skaet: I've been informed that ppisati has a fix for bug 963512?  Was curious if a ti-omap4 upload would be approved at this point in time?
<ubot2> Launchpad bug 963512 in linux-ti-omap4 "Latest kernel updates broke video on omap4" [Critical,Confirmed] https://launchpad.net/bugs/963512
<ogasawara> skaet: just want to set his expectations for how to proceed...
<infinity> dobey / skaet: Kay, change-free u1 uploads accepted, will review the rest shortly when the appservers catch up with diff requests.
<slangasek> it's a kernel package that exists solely to support omap4; if video doesn't work on it, I'd say that's rather important to fix
<slangasek> ogasawara, skaet: ^^
<ogasawara> slangasek: current workaround was just to back out the changes which broke it, but he's got a proper fix now
<skaet> ogasawara,  queue it up.  If there's a quiet window, we'll pick it up.
<ogasawara> skaet: I assume, he should upload to -proposed
<ogasawara> skaet: ?
<slangasek> ogasawara: so the kernel currently in precise is not broken?
<skaet> ogasawara, yes,  definitely to -proposed
<ogasawara> slangasek: correct, not broken.  just not entirely up to date.
<skaet> hmm...
<skaet> ogasawara, how does the not entirely up to date manifest itself?
<ogasawara> skaet: am getting details from ppisati...
<ppisati> here i am
<ogasawara> ppisati: hey, just want to confirm what the linux-ti-omap4 upload is going to contain...
<ogasawara> ppisati: from my understand the upload currently in the archive, 3.2.0-1411.14, is actually the 3.2.0-1411.12 upload since -1411.13 is what broke video.
<ogasawara> ppisati: and the -1411.13 upload was primarily a rebase on the main distro kernel ?
<ppisati> ogasawara: right
<tgardner> ppisati, , so essentially the current upload lags behind the main distro kernel by a number of stable updates ?
<ppisati> tgardner: yes
<tgardner> ppisati, are any of them that important for arm ?
 * skaet wondering what bugs that's reintroducing?
<ppisati> tgardner: it's latest master (-stable kernel updates) + same TI enablemenet bits that we always had
<ppisati> skaet: it's not reintroducing any bug, it's resolving 963512
<ppisati> skaet: since we never resolved it (we reverted to a previous kernel that didn't expose that problem)
<tgardner> ppisati, I'm wondering rather then ram this in at the last minute if it can wait for a normal stable update cycle
<ppisati> tgardner: well, we could do that, but there's one config diff that i would like to shove in, at least
<tgardner> ppisati, and that is ?
<ppisati> tgardner: 924419
<ppisati> tgardner: disable internal camera interface since the installer thinks there's a webcam attached, while it's not there (just the interface)
<ppisati> infinity: ^^^
<tgardner> ppisati, that one seems a bit more serious in that it affects installation, but is also not a very risky change.
<ogra_> bug 924419
<ubot2> Launchpad bug 924419 in ubiquity "oem-config detecting camera where no camera exists" [Medium,Incomplete] https://launchpad.net/bugs/924419
<ogra_> its not a biggie either, just ugly
<tgardner> ppisati, I assume you've already tested your rebase kernel somewhat ?
<ppisati> tgardner: tested on my new board
<tgardner> ppisati, with the config change too ?
<ppisati> tgardner: nope, didn't try that change yet, but we are not building a driver in that case
<tgardner> skaet, so, the stable patches that are missing in ti-omap4 that might have an impact are for net, ext4, nfs, and a bunch of usb. All of these are already in the main kernel.
<skaet> tgardner, so, basically we'll just be getting all the kernels closer to in synch wit some of the tested fixes already in main but not in the ti-omap4 version,  as well as getting video working.
<tgardner> ppisati, you might as well prep a pull request. I can always defer it until after release. you'll need an SRU justification in the bug for the config change.
<tgardner> skaet, correct
<tgardner> skaet, plus, we only have _one_ platform to test for which makes it a bit easier to detect regressions.
<skaet> tgardner,  indeed.  :)   prep it up for -proposed,  but lets defer on uploading and building until we know we have a quiet spot.
<tgardner> ppisati, ^^
<ppisati> ack, so i prep the pull req with video and camera fixes in (and relative buglink/SRU justification)
<tgardner> ppisati, yep
<infinity> skaet: Uploading it now would be fine, surely?  We can get it built and then copy when we feel appropriate.
<infinity> skaet: The only reason ARM buildds are "busy" is the rebuild test, I can free two up to build the kernel ASAP.
<skaet> infinity,  was hoping to see if we could get it in after the compiler change, so not need to rebuild it later.
<infinity> skaet: Are we really planning to rebuild all the kernels after the compiler rev? :/
<infinity> skaet: ARM's not special here, the compiler change won't affect the kernel.
<skaet> infinity,  will be doing it for the first week changes anyhow.
<infinity> Sure, but we want the ARM kernel to actually be fixed for the final images.
<infinity> Given that the one bug here is installer-related.
<skaet> infinity,  not sure i caught that there was an installer related bug in the set that tgardner said were already in main kernel.
<tgardner> skaet, it was mixed in that discussion. ppisati needs to disable a driver in order to fix the installer incorrectly detecting a video device.
<tgardner> skaet, bug #924419
<ubot2> Launchpad bug 924419 in ubiquity "oem-config detecting camera where no camera exists" [Medium,Incomplete] https://launchpad.net/bugs/924419
<infinity> skaet: Yeah, this upload is twofold.  Rebasing on the primary kernel's current version, and fixing the camera-in-installer issue.
<infinity> skaet: The former needs to happen anyway, and we want the latter for the images.
<skaet> Thanks tgardner.  Infinity,  if the compiler change won't affect ARM, then I can't see a good reason to hold off on it being uploaded to -proposed when its ready, and pocket copied over once we're comfortable.
<skaet> infinity, thanks for raising.
<tgardner> skaet, cool, I'll upload as soon as ppisati is ready
<infinity> tgardner: Danke.
<skaet> tgardner,  thanks.
<infinity> tgardner: Since it's heading to -proposed anyway, just toss -meta up at the same time, and we can just copy it all when it's consistent.
<tgardner> infinity, yep, will do
<ppisati> tgardner: i'm doing a couple more tests and then i'll pull req
<tgardner> ppisati, ack
<ScottK> slangasek: OK.
<infinity> dobey: So... What's the deal with this untranslatable string in u1-cp?
<infinity> dobey: Translations are done post-release too (we push langpacks in updates), there's no reason to do this, except if you're intentionally trying to pretend you didn't break string freeze. :P
<dobey> infinity: which untranslatable string?
<infinity> +# TODO: mark the following strings translatable after precise is released
<infinity> +UPDATE_TITLE = APP_NAME
<infinity> +UPDATE_SOFTWARE = ('There is a new update available.'
<infinity> +                   ' Would you like to install it?')
<infinity> dobey: ^
<dobey> infinity: ah. if it's the string i think you're talking about, it is only used on windows anyway
<dobey> indeed
<infinity> dobey: Sure, but why make it untranslatable?
<dobey> so i don't think it matters either way, because we're not installing any translations on there
<dobey> infinity: not sure why it wasn't marked as translatable.
<infinity> Just seems like the sort of string one might want localised.
 * infinity shrugs.
<micahg> could I please get an archive admin to fiddle the appropriate bits to push this through? bug 978571
<ubot2> Launchpad bug 978571 in natty-backports "Please backport puppet 2.7.1-1ubuntu3.6 (main) from oneiric-security" [Undecided,New] https://launchpad.net/bugs/978571
<ScottK> micahg: You need a backport accept?
<ScottK> I can do that.
<micahg> ScottK: no, I need it uploaded :)
<ScottK> OK.  That's not me then.
<dobey> infinity: was that shrug meant to be indicative that you'd be accepting u1-cp soon? :)
<infinity> dobey: No, I thought I'd make you suffer for a bit.
<micahg> infinity: can you upload my backport above?
<dobey> infinity: ah ok, just checking. ;)
<infinity> micahg: Just to natty?
<infinity> micahg: Or lucid too?
<micahg> infinity: natty and lucid
<micahg> both approved in the bug
<infinity> micahg: Kay, you only mentioned natty when you brought it up last, I think. :)
<micahg> infinity: that was ubot :)
<infinity> micahg: Oh, so it was.
<micahg> infinity: thank you much :)
<ScottK> Riddell: ^^^
<dobey> infinity: thanks for all the reviews btw
 * Riddell looks at strigi
<Riddell> ScottK: "(optional=templinst|arch=i386 powerpc)" recon that'll work on amd64?
<ScottK> Dunno.  It turned up missing on i386 when I test built.
<Riddell> let me try on amd64
<Riddell> ScottK: accepted
 * skaet --> errands,  biab.
<ScottK> Riddell: ^^^ The armhf build finished and was fine, so I think this'll be it.
<Riddell> ScottK: for strigi?
<ScottK> Yes.
<ScottK> (confirmed the symbols are fine on it, so should be fine for armel as well)
<ScottK> OK, I think Riddell fell asleep, so anyone else feel free.
<ogasawara> infinity: I've uploaded linux-ti-omap4 and linux-meta-ti-omap4 to precise-proposed for ppisati, if I could get those approved in the queue that'd be great.
<cjwatson> slangasek: partman-auto was primarily for the translation improvements, which are cumbersome to pull any other way, but I reviewed the recipe changes by eye and have trouble imagining a situation where they would break
<cjwatson> slangasek: the armhf bits are IMO mostly a non-issue, since all the armhf images we ship are preinstalled and AFAIK those don't use partman, although, OK, there's netboot
<cjwatson> slangasek: if it would make people feel better I can back out the changes to the default recipes temporarily?
<cjwatson> (FWIW, I did skip several installer merges that would have pulled in updated translations but that I considered too risky for other reasons - it wasn't just a blind bulk merge)
<slangasek> cjwatson: well, it is important to have netboot working; I believe it's the only image we have currently for armadaxp.  I don't know that anything needs backed out necessarily, I just wanted to be sure these recipe changes hadn't slipped under the radar somehow
<cjwatson> not under the radar, but I'm not surprised people wanted to ask
<cjwatson> I can't claim to have tested them directly, only eyeball-reviewed (and I made some corrections following that review, visible in bzr)
<slangasek> cjwatson: ok - provided then that you're satisfied the raised minima for partition sizes aren't wrong for Ubuntu, I'm happy to accept
 * cjwatson checks one more time
<cjwatson> I wonder about minimal server installs, is the only thing - I think those are supposed to fit under this
<slangasek> fit under as in, have a lower minimum disk requirement?
<cjwatson> yeah, well, <<900 anyway, I vaguely recall 500 being mentioned
<cjwatson> I think I'll back out the changes to recipes/atomic and recipes/home, on reflection.  recipes/multi is fine, if anything those are probably still too low so raising them is pretty unlikely to hurt
<slangasek> ok, rejecting the one currently in queue
<cjwatson> uploading a new version now
#ubuntu-release 2012-04-12
 * ScottK ^^^
<ScottK> That was me.
<cjwatson> cool, was waiting for that
<cjwatson> glib2.0 looks OK for precise; last call for objections before I copy
<ScottK> ^^^ There was already a sync in queue, so the direct upload was unnecessary.
<cjwatson> copied glib2.0 to precise
 * ScottK reviewed apport
<slangasek> partman-auto accepted
<micahg> do I need an FFe to switch from python-gobject to python-gi?
<ScottK> ^^^ was me.
<ScottK> infinity: It might not be a bad time to start to rebalance back towards armel from armhf.
<micahg> ScottK: do I need an FFe for the python-gi conversion?
<ScottK> Dunno.
<ScottK> I'd say do whatever you need to do and I'll sprinkle holy water on it as needed.
<ScottK> Don't screw up.
<infinity> The nux upload I just sponsored for rsalveti is necessary to make all the work done for compiz/unity GLES support on ARM not be a complete waste of time.
<infinity> If someone who isn't me wants to poke it and let it in, since I sponsored it.
<rsalveti> that will finally allow (once the compiz changes are in place by ogra_) to have a working unity 3d experience on ARM
<rsalveti> infinity: thanks for the upload btw
<infinity> rsalveti: "once the compiz changes are in place"?  Is 1:0.9.7.4-0ubuntu3 still not good enough?
<rsalveti> infinity: iirc ogra_ was updating compiz-plugins-main
<rsalveti> and I remember he was also fighting with a newer upstream update/rebase
<rsalveti> so not yet sure if current compiz version will be the one used at the release
<infinity> I should hope so.
<rsalveti> or if it might just be something for -updates
<infinity> Final freeze is tomorrow. :P
<rsalveti> yeah, then we should be good :-)
<jdstrand> can someone approve that ^
<jdstrand> it fixes bug #978297 (and by extension bug #978147)
<ubot2> Launchpad bug 978297 in apparmor "apparmor should quietly return success in a container" [High,In progress] https://launchpad.net/bugs/978297
<ubot2> Launchpad bug 978147 in lxc "rsyslogd fails to start in cloud template " [High,Confirmed] https://launchpad.net/bugs/978147
<jdstrand> so my comment in 978297 on testing performed. it is a simple patch
<jdstrand> s/so my/see me/
<jdstrand> meh
<jdstrand> see my
<skaet> jdstrand,  looks reasonable.  Thanks for getting the fix in.   approved.
<jdstrand> \o/
<jdstrand> skaet: thanks
<skaet> jdstrand,  is there an outlook on bug 969299?
<ubot2> Launchpad bug 969299 in apparmor "apparmor prevents dpkg-divert and localedef from working in a container" [Critical,Confirmed] https://launchpad.net/bugs/969299
<jdstrand> skaet: fyi, I will be sponsoring an upload for sbeattie for apparmor
<jdstrand> skaet: he will be able to answer questions on the bugs, but he'll contact you
<jdstrand> skaet: let me look
<skaet> thanks jdstrand.    could you please add the rls-p-tracking tag to it, if appropriate.
<jdstrand> skaet: to which, 969299?
<jdstrand> skaet: I think the workaround in lxc is what we will go with for precise. jjohansen was looking at this-- he should comment
<jjohansen> jdstrand, skaet: right basically the two patches serge came up with, that disables apparmor load scripts inside the container
<jjohansen> since apparmor does not support loading policy in the container for precise this is the cleanest solution
<jdstrand> jjohansen: this is the mediate_deleted bug
<jjohansen> no
<jdstrand> (969299)
<jdstrand> yes :)
<jdstrand> jjohansen: not talking about upstart. skaet asked about 969299 separately
<skaet> jdstrand, jjohansen,  understanding if we'll be fixing this or not, is what I'm trying to understand.  :)
<jjohansen> jdstrand: err, which bug did you want me to comment on? ah
<jdstrand> jjohansen: 969299/970647
<skaet> 969299
<jjohansen> skaet: no. The lxc adding the mediate_deleted flag to the profile is the work around for precise.
<jjohansen> so the lxc work around
<skaet> jjohansen, ok, can the bug milestone and priority for upstart be updated then to reflect this?
<jjohansen> jdstrand: I am still trying to figure out bug#970647
<skaet> Right now its critical,  which catches my attention ;)
<jjohansen> I expect to sru it, but it isn't release critical, it can make figuring failures tricky but does not cause failures
<infinity> s/upstart/apparmor/
<skaet> fair nuf,  milestone target should be precise-updates then.   Importance shouldn't be critical.
<jjohansen> skaet: bug#970647 isn't marked critical, 969299 is but we can not do anything more than the workaround lxc is using for precise
<skaet> for 969299.  :)
<jdstrand> infinity: the upstart bug is dealt with. we are talking about a different bug
<jdstrand> I'm going to mark the 969299 as wontfix for apparmor
<infinity> jdstrand: Yes, I know.  Hence the correction to someone mentioning milestone and priority for an upstart bug. :P
<jdstrand> we can sru 970647
<jjohansen> jdstrand: yes please
<jjohansen> jdstrand: I think we should be able to
<jdstrand> infinity: ah, read that the other way around
<jjohansen> it will be a kernel patch, and it will be something pushed upstream too
<infinity> jdstrand: Your sed runs backwards? ;)
<jdstrand> infinity: more that I read confusion in general and assumed you were confused too. I apologize
<infinity> ;)
<jdstrand> skaet: 969299 should fall off your list now
<skaet> :)
<infinity> rsalveti: Say, speaking of sponsored uploads, whatever happened to xbmc?
<skaet> thanks jdstrand, jjohansen.
<rsalveti> infinity: pull request sent to upstream by the debian maintainer, avik is working on getting the new patch set/debdiff tomorrow
<infinity> Mmkay.
<rsalveti> superm1 also knows the current status of that, hopefully we'll get it sorted over the next few days
<rsalveti> might be still good to get as sru
<infinity> rsalveti: Sure, it's unseeded universe, so there's a bit of wiggle room.  I'd *prefer* not to enable new arches as an SRU, but there's no technical reason we can't.
<rsalveti> yeah, should know better tomorrow, once avik updates the merge proposal
<rsalveti> will keep you updated
<infinity> Danke.
 * ScottK looks at nux
<ScottK> infinity: I'd appreciate it if you'd look at strigi.  It's a trivial diff.
<infinity> ScottK: I was waiting on an appserver to feed me a diff, cause I'm lazy. ;)
<infinity> ScottK: But I intend to look through the whole queue tonight, I'm up for a while working.
<ScottK> OK.  Thanks.
<ScottK> Strigi was uploaded 5 hours ago.  If you don't have a diff by now, I don't think you'll get it.
<infinity> Yeah.  I'm getting that impression. :P
 * infinity grabs the source.
<ScottK> In any case, nux is in.
<infinity> Thanks.
<ScottK> Part of the reason I want to get strigi in is that the previous upload isn't built on armel and powerpc yet, so if it can get in, it'll save doing it twice on the slow archs.
<infinity> Heh.
<infinity> Uhm.
<infinity> Maybe I'm just going cross-eyes, but this looks like the same symbol is being listed twice.
<infinity> Oh, no.  I'm just going cross-eyed.
<infinity> But.
<infinity> (optional=templinst|arch=i386 powerpc)_ZN10QDBusReplyI5QListI5QPairIb7QStringEEEC2ERK12QDBusMessage@Base 0.7.7
<infinity> ^-- Doesn't that nees the same s/i386 powerpc/!armel !armhf/ treatment?
<infinity> need, too.
<infinity> I can't type tonight, apparently.
<infinity> ScottK: I'm happy to be proven wrong, but the diff looks a bit suspect.
<ScottK> It should change from i386 powerpc to !armel !armhf (i.e. add amd64)
<infinity> ScottK: Yes, but it doesn't. :P
<infinity> ScottK: (My point is that that construct is in two symbols in a row, the diff only changes one of those)
<ScottK> Looking
<jdstrand> skaet: btw, what is the final freeze deadline? I know it is tomorrow, but what hour?
<infinity> My bet's 2100UTC, people seem fond of that hour.
<skaet> 2100 UTC
<ScottK> They aren't the same.
<infinity> ScottK: No, I know they're not the same symbol.
<ScottK> OK.
<ScottK> Only one of them came up in the build log with a change.
<jdstrand> infinity: they are fond of that, aren't they? :)
<jdstrand> skaet: thanks
<infinity> ScottK: I'm questioning that two nearly identically-named symbols are represented on a strange venn diagram of arches.
<skaet> infinity,  yup,  that gives enough time for builds to complete before the overnight build, and catch in the work day, without lots of requests for extensions.
<infinity> ScottK: But I guess we can let it in and see. :P
<ScottK> infinity: No, you're right.
<ScottK> infinity: Please reject and I'll upload again.
<ScottK> I can't tell you how many times I looked at that.  Thanks for a careful check.
<ScottK> Re-uploaded.
<infinity> symbols files hurt my head too, don't feel bad.
<infinity> Especially since I always stupidly edit them by hand.
<slangasek> cf. Russ's recent indictment of symbols files for C++ libs on debian-devel
<infinity> slangasek: Define recent?
<slangasek> last three months
<RAOF> Longish thread; âDo symbols make sense for C++â
<slangasek> http://lists.debian.org/debian-devel/2012/01/msg00671.html
<slangasek> rather, http://lists.debian.org/debian-devel/2012/01/msg00727.html
<infinity> ScottK: Looks gooder.
<ScottK> Great.
<ScottK> infinity: I did edit that one by hand too.
<infinity> And I reviewed by eye.
<infinity> Software be damned.
<slangasek> I use gimp for diffing
 * infinity mails magnets to London and marks the envelope "eglibc upload".
<infinity> But first, to Subway to fuel my evening.
 * ScottK took care of ^^^
<micahg> do flavors need UIFe's for their own packages?
<pitti> micahg: that's somewhat underspecified; but I'd say, it depends on the leads of that derivative being okay with it
<micahg> pitti: he made the commit ;), should I just remind them to update their docs as necessary?
<pitti> at some point we just need to update https://wiki.ubuntu.com/UserInterfaceFreeze
<didrocks> grrrrr at linaro again for not using the vcsâ¦
<didrocks> 3 times in less than a week,
<cjwatson> ^- ubiquity - giant diff, but mostly d-i stuff that's been approved already
<pitti> cjwatson: will wait a bit to get a diff, then review
<infinity> didrocks: Oh, for nux?
<didrocks> infinity: yeah, no coordination with us, and of course, the ppa for unity 5.10 release is now not working at all
<infinity> didrocks: How did it break your PPA?
<didrocks> infinity: well, newer version with a version incompatible for the ABIâ¦
<infinity> didrocks: (You can probably blame me for not committing to your branch, though... I can clean that up now)
<didrocks> infinity: I'm doing that, I'll then apt-get source from the ppa and copy the changes over
<infinity> Oh, you're already fixing it up?  Kay.  Sorry for the noise.
<pitti> didrocks: does that mean we'll need another full round of PPA builds and testing? Or can that happen in -proposed?
<didrocks> infinity: no worry, but between that and compiz/compiz-plugins-main on Friday, I'm tired of fixing linaro's breaking the ppa :)
<didrocks> pitti: no, the switch is only building on armel, but I doubt of how the change good is, knowing that unity has no support for opengles
<infinity> It works fine, AFAIK.
<pitti> didrocks: if that's causing too much trouble, we could also just revert the nux upload
<infinity> That was the whole drive for the compiz and nux changes.
<didrocks> infinity: it doesn't apparently, they have a huge branch that is under review upstream
<didrocks> infinity: so I doubt it's working :)
<cjwatson> urgh, forgot to bump installer seed to 3.2.0-23
<slangasek> "under review upstream"> should've landed last week?
<slangasek> (in Ubuntu)
<cjwatson> done, but it's possible jenkins will hate us and require alternate/server respins, depending on exactly how it works out
<infinity> didrocks: The backported stuff in Ubuntu works.
<didrocks> slangasek: no, we told them that we take compiz and compiz-plugins-main this cycle, but not nux nor unity
<didrocks> slangasek: as it was too late
<slangasek> ah
<didrocks> ok Vcs fixed, now fixing the ppa
<didrocks> infinity: so if they come with a bug unity patch for opengles, please ping me first ;)
<didrocks> (all fixed now, let's wait for newer testing)
<infinity> didrocks: Check.
<infinity> didrocks: This one wasn't particularly intrusive, and there were claims it actually made things work.
<didrocks> infinity: yeah, this one is fine, it's just a pity that it screwed the ppa for a while, but fortunatly, the upload was recent
<RAOF> Hm.  How come this https://launchpad.net/ubuntu/+source/mysql-dfsg-5.1/5.1.62-0ubuntu0.10.04.1 mysql-dfsg-5.1 update has ended up in -proposed, not -updates or -security?
<infinity> RAOF: You'd have to ask the security team, I imagine.
 * cjwatson -> Millbank
<micahg> RAOF: it needs more testing
<micahg> RAOF: https://lists.ubuntu.com/archives/ubuntu-devel/2012-April/035035.html
<RAOF> micahg: Ta.
<astraljava> Anyone from the release team able to look at three bugs with debdiffs on them? I understand they'd need to get in today before final freeze. Or is this the wrong place to ask?
<infinity> This is the right place.
<infinity> Are they large changes?
<astraljava> Thank you. Bugs are: bug #972749, bug #972781 and bug #973373
<ubot2> Launchpad bug 972749 in indicator-sound "Prefer pavucontrol over xfce4-mixer in ubuntustudio session" [Undecided,Fix committed] https://launchpad.net/bugs/972749
<ubot2> Launchpad bug 972781 in xfce4-volumed "Prefer PulseAudio when XF86AudioMute is used for ubuntustudio session" [Undecided,Fix committed] https://launchpad.net/bugs/972781
<ubot2> Launchpad bug 973373 in ubuntustudio-meta "package ubuntustudio-audio 0.90 failed to install/upgrade: subprocess new pre-installation script returned error exit status 1" [Undecided,Confirmed] https://launchpad.net/bugs/973373
<astraljava> infinity: No, quite trivial each.
<micahg> astraljava: you should've caught infinity when he was piloting earlier
<infinity> Indeed.
<infinity> But, as it turns out, I'm still capable of doing all the same things. :P
<astraljava> Oh? Why's that?
<infinity> Now, that said.  Reading just the bug titles, while the patches may be trivial, the changes aren't.
<astraljava> infinity: Right, anything particular you want to talk about, or are you rejecting some|all of them off-hand?
<infinity> astraljava: I haven't had a chance to actually look at the diffs or think about impact, I'll get back to you.
<infinity> astraljava: But things like changing default mixer applets and whatnot are pretty major changes, even if it's a 1-line code change. :P
<astraljava> infinity: Sure, I get that. I'll be around if you want to have a chat. :)
<pitti> ^ review appreciated (I uploaded)
 * pitti reviews the other queue items
<didrocks> so starting to push the whole unity stack (we will maybe have a bamf release a little bit later) including compiz and c-p-m. There is no ABI break for those, so I can push them directly
<didrocks> then, for nux/unity/unity-2d I will use -proposed once the release is ready
<infinity> pitti: Looking.
<infinity> pitti: Accepted.
<pitti> infinity: thanks
<micahg> pitti: can you give back the g* failures here: http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20120328-precise.html#ubuntustudio
<pitti> micahg: what do you mean with "give back"? they all built fine
<pitti> oh, I suppose the test rebuilds, yes
<micahg> pitti: huh? they failed in the rebuild
<pitti> I tried the archive
<micahg> no, rebuild :), I can do archive give backs
 * infinity does it.
<pitti> micahg: done
<pitti> infinity: ^
<micahg> thanks
<infinity> Or, pitti will beat me to it. :P
<micahg> still not sure what to do with the goffice rebuild failure, will have to think about it over the weekend
 * micahg delegates
<infinity> micahg: If our PCRE is UTF-8 clean, just patch that test out of goffice's configure?
<micahg> infinity: that's one option :)
<micahg> the weird thing is that it works in Debian
<micahg> and Debian doesn't have the test binary either, so I figure I'm missing something
<infinity> micahg: Really?
<infinity> micahg: That is weird...
<micahg> and it built the first time when the binary didn't exist either
<infinity> Well, maybe you're misreading the test, and it doesn't require pcretest at all?
<infinity> And maybe we really do have an issue the test is tripping on?
<infinity> That check is pretty straightforward, though...
<micahg> infinity: this is ugly, it's conditional on other tests failing which is probably why it works in Debian and worked in Oneiric
<infinity> micahg: Yeah, I'm seeing that the Debian buildds don't even run the pcre tests...
<micahg> neither did the oneiric build
<infinity> (Does that mean they also don't end up linking pcre?)
<infinity> That sounds like a bug.
<infinity> Oh, I see, it wants pcre iff some glib feature isn't there.
<micahg> yeah, not linked against pcre in Debian or Oneiric
 * micahg thinks we should switch channels
<infinity> So, the question is why does glib no longer have that feature?
<stgraber> skaet: We just found a critical bug in LTSP (ldm actually), caused by a typo in one of the scripts ending up breaking the environment of the thin client session. Fix has been commited upstream and we're expecting a bugfix release to land in Debian later today/tomorrow which we'll then sync in Ubuntu
<stgraber> skaet: so won't make it before final freeze but should be there shortly after. The fix is a trivial one liner.
<micahg> infinity: please give back goffice in the rebuild (or someone else)
<stgraber> micahg: looking at it
<stgraber> micahg: done
<stgraber> micahg: do you need the rebuild result quickly?
<micahg> stgraber: no, just not to show up (it should be fine now) as it's on the xubuntu and lubuntu ISOs
<stgraber> k
<doko> wie baue ich die treiber nochmal manuell?
<didrocks> slangasek: the gnome-session upload is just for you ^ ;)
<Riddell> so it seems KDE .pot translation templates haven't been generated for the whole of the cycle
<Riddell> this means we are missing lots of strings
<Riddell> to fix it I need to do a mass upload of everything KDE
<Riddell> and then a mass upload of all the language packs
<Riddell> any problems?  (besides taking up the build daemons for ages)
<seb128> Riddell, why do you need uploads? you can upload the pot directly to launchpad without a source upload
<Riddell> hmm
<seb128> Riddell, https://translations.launchpad.net/ubuntu/precise/+source/YOURSOURCE/+pots/YOURSOURCE/+upload
<Riddell> that's a million clicks rather than just scripting it
<Riddell> I'm asking dpm if it's possible in an easier way
<seb128> Riddell, well it's easier a million clicks or a millions builds and updates throwing at the archive,buildds,users
<seb128> easier->either
<Riddell> seb128: automated work >> manual work
<seb128> Riddell, annoyance for thousand of users >> annoyance for 1 devel
<seb128> Riddell, throwing ton of updates has a cost on buildd time, download time for users, etc
<Riddell> that's the price of using a development version
<micahg> bandwidth for everyone...
<seb128> Riddell, that devel is pre release frozen though
<infinity> Riddell: I'd rather not rebuild all of KDE if there's no actual sane reason.
<Riddell> infinity: translations are a sane reason
<seb128> Riddell, I would consider now is a time where you should rather script the pot upload to launchpad that abuse users and buildds
<infinity> Riddell: But, by your own admission, the rebuilds are just to get them into rosetta, and into langpacks.
<seb128> Riddell, you don't need source uploads for updating the templates
<Riddell> seb128: it can't be scripted
<Riddell> seb128: there is no other sane way to update the templates
<seb128> Riddell, it can easily be scripted to call $webbrowser $uri for you and be one click by pot
<seb128> it's like an half an hour job
<seb128> Riddell, just get the list of source, iterate the url I gave you before replace YOURSOURCE by the template name
<Riddell> < dpm> it would take me a whole day to manually upload them into Launchpad
<seb128> how many sources,templates are we talking about?
<seb128> come on, iterating over your sources list with a script calling https://translations.launchpad.net/ubuntu/precise/+source/YOURSOURCE/+pots/YOURSOURCE/+upload
<seb128> and doing 2 clicks
<Riddell> 50-150 sources, 100-1000 templates?
<seb128> if you do it for 100 sources it's less than an hour
<Riddell> no it's a lot more than an hour
<seb128> it takes you more than a minute to click 2 buttons?
<dpm> there are a *lot* of templates
<seb128> like pick the file, click the "upload" button
<dpm> Riddell, seb128, I've actually got a script to do uploads, but I haven't been using it in a while and so it remains untested. But perhaps we could use it: http://bazaar.launchpad.net/~dpm/ubuntu-l10n-tools/trunk/view/head:/ubuntu_l10n_tools/lp_l10n_upload/__init__.py
<dpm> it's part of the ubuntu-l10n-tools PPA
<seb128> well not my call, but I think throwing 150 KDE builds to the builders and to users on hard freeze day is not 0 cost either
<seb128> it might take a week for the armel builders to catch up
<Riddell> dpm: able to test it?
<dpm> Riddell, sure, but even if it works, I'll need some help with the list of templates/source packages. Do you have a source package with a single template I could test it against?
<bulldog98> dpm: rekonq?
<dpm> Riddell, bulldog98, if you tell me the source package (I assume it's rekonq) and give me an up-to-date .pot file, I can test it straight away
 * Riddell grabs
<Riddell> dpm: http://people.canonical.com/~jriddell/tmp/rekonq.pot
<Riddell> source: rekonq
<dpm> Riddell, ok, thanks, give me a few minutes to see if the uploader script still works and can be used
<stgraber> argh ... I specifically poked the ubiquity slideshow guy about getting UIFe before doing any slideshow change... and now that I'm ready to do a translation upload I see they changed a bunch of screenshots without documentation
<Riddell> stgraber: just reject them?
<stgraber> Riddell: well, I'm the one uploading the package ;) so I need to go through the changes extract the actual bugfixes, revert the rest, then merge the translations and upload
<stgraber> so quite a bit more than the 2 minutes I was hoping for it to take
<Riddell> yes manual operations are no fun to do
<pitti> infinity, stgraber, Riddell: I left a blurb about the gnome-session upload in https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/771896/comments/27, FTR
<ubot2> Launchpad bug 771896 in gnome-session "No way to save current session" [Low,Triaged]
<pitti> I also reviewed pkg-kde-tools, please don't accept yet
<pitti> (see pad)
<Riddell> pitti: right enough, rejecting pkg-kde-tools
<pitti> Riddell: cheers
<infinity> pitti: Yeah, I'm not really sure how anyone would even inject that variable into the environment.  Well, any "normal" user who doesn't understand how X/dm/session startup works.
<pitti> didrocks: ah, you're back
<pitti> didrocks: FYI, I left a comment in bug 771896
<ubot2> Launchpad bug 771896 in gnome-session "No way to save current session" [Low,Triaged] https://launchpad.net/bugs/771896
<didrocks> pitti: yeah, I was logging out/in to test the plumbings
<infinity> What was so wrong with have a UI tickbox that's off by default and warns against use?
<didrocks> pitti: looking
<infinity> So the "power users" can break what they like?
<pitti> session saving has never really worked the way it is implemented in g-session
<infinity> Yeah, it's never worked well, and I don't use it.
<pitti> it's spelled s-u-s-p-e-n-d
<infinity> But clearly, lots of people prefer a broken solution to no solution.
<didrocks> pitti: well, we discused it at UDS
<didrocks> pitti: slangasek made a session at the last minute for it and was fine with a hidden way to get it back for people wanting it
<pitti> and this causes so many weird bugs that we should just declare this broken and bury it for good IMHO
<infinity> pitti: To be fair, without ksplice, and with our 2-week kernel update schedule, suspend isn't a great option to many either. :)
<pitti> but *shrug*, as I said I won't veto it, but that env var approach seems rather undiscoverable
<RAOF> Do people *actually* prefer a broken solution, or do they *say* they'd prefer a broken solution? :)
<infinity> RAOF: I dunno, have you read the bug log?
<infinity> RAOF: There are a ton of people who talk about how awesome GNOME session saving was before we took it away.
<RAOF> Yes, but not recently.
<infinity> And, since I know it was always crap.
<infinity> They must like crap.
<infinity> The end.
<didrocks> pitti: well, I don't mind, it's not for me and I don't use it. slangasek was pretty willing to have a way to get it back and we really don't want to expose as it's completely broken if you switch between session for instance
<seb128> what didrocks said
<infinity> didrocks: I think the environment thing is a bit of a joke, TBH.  It's going to lead to weird forum HOWTOs on editing dm startup files in perverse ways that people will follow without knowing what they're doing.
<seb128> slangasek find the current gnome-session saving good enough that's it's make him spare time and be useful so he asked for a way to be able to turn it back on
<infinity> didrocks: If we're going to let them do it, just let them do it.
<didrocks> infinity: so, let's push it back. I did what was planned at UDS, that's all ;)
<seb128> yeah, that no option, too bad for Steve ;-)
<seb128> that->then
<infinity> I'm just saying that a mystery environment key isn't exactly an option. :)
<didrocks> infinity: what do you propose then?
<infinity> didrocks: Like I said, restore the tickbox to the UI, and add a "don't use this" warning?
<seb128> infinity, it's a secret "make slangasek happy" option :p
<seb128> infinity, we could change it by an username check :p
<didrocks> infinity: hum, not really, people will still use it without knowing and we will have even more people getting a broken state
<infinity> seb128: And a ton of people in the forums, apparently.  And following up to that bug.  And...
<infinity> didrocks: They'll use it anyway.
<didrocks> less user will use an env variable that the option I guess ;)
<infinity> didrocks: Look at the number of people who muck around to turn off global menus.
<infinity> didrocks: And the odds that even 2% of them know what they're doing in those conffiles seems slim.
<didrocks> but again, I don't care and don't have time to argue over it, I just did what we planned, reject if you want ;) now on unity
 * infinity shrugs.
<infinity> I'm passing on it, pitti's a desktop guy. :P
<infinity> Or, he can make vorlon have the final say.
<pitti> didrocks: as I said, I'm not vetoing it, I just question how useful it is
<infinity> I don't use GNOME session saving anyway, so it's moot for me, I'm just trying to figure out the best way to solve things for people who think it's "good enough".
<infinity> (Telling them they're wrong, while a GNOMEish answer, probably isn't helpful)
<didrocks> I really don't have the time to argue over it. I'll just have the filling I didn't promess something and didn't try to do it :)
<didrocks> feeling*
<seb128> infinity, slangasek's point is that the session saving is "good enough" that he spares him 5 minutes or reopening and replacing windows on screen when he needs to restart
<infinity> seb128: Yes, and lots of others agree.
<seb128> so he really wanted a way to opt in for users who really want
<infinity> seb128: (cf: the bug, and forum threads)
<infinity> seb128: I'm saying that a magical environment key isn't really helpful to any but the most technical users (or people who routinely copy and paste from random forum threads)
<seb128> we wouldn't give him an ui option though because we consider we shouldn't offer ui option for things we don't consider working well enough to be at that level
<seb128> well, at least if you deal with environment option we can claim you did stuff in an hackish way non supported
<infinity> seb128: If you can prove that the subset of "people who like the crappy session support" mostly overlaps with the set of "very technical people", then maybe it's a non-issue.
<seb128> when it's us who provide a checkbox we have an harder time to bail out
<micahg> ^^ pfb2t1c2pfb - debs match, drops dpatch in favor of source format 3.0
<infinity> That's the worst source package name ever...
<pitti> is that in base64 or something?
<micahg> pfb2t1c2pfb: convert pfb into more compressible format and back
<cjwatson> pfb to t1c to pfb
<infinity> Yeah, I can read the 2s.
<stgraber> uploaded ubiquity-slideshow-ubuntu, good luck to whoever reviews it... it took me md5sums to confirm the changes in the upstream branch were sane (for these I didn't revert)
<infinity> It's still an awful name. :P
<cjwatson> golang: that's for bug 979390
<ubot2> Launchpad bug 979390 in golang "[FFe] Update golang to 2:1-3 in Precise" [Undecided,New] https://launchpad.net/bugs/979390
<cjwatson> (not actually FFe, as ScottK said)
<ogra> someone should tell the maintainer that in dh_make -p the -p doesnt stand for password but for packagename :P
<ara> pitti, rickspencer3: have we made any decisions about whether we are going to recommend i386 or amd64 in the ubuntu.com/download page for Ubuntu Desktop?
<infinity> Didn't we have a bunch of sessions and a spec about switching to amd64 as the recommended default?
<didrocks> pitti: infinity: cjwatson: so all unity plumbings now uploaded (with libgnomedesktop3). What remains is nux/unity/unity-2d (and gnome-control-center for the hud configuration depending on unity-2d). So I'm just waiting a little bit to see if we can sneak a focus fix in unity first. Anyway, all this will be uploaded to -proposed
<pitti> ara: I'm not aware of an official decision
<cjwatson> we had a session about that, whose work items mostly haven't been done
<pitti> FWIW, I've run amd64 since hoary
<cjwatson> so I think status quo wins
<ara> :)
<cjwatson> https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-64bit-by-default
<infinity> Oh, yeah.
<infinity> None of that's solved.
<infinity> Cross-grades?  Really?
<infinity> That was an ambitious session.  I'm glad I didn't go :)
<pitti> didrocks: ok, I guess the lenses etc. are not API sensitive and can go already
<cjwatson> it mostly works in ubiquity, modulo bugs
<didrocks> pitti: right, they work with the older unity
<cjwatson> where "crossgrade" is "install over the top and bodge"
<infinity> Heh.
<pitti> didrocks: erk @ gnome-desktop3
<pitti> didrocks: does that "just" add that new API, or does it change the functionality of libgnome-desktop itself?
<didrocks> pitti: it doesn't add it as an API in fact, it set on the root window the right color as an X property
<didrocks> pitti: the patch was reviewed by desrt last week
<pitti> it looks quite expensive
<pitti> didrocks: libunity removes API, can you please confirm that this shouldn't go via -proposed?
<didrocks> pitti: well, it's the code that was in unity in fact
<didrocks> pitti: no, that's private headers (see changelog)
<didrocks> pitti: so the code in gnome-desktop was the one in unity, it just has been moved around and now set on the X root window. It's even possibly going upstream
<didrocks> and we avoid the race where everyone can get an orange color on all unity with the background
<pitti> didrocks: ok, thanks; would be nice to send it upstream, as it's quite large
<didrocks> pitti: yeah, desrt is on it, he wants to use it for gnome-shell :)
<pitti> and it's really looking like clutter like that
<pitti> ah :)
<seb128> didrocks, pitti: that can't really go upstream I think
<didrocks> seb128: he told so on Monday though?
<pitti> if that's unity specific, it should rather stay in unity
<seb128> didrocks, pitti: well, the set the x property stuff is upstream, but the maths are biased on the launcher side and quite an unity design choice
<seb128> so I'm not sure how much the computation can go upstream
<seb128> or if we need to keep the tweaks
<pitti> right, and that computation looks very expensive
<didrocks> seb128: right, but he wanted to give different option on the math in the upstream code
<didrocks> seb128: like unity, gnome-shell, from what I understood
<seb128> pitti, having it in unity means you get 2 code loading the same images and computing it
<seb128> so you increase your login time
<didrocks> pitti: well, we already have the computation in unity for 3 monthes
<didrocks> pitti: the issue is that it's not the place to have it as we can get the image from libgnome-desktop when we shouldn't
<didrocks> and so end up with blue indicators
<pitti> yes, but that doesn't help to convince upstream to take a much more expensive one :)
<didrocks> or blue colors
<seb128> didrocks, pitti: let's sort that after release
<seb128> desrt is on it in any case
<seb128> he wrote most that and upstream quite some bits already
<didrocks> thanks pitti :)
<savvas> Hi, is there any chance linux 3.3 to be included in precise? The updated acpi patches <http://tinyurl.com/7krlqgv> should be a good reason to do that. But the kernel is an important package and I have my doubts that anyone would approve such a change so late in development. :)
<Riddell> savvas: we're not the linux team, I think they're in #ubuntu-kernel
<savvas> ah, thanks :)
<pitti> savvas: FTR, not for precise final
<pitti> savvas: there are 3.3 packages which you can run, and 12.04.1 or .2 will have newer kernel releases optionally available for install
<savvas> ah good enough for me :)
<savvas> thank you!
<pitti> ^ review appreciated, I uploaded this
<stgraber> looking
<pitti> no diff yet
<stgraber> pitti: I think I'll go get some lunch and check udisk afterwards ;) still no diff
<stgraber> pitti: your version number seems a bit odd (lower than the previous changelog entry), though can be explained by -6 being UNRELEASED in Debian
<stgraber> rest looks good
<pitti> stgraber: yes, I don't want to make it higher than -6, as -6 is not released yet
<tjaalton> i'd like to push a newer gstreamer-vaapi (0.3.4 -> 0.3.6), which makes it work for cedartrail enablement
<tjaalton> still time before the freeze?
<tjaalton> should I file a ffe etc
<infinity> tjaalton: Toss a diff somewhere.
<infinity> tjaalton: Don't care about a formal paper trail as much as I do a proper review.
<tjaalton> infinity: ok, I'll put a changelog diff and diffstat firt
<tjaalton> first
<tjaalton> http://paste.ubuntu.com/926244/
<tjaalton> it's not exactly a small diff :/
<tjaalton> but this is somewhat fast moving code
<infinity> Oh dear.
<tjaalton> the package is new, added a couple of months ago
<tjaalton> so no fear of regressions compared to earlier releases :)
<infinity> tjaalton: Oh, yeah, nothing depends on it, just go for it.
<tjaalton> infinity: right, thanks
<tjaalton> and let's add "!!!", since it'll make vanhoof & jmleddy happy :)
 * pitti investigates our recent CD overflow
<pitti> ubuntu-wallpapers grew by 0.2 MB
<pitti> linux-firmware (Î 1.0 MB - 1.74: 26.7 MB   1.78: 27.7 MB)
<pitti> gvfs-backends (Î 0.7 MB - 1.11.5-1ubuntu1: 0.4 MB   1.12.0-0ubuntu5: 1.0 MB)
<pitti> gvfs-daemons (Î 0.2 MB - 1.11.5-1ubuntu1: 0.1 MB   1.12.0-0ubuntu5: 0.4 MB)
<pitti> seb128: ^ I guess those are due to dropping the patch for shared lib?
<seb128> pitti, likely
<pitti> apw: would you happen to know anything in linux-firmware which could be dropped or moved someplace else? this thing keeps growing..
<apw> pitti, it is likely to ... hmmm ... more and more drivers are pulling the firmware out
<apw> pitti, is this for CD space ?
<pitti> apw: yes, after beta-2 we broke the limit again
<pitti> we could perhaps also squeeze the wallpapers a bit again, but that alone won't suffice
<pitti> the alternates will get back into the limit with a fresh langpack build
<pitti> but that won't help the desktops
<infinity> What's this about gvfs not using shared libs?
<pitti> it was a workaround for bug 899858
<ubot2> Launchpad bug 899858 in oem-priority/precise "regression in gvfs to connect/browse using obex" [High,In progress] https://launchpad.net/bugs/899858
<pitti> or rather, that patch for the shared lib was buggy
<seb128> pitti, infinity: it's not a workaround, it's dropping a debian hack
<seb128> infinity, basically upstream override dbus-glib functions with a local copy, debian made a patch to make the local copy a shared lib, but that lead the random symbol resolution issues and having the non overwritten version loaded
<seb128> infinity, that code is going away next cycle
<infinity> Check.
<pitti> we need to reclaim 1.23 MB
<apw> pitti, unsure, we may have some older firmware in here that perhaps could move to a separate package, but i'll have to poke it to be sure
<pitti> apw: for example, it seems to have firmware for some old graphics cards, and we actually dropped some drivers in precise
<tgardner> ogasawara, infinity: looks like ti-omap4 is cooked and ready for promotion.
<apw> pgraner, who would know if we have machines with bnx2 cards in them in the la
<apw> lab ?
<pgraner> apw, no idea, I doubt anything does most of our nics are e1000e
<apw> pitti, tgardner is going to look at ripping some of the older firmware into a new package
<ogasawara> apw: you could maybe check hexr?
<apw> pgraner, i am sure it was QA who was complaining when the firmware was missing ... hmmm
<pitti> apw: cool, thanks; we found 0.6 MB of stuff to get rid of for now, so we'll still need some 600 kB
<tgardner> pitti, I think I can use modinfo to filter out unused legacy firmware. I think linux-firmware is getting sort of large with unused firmware anyways. its time to split it into a legacy and a current binary package.
<pitti> tgardner: if there is firmware which is not loaded by any module any more, I suppose we could just drop that?
<tgardner> pitti, right, but the trick is to figure out _which_ files are unused.
<pitti> tgardner: out of interest, how do you use modinfo for that? e. g. "modinfo phantom" does not show me that it wants phanfw.bin
<apw> apw@dm$ modinfo phantom | grep firmware
<apw> tgardner, damn
<tgardner> pitti, should n't that be 'modinfo be2net' ? though it doesn't show the firmware filename.
<pitti> tgardner: oh, I just guessed that it was phantom.ko that uses phanfw.bin
<infinity> pitti: "modinfo ipw2200 | grep firmware" for an example of it being useful.
<tgardner> pitti, try 'modinfo iwlwifi'
<infinity> So, walking the tree and collecting modinfo on everything should be simple enough.
<pitti> yes, I know that
<pitti> I was just wondering if that's sufficient
<tgardner> pitti, there is clearly some missing modinfo , but that will just provide opportunities to send patches upstream.
<apw> tgardner, so perhaps only if there is a firmware list for a module, we can use the prefix to reap similar ones
<tgardner> apw, that assumes a homogeneous naming scheme.
<apw> tgardner, yeah but i suspect we do if we only reap things with a common prefix
<pitti> yay, we found another 400 kB, so 200 kB to go
<seb128> pitti, you can probably kill 200k worth of changelogs or NEWS in gtk or something if really needed
<jelmer> thanks
<ScottK> Looking at bind9
<pitti> tgardner: so, please don't waste too much effort on this; if you find an obsolete firmware or two with a relevatn size (i. e. >= 100 kB), that's sufficient
<pitti> the more the better, of course, but no need to spend a day on this, or introduce a package split, etc.
<tgardner> pitti, well, it'll keep coming up in the future unless we decide to just abandon the standard CDROM size limit.
<pitti> tgardner: we already did
<pitti> tgardner: sabdfl approved 750 MB USB media next cycle
<tgardner> pitti, um, so its only an issue for this cycle ?
<pitti> tgardner: but we need to make the 12.04 images fit
<pitti> tgardner: that's the most pressing one, anyway
<pitti> tgardner: that's not to say that it wouldn't be useful to put a script into l-f that checks for obsolete firmware files
<tgardner> pitti, I've already got the infrastructure script in the kernel package that I can use to list firmware files, so I'll spend a couple hours on it at least.
<cjwatson> I'd say that for precise we don't have much time to debug hardware support breadth issues caused by dropping firmware, so it'd be better not to do anything non-trivial there for precise ...
<pitti> yes
<tgardner> there are some obvious candidates just among the iwlwifi ucode files. at least 3 400K files could be dropped.
<pitti> tgardner: wow
<pitti> tgardner: if these are not used by any module any more, we are back in the game already
<tgardner> pitti, since I don't have to worry about older kernel support, I think we're pretty safe removing them.
<pitti> tgardner: ah, you mean supporting running precise with e. g. a lucid kernel?
<tgardner> pitti, right.
<tgardner> pitti, I only have to support newer kernels, e.g., the LTS backports going forward
<cjwatson> ah, yes, indeed
<pitti> tgardner: perfect
<tgardner> is there a bug already created about oversize linux-firmware ?
<pitti> tgardner: no, but I can create one if you need it for bookkeeping
<tgardner> I'll need it for the upload. skaet likes to see things tracked :)
<pitti> tgardner: filed bug 979887
<ubot2> Launchpad bug 979887 in linux-firmware "Remove some obsolete firmware to reduce package size" [Undecided,New] https://launchpad.net/bugs/979887
<tgardner> pitti, ack
<pitti> ^ shrinks from 412 kB to 80 kB
<pitti> if someone can review in a bit?
<pitti> (it'll probably get smaller after pkgbinarymangler even)
<pitti> so that's ~ 300 kB from hwdata, 400 kB from dropping rarian-compat, and we should get back 600 kB with the next LibO upload
<stgraber> pitti: I'll take your hwdata and you take my edubuntu-live? :)
<pitti> if we also shrink linux-firmware by 1 MB, we can get tomorrow's images back in size, and have a safety margin with LibO
<pitti> stgraber: deal!
<stgraber> I posted some details in bug 966294 as there's a decision that the release team needs to make there
<ubot2> Launchpad bug 966294 in gstreamer0.10 "gstreamer hangs when accessing webcam (on specific hardware)" [High,In progress] https://launchpad.net/bugs/966294
<stgraber> skaet: ^
<pitti> I thought slomo OKed reverting the patch?
 * ScottK looks at postfix
<seb128> pitti, he said he want to have a look
<seb128> pitti, he didn't really gave an opinion on reverting part of that commit, he said he needs to understand the issue first
<stgraber> right, I didn't get a definitive opinion from it on whether I'd break stuff by reverting it
<stgraber> and I don't know gstreamer so I'm assuming I very well might break some stuff by doing it
<cjwatson> I'm inclined to agree that any regression there will be easier to fix than busted installation media
<cjwatson> it's a tough one though, I wonder how long we can get away with waiting
<seb128> well slomo just got pinged for the first time an hour ago
<seb128> let him a bit of time maybe?
<pitti> would be interesting to check when we got the commit that is to be reverted
<seb128> pitti, you mean?
<seb128> pitti, we have the commit which created the issue
<pitti> seb128: if we only got that offending patch into the distro three weeks ago, then it can't hurt much to revert it
<seb128> oh
<stgraber> pitti: Looking at hwdata, is pci* only matching pci.ids?
<stgraber> seb128, pitti: The bug appeared in the archive in December
<slangasek> seb128: he wants a couple of days; that's time that certain folks in QA can't do manual testing, and leaves us less time to /detect/ any regressions that happen...  surely it would be better to take it sooner rather than later to get the extra time to smoke test?
<stgraber> when we switched from 0.10.35-1ubuntu1 to 0.10.35.2-1
<seb128> slangasek, your call, I feel uncomfortable backing out a commit we have no understanding about without having somebody who knows gstreamer saying he feels ok with it
<seb128> other commits might depends on it and it might break video player or rhythmbox or whatever else for what we know about
<seb128> -about
<slangasek> certainly
<seb128> slangasek, I've pinged slomo to try to figure how he feels about reverting that commit or part of it
<slangasek> but we'll at least know what breaks and can revert those... and as cjwatson says, it's unlikely anything breaks as bad as the installer hanging
<slangasek> er, can revert the change again if necessary
<seb128> sure
<seb128> I would rather have somebody who understand the code and the issue come with a suggestion, than a random guess stab reverting a commit without having a clue of what sideffects that might have
<seb128> and yes I appreciate that doesn't give us a good solution or way out :-(
<seb128> slangasek, let's wait for slomo to comment at least and try the revert if he's ok with it?
<slangasek> ok
<stgraber> pitti: I'm happy with hwdata (confirmed that the pci* only matches pci.ids so we're not dropping random files with the change)
<pitti> stgraber: thanks, I'll accept
<pitti> seb128, slangasek: so in the worst case we could back it out from final, and reintroduce it in -updates ?
<pitti> btw, if we ever need another 1.5 MB of CD space, we could drop libc-dev-bin's Recommends: manpages-dev
<pitti> we currently install that by default
<pitti> infinity: ^ as you are about to do an eglibc upload..
<scott-work> i've been told there are some concerns about the ubuntustudio-default-settings package?  specifically about the inclusion of an *.svg
<scott-work> i am very anxious and motivated to resolve this issue as soon as possible
<scott-work> does anyone know about this situation?
 * skaet catching up on the backscroll of the gstreamer issue. 
<seb128> ^ that disable the "report a bug" entry for release
<seb128> slangasek, pitti: ok, slomo says to revert the commit, though the whole commit not only the part suggested on the bug since that would break stuff
<pitti> skaet: FAOD, I planned to turn off apport and kerneloops next Tuesday or Wednesday, together with the final langpack upload; sounds ok?
<skaet> thanks slangasek, stgraber, pitti, seb128 re: gstreamer.
<stgraber> seb128: ok, I'm digging my other debdiff (full revert of the commit), will re-test (I know it worked when I tried earlier, but still) and will upload
<skaet> pitti, next Tuesday witht he final langpack upload sounds good.
<skaet> thanks.
<seb128> stgraber, thanks
<skaet> stgraber,  possibly send email to kan hu (linaro), who has some expertise on gstreamer, and might be able to provide a sanity check/watch out for... comments.
<seb128> wth? why does the queue has "diff from 1:3.4.0-0ubuntu2 to 1:3.4.0-0ubuntu7" for g-c-c
<seb128> i.e not with the current revision but 5 revisions back
<ScottK> quickly accepted quickly.
<skaet> :)
<didrocks> skaet: unity is just checking we fixed a last crash and then, pushing unity and unity-2d which are the latest in the stack
<didrocks> gnome-control-center (above ^) is also part of the unity changes btw, if someone can review it :)
<skaet> didrocks,  please push to -proposed when they're ready.  Definitely want to get this built and included as soon as possible.
<didrocks> skaet: yeah, I want the crash to be confirmed to be fixed by 3 person on the 3 who got it
<didrocks> skaet: but all seems fine, we are already after a week of testing :)
<didrocks> nux should be ready in -proposed, so then, we can fire off unity and unity-2d ASAP
<didrocks> the rest of the stack is already in precise (was not ABI break)
<skaet> thanks didrocks. :)
<didrocks> yw :)
<jdstrand> skaet: fyi, tseliot will be uploading a fix for bug #959842 sometime today. it is likely something you want to track
<ubot2> Launchpad bug 959842 in nvidia-graphics-drivers "root escalation via /dev/nvidia0" [Critical,In progress] https://launchpad.net/bugs/959842
<skaet> thanks jdstrand
<jdstrand> skaet: also, tyhicks will be uploading a security fix for samba later today
<SpamapS> Hey canwe squeeze in a FFE for kvm linked to librbd?
<skaet> is there a bug number for the SAMBA one?
<jdstrand> yeah, getting it
 * SpamapS will file the FFE bug momentarily
<jdstrand> skaet: 978458
<skaet> SpamapS,  depends on scope of impact and regression potential.
<SpamapS> regression potential is near zero
<SpamapS> literally just links a new library
<ogra_> hmm, given i'm patch piloting today, should my uploads go to proposed rather than to the archive for the sponsored bits ?
<SpamapS> hallyn: would you say there is any risk to linking to librbd?
<hallyn> SpamapS: I would say I'd like to test it!
<hallyn> Ideally, answer is no
<hallyn> link against it, but the library won't mess with you unless you're using it
<SpamapS> hallyn: didn't you upload to a PPA?
<hallyn> but we'll be change the source coverage a bit with configure flags presumably
<hallyn> SpamapS: no
<hallyn> I uploaded the patches the rbd folks wanted, and that's in the archive
 * SpamapS goes afk for a moment
<hallyn> SpamapS: I thought you were doing the patch to link against rbd and enable it?
<stgraber> skaet, seb128: right, full revert of the commit built and works here. I'll give the diff to slomo as it's a manual revert (too many changes for a reverse diff to apply)
<seb128> ok
<SpamapS> hallyn: I have one, yes :)
<jdstrand> skaet: fyi, I just sponsored apparmor for sbeattie that should fix all the rls-p-tracking bugs, LXC fixes and updating some documentation
<Riddell> skaet: I need to upload 32 packages to fix their translations
<Riddell> dpm can confirm
 * ScottK will review.
<skaet> thanks jdstrand
 * skaet smiles to see some of those off the list... :)
<skaet> thanks ScottK for handling the translation reviews.
<jdstrand> skaet: yes-- we are smiling too :)
<stgraber> jdstrand: lxc fixes, yay!
<cjwatson> Riddell: I'm sure I've done uploads to Launchpad Translations recently without having to do package uploads
<jdstrand> :)
<stgraber> speaking of lxc, hallyn is planning a bugfix lxc upload for before-final-freeze. I'll do the review when it hits the queue.
<cjwatson> I did debian-installer translation uploads this way a month or two ago
<ScottK> Riddell: I think we want Bug 979824, but since it would involve a plymouth upload, I think it should have some discussion here.
<ubot2> Launchpad bug 979824 in plymouth "UI Freeze exception for kubuntu splash theme" [Undecided,Confirmed] https://launchpad.net/bugs/979824
<hallyn> stgraber: and there is one more new one which i'm hoping utlemming will have a fix for, though that one is probably ok to sru
<dpm> Riddell, ack, plus the subsequent kde-l10n-* uploads
<cjwatson> There's likely to be a plymouth upload at some point, one way or another
<hallyn> (bug 979996)
<cjwatson> dpm: couldn't you get the upload tools to work?
<ubot2> Launchpad bug 979996 in lxc "ubuntu-cloud template can't find .img" [Undecided,New] https://launchpad.net/bugs/979996
<cjwatson> I'm using lp:~jtv/lp-translations-tools/trunk
<dpm> cjwatson, I did, and I could upload ~700 out of ~800 templates, but LP only allows uploading templates that are already in LP, for new ones to be created, the source package needs to be uploaded
<Riddell> dpm: I think I'll do kde-l10n tomorrow to make sure the packages are all through launchpad?
<dpm> ok
<cjwatson> dpm: hmm, ok
<cjwatson> at least that cuts the number down
<cjwatson> Riddell: err, can't these go through -propossed?
<cjwatson> -s
<Riddell> cjwatson: precise-proposed rather than just precise?
<cjwatson> yes
<skaet> yes
<cjwatson> that way arch all/any skew in the builds doesn't leave us with uninstallable packages on some architectures
<cjwatson> kdepim for instance will have that problem if i386 builds before the rest
<Riddell> ok I'll do a mass reject then
<cjwatson> sorry, but I do think it will make life more reliable
<cjwatson> I suppose I should just check that translations work right for -proposed
<SpamapS> ok, so I need an approval on this FFE: https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/932896
<ubot2> Launchpad bug 932896 in ceph "[FFE] Should use libnss instead of libcrypto++" [High,Fix committed]
<SpamapS> so I can upload a new version of ceph so we can pull librbd and librados into main, so that kvm can be linked against them
<cjwatson>         valid_pockets = (
<cjwatson>             PackagePublishingPocket.RELEASE, PackagePublishingPocket.SECURITY,
<cjwatson>             PackagePublishingPocket.UPDATES, PackagePublishingPocket.PROPOSED)
<cjwatson> cheesy, but yeah, translations in -proposed should work
<SpamapS> https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/904834
<ubot2> Launchpad bug 904834 in qemu-kvm "[FFE] Build qemu-kvm with RBD support" [High,In progress]
<SpamapS> Just an FYI, still working on the patch/upload but wanted to make sure you guys know its incoming
<hallyn> SpamapS: shall i fire up my testbed?  Do you have a patch I should test?
<SpamapS> hallyn: It would be great if you could. I'm about ready to start my own sbuild
<skaet> SpamapS, thanks.   If testing proves it safe,  and scope is as you say,  yeah should be ok.
<SpamapS> Packaging branch status: OUT-OF-DATE
<SpamapS> *argh*
 * skaet --> shifting locations, biab
<stgraber> I'll be off for dinner soon and back a bit later to look at lxc.
<stgraber> I uploaded gstreamer to the queue now, haven't heard from slomo yet though
<hallyn> stgraber: ok, package pushed fwiw
<ScottK> micahg: I see in Bug 979986 that opensc has a firefox module. Is mozillateam aware and OK with us shipping that?
<ubot2> Launchpad bug 979986 in opensc "[FFe] Please merge opensc 0.12.2-2 (universe) from debian unstable" [Undecided,Triaged] https://launchpad.net/bugs/979986
<stgraber> hallyn: ok, might even have a look before dinner then :)
<SpamapS> while I work on the kvm build, I still need approval for FFE bug 932896
<ubot2> Launchpad bug 932896 in ceph "[FFE] Should use libnss instead of libcrypto++" [High,Fix committed] https://launchpad.net/bugs/932896
<tgardner> pitti, I was able to shrink nic-firmware a bit as well:
<tgardner> -rw-rw-r--  1 rtg rtg  27M Apr  3 12:54 linux-firmware_1.78_all.deb
<tgardner> -rw-r--r--  1 rtg rtg  22M Apr 12 09:59 linux-firmware_1.79_all.deb
<tgardner> -rw-rw-r--  1 rtg rtg 6.6M Apr  3 12:54 nic-firmware_1.78_all.udeb
<tgardner> -rw-r--r--  1 rtg rtg 5.7M Apr 12 09:59 nic-firmware_1.79_all.udeb
<tgardner> -rw-rw-r--  1 rtg rtg 324K Apr  3 12:54 scsi-firmware_1.78_all.udeb
<tgardner> -rw-r--r--  1 rtg rtg 324K Apr 12 09:59 scsi-firmware_1.79_all.udeb
<Riddell> ScottK: packages for your reviewing pleasure
<ScottK> Thanks.
 * Riddell out for a few hours, text or phone me if you need me
<ScottK> Riddell: I think the plymouth theme is the one big thing left.
<micahg> ScottK: looking
<stgraber> can an archive admin reject lxc? an improved version will be uploaded by hallyn very soon
<jdstrand> I'll do it
<jdstrand> be chance, I was reading the diff :)
<jdstrand> s/be/by/
<stgraber> cool
<jdstrand> stgraber: done
<stgraber> the current one isn't wrong but would show an error message to the user that may interpret it as a bug, so better add some checks in there
<zul> can someone review swift please?
<doko> could the release team please have a look at bug 979923? I'd like to schedule no-change uploads for universe before the weekend
<ubot2> Launchpad bug 979923 in python2.6 "Python 2.6 and several virtual packages are still available in 12.04" [High,Confirmed] https://launchpad.net/bugs/979923
<pitti> doko: sounds fine to me
<pitti> doko: we still have a large buildd lag, so over the weekend sounds better than starting it now
<tgardner> pitti, cjwatson: uploaded linux-firmware
<doko> pitti: then I'll self-approve these when I do these on Sat or Sun
<pitti> doko: although they are mostly universe, so mostly shouldn't get in the way
<pitti> doko: WFM
<pitti> tgardner: \o/, thanks
<pitti> Riddell: why are all these .pot rebuilds in -proposed?
<stgraber> pitti: see 15:46 UTC
<pitti> stgraber: ack
<pitti> -proposed has a higher build prio, though, so if we accept the lot now, we'll also starve other builds
<hallyn> SpamapS: patch url?
<SpamapS> https://bugs.launchpad.net/ubuntu/precise/+source/qemu-kvm/+bug/904834/+attachment/3053871/+files/enable-rbd.debdiff
<ubot2> Launchpad bug 904834 in qemu-kvm "[FFE] Build qemu-kvm with RBD support" [High,In progress]
<SpamapS> hallyn: ^^
<hallyn> thanks
<SpamapS> still waiting on FFE approval for the CEPH switch from crypto++ to libnss
<SpamapS> bug 932896 .. please?
<ubot2> Launchpad bug 932896 in ceph "[FFE] Should use libnss instead of libcrypto++" [High,Fix committed] https://launchpad.net/bugs/932896
<hallyn> heh, will shut up about tabs/spaces
<SpamapS> hallyn: I know.. I hate that
<ScottK> Done.
<stgraber> wow, I'm really impressed at how well that hackish flood protection works, no more kick for excess flood!
<SpamapS> hallyn: Supported formats: vvfat vpc vmdk vdi sheepdog rbd raw host_cdrom host_floppy host_device file qed qcow2 qcow parallels nbd dmg tftp ftps ftp https http cow cloop bochs blkverify blkdebug
<SpamapS> hallyn: it at least thinks it can do rbd :)
<pitti> stgraber: does it rate-limit itself?
<hallyn> SpamapS: still rebooting before building with your patch
<pitti> good night
<stgraber> pitti: yeah, it sleeps for 2s after it pasted 5 items in less than 5s (IIRC)
<stgraber> pitti: that's not technically following the IRC spec but it's apparently limiting it enough that it doesn't hit the server flood detection code anymore :)
<stgraber> pitti: good night
<skaet> good night pitti,  thanks.
<stgraber> lxc looks good, can an archive admin please accept?
 * ScottK looks
<ScottK> stgraber: Done.
<stgraber> ScottK: thanks
<zul> can someone reject the nova upload please
<ScottK> zul: I don't see one in queue.
<zul> it should be there soon i think
<ScottK> OK
<tseliot> can anybody approve nvidia-graphics-drivers, please? (it contains a security update)
<ScottK> Sure.
<ScottK> It's not like we have a real choice on that one.
<micahg> ScottK: mozilla plugin doesn't appear to be built for opensc
<ScottK> micahg: OK.  There was a mention of it in the FFe for opensc that just got approved. It might be worth a check to make sure it didn't suddenly grow one.
<micahg> yeah, I built the package, one isn't installed anywhere
<tseliot> thanks!
<ScottK> tseliot: Done
<ScottK> micahg: OK.  Great.
<zul> ScottK: there it is
<tseliot> ScottK: thanks
<ScottK> zul: rejected.
<micahg> ScottK: thanks for flagging
<ScottK> No problem.
<zul> ScottK: thanks
<skaet> thanks ScottK, tseliot
<ScottK> You're welcome.
<cyphermox> please reject the evolution-exchange upload, something went wrong
<ScottK> Looking
<ScottK> cyphermox: Done
<cyphermox> ScottK: thanks.
<ScottK> You're welcome
<hallyn> SpamapS: no regressions found in test-qemu.py or test-libvirt.py on my box \o/
<hallyn> i'll do a long guest install now too
<SpamapS> hallyn: awesome! I got qemu-image create to create an RBD based image at least.. haven't tried to do much else though.
<SpamapS> Now if only somebody could please look at the CEPH FFE bug 932898
<ubot2> Launchpad bug 932898 in ceph "[MIR] ceph" [Undecided,In progress] https://launchpad.net/bugs/932898
<SpamapS> err bug 932896
<ubot2> Launchpad bug 932896 in ceph "[FFE] Should use libnss instead of libcrypto++" [High,Fix committed] https://launchpad.net/bugs/932896
<SpamapS> sorry that was the MIR bug blocked on the FFE
<skaet> slangasek, infinity - could one of you look at 932896?
<hallyn> SpamapS: don't suppose you have plans to write a short rbd howto (for serverguide or wiki inclusion)?
<SpamapS> hallyn: http://ceph.newdream.net/wiki/QEMU-RBD
<ScottK> slangasek: If I upload the proposed plymouth change for the Kubuntu splash update, can you review it?
<slangasek> ScottK: can do, though fyi there's another plymouth upload in the works for tomorrow - maybe it's better to just commit for now and have a single upload?
<ScottK> Yes.  Sounds good.
<ScottK> slangasek: I'm sending yofel over to chat with you about it (I don't have the code and I don't know if he has rights to the branch.
<slangasek> ok
<slangasek> SpamapS: question for you on bug #932896
<ubot2> Launchpad bug 932896 in ceph "[FFE] Should use libnss instead of libcrypto++" [High,Fix committed] https://launchpad.net/bugs/932896
<SpamapS> slangasek: yes?
<slangasek> no, I mean there's a question for you /on/ bug #932896 ;)
<slangasek> sorry for my ambiguous preposition up on
<didrocks> unity and unity-2d uploaded (do not forget metacity as well which is waiting) all that in -proposed.
<ScottK> zul: Is there an FFe for the package split in quantum?
<zul> ScottK:  no should there be?
<ScottK> Yes.
<zul> ScottK: k
<ScottK> zul: Mostly what it needs is a documentation trail and an archive admin to volunteer to do the binar New review (not me).
<zul> ScottK: cool gimme a sec
<zul> ScottK:  https://bugs.launchpad.net/ubuntu/+source/quantum/+bug/979192
<ubot2> Launchpad bug 979192 in quantum "FFE: Separate agent binaries in different packages" [Medium,New]
<ScottK> Daviey: ^^^ would you please look at 979192?
<SpamapS> slangasek: answer for you on bug 932896 (from Sage Weil, author of CEPH ;)
<ubot2> Launchpad bug 932896 in ceph "[FFE] Should use libnss instead of libcrypto++" [High,Fix committed] https://launchpad.net/bugs/932896
<slangasek> SpamapS: FFe granted
<SpamapS> slangasek: yaaaay
<SpamapS> slangasek: you're on a roll, want to also approve this one?: https://bugs.launchpad.net/ubuntu/precise/+source/qemu-kvm/+bug/904834 ?
<ubot2> Launchpad bug 904834 in qemu-kvm "[FFE] Build qemu-kvm with RBD support" [High,Fix committed]
<SpamapS> slangasek: 932896 was a blocker for librbd going into main.. so pending jdstrand's final approval, ceph should enter main, and 904834 can then be uploaded. :)
 * jdstrand looks
<tyhicks> slangasek: Hello
<tyhicks> slangasek: Have a bit to chat about getting an updated samba into Precise?
<jdstrand> fyi, ceph looks fine to me
<jdstrand> (commented in the bug)
<tyhicks> I've attached a (tested) debdiff for Precise to bug 978458
<ubot2> Launchpad bug 978458 in samba "CVE-2012-1182: "root" credential remote code execution" [High,In progress] https://launchpad.net/bugs/978458
<tyhicks> jdstrand has sponsored the debdiff and jelmer has +1'ed it
<tyhicks> If someone from the release team can find the time to take a look and accept it for Precise, I think it would be very worthwhile since it closes a large security hole
<jdstrand> slangasek, SpamapS: ^ (fyi, ceph looks fine to me)
<slangasek> SpamapS: qemu-kvm acked
<slangasek> tyhicks: please upload the samba package if you haven't already; should  go to -proposed
<slangasek> oh, it's in unapproved -release
<tyhicks> slangasek: right
<highvoltage> yay
<slangasek> hmm, will cause installability due to build skew... let me see
 * micahg suggests rejecting and reuploading to -proposed
 * highvoltage 's collueges has been bugging him for new samba
<jdstrand> slangasek: I can delete and retarget
<slangasek> jdstrand: yes please
<jdstrand> slangasek: I figured since we didn't hit final freeze yet 'precise' was ok
<jdstrand> rejected
<tyhicks> thanks jdstrand
<slangasek> jdstrand: cf. kate's last announce mail about using -proposed for things that cause archive uninstallabilites
<slangasek> this qualifies :)
<jdstrand> slangasek, tyhicks: ok, samba uploaded to precise-proposed
<jdstrand> and there is your proof :)
<tyhicks> thanks, jdstrand :)
<jdstrand> slangasek: assuming this goes through, does the release team do a pocket copy or should we be watching for it?
<jdstrand> (for the builds to finish)
<maxb> Hi release team. I've just ended up in the middle of a conversation in #svn-dev about whether it's still plausible to update subversion from 1.6.17 to 1.6.18 in precise. The rationale is repository corruption fixes. There *are* other changes in the upstream point release, but they appear pretty conservative. Details are in bug 980087. If someone has a moment, could you offer an initial "Yes if you move quickly" or "No way, we insist on a
<ubot2> Launchpad bug 980087 in subversion "Update to 1.6.18 to fix fsfs repository corruption issues" [Undecided,New] https://launchpad.net/bugs/980087
<maxb> targeted backport if anything" prognosis?
<slangasek> jdstrand: release team should take it
<jdstrand> cool
 * jdstrand hands conversation off to tyhicks 
<micahg> maxb: I just sent someone to #ubuntu-server to look for someone to do the update (assuming it's bug fix only)
<tyhicks> I'll be around, so ping me if/when you have questions
<micahg> and there he is :)
<maxb> micahg: Right, so updating to 1.6.18 is still within the realms of acceptability at this stage?
<maxb> It's bugfix only, but the bugfixes vary in criticality
<maxb> As far as actually preparing the package goes, I could do that
<micahg> maxb: IANA release team member, but there seems to be some severe fixes in there and we're before final freeze (for another hour or so), Daviey would probably be the best person to ask
<maxb> Right. Well, there's not going to be a package by final freeze, but I'll see if I can sort one out in the next 24h if no-one else does or tells me it's too late
<maxb> (but I'm not a developer, so I'd still need a sponsor)
<micahg> maxb: it impacts the server image most, so you'll want to talk to Daviey about it
<maxb> I imagine he's been pinged enough by this conversation, I'll wait and see :-)
<micahg> also on Kubuntu dvd
 * micahg wonders if infinity has a Daviey incantation
<slangasek> can anyone here explain to me what rosetta's doing in bug #978724?
<ubot2> Launchpad bug 978724 in update-notifier "update-notifier needs to build translation template" [Undecided,Incomplete] https://launchpad.net/bugs/978724
<slangasek> I thought it looked at all .pot files present in the build tree
<slangasek> having to rebuild the .pot file that's already built is definitely wrong
<Daviey> ScottK: looking
 * skaet ^ did the reject,  risk too high for the possible return (low priority bug too)
<slangasek> skaet: of which one?
<skaet> gnome-session
<slangasek> hmm
<skaet> slangasek, see comments in bug.
<gilir> could someone review lubuntu-meta please, it adds missing packages for usb and 3G modems to the ISO, and remove a problematic package on armel ?
<slangasek> skaet: so this was something that was discussed at UDS, the desktop team agreed to reintroduce this option
<slangasek> I don't agree at all that this is high risk
<slangasek> the risk of regression is non-existent; the only risk is that users will /use/ the feature
<skaet> slangasek, was thinking that by using the feature it might cause problems, based on what I was reading.
<skaet> why was it only a low priority bug if it was that important?
<slangasek> well, having the feature ripped out because GNOME upstream wouldn't commit to providing a working session management solution also caused problems
<slangasek> I don't know, I didn't set the bug severity - I filed my bug report in person with didrocks :)
<skaet> https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/771896/comments/27
<ubot2> Launchpad bug 771896 in gnome-session "No way to save current session" [Undecided,New]
<slangasek> yes - pitti's position there fundamentally contradicts what was agreed at the UDS session
<slangasek> i.e., we agreed that an option, not discoverable in the GUI, would be a reasonable compromise
<skaet> slangasek,  if you feel strongly about it,  and have more context to assess from.   Fish it out of the reject queue, review and let it through if it looks ok.
<slangasek> I *do* feel strongly about it, I waste 5-10 minutes of time every time I reboot getting my desktop set back up because of this dropped feature
<skaet> :)
<skaet> fair 'nuf then.
 * skaet saw it lingering in the +queue, and on the pad, and trying to get things cleaned up before final freeze.
<slangasek> so are you happy for me to un-reject?
<skaet> yes
<slangasek> yep, understood
<skaet> :)
<slangasek> it was on my TODO list still for today :)
<skaet> gilir,  I'll look at lubuntu-meta as soon as the diff is generated.
<micahg> ummm, not good, bug 980205
<ubot2> Launchpad bug 980205 in openjdk-6 "package openjdk-6-jre 6b24-1.11.1-4ubuntu1 failed to install/upgrade: './usr/share/applications/openjdk-6-policytool.desktop' is different from the same file on the system" [Undecided,New] https://launchpad.net/bugs/980205
<micahg> doko: ^^
<slangasek> um?  I know openjdk6 has multiarch support, but I didn't realize people were using it now?
<slangasek> micahg: is this a regression?
<roaksoax> Hi all, can someone please review bug #980240 (https://bugs.launchpad.net/ubuntu/+source/maas/+bug/980240/+attachment/3055431/+files/maas_0.1%2Bbzr462.debdiff)
<micahg> slangasek: the .desktop files were removed because of this issue, but were added back as it was supposedly fixed
<ubot2> Launchpad bug 980240 in maas "[FFe] New maas upstream release" [Critical,Confirmed] https://launchpad.net/bugs/980240
<ubot2> Launchpad bug 980240 in maas "[FFe] New maas upstream release" [Critical,Confirmed]
<slangasek> ah
<micahg> bug 969322
<ubot2> Launchpad bug 969322 in openjdk-6 "OpenJDK issues in 12.04 (dup-of: 946736)" [Undecided,Fix released] https://launchpad.net/bugs/969322
<ubot2> Launchpad bug 946736 in openjdk-6 "missing openjdk-6-java.desktop file" [Medium,Triaged] https://launchpad.net/bugs/946736
<Daviey> roaksoax: please upload, will review from the queue
<skaet> gilir,  lubuntu-meta looks fine,  its approved
<roaksoax> Daviey: alright, cool
<roaksoax> thanks
<gilir> thanks skaet :)
<skaet> Daviey,  can you add nova's review to your list?
<SpamapS> can we get ceph accepted from the queue? It takes quite a while to build
<ScottK> Does it need to be promoted at the same time?
<SpamapS> jdstrand: ^^ ?
<jdstrand> it doesn't, but it can be. I'm happy to do the promotion if someone accepts it
<ScottK> I can promote the source when I accept it.  It seems fine.
<jdstrand> ScottK: note some binaries will be denoted
<Daviey> skaet: ack.. i just want to make sure everything is in the queue first.
<jdstrand> demoted
<ScottK> jdstrand: OK.  I'm not sure if they'll all land in Main or all land in Universe.  Either way, I guess c-m will let someone know.
<ScottK> SpamapS: Done.
<SpamapS> ScottK: thanks!
<ScottK> You're welcome.
<SpamapS> queuebot is cool
<zul> can someone binary new quantum please
<doko> micahg, I'll have a look tomorrow, maybe another upload this weekend when the buildds are idle
<skaet> bdmurray,  update-manager contains other fixes than those listed in the change log, based on scanning the diff.   can you please update to include them all?
<skaet> +  * Backport from upstream (Joey Hess):
<skaet> +    - Add missing semicolon to /etc/apt/apt.conf.d/00CDMountPoint.
<doko> micahg, bah, missed one desktop file :-(
<micahg> doko: ok, you might want to use -proposed for the upload as it takes a while to build (unless this .desktop impact is high as arm* will still take quite a while)
<doko> yeah, sounds better
<jdstrand> I went ahead and promoted librados-dev librados2 librbd-dev librbd1 for the qemu-kvm SpamapS is preparing
<jdstrand> (as per the MIR)
<skaet> thanks jdstrand
<jdstrand> so depending on when qemu-kvm gets uploaded/accepted, those might show up on component-mismatches
<jdstrand> skaet: np
<jdstrand> I'll be heading out though, so if there is a problem, SpamapS knows what is ok to promote
<SpamapS> jdstrand: many thanks
<ScottK> zul: ^^^ is just your first upload.  The second one is still in queue.
<jdstrand> sure thing! :)
<SpamapS> ScottK: would you mind accepting qemu-kvm as well? Then I'm done bugging you guys for anything seeded...
<ScottK> Looking
<doko> micahg, arm builds fast, it doesn't run the jdk tests
<ScottK> SpamapS: accepted.  It may need some retrying since ceph in Main isn't built except on amd64.
<bdmurray> skaet: are you talking about the base-installer change which is included in update-manager?
<micahg> doko: yeah, powerpc and arm* were about the same
<skaet> bdmurray,  spotted the lines I was pasting above, that didn't correspond to the changelog, and wanted to make sure it was all as expected.  translations were there too.
<micahg> doko: but IANA release team member :), it's at their discretion
<Daviey> why was quantum rejected?
<Daviey> ScottK: ^^
<slangasek> Daviey: < ScottK> zul: ^^^ is just your first upload.  The second one is still in queue.
<ScottK> Daviey: There were two uploads. I just rejected one of them.
 * slangasek goes all meta
<skaet> :)
<SpamapS> ScottK: alright, I'll tend to any build retries
<skaet> ScottK,  are you planning on handling the kubuntu-default-settings?
<ScottK> skaet: Waiting for plymouth tomorrow (per the note on the pad)
<slangasek> ScottK: I would think those could go in independently?
<ScottK> It may be that I made a false assumption, but I thought they were connected.
<slangasek> TTBOMK the two themes are independent of one another
<ScottK> OK.
<ScottK> I'm at EOD, so if I do it won't be until late tonight or tomorrow.
<doko> what is the final date when the archive should be in sync for all archs?
<Daviey> doko: seeded?
<slangasek> accepting mountall
<doko> Daviey, yeah, openjdk-6 on the dvd images, just a path in a .desktop file
<Daviey> skaet: 19th ^^, right?
<SpamapS> ow.. poor armel.. "start in 21 hours"
<skaet> Daviey, final freeze is today,  we should have release candidates with all the translations in hand by the 19th.
<doko> so I do have 28 minutes ...
<doko> infinity, why is nasl on manual?
<Daviey> skaet: Right, but archive skew should be resolved by the 19th, right?
<Daviey> that is the *absoloute* deadline for skew, right?
<skaet> Daviey, resolved is going to depend on what fixes are going in.   Expect the bulk of it should be resolved before then.
<infinity> doko: Because every time we take it off manual, it explodes.  Headless chickening too much to look into it.
<doko> ok
<infinity> Oo, IS finally located rusalka physically?
<infinity> Shiny.
 * skaet rejected quantum per request,  issue noticed.
<skaet> hmm... has something happened to our queuebot?
<Daviey> 22:15 -!- queuebot [~queuebot@vorash.stgraber.org] has quit [Read error: Connection reset by peer]
<skaet> thanks!
<stgraber> I need to get the bot to poke me when it dies ;)
<stgraber> (or just write code so it auto-reconnect on freenode failure)
<skaet> auto-reconnect seems like the way to go...;)
<Daviey> while true ; do ./queuebot.sh ; done \o/
<stgraber> Daviey: that's the idea but first I need to change my exception handling so that it exits when it gets an IRClib exception but not when it gets an LPlib or xmlrpc exception :)
<Daviey> astraljava: exception handling, what is this?  Ah, it's like unit tests.. or some other foreign language.
<Daviey> err, stgraber
<stgraber> ;)
<skaet> infinity, could you review the ndiswrapper one (looks basically sane to me, but would rather a more knowledgable set of eyes on it)
<infinity> skaet: Sure.
<infinity> Is that a patch we dropped at some point, or has ndiswrapper been broken ever since oneiric?
 * infinity looks.
<infinity> The latter.
<infinity> Special.
<skaet> SRU worthy?
<skaet> oneiric that is?
<infinity> Probably, but it seems no one's complaining.
<infinity> Which, I guess, proves that our mainline network drivers suck less than they used to.  That's something.
<infinity> 5 years ago, breaking ndiswrapper would have led to bloodshed. :P
<skaet> :)
<slangasek> stgraber: fyi, gstreamer out-of-syncness has broken ia32-libs installability for the moment (fixing itself w/ next publisher run); if there are further uploads of this, -proposed would be best
<skaet> oooh... utouch-geis - fixing crashes and adding regression testing in the same patch,  nice.
<skaet> hmm... another copy of glance uploaded.   removing the older one.
<Daviey> skaet: yep, that new one fixes the oppsy
<Daviey> oopsie ?
<stgraber> slangasek: oops, sorry for that. I remember noticing after it was accepted that I pushed it to release and not to proposed, bumped some of the build scores to avoid the skew but that wasn't enough apparently...
<Daviey> Please can squid3 be accepted purely a doc fix.
<slangasek> rejecting eglibc, needs to go to -proposed per discussion with infinity
<Daviey> skaet: My assignments are all reviewed, and good to go.  Thanks.
<skaet> Thanks Daviey.  :)
<doko> openjdk-6, openjdk-7, python-defaults are pending, let me know if you need anything else. afk in 20min
<skaet> infinity, ^ can you look at doko's
<skaet> ?
<doko> and same thing for python3-defaults, but I have to wait until python3.2 is built on all archs
<infinity> skaet: I will in two seconds, just working on an irresponsible last minute upload of my own. :P
<skaet> ack
<infinity> Or two...
 * skaet starts to get worried.... 
<infinity> ;)
<skaet> *sigh*  launchpad keeps timing out on me when I'm going to accept those that Daviey reviewed... :P
<doko> I wouldn't trust Daviey either ... ;p
<Daviey> a what now?
<cjwatson> skaet: that 00CDMountPoint change in update-manager is not in the part of the included base-installer source package that's actually used by update-manager, so there is no point in changelogging it
<skaet> cjwatson,  ah,  fair enough.   Thank you.
<skaet> interesting,  going one by one, got 2 through, but it really doesn't like maas and nova.
<infinity> slangasek: Care to review my apt and dpkg uploads?  (Both are in proposed, don't let the changelogs fool you)
 * skaet has learned her lesson,  don't try to select multiple complex packages then ask them to be accepted.  1 by 1 seems to be what it will tollerate.  :P
<cjwatson> There are still timeout problems with +queue.
<cjwatson> Should be fixable with an API client, since we'll be making one transaction per PackageUpload no matter how many you ask for in one go.
<cjwatson> PackageUpload.acceptFromQueue() handles things like notifications, so I'm not too surprised that it scales poorly.
<doko> slangasek, infinity: I'm a bit confused about the eglibc rejection. these things look worth fixing for the final. I was just objecting to change the dynamic linker name for armhf for the final
<cjwatson> doko: you know we're using -proposed for pre-release work, right?
<doko> cjwatson, including copying to release?
<cjwatson> yes
<doko> ahh, ok
<cjwatson> per my mail to, er, somewhere a week or two back
<cjwatson> ubuntu-release maybe
<skaet> bug collecting info on timeout problems:  https://bugs.launchpad.net/launchpad/+bug/745799
<ubot2> Launchpad bug 745799 in launchpad "DistroSeries:+queue Timeout accepting packages (bug structural subscriptions)" [Critical,Triaged]
<doko> sorry for my ignorance
<micahg> doko: FYI, https://lists.ubuntu.com/archives/ubuntu-devel-announce/2012-April/000949.html
<cjwatson> skaet: *shrug* the fix that matters to us won't fix that bug :-)
<skaet> thanks cjwatson for the background.
<cjwatson> skaet: https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-replace-archive-admin-shell-access
 * infinity grabs some breakfast before getting back to the queue.
<cjwatson> making PackageUpload.acceptFromQueue faster wouldn't hurt, but for the API it won't be necessary to make multiple accepts fit inside a single hard timeout
<cjwatson> whereas if you check multiple things in the web UI, that has to be the case
<Riddell> should I upload to precise or precise-proposed?
<cjwatson> so I don't really think there's much point pushing on 745799 - it's Critical because it's an oops per LP policy, but (while I'd be happy to be wrong) I doubt anyone's going to fix it before I finish the API wor
<cjwatson> k
<skaet> Riddell,  depends on what you're uploading and impact on archive,  https://lists.ubuntu.com/archives/ubuntu-devel-announce/2012-April/000949.html
<skaet> cjwatson,  ok,  will make a note of that.   :)
<Riddell> "we'll promote your package to precise once
<Riddell> it's built everywhere"
<Riddell> is someone doing that manually?
<cjwatson> yes, from time to time
<cjwatson> speaking of which, in goes linux-{,meta-}lowlatency
<skaet> thanks cjwatson.
<cjwatson> is there anything in -proposed at the moment with special testing instructions attached to it?
<maxb> Apologies for bothering here with something only barely on topic: could someone moderate through my ubuntu-devel@ post "Request for advice - subversion FTBFS in precise", since it's about a potential option for fixing that FTBFS before release ?
<cjwatson> maxb: done
<maxb> thanks :-)
<infinity> cjwatson: Or, since you seem to be around, want to review my apt/dpkg uploads?
<cjwatson> sure, few minutes
<cjwatson> ah yes, that dselect fix, that one is fine
<infinity> skaet: openjdk* are fine, unless you wanted doko to reupload them to proposed?
<skaet> infinity, given the potential impact that would be safer.
<skaet> doko,  can you reupload to -proposed?
<infinity> Well, the impact of the changes is nil, but the impact of building could be arch skew, I dunno.
<skaet> arch skew
<infinity> doko: Does openjdk do any/all skew?
<infinity> Same story with python-defaults, upload's fine, might cause temporary skew, if I recall.
<cjwatson> There's no any/all skew problem in openjdk-6 that I can see.
<cjwatson> Oh, wait, openjdk-6-source might have
<cjwatson> Depends: openjdk-6-jre (>= 6b24-1.11.1-3ubuntu3), openjdk-6-jdk (>= 6b24-1.11.1-3ubuntu3)
<cjwatson> So, yeah, that should be -proposed
<cjwatson> looks like >= ${source:Version} or similar
<infinity> doko: Want to just s/Distribution: precise/Distribution: precise-proposed/ in your openjdk and python-defaults changes files, re-sign, and re-upload?
<infinity> Or, I could do the same.
<infinity> Would be nice if the queue just let me do that. :/
<cjwatson> hm, yeah
<cjwatson> acceptFromQueue(pocket=None)
<cjwatson> I mean hypothetically ...
<cjwatson> oh, somebody else did apt.  but it looked fine to me.
<slangasek> yeah, just did it
<slangasek> I'm surprised to see plymouth showing up today
<slangasek> looking
 * skaet --> dinner, l8r
 * infinity reuploads openjdk to proposed.
<cjwatson> infi	though do use bzr bd -S next time, to reduce noise in the diff
<slangasek> yeah... it was just the .bzr-builddeb.conf, so I didn't heckle him about it
<slangasek> Riddell: per prior discussion with ScottK, I'm going to reject this plymouth upload since there's another one coming tomorrow
<Riddell> ok
<infinity> And same -proposed treatment for python-defaults.
 * infinity wonders which of these kubuntu-default-settings uploads is authoritative...
<infinity> Riddell: Are you going to take care of the k-d-s upload(s)?
<skaet> infinity,  see pad
<skaet> and backscroll
<skaet>  :)   ScottK's comments about coord.
<slangasek> Riddell: and yodel's branch merged to lp:ubuntu/plymouth now, so it won't get overlooked tomorrow
 * infinity curses the pad and it's 403s...
<slangasek> cjwatson: btw, the importer unhelpfully moved https://code.launchpad.net/~ubuntu-branches/ubuntu/precise/plymouth/precise-201204112052 aside and shoved its own import on top when there was already a perfectly good branch there; I've now returned the favor.  So if you or James happen to get merge weirdness tomorrow, that's why :P
<cjwatson> slangasek: sigh, not again.  usual problem is that it's picky about .pc contents
<slangasek> oh, well
<slangasek> we have no .pc on that branch for some reason :P
<cjwatson> slangasek: and I bet that will require maxb intervention again
<slangasek> mmk
<maxb> hmm, was plymouth the one I did stuff to a couple of days ago?
<slangasek> yeah :)
<maxb> 75.054  Found changes between steve.langasek@canonical.com-20120411045958-bkyk0f8xw3zp912l and package-import@ubuntu.com-20120411045954-nx8xv3ae1empxog1:
<maxb> (massive list of python tuples follows)
<maxb> yeah, it sulked because you didn't have a .pc with all the content that it wanted
<maxb> This is really annoying, I've tried to convince people that we should just bin the concept of keeping patches applied in vcs on a couple of occasions now, but never been successful. But it just doesn't work :-/
<cjwatson> patches applied doesn't have to imply .pc in vcs; it's unfortunate that the importer took that particular decision
<slangasek> maxb: proper serialization of bzr topic branches to quilt files on bzr bd -S please :)
<cjwatson> (I've been using patches-applied-in-bzr since well before the importer did, *without* .pc)
<maxb> cjwatson: how do you then get the branch into a state where quilt will do the right thing, after branching fresh from the server?
<cjwatson> maxb: a mere client problem
#ubuntu-release 2012-04-13
<cjwatson> maxb: my non-flippant answer is in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572204; that would be automatable in bzr-builddeb, I'm sure
<ubot2> Debian bug 572204 in dpkg-dev "dpkg-dev: maintainer workflow problems with 3.0 (quilt) and VCS" [Wishlist,Open]
 * cjwatson -> bed
 * maxb drops a quick mail to u-distributed-devel@ about this
<cjwatson> I think at the time it seemed quite intrusive, but now bzr-builddeb is doing lots of quilt munging already ...
 * skaet --> EOd
<slangasek> skaet: 'night
<ScottK> Nice.  caph and chort both building the same package on the same arch at the same time.
<pitti> slangasek: as I said, I don't veto gnome-session, I just don't think it's very useful or wise
<slangasek> pitti: yep - I understand your position, my point is merely that the arguments here are no different during a freeze than not
<pitti> slangasek: yes, I agree
<pitti> it's not risky at all
<pitti> oh, someone rejected it?
<slangasek> anyway, I would love for there to be a non-sucky session manager solution that upstream would back... in the meantime, I'll take what I can get ;)
<pitti> I reject one of the two kubunut-default-settings (identical), leaving the other one as per pad
 * slangasek nods
<slangasek> I really don't think kubuntu-default-settings needs to block on plymouth, but it shouldn't matter as plymouth should come later today (according to cjwatson)
<pitti> slangasek:
<pitti> -Command: /usr/lib/update-notifier/package-data-downloader
<pitti> +Command: gksudo /usr/lib/update-notifier/package-data-downloader
<pitti> slangasek: does that file not apply to Kubuntu?
<pitti> (also, "gksu" is the canonical command, but not a biggie)
<pitti> argh, so once again powerpc backlog is causing trouble
<slangasek> pitti: well.... I don't see any available alternative that works in kubuntu (see changelog, & bug comments about policykit not happening for final)
<slangasek> so calling gksudo, so that it fails only on Kubuntu, is better than calling the raw command and having it fail everywhere
<pitti> hm, but these two changes together don't make much sense to me
<pitti> sudo does not keep the proxy variables from the user, so we rely on the user to have clicked "apply system wide" when configuring the proxy
<pitti> but wouldn't that set the proxy in apt, too?
<pitti> ah, you hope that the general proxy in /etc/environment is better for the auxiliary downloads than apt's, I see
<slangasek> yeah
<slangasek> it's imperfect, but, well, apparently there are some large deployments of Ubuntu whose proxy usage conflicts with my previous assumption
<slangasek> users relying on the apt proxy setting for package data downloads before couldn't get ubuntu-restricted-extras anyway... because msttcorefonts implemented this one way, flashplugin-nonfree implemented it the other way
<pitti> didrocks: good morning
<pitti> didrocks: is the unity FTBFS on arm due to the nux changes?
<didrocks> hey pitti :)
<didrocks> pitti: hum, can be yeah, let me look
<pitti> slangasek: I'll move some built -proposed stuff to release now (eglibc, etc.), ok?
<slangasek> pitti: if powerpc is caught up, sure - it wasn't last I'd looked
<pitti> yes, for glibc; it's currently chewing on the KDE rebuilds
<pitti> I guess infinity nudged it a bit :)
<didrocks> pitti: so:
<didrocks> https://launchpadlibrarian.net/101498332/buildlog_ubuntu-precise-armhf.unity_5.8.0%2Bbzr2276ubuntu0%2B677_FAILEDTOBUILD.txt.gz didn't built on armhf
<didrocks> https://launchpadlibrarian.net/101346712/buildlog_ubuntu-precise-armhf.unity_5.8.0%2Bbzr2275ubuntu0%2B677_BUILDING.txt.gz built
<didrocks> the libnux version commit between the two isn't meaningfull
<didrocks> looking for compiz
<didrocks> as linaro changed compiz as well
<didrocks> (the packaging is the same, so it's not the nux change)
<pitti> erk, accidentally copied to -updates; please ignore the following flood of new/rejects in -updates
<didrocks> pitti: the only thing that seems to be have meaningfully changes is compiz
<didrocks> pitti: so it's the linaro patch for compiz
<didrocks> pitti: can try in a ppa building unity with the previous compiz (without their patch)
<pitti> didrocks: you have an arm PPA?
<didrocks> pitti: I do ;)
<didrocks> (well, the unity one)
<didrocks> not really done for that, but I guess it can be used for that
<pitti> didrocks: ok, please prod me for build score bumps if needed
<didrocks> pitti: it's already a priority ppa, heh ;)
<didrocks> ok, compiz first
 * pitti hugs didrocks
 * didrocks hugs pitti back
<pitti> so, -proposed flushed as much as possible
<slangasek> did samba make it into the flushed set?  I see that it's published now, and I was watching for it
<didrocks> pitti: oh wait
<pitti> slangasek: yes
<slangasek> ok, cool
<didrocks> pitti: https://launchpad.net/ubuntu/+source/compiz/1:0.9.7.6-0ubuntu1 no give back done?
<didrocks> pitti: it seems to be some archive skew to me
<pitti> erk, that looks bad; these can be retried?
<didrocks> yeah, failing due to kde-workspace-dev
<didrocks> so I guess some arch skew because of kde?
<pitti> retried, bumping
<didrocks> thanks
<didrocks> pitti: that still doesn't fix the FTBFS on armel, I uploaded compiz in the ppa
<didrocks> waiting for armhf to build to retry unity
<didrocks> (in the ppa)
<rsalveti> weird, maybe the unity issue might be related with the compiz changes
<rsalveti> let me rebuild compiz locally to see if I can also reproduce it here
<didrocks> rsalveti: thanks! I can say that from my build logs, armhf started to fail to build once the compiz version with the armel patch was made available
<didrocks> libnux just had an irrelevant commit change between the two
<didrocks> and the rest of the stack didn't change
<rsalveti> yeah
<didrocks> pitti: thanks for the give back, compiz rebuilt on amd64 in the archive
<didrocks> pitti: maybe you will till be able to score the build a little bit more for the ppa: https://launchpad.net/~unity-team/+archive/ppa/+build/3402499
<pitti> didrocks: done
<didrocks> sweet! :)
<didrocks> pitti: argh, I need to remove some build-dep as well on armel for the ppa, one sec
 * didrocks not really happy with the intrusive changes that linaro introduced at the last minuteâ¦
<rsalveti> hm, locally compiz failed to build because of the way the extra patch is applied
<rsalveti> when generating the source it failed to remove the already applied patches, because the gles related one was not removed before the others
<didrocks> rsalveti: interesting, it built on the ppa, so I guess the way the patch is applied/unapplied is right (and ogra checked it)
<didrocks> pitti: a small help? https://launchpad.net/~unity-team/+archive/ppa/+build/3402518 ;)
<rsalveti> didrocks: yeah, could be related with my local options
<pitti> didrocks: I can't get it below 27 minutes, sorry
<pitti> the buildds seem all busy
<rsalveti> I got the debs, just failed in the end
<didrocks> pitti: ok, let's see how it goes
<rsalveti> let me check compiz-plugins-main now
<didrocks> rsalveti: seeing the source, the failure seems to really be due to an interface that compiz proposed that has been removed for unity
<didrocks> seems that the patch wasn't tested against unity
<rsalveti> that's weird, I know alf tested it with unity as well
<rsalveti> maybe because of an upstream update?
<didrocks> rsalveti: can be yeah
<didrocks> rsalveti: however, the first version we had a failure on armhf is not touching the file which is failing
<didrocks> (and not including it)
<pitti> splendid, amd64 builders build three gccs in parallel
<didrocks> so the only obvious diff I can see between the two builds is this compiz armel patch
<rsalveti> hm, ok
 * rsalveti loves icecc, building compiz in minutes 
<rsalveti> I know that ogra_ was fighting with an upstream rebase/update
<didrocks> rsalveti: yeah, and alf_ reupdated the patch
<rsalveti> maybe something was removed or missed during the patch update
<didrocks> the patch update was done by alf, so I though he tested it against last unity :)
<rsalveti> compiz-plugins-main also built fine, trying unity now
<didrocks> rsalveti: unity isn't that fast to build even with icecc, isn't it? ;)
<didrocks> (and be happy, the tests are not building, which doubles the compilation time ;))
<rsalveti> didrocks: seems the unity package is not yet enabling gles compatible builds
<rsalveti> not using BUILD_GLES nor USE_GLES
<rsalveti> well, it's a lot better than using one single host :-)
<didrocks> rsalveti: well, nothing was merged upstream for opengles, that's what I was telling yesterday
<rsalveti> got 5 different machines here
<rsalveti> the support seems to be already avialable at upstream, just not enabled at the package
<rsalveti> let me try to build it with GLES
<didrocks> rsalveti: ok, keep me posted
<didrocks> (nobody told me anything about the new option, I thought ogra will take care of this as it was part of the deal)
<rsalveti> nux was still building for GL until yesterday, so that's seems to still be a wip
<rsalveti> the focus was more at compiz, because it needed the extra big patch
<didrocks> right ;) let's figure unity out now
<didrocks> if there is an option to enable for unity on armhf, we can do that
<rsalveti> yup
<didrocks> (as anyway, before, it was simply useless on that arch)
<rsalveti> yeah
<pitti> my evo-exchange upload reverts the previous upload which can't possibly work (FTBFS)
<pitti> review appreciated
<pitti> infinity: if you have a sec, can you please look at evolution-exchange?
<pitti> wrt. http://people.canonical.com/~ubuntu-archive/testing/precise_outdate.html, I pinged ev about whoopsie, uploaded fix for evo-exchange, retried network-manager (arch skew), and compiz is needs buildl
<pitti> and ran NBS for the old linux bits
<pitti> didrocks: compiz built everywhere (in precise)
<pitti> didrocks: when that's published, does it make any sense to retry unity, or are you still figuring that out?
<didrocks> pitti: I don't think so, as the diff of the FTBFS I showed before was with the new compiz (and the armel patch was already here)
<rsalveti> pitti: not yet, it'll fail
<didrocks> so, two choices from here:
<rsalveti> hm, got the following now:
<pitti> ok, so we'll either need a new unity, or revert compiz?
<didrocks> - either rsalveti enabled the right option in upstream unity
<rsalveti> /home/linaro/compiz/unity-5.8.0/plugins/unityshell/src/unityshell.cpp:610:2: error: #warning Panel shadow not properly implemented for GLES2 [-Werror=cpp]
<didrocks> and this work
<didrocks> - either my ppa test build shows that the armel patch is guilty (compiz is still building) and we revert the armel patch
<didrocks> I think everyone will prefer #1
<pitti> ok, I'll let you guys figure this out
 * pitti toddles off for a bit
<didrocks> ironically this means that for a week, we couldn't rebuild unity if we needed due to the compiz armel patch ;)
<didrocks> rsalveti: your warning is happening with the opengles option enabled?
<rsalveti> yup, and it's part of the code
<rsalveti> but it's failing because of -Werror
<rsalveti> so I believe this is expected
<didrocks> yeah, we try to keep the source cleaned :)
<didrocks> rsalveti: any progress?
<rsalveti> didrocks: still building
<didrocks> ok, unity's story ;) building builing ;)
<rsalveti> didrocks: check bug 980544
<ubot2> Launchpad bug 980544 in unity "Unity should be built with OpenGL ES2.0 support at ARM " [High,In progress] https://launchpad.net/bugs/980544
<rsalveti> didrocks: added a debdiff with the packaging changes there
<rsalveti> and finally got it to build here
<rsalveti> with gles we need to use -DDISABLE_MAINTAINER_CFLAGS=ON
<didrocks> rsalveti: ok, so no additional patch, what about the warning you had?
<didrocks> ah
<rsalveti> because it's not completely implemented
<didrocks> you disbale maintainer cflags
<didrocks> so no Werror
<didrocks> fine with me anyway, as its on arm only :)
<didrocks> it's*
<rsalveti> yeah
<didrocks> rsalveti: need sponsoring?
<rsalveti> arm/gles support is kind of experimental at this phase, so should be fine
<rsalveti> didrocks: yup
<didrocks> doing then
<rsalveti> didrocks: thanks
<didrocks> (just changing debian/changeog to target -proposed)
<rsalveti> sure
<didrocks> ah, rejection before you didn't pick the last changelog, fixing that :)
<rsalveti> there's a new release on proposes, right?
<rsalveti> proposed
<didrocks> yeah ;)
<didrocks> done, no worry!
<rsalveti> great, thanks
<didrocks> thank to you for the quick look :)
<rsalveti> np
<didrocks> pitti: available and waiting approval ^
<pitti> wohoo
<pitti> ok, looks like a no-change for x86
<didrocks> indeed
<pitti> didrocks: I guess I should wait until compiz is published everywhere in precise? or does it have b-deps?
<pitti> (still pending publishing on armhf and i386)
<didrocks> pitti: maybe better to wait, the armel patch changed. I know there is no ABI change for x86, but as we saw, the armel diff is big ;)
<pitti> ok, I'll better wait
<infinity> pitti: evo-exchange is straightforward enough.
<ogra_> didrocks, ouch, i was somewhat relying on upstream to include an arch sepcific default when they included the patch, sorry
<didrocks> ogra_: no worry, all sorted out now  :)
<didrocks> ogra_: but this whole arm story hasn't been painless ;)
<ogra_> yeah, i see, thanks so much and sorry again
<ogra_> didrocks, no, it hasnt, thats why i asked for having all patches ready by last UDS so we could have them in before A1 :P
<ogra_> well, at least we'll have it in Q
<ogra_> from the beginning
<didrocks> ogra_: yeah, it's just the timing which made it worseâ¦ but well, it's in now, let's hope that the story in Q will be better :)
<didrocks> right!
<jamespage> has final freeze been announced yet? piloting this morning and want to ensure that I'm focussed on the right things...
<pitti> didrocks: ok, compiz is published, accepting unity
<didrocks> pitti: sweet!
 * pitti bumps build score
<RAOF> We're not in final freeze yet, right?
<pitti> we are supposed to be
<RAOF> Shall someone update the topic in #ubuntu-devel, then?
 * ogra_ guesses once kate gets up we are 
<ogra_> RAOF, there was no official announcement yet
<ogra_> (unless i missed it)
<pitti> cjwatson: should we move linux-ti-omap4 from -proposed to release, or do you want to stage d-i in -proposed for that as well?
<RAOF> Ok :)
<pitti> RAOF: in practice we've been frozen for a week already anyway
<RAOF> Right, but final freeze changes whether or not I upload this xxi-synatpics
<ogra_> RAOF, -proposed is open as well ;)
<Daviey> maas-enlist incoming, basically a Arch s/all/any change.  My upload, please can someone else review.
<Daviey> (also accept the bin NEW's)
<pitti> didrocks: meh @ unity armhf FTBFS :/
<pitti> OPENGL_gl_LIBRARY (ADVANCED)
<didrocks> rsalveti: ^
<pitti> not found
<pitti> missing build dep?
<didrocks> rsalveti: any special build-dep for opengles?
<didrocks> rsalveti: the compiz-dev and nux are supposed to provide everything
<didrocks> pitti:  ^
<didrocks> ogra_: maybe you have a clue on this stack
<pitti> didrocks: we'll keep control-center in -proposed until unity and -2d are released, right?
<didrocks> pitti: yeah, because it's using an unity-2d new gsettings key
<didrocks> so will crash without it
<didrocks> I didn't want to put an explicit dep or breaks just for that
<pitti> right, that's what I meant
<didrocks> pitti: ok, I'm not found of to have unity stalled on proposed forever. The deal was that if arm fails because of the linaro patch, we can go ahead and they have to fix it
<didrocks> pitti: if it's not fixed in one hour, should we revert all the linaro changes?
<pitti> didrocks: WFM
<didrocks> ogra_: in case you didn't see ^
<ogra_> i did have a reconnect
<ogra_> seems i miss the beginning
<infinity> You didn't give people much chance to respond. :P
 * ogra_ just noticed that lubuntu-desktop doesnt have armhf support at all :/
<ogra_> didrocks, whats the issue ? how can i help ?
<infinity> ogra_: At a quick glance, it looks like compiz-dev is missing dependencies.
<ogra_> hmm, it shouldnt, i used the linaro branches for the deps ...
<infinity> Though, maybe not..
 * ogra_ downloads the source package
<didrocks> OPENGL_gl_LIBRARY (ADVANCED)
<didrocks> ogra_: it's unity which FTBFS
<ogra_> hmpf
<infinity> Kay, compiz-dev's deps are fine.
<infinity> So, it's the CMake test that's wrong, I assume.
<didrocks> yeah, can be the CMake one I guess
 * tumbleweed hopes we get a name for Q soon
<infinity> Or is the GLES support in Unity not mutually exclusive with GL?  If so, then it just needs libgl1-mesa-dev installed too.
<ogra_> no. it should have the same !armhf/armhf setup as compiz
<infinity> ogra_: Kay, then I contend that the CMake test is wrong, and probably looking for libgl unconditionally, even if the source doesn't need it when building for EGL.
<ogra_> right
<infinity> pitti: I see no advantage in leaving the ti-omap kernel in -proposed...
<infinity> pitti: We kinda want it for image builds too.
<pitti> infinity: right, but it's an ABI bump, so needs to go along with a d-i upload and seed changes
<infinity> pitti: Yeahp.
 * ogra_ pinged alf, i think he has a unity packaging branch somewhere 
<didrocks> ogra_: keep us posted, I wanted to have feedback on the upgrade before the week-end, but I guess this won't happen :(
<ogra_> didrocks, lets see ... i found the linaro packaging branch, doesnt seem it touches any cmake stuff nor deps
<ogra_> didrocks, hmm, are all compiz builds published already ? could be that compiz-dev is to old
<pitti> yes, I waited for that
<ogra_> (seems the versioned dep is outdated)
<ogra_> ok
<didrocks> ogra_: well, it's not a versioned dep because there is no ABI change
<didrocks> at least on i386/amd64 not sure what happened on arm
<ogra_> GLES support was added ... i reflected that in the versioned dep in compiz-dev but indeed not in unity
<ogra_> but if compiz is up to date that doesnt matter anyway
<infinity> Well, you can tell from the build log if it was.
<didrocks> ogra_: right
<infinity> (and it was)
<ogra_> AHA !
<ogra_> http://bazaar.launchpad.net/~linaro-maintainers/unity/overlay/revision/20
<ogra_> "Disable standalone-clients as it forces opengl (testing related)"
<didrocks> ogra_: so we will need your quilt hack
<ogra_> yup, looks like
<didrocks> for arm only
<didrocks> ogra_: I can give it a try, but not build to confirm
<didrocks> apart from pushing to a ppa
<ogra_> right, let me make sure thats the only missing thing first though
<didrocks> yep
<ogra_> did you plan to have that -proposed upload in the release ?
<didrocks> ogra_: what do you mean?
<ogra_> or is that a zero day update ?
<didrocks> ogra_: oh, it's in the release
<ogra_> ok
<ogra_> just wanted to know about the time pressure ;)
<didrocks> well, I guess it's high :p I rushed to get everything in shape yesterday evening
<didrocks> and hoped I can have a quiet Friday :p
<ogra_> yeah
<didrocks> but pinged 5s after connection because of arm :(
<ogra_> i only noticed it was uploaded to -proposed
<ogra_> so i thought i'd better ask
<didrocks> ogra_: yeah, please upload with -v also
<didrocks> (to include the 2 previous ones)
<ogra_> anyway, doesnt look like there is anything in the linaro branch that touches any other cmake stuff
<didrocks> so that bugs are closed when syncing
<ogra_> so i guess that patch is it, let me add the quilt stuff and to an armel testbuild
<didrocks> great ;)
<infinity> ogra_: Please do test locally in a clean chroot before uploading another FTBFS. ;)
<ogra_> infinity, indeed :P
<cjwatson> slangasek: gksudo> you could use something like ubiquity's wrapper that tries to escalate using whatever means is available
<cjwatson> pitti: no point staging d-i in -proposed for ti-omap4, we should just move it
<pitti> cjwatson: ack, doing that then
<ogra_> gah, ricardo made his -Werror dircetly in the code
<ogra_> +change
 * infinity notes that doing all the proposed->release copies as syncs makes pitti looks very active on -changes...
<pitti> I hope in the not too distant future that's going to be done by a bot :)
<didrocks> what? pitti isn't a bot? how can he possibly achieve that much work then? ;)
<ogra_> phew, finally building ...
<ogra_> and passed the error :)
<didrocks> sweet, let's wait for it to successfully finish building
<ogra_> indeed :)
<ogra_> didrocks, do you think we could disable -Werror across the board for the release ? seemingly that option leaves me with a modified Cmake setup, so dpkg-source complains about upstream changes when trying to roll a source package on arm
<didrocks> ogra_: I prefer keeping -Werror for non arm if possible (and so, please ask linaro to fix the arm case), it saved us from some issues that happened in the pasts
<ogra_> ok
<ogra_> i dont think its that important :)
<didrocks> ogra_: TBH, dpkg-source should already complain when I'm cherry-picking patches from upstream, it just enables us to see what files are touched ;)
<didrocks> (I bzr merge upstream-branch in packaging branch)
<ogra_> didrocks, i pushed my changes (UNRELEASED yet) to lp:~ubuntu-desktop/unity/ubuntu/ ... so you could start a PPA build i suppose if you want
<ogra_> oh crap !
<didrocks> hum?
<ogra_> failed
<didrocks> ah :(
<didrocks> ogra_: aren't the linaro guys around to help us on this?
<ogra_> apparently not
<didrocks> I'm just about considering reverting if that can't be fixed
<ogra_> alf is greek ... its good friday in the greek chruch today
<didrocks> pitti: wdyt? ^
 * ogra_ found another patch ... gimme a sec
<didrocks> ok
<ogra_> ah, no, seems unrelated
<ogra_> didrocks, would you keep my package changes but drop the patch ? that way we can easily SRU a new patch in ...
<didrocks> ogra_: I want the release team to agree first, but yeah, dropping the patch and the custom .install file in compiz should be enough, right?
<ogra_> didrocks, err, why compiz ?
<ogra_> compiz is fine
<ogra_> i'm only talking about unity, i would like to have the package prepared as well as we can so i only need to dump that single quilt patch in
<didrocks> ogra_: no, it's compiz on arm which doesn't provided the opengl-es dep
<didrocks> ogra_: you are talking about the revert first, right?
<ogra_> i'm only talking about unity
<didrocks> ogra_: right, but basically, since you landed the compiz patch a week ago, we can't build unity on armel
<ogra_> if there need to be fixes in compiz i would prefer to keep them as small as possible ... as long as it builds it wont do no harm
<didrocks> because compiz is providing opengles build-dep
<didrocks> so unity has opengles build-dep only on arm
<ogra_> it doesnt build if you revert the changes ricardo made ?
<ogra_> hmpf
<didrocks> ogra_: no, ricardo did those changes because it FTBFS
<ogra_> right, that was the bit of the conversation i missed above
 * ogra_ curses loudly 
<didrocks> so that would mean: reverting compiz and c-p-m
<didrocks> the arm part
<ogra_> yeah, thats a very bad idea
<didrocks> well, unity can't build for a week since those patches were introduced into ubuntu
<didrocks> (on arm)
<ogra_> you didnt tell me ... i thought all was fine (though i also though the unity changes were in since ages since i was told everything for this was done upstream and we wouldnt need to care)
<didrocks> ogra_: well I didn't know until this morning, remember that you uploaded it in the archive whereas we were testing a newer version in the ppa? :)
<ogra_> yeah
<didrocks> so we never got the issue until this morning
<ogra_> didrocks, do you mind if we wait until ricardo gets up again, probably he has an easy fix in the drawer
<didrocks> ogra_: let's see with the release team
<didrocks> I was hoping getting feedback on the new release today
<ogra_> it survives 80% of the build and fails in a single declaration atm
<didrocks> but seems that despite rushing and working like mad yesterday, it's not possible
<didrocks> or we can as well declare the armel image failing to build this week-end
<didrocks> and copying to the release pocket for now
<ogra_> i'm really sorry for that, i hinestly was 100% convinced we dont need to touch the unity package at all
<ogra_> i dont think LP allows that ... we had a similar issue in B2
<didrocks> ogra_: no worry, I would have prefered that linaro gave the patch to you sooner and not at the last minute ;)
<didrocks> ah?
<ogra_> you need to copy over all arches or you lose
<didrocks> ok
<ogra_> intrestingly the build seems to fail in a nux function
<ogra_> hmm, how did libglu1-mesa end up in the chroot, that cant work
<ogra_> seems the former nux version pulled that in
 * ogra_ retires the build 
<ogra_> *retries
<ogra_> :)
<didrocks> both were valid :p
<ogra_> haha
<didrocks> ogra_: https://code.launchpad.net/~linaro-graphics-wg/unity/fix-gles2-build/+merge/101087
 * ogra_ looks
<didrocks> I saw that patch pending, told to ricardo this morning that some patchs were not approved (as we agreed) in unity and he answered that nothing was pending for him
 * ogra_ hugs didrocks, thats the one 
<ogra_> well, at least thats the file it failed in
<didrocks> ogra_: testing with it? ;)
<didrocks> ok, let's cross fingers
<ogra_> not yet, let me add it
<didrocks> ogra_: you can bzr merge it directly
<ogra_> k
<didrocks> (as it's an ifdef)
<didrocks> it that works, I'll accept it upstream, even if that's not what we agreed on first :/
<ogra_> yeah, pretty much nothing is ...
<ogra_> building again
<pitti> didrocks: I don't think we can copy unity to precise without completely breaking arm, can we?
<ogra_> not if the binaries are missing, no
<didrocks> pitti: no, we can't, let's hope that the branch I pointed ogra too will fix it
<pitti> right, we'd potentially end up releasing with NBS
<ogra_> will break -desktop deps
 * ogra_ is confident the patch will make it work 
<pitti> I think we should upload a reversion of compiz, then build unity against it, move both to release
<pitti> and then we can re-stage compiz/unity with gles in -proposed
<ogra_> build is at 34%
<didrocks> pitti: it's compiz, compiz-plugins-main, nux and then unity
<ogra_> pitti, that measn SRUing a 300-400k patch
<didrocks> so not that straightforward :)
<ogra_> *means
<ogra_> i would love to avoid that
<pitti> well, if you SRU something that jst enables a 300 k patch in debian/patches/series, the net effect is the very same
<pitti> SRUs are bound by regression potential, not primarily by patch size (although the two certainly correlate)
<ogra_> its also package changes that have to be reverted across the chain ...
<ogra_> (and re-enabled for the SRU)
<pitti> well, other suggestions appreciated
<didrocks> pitti: I pointed ogra to an unity patch that can help
<pitti> but we are supposed to have a releasable image since today, and right now we don't
<ogra_> i would really prefer to get it into a building state now ... keep possible fixes for SRUs then
<didrocks> pitti: even if the first deal was linaro was "only compiz and c-p-m"
<ogra_> but reverting the world is hell
<didrocks> but it seems they broke the deal
<didrocks> which doesn't really make me happy about how hard they pushed it and how they delivered it
<pitti> so, if the gles-enabled unity can be made to work this afternoon, sure, but it doesn't currently look like we'd have a robust and solid plan for that
<didrocks> but that's another story
<ogra_> right, deal was no ifdefs and package changes for unity and nux ... but we cant change that now
<pitti> this really sounds like something which ought to be staged up in -proposed without blocking the current release
<didrocks> pitti: 13:40:30  didrocks | pitti: I pointed ogra to an unity patch that can help
<pitti> we could also release precise with unity 5.8, but I'm not sure folks would be happy about that
<didrocks> it's building right now
<ogra_> pitti, how long is your definition of afternoon ;)
<ogra_> build is at 38%
<ogra_> should be done soon
<pitti> ogra_: given that the stuff needs a couple of hours to build, we should get it in before release team meeting IMHO
<ogra_> (if it survives)
<ogra_> pitti, its only unity itself
<ogra_> wont need a couple of hours
<pitti> not if we need to revert compiz/c-p-m/nux/whatever, too
<ogra_> oh, you mean the reverting
 * ogra_ was thinking positive :) 
<pitti> well, that's like the third or fourth patch we are trying now; if it works now, fine, but none of this sounds very reliable TBH
<pitti> the result will not have been tested _at all_
<ogra_> doesnt matter ... if we revert the patches it segfaults completely
<ogra_> these patches are all arm only on which without the patches unity doesnt work at all
<pitti> so whichever solution gets us a working unity stack in precise by EOD
<ogra_> great
<cjwatson> hm, http://qa.ubuntuwire.com/ftbfs/ doesn't seem to be answering me
 * ogra_ noticed that last night already but thought it was my side since i had LAN issues
<infinity> pitti: I'm pretty unhappy about the current state too, but reverting will leave ARM just as broken.  We could copy everything (despite the missing ARM binaries), and let the next upload sort it out.
<infinity> It's not like we care about ever having the current version build on ARM (cause it can't).
<pitti> infinity: that would introduce NBS again
<pitti> err, what? unity always built on arm before
<ogra_> the unity build takes 1h ... i'm 50% through ...
<ogra_> lets just see if it finishes
<didrocks> it built but never started as there is no opengl capable hw, right?
<infinity> No, I mean the current version won't build, so copying it won't hurt (cause it won't magically build later).
<ogra_> pitti, it built but wasnt executable
<pitti> infinity: right, hence introducing NBS
<infinity> And yeah, what ogra said.
<infinity> pitti: NBS on one arch for a day isn't world-ending, surely.
<pitti> well, _I_ won't copy it
<infinity> pitti: The concern for !arm seems to just be having the whole stack in and working, no?
<pitti> just about the last thing I want to do at this point is deliberately introducing archive breakage and broken image builds
<infinity> Whereas, for ARM, it's either broken, or broken, or we fix it. :P
<infinity> (ie: reverting just takes it from broken to broken, for the sake of archive tidyness)
<pitti> arm images curretnly have unity-2d workign, and this is also blocking unity-2d, gnome-control-cetner, and nux for precise
<infinity> The only real option is fixing it.
<pitti> it's not as simple as "make it work on arm"
 * ogra_ thinks it is as simple as "get that next upload to build"
<infinity> Yeah.
<pitti> ogra_: FSVO "simple"..
<pitti> infinity: reverting the compiz/cpm uploads and uplaoding the unity that was actually tested is a real option
<didrocks> at least, I confirm it's what worked on the ppa
<infinity> And nux.
<didrocks> right, nux in addition now
<infinity> pitti: That all takes a lot longer than just hunting down what's broken, I suspect.
<didrocks> pitti: well, you mean, reverting the arm part of compiz/cpm, isn't it?
<pitti> infinity: *shrug*, given that several people desperately fight with this problem for at least 7 hours now..
<infinity> (And isn't dealing with breakage half the point of staging in -proposed?)
<pitti> sure
<pitti> but I disagree that it's ok to copy it to precise at this point
<infinity> Sure, so don't.
<pitti> so if we don't revert, and don't get this to work, we'll just release with 5.
<pitti> 5.8
<infinity> That's the part I don't follow.
<pitti> and I'd rather relelase with 5.10
<infinity> We release in 15 days.  Holding up this pocket copy for a day doesn't magically make the world explode.
<pitti> as that also unblocks a few other things, including UIFEs
<pitti> and has been tested in the PPA
 * infinity notes that it hasn't build on PPC either...
<infinity> built*
<pitti> didrocks: is the current (precise) unity 5.8.0-0ubuntu2 even buildable with the new compiz that's in precise?
<didrocks> pitti: no, that's what I told above ^
<pitti> ok, that's what I figured
<didrocks> pitti: my bet is that since last Friday and the compiz upload that was done unnoticed why we were testing the new version, it's not buildable
<didrocks> but I never tried, we always had the newer version in the ppa
<didrocks> it's 90% sure it's not (if not more)
<ogra_> ok, its in unitydialog ... i think i'm past the last failure
 * ogra_ crosses fingers for the last 25% to go
<ogra_>    dh_builddeb
<ogra_> dpkg-deb: building package `unity' in `../unity_5.10.0-0ubuntu2_armhf.deb'.
<ogra_> dpkg-deb: building package `unity-services' in `../unity-services_5.10.0-0ubuntu2_armhf.deb'.
<ogra_> dpkg-deb: building package `unity-common' in `../unity-common_5.10.0-0ubuntu2_all.deb'.
<ogra_> ....
<ogra_> DONE !
<pitti> ogra_: \o/
<ogra_> didrocks, could i ask you to roll the new package i'm scared i'll catch the wrong branches again or some such
<ogra_> i merged the linaro patch and all my patches and pushed everything to lp:~ubuntu-desktop/unity/ubuntu/
<didrocks> ogra_: ok, looking
<seb128> ogra_, switch to v3 format ... is that needed?
<ogra_> tellk me if i did anythign wrong
<ogra_> seb128, yes, for the subarch specific patching
<seb128> ogra_, it creates issues with cherrypick done with bzr merge for sources like dx ones
<ogra_> it needs full quilt support
<seb128> not cool :-(
<didrocks> yeah, not cool :/
<didrocks> we wanted to avoid v3
 * ogra_ wanted to avoid touching unity ... sorry 
<didrocks> ogra_: don't you want to do the same trick than with compiz?
<ogra_> if you can make quilt properly work with dh_quilt_patch/unpatch another way, please revert
<didrocks> ah you need
<seb128> ogra_, debian/patches/series.armel@ .. is the "@" right there?
<didrocks> why v3 is needed then?
<ogra_> didrocks, yeah, it is the exact same thing
<didrocks> seb128: yeah, symlink
<ogra_> seb128, yes, it links to armhf
<seb128> oh ok
<didrocks> but a build-dep on quilt and dh --with quilt should be enough, isn't it?
<seb128> didrocks, ogra_: thanks ;-) (learning every day)
<didrocks> without v3?
<ogra_> didrocks, hmm, not sure, does that properly trigger debhelpers scripts ?
<didrocks> I think so
<didrocks> ogra_: let me push something and tell me if that applies on bzr bd
<ogra_> all i need is that override_dh_quilt_patch/unpatch work
<cjwatson> dh --with quilt will work with overrides
<ogra_> i didnt think thats doable without v3.0 ... if it is, i'm fine
<cjwatson> if anything I'd have expected 3.0 (quilt) to make matters harder in this case, not easier
<didrocks> yeah, it's called
<ogra_> then just revert the 3.0 stuff
<didrocks> hum
<ogra_> issues ?
<didrocks> yeah, dpkg-source complains about diff not serializable
<didrocks> however, the changes are just in  plugins/unityshell/src/DashController.cpp
<didrocks>  plugins/unityshell/src/OverlayRenderer.cpp
<didrocks>  services/CMakeLists.txt
<didrocks> oh
<didrocks> the symlink maybe?
<ogra_> i think its the first change from ricardo
<didrocks> debian/patches/disable_standalone-clients.patch?
<ogra_> no, that one was in the source directly
<ogra_> before i added anything
<didrocks> no, the issue was the symlink
<ogra_> seems configure ran before the tarball was rolled, i had complaints here as well and had to revert the changes that override_dh_gencontrol had produced
<ogra_> really ?!?
<didrocks> yeah
 * ogra_ has never had issues with symlinks in bzr 
<ogra_> weird
<didrocks> ogra_: source 3 only? :p
<cjwatson> 1.0 diffs don't support symlinks not in the original tarball, indeed
<ogra_> oh
 * ogra_ echoes seb128 (learning every day)
<didrocks> ok, override_dh_quilt_unpatch and override_dh_quilt_patch are called
<ogra_> yay
<ogra_> cjwatson, i only had symlinks in the debian dir
<infinity> ogra_: Right, "not in the original tarball".
<didrocks> ogra_: pushed, do you want a last sanity check? (just start the build to ensure the patch is applied?)
<infinity> ogra_: As in, diff.gz can't represent a symlink.
<ogra_> err
<ogra_> i missed the "not" :P
<ogra_> thanks for repeating ti for that old blind man :)
<ogra_> *it
<infinity> (Though, I thought it just represented it as a dereferenced copy of the file...)
<cjwatson> actually maybe it can, I'm sure I remember using symlinks in debian/ pre-3.0
<ogra_> didrocks, pulling
<cjwatson> yeah, don't take my word as gospel here, I don't have time to check properly right now
<didrocks> dpkg-source yielled at me though ;)
<didrocks> cjwatson: ^
<infinity> didrocks: I assume you just did a cp -a and called it good? :P
<didrocks> infinity: bzr rm, cp -a and bzr add yeah, because bzr wasn't happy I cheated on a symlink :)
<infinity> cjwatson: Actually, I'm betting the remembering symlinks pre-3.0 was always in native packages.
<infinity> cjwatson: Cause there really is no way to sanely represent a symlink in pre-3.0 non-native.  After the first pack/unpack, it would be a copy.
<cjwatson> oh, could well be, yes
 * ogra_ twiddles thumbs ... why is bzr so slow now
<infinity> (And I think dpkg just says "no" instead of giving you that confusing result)
<cjwatson> yeah
 * didrocks is just a dput away once ogra_ confirms the patch is applied on his armel system :)
<ogra_> yeah, seems my pandas network connection is a bit unhappy, bzr pull takes a century here
<ogra_> didrocks, applies, i'll leave the build run so we can see weverthing is right
<ogra_> *everything
<didrocks> \o/
<didrocks> ok, pushing
<ogra_> thanks for taking over that bit
<didrocks> as I guess we don't want to wait on your build again :)
<didrocks> ogra_: thanks for looking into the issue and trying the branch I pointed ;)
<ogra_> nah, just as additional measure :)
<ogra_> well, without you pointiing at it i would have given up
<didrocks> ogra_: I'm forced to approve the branch upstream now :p
 * ogra_ thinks there will have to be a lot beer flowing back and forth at UDS
<didrocks> heh, as usual, ;)
<didrocks> pitti: ^ you maybe heard about thatâ¦ an incoming unity fixing some issues on arm we might care about ;)
<pitti> didrocks: no idea what you are talking about, I'll just reject it
<didrocks> pitti: please do reject ;)
<infinity> Oh look, langpack spam day.
<pitti> at it
 * infinity goes to update the i386 chroot to keep build times down.
 * pitti disables the automatic langpack cron job now; we'll get a fresh -base rebuild next Tuesday
<pitti> infinity: ok, cancelling my q accept run until you're done; thanks
<ogra_> yay, and lubuntu-desktop is finally installable on armhf
<infinity> pitti: Nah, accept away.  No point delaying.
<pitti> ack
<infinity> New chroot will be there in a few minutes.
 * infinity gives allspice to i386.
<pitti> didrocks: do we need to reupload unity-2d for that, or is that fine? (ISTR that it build-deps on unity)
<didrocks> pitti: it doesn't, at east, I didn't spot an ABI break
<didrocks> pitti: I'll test from proposed right now
<pitti> cjwatson: want me to upload d-i for new l-ti-omap4, or are you already at it?
<pitti> (and seeds)
<cjwatson> pitti: go ahead, I've been working on a couple of other things
<pitti> ack
<cjwatson> looking into a workaround for bug 922949
<ubot2> Launchpad bug 922949 in apt "installation process can crash due to an issue with one package when choosing "install updates" as part of the install" [High,Triaged] https://launchpad.net/bugs/922949
<infinity> pitti: I did the seeds.
<infinity> pitti: I can do d-i too, if you like.
<pitti> I don't mind much either way, it's mostly mechanical anyway
 * infinity nods.
<pitti> flip a coin?
<infinity> Heh.  I'll do it in just a second. ;)
<infinity> Just want to make sure I didn't break the world with the new i386 chroot.
<infinity> World looks decidedly unbroken.
<infinity> pitti: Uploaded.
<pitti> cheers, will review in a bit
<ScottK> Daviey: horizon just made component mismatches explode.  You may want to have someone look into it.
<ogra_> didrocks, oh, just FYI, the other build is done too
<didrocks> ogra_: nice to hear! Now let's wait a little bit less anxiously :)
<ogra_> yeah :)
<ogra_> infinity, oh, btw, did you change the omap4 cmdline in debian-cd yet (vram=40 ... and dropping the memory hole etc)
<infinity> Did rsalveti file that bug for me and I missed it?
<infinity> Dropping the memory hole can't be done until 3.3+, AIUI, it was just the vram bump we need for now...
<infinity> (Which can also be dropped in 3.3+)
<ogra_> i dont think he filed any bug
<ogra_> i just remembered you had a conversation about it with him
<infinity> Yeah, which ended in "file a bug so I don't forget". :P
<ogra_> if you didnt do it i'll make sure it happens before release
<ogra_> wforget it
<ogra_> *e just shouldnt forget ot
<ogra_> sigh, why is my system swallowing letters
<ogra_> whole words actually
<infinity> If it's only debian-cd, it's a quick change.  I'll do it right now.
<infinity> I wasn't sure if it popped up in other places.
<infinity> But I can't find it in flash-kernel.
<infinity> So...
<ogra_> its in omap4_boot
<ogra_> flash-kernel shouldnt touch the cmdline (f-k-i should though, but we dont use it)
<infinity> Oh, right, I meant to fix that.
<infinity> Drat.
<infinity> Not enough hours in the day.
<infinity> For Q, I guess.
<ogra_> what ?
<ogra_> the cmdline fix ?
<ogra_> or f-k
<infinity> Yeah, make f-k-i DTRT with custom command lines and such.
<ogra_> ah, k
<infinity> Was just some caro-culting from grub-installer that I didn't get to, but I'm not going to do it now.
<ogra_> well, for preinstalled thats moot
<ogra_> since f-k isnt used for anything but mkimage there anyway ...
<ogra_> its debian-cd and jasper
<ogra_> but jasper only takes the existing cmdline and parses the serial and debconf bits out ... the rest is used unmodified ... so the change is debian-cd only
<infinity> Right, I meant fixing f-k-i to actually do sensible things in the face of custom commandlines. :P
<infinity> debian-cd is already fixed.
<infinity> Well, when I commit.
<ogra_> well, lets revisit the "burn jasper" spec in Q
<ogra_> and actually implement the fixes we defined
<ogra_> f-k-i was one of the bits iirc
<infinity> We might be getting dangerously close to just dropping preinstalled entirely.  I dunno.
<ogra_> or that, yeah
<ogra_> which will still need f-k-i touching though
<ogra_> and i would still like to work on  the "d-i as tarball installer" bit
<ogra_> (which is indeed more ac100 than preinstalled)
<Daviey> ScottK: looking, thanks
<cjwatson> sent the foundations report now, sorry that was late
<cjwatson> ^- that's the reupload expected from last night
<cjwatson> works around our oldest rls-p-tracking bug sufficiently to consider it closed for now, yay
<ScottK> cjwatson: Does that include the Kubuntu changes too?
<cjwatson> yes
<ScottK> Cool.  Thanks.
<cjwatson> though I didn't verify against the rejected upload, it was what was in bzr
<ScottK> That should be correct.  The same person did both.
<cjwatson> ok
<brendand> skaet - no release meeting today?
<ogra_> brendand, in 30min, no ?
<skaet> brendand,  there's a release meeting today.  1500 GMT
<skaet> brendand,  can you please summarize in the meeting or in email,  who each of the bugs you've listed as blockers is waiting on?
<skaet> (ie.  waiting on validation, waiting on fix - is what I'm trying to understand)
<pitti> hey skaet
<pitti> didrocks: so once unity is built in -proposed, do we need any other packages?
<skaet> hiya pitti,   just doing the pass through the weeklies to find out issues.
 * skaet still sees we're pending unity builds...
<didrocks> pitti: no, everything should be fine, copy g-c-c, nux, unity, unity-2d
<pitti> skaet: yeah, that was a bit of a pain, but should hopefully be good now
<skaet> am thinking that once its build,  recreating the images before tonight and seeing if we've got issues before the weekend would be prudent.
<didrocks> and life will be beautiful ;)
<pitti> didrocks: ack; just wanted to triple-check
<pitti> skaet: *nod*
<skaet> :)
 * skaet likes tripple checking..... 
<pitti> still waiting on powerpc, once again
<pitti> (as we have done all day for flushing -proposed ...)
<ScottK> I think it's been over three days since a Universe package got built on powerpc.
<ScottK> Will the kde-workspace/qt4-x11 syncs that just showed up in the queue cause the packages to get rebuilt?
<ScottK> That certainly isn't what we want.
<pitti> no
<pitti> they include binaries
<ScottK> OK.
<pitti> that's the very point of using -proposed, after all
<pitti> I'm waiting until they built on all arches, then move them over
<pitti> we got some 40 of them yesterday to update the .pot, I think
<ScottK> Yes.  Precisely my concern.  The LP U/I gives no indication that the binaries are included.
<ScottK> That was the reason.
<pitti> it's exactly the same script as we use for releasing SRUs, FYI
<pitti> (in case you are curious, it's sru-release in lp:ubuntu-archive-tools)
<ScottK> Interesting.
<ScottK> Does it still have to be run in the data center or can any archive admin run it?
<pitti> ScottK: the latter
<pitti> it's lplib
<pitti> I don't use the DC at all any more for SRU work
<ScottK> Interesting.
<pitti> the new version cannot time out any more, as it's fully async
<pitti> so we also process kernels that way now
<pitti> ah, for them I do need DC access for change-override
<ScottK> So I could do that for non-AA SRU people.
<cjwatson> ScottK: yep
<slangasek> cjwatson: is that ubiquity escalation wrapper in a package that we could pull in?
<cjwatson> slangasek: no
<slangasek> ok
<slangasek> I'm going to stand pat for .0 then :)
<cjwatson> slangasek: you'd need to extract bits from lp:ubiquity bin/ubiquity-wrapper
<cjwatson> and probably tweak
<cjwatson> dunno if you need the tedious dbus and xauth munging
<cjwatson> (actually not dbus)
<rsalveti> didrocks: ogra_: I'm back
<rsalveti> what is the extra change that needed to land at unity
<ogra_> rsalveti, to late, all fixed :P
<didrocks> rsalveti: it's all sorted, seems I was right, a change was needed :p
<rsalveti> seems my build worked fine because for some reason libgl1 was also included during the build
<ScottK> ^^^ was me
<ogra_> rsalveti, the fix is already merged upstream by didrocks
<rsalveti> then not causing the ftbfs while build the tests
<ogra_> yeah
<ogra_> i had a similar issue doing the testbuild here
<rsalveti> let me check the changes
<ogra_> older nux had pulled in libgl1 to the chroot
<rsalveti> which packages got changed? just unity?
<ogra_> yep
<ogra_> one quilt patch and one upstream fix additionally to your change
<rsalveti> the upstream fix kinds of surprised me, I thought it was all in
<ogra_> it was a linaro merge request
<rsalveti> oh, it was approved way back
<ogra_> apparently missed or late
<rsalveti> just not merged
<ogra_> yeah
<ogra_> well, all done now, and i belive infinity also changed to vram=40 already
<rsalveti> ogra_: removed the mem whole also?
<ogra_> so in tomorrows image unity should be testable
<ogra_> i think so ...
<ogra_> ask him ;)
<rsalveti> ended up not opening I bug directly because I thought you'd do the changes :-)
<rsalveti> but seems infinity did it all
<ogra_> we talked about both ... but i didnt check if he did it
<rsalveti> ok
<ogra_> yeah, he was on it already, else i had done it
<rsalveti> <infinity> Dropping the memory hole can't be done until 3.3+, AIUI, it was just the vram bump we need for now...
<ogra_> thats wrong
<rsalveti> well, we're not going to get video decoding at all with this kernel
<ogra_> right
<rsalveti> we don't have a compatible kernel and userspace for it
<ogra_> thats whys we want to drop it and keep the ram for the system
<ogra_> well, if there is anything missing i'll fix it, i know whats needed
<ogra_> no worries
<rsalveti> ok :-)
<pitti> unity built on all arches now, at last!
<ogra_> \o/
<ScottK> skaet: It was a mail to ubuntu-devel on stuff to discuss at UDS.
<rsalveti> \o/
<pitti> cjwatson: just spoke with seb128; he and I can team up on Monday to work on a fix, if you think bug 942539 should be rls-p-tracking, ubuntu-12.04 milestoned, and all that
<ubot2> Launchpad bug 942539 in nautilus "Ubiquity desktop icon text looks messy" [Medium,Triaged] https://launchpad.net/bugs/942539
<pitti> it's certainly a visual wart
<cjwatson> I think it should be, yes - it seems like it shouldn't be that intrusive a fix, once identified
<seb128> pitti, I've pinged upstream nautilus in case they have a clue where to start looking at it
<pitti> cjwatson: yes, I agree; we basically need to teach it to not break on '.' unless followed by whitespace
<cjwatson> thanks
<ev> jdstrand: might I convince you to have a gander at bug https://bugs.launchpad.net/ubuntu/+source/syslinux-legacy/+bug/966135 ?
<ubot2> Launchpad bug 966135 in syslinux-legacy "[MIR] syslinux-legacy" [Undecided,New]
<ev> there's candy and other delicious things inside
<ev> pay no attention to ubot2
<seb128> pitti, I fear it's not going to be "that easy", unicode text wrapping have lot of rules and can be complex, but let's see
<jdstrand> ev: sure
<ev> cheers
<pitti> seb128, cjwatson: I updated the bug
<seb128> pitti, ok, I got a pointer for upstream, I'm looking at it
<seb128> pitti, http://git.gnome.org/browse/nautilus/tree/libnautilus-private/nautilus-icon-canvas-item.c#n1479
<seb128> 			if (*p == '_' || *p == '-' || (*p == '.' && ZERO_OR_THREE_DIGITS (p+1))) {
<seb128> 				/* Ensure that we allow to break after '_' or '.' characters,
<seb128> 				 * if they are not likely to be part of a version information, to
<seb128> 				 * not break wrapping of foobar-0.0.1.
<seb128> 				 * Wrap before IPs and long numbers, though. */
<seb128> pitti, should be easy now that I know where to look at ;-)
<pitti> ah, indeed
<didrocks> oh great :)
<pitti> http://people.canonical.com/~ubuntu-archive/testing/precise-proposed_probs.html
<pitti> \o/
<pitti> all clear again
<pitti> so, just waiting for the publisher to pick up the powerpc unity binary, then we can flush the lot
<skaet> \o/
<pitti> and http://people.canonical.com/~ubuntu-archive/testing/precise_outdate.html is starting to look sane again, too
<pitti> ev knows about that and is on it
 * pitti flushes NBS
<rsalveti> infinity: jbicha: ogra_: I attached the debdiff for bug 935124, if it's still useful
<ubot2> Launchpad bug 935124 in gnome-shell "gnome-shell version 3.3.92-0ubuntu1 FTBFS on armhf in precise" [High,In progress] https://launchpad.net/bugs/935124
<jbicha> rsalveti: it's definitely useful, so it builds on ARM with that patch?
<rsalveti> jbicha: yup
<pitti> didrocks: do you want to have the honor of copying the stuff to -release? I fixed teh tool since the last time
<ogra_> does it run ?
<ogra_> or does it only fix the build failure
<pitti> didrocks: (I can do it, just asking)
<didrocks> pitti: let me do that, it's a nice way to finish the week! :)
 * ogra_ cant imagine it runs without a lot more changes
<pitti> didrocks: it's sru-release -r precise unity unity-2d ...
<didrocks> pitti: sweet! doing ;)
<pitti> didrocks: mind the "-r" to copy to release instead of -updates
<rsalveti> ogra_: I'm still to fully test it, but clutter/cogl is running and fixed for gles
<pitti> didrocks: hold your horses
<didrocks> yeah?
<ogra_> rsalveti, oh, cool !
<pitti> didrocks: still needs to be published, should be in a couple of mins
<rsalveti> and the fixes I proposed at the debdiff are all from upstream
<pitti> didrocks: https://launchpad.net/ubuntu/+source/unity/5.10.0-0ubuntu3
<didrocks> pitti: ok, just the time to finish an email then! ;)
<pitti> didrocks: ppc is "accepted"
<didrocks> looking
<slangasek> skaet: verdict is in; we're changing the armhf PI to the new, really-really-agreed-upstream path
<slangasek> skaet: so that's the glibc and gcc uploads we discussed earlier - infinity will drive
<ogra_> rsalveti, well, definitely SRU-worthy  even if it wont make release
<pitti> didrocks: the publisher starts at :03, and it should be published (in LP's mind) shortly after
<rsalveti> ogra_: yeah
<pitti> didrocks: (it does not actually need to be on archive.u.c., which takes some 30 mins)
<didrocks> pitti: ok, just published on launchpad?
<pitti> didrocks: yes, i. e. in the DB (not necessary to be on archive.u.c.)
<didrocks> ok, thanks, will deal with that :)
<pitti> didrocks: and there we go
 * pitti waves the black-white flag
<ogra_> wrooom
<didrocks> go go go ;)
<pitti> didrocks: wohoo! now go approve them
<cjwatson> slangasek: so a symlink, and binaries built after the gcc change will use the new path?
<didrocks> pitti: and done! :)
 * pitti flushes two more
 * ogra_ hears the gurgling sound 
<slangasek> cjwatson: yes
<slangasek> cjwatson: and I guess we keep the symlink until 14.04
<cjwatson> presumably, and make sure everything gets rebuilt
<slangasek> infinity: ^^ probably a good thing to notate in the source package..
<cjwatson> until *after* 14.04
<slangasek> yes
<slangasek> cjwatson, jodh: so the plymouth change is a "temporary workaround" - this is the stopgap checking for the reference in the specific list before deallocing?
<cjwatson> that's right
<slangasek> ok
<cjwatson> or indeed before doing anything with the event source
<slangasek> you guys think that'll hold up?
<cjwatson> it looks solid so far
<slangasek> ok cool
<slangasek> I guess the bug traffic will let us know if we're wrong
<skaet> slangasek, infinity.   understood.   -proposed please.
<jodh> slangasek: still investigating epoll semantics and adding instrumentation to plymouth...
<slangasek> do we want to assume that all the other crashes are the same bug?
<slangasek> skaet: definitely
<slangasek> jodh: ack :)
<cjwatson> anything that's a crash somewhere under ply_event_loop_process_pending_events that seems to be due to a bogus event source pointer is probably this
<infinity> slangasek: We have no symlink to worry about.
<slangasek> infinity: what now?  /lib/arm-linux-gnueabihf/ld-linux.so.3 ?
<infinity> slangasek: We install *all* our PIs to multiarch paths anyway, and then link from the compiler-derived location.
<jodh> slangasek: adding in extra asserts, we see epoll_ctl calls failing and some of the errno handling is dubious, however we still can't yet pin down the exact cause.
<slangasek> infinity: oh... so this is The Right Thing going forward anyway
<slangasek> check
<cjwatson> jodh: I'm still not entirely convinced that those epoll_ctl failures are causes rather than symptoms, though
<infinity> slangasek: Now, this may take some wrangling in glibc once I do a couple of rounds of rebuilds and realise it's about to do something silly, but I'll find that out today.
<slangasek> yep, understood
<cjwatson> you'd see a failing epoll_ctl if it tried to remove a source that had already been removd
<cjwatson> *removed
<jodh> cjwatson: right - could well be, however the asserts fire pretty consistently - I can guarantee a crash within 2 invocations of plymouthd which is significant I think compared to what we were seeing yesterday.
<cjwatson> so the question is whether that has anything to do with the bug, or just a spurious double-removal
<ev> fixing the whoopsie unit tests on arm is going to have to spill over into the weekend / monday
<pitti> good night everyone, have a nice weekend!
<ev> pitti: and you!
<didrocks> have a nice week-end pitti ;)
<skaet> have  good weekend pitti,  thanks!
<jodh> cjwatson: it's invalid on the very first call to ply_event_loop_remove_source_node().
<cjwatson> curious
<cjwatson> jodh: so that sounds like something closing an fd before disconnecting the epoll source
<jodh> cjwatson: confirmed its the source->fd that's invalid. will look for rogue closes...
<slangasek> infinity: are you bumping shlibs for libc6, or how are you expressing the dependency on the new PI path for binaries built with the new gcc?
<cjwatson> I tried a quick audit and it wasn't trivial to find; I wouldn't be confident we'd got them all
<cjwatson> so I'm glad we have the workaround in place as insurance
<cjwatson> slangasek: for that matter, how would we express that shlibs for binaries built between new gcc and new libc?
<cjwatson> we might have to put armhf on manual for the duration ...
<cjwatson> or perhaps do it all in a PPA
<slangasek> cjwatson: if it's via -proposed?
<cjwatson> we'd have to make sure that nothing else landed in -proposed; I'm not that confident in our communication over extended periods
<slangasek> right
<slangasek> so
<cjwatson> a non-virt PPA would be safer
<slangasek> the bootstrap is eglibc->gcc->eglibc
<slangasek> the first eglibc that adds the new PI path can also add the bumped shlibs
<slangasek> it's slightly overbroad, but safe
<cjwatson> oh, the new PI is in the first eglibc?
<slangasek> yes, AIUI / IIRC
<slangasek> infinity: ^^ can you confirm?
<slangasek> jdstrand: is the 'ubiquity' task on bug #980772 a misunderstanding?  ubiquity is only used for desktop CDs, and the bug report says this only applies to non-desktop
<ubot2> Launchpad bug 980772 in ubiquity "Various files and directories created with odd permissions on precise" [High,New] https://launchpad.net/bugs/980772
<cjwatson> the bug report lists desktop problems ...
<cjwatson> albeit one I can't reproduce
<slangasek> "The desktop install does not seem to be affected:"
<cjwatson> "Other directories:
<cjwatson> drwsrwsrwt 2 root root 40 Apr 13 06:59 /run/initramfs/ (desktop and server)"
<slangasek> oh
<slangasek> lala
<infinity> slangasek: I wasn't entirely sure I was going to care about upgrade paths, given that this is unreleased, but I could bump shlibs on armhf, sure.
<slangasek> infinity: these aren't the last binaries being built in precise; we'd certainly like out-of-order upgrades to not explode on impact over the next two weeks
<jodh> cjwatson: looks like ply_boot_connection_free() is closing the fd source->fd refers to.
 * jodh -> afk
<infinity> slangasek: Sure, I'll do that, then.
<infinity> slangasek: I was going to have to for Debian anyway, where I certainly have less control over things like the buildd network.
<infinity> slangasek: So, I'll bump shlibs for both.
<infinity> cjwatson / slangasek: As for "in between" issues, I'm not bootstrapping it in the archive, unless people give me a really solid excuse to.
<slangasek> infinity: because we don't trust your scary out-of-archive binaries :P
<infinity> cjwatson / slangasek: I have to do test builds locally anyway, to make sure everything's just so, so once those are done, I can toss them on archive-team.internal, and pull them in for one gcc and eglibc build.
<slangasek> yeah, ok
<cjwatson> jodh: so http://paste.ubuntu.com/928183/, maybe
<slangasek> infinity: it spares powerpc some pain, so I guess that's best
<cjwatson> jodh: (assuming that's the only event loop user with this problem)
<infinity> slangasek: It's how I did the rest of the port, why stop now? ;)
 * infinity goes back to setting his local ARM machines on fire.
 * pitti pleasantly sees that today's image is _well_ under the limit
<pitti> thanks Tim Gardner
<infinity> slangasek: The only other question I have is if you'll be cool with me swapping in Michael Hope's GCC patch instead of the one we've been using.  Our compiler is broken for any non-glibc targets (which would matter if people wanted to use Ubuntu to develop for uclibc, bionic, etc)
<slangasek> pitti: what did he jettison? :-)
<cjwatson> unused firmware
<slangasek> sweet
<pitti> throwing out obsolete firmware from linux-firmware
<slangasek> infinity: I haven't seen the delta; want to throw it my way for pre-approval?
<infinity> slangasek: It's patching an entirely different file (ie: the right one).
<slangasek> jdstrand: bug #980772 again - did you use encrypted home dirs when installing?
<ubot2> Launchpad bug 980772 in ubiquity "Various files and directories created with odd permissions on precise" [High,New] https://launchpad.net/bugs/980772
<slangasek> infinity: then can you throw me two deltas?
<infinity> slangasek: http://lists.linaro.org/pipermail/cross-distro/2012-April/000160.html
<slangasek> cjwatson: aha, I'm seeing bug #980772 on an upgrade - so this isn't the installer, it's something amok with initramfs or a udev rule at boot time
<ubot2> Launchpad bug 980772 in ubiquity "Various files and directories created with odd permissions on precise" [High,New] https://launchpad.net/bugs/980772
<cjwatson> slangasek: heh, we commented two seconds apart
<infinity> slangasek: http://paste.ubuntu.com/928192/ <-- Our current patch
<cjwatson> slangasek: how about /media
<slangasek> :-)
<cjwatson> ?
<slangasek>  /media is fine for me
<slangasek> (new install and also upgrade)
<cjwatson> well, I stand by my Incomplete status :)
<slangasek> yes :)
<cjwatson> installer bugs with no logs => not fun
<jdstrand> slangasek: yes
<slangasek> ok
<slangasek> I'm tentatively blaming cryptsetup
<slangasek> jdstrand: is cryptsetup there on the server test too?
<jdstrand> slangasek: 2:1.4.1-2ubuntu3
<slangasek> yep
<slangasek> now the question is, why/where
<cjwatson> can somebody review ubiquity in the queue, so I can nuke the rls-p-tracking tag off apt?
<cjwatson> (problem with tags for this: they can't be bug-task-specific)
 * skaet nods at that
<jdstrand> I should note that these are just straight up iso installs in a vm. for desktop, I used encrypted home and 3rd party. for server encrypted home and all tasks in tasksel (except manual). otherwise default installs
<jdstrand> slangasek, cjwatson
<jdstrand> ^
<jdstrand> cjwatson: which logs do you want?
<gotwig> hey
<jdstrand> the machine is still up
<slangasek> plymouth touches /run/initramfs if it's in the initramfs, which it is if cryptsetup is installed
<gotwig> critical broken package for precise !! : https://bugs.launchpad.net/ubuntu/+source/npm/+bug/863094
<ubot2> Launchpad bug 863094 in npm "npm versions less than 1.1 will not work with registry.npmjs.org" [Unknown,Fix released]
<cjwatson> jdstrand: the standard installer log is /var/log/installer/syslog
<cjwatson> jdstrand: but it doesn't sound like this is actually an installer bug anyway
<jdstrand> it might not be the installer btw-- I just didn't know where else to put it
<jdstrand> (but I'm sure you know that :)
<jdstrand> heh
<gotwig> please help
<cjwatson> gotwig: please don't shout at us
<gotwig> cjwatson: oups... sry
<slangasek> cjwatson: looking at ubiquity
<gotwig> cjwatson: you know, its important....
<cjwatson> SpamapS: ^- can you look at the npm bug above?
 * gotwig likes to use a packaged node.js
 * SpamapS looks
<SpamapS> perhaps we should move the discussion to #ubuntu-motu though?
<cjwatson> yeah, not really a -release matter
<JohnLea> slangasek; hyia, would it be possible to take a look at bug #959339 ?  This is a really critical bug that seems to have fallen through the cracks on the Unity 3d side, and we are trying to get it fixed in time for SRU-0
<ubot2> Launchpad bug 959339 in unity "Launcher, Alt-Tab - clicking on launcher item or selecting a app in Alt-Tab raises all app windows, not just most recently focused" [Critical,In progress] https://launchpad.net/bugs/959339
<gotwig> SpamapS: I reported it there, too...
<slangasek> JohnLea: I'm a bit contended at the moment; perhaps another release-teamer can look
<slangasek> cjwatson: has the ubiquity change been tested in anger?  I'm not going to effectively review the exception handling here
<JohnLea> slangasek, np, thx
<skaet> JohnLea, its being targetted to SRU-0.
<cjwatson> slangasek: I can't reproduce the corruption itself, but I've given it a straight run-through in an install that was doing language pack downloading, and confirmed that language packs are still downloaded correctly
<cjwatson> (and installed)
<cjwatson> slangasek: I can see if I can forcibly corrupt things in situ or something
<JohnLea> skaet; and that is all good at your end?  I'm trying to get everything lined up for the fix for this bug to be landed.
<slangasek> cjwatson: nah, I'm satisfied if we haven't regressed in the non-corrupted case
<cjwatson> IOError is what the consumer of this code is expecting in the "the network ate my homework" case
<slangasek> got it
<infinity> JohnLea: FWIW, I think it should be fixed.  Shame it was broken in the first place. :P
<slangasek> that was about to be my question :-)
<slangasek> cjwatson: accepted
<cjwatson> and the result of IOError is "shrug, log it, carry on"
<cjwatson> great, thanks
<skaet> JohnLea,  been reading through the bug.  possibly this is something to cherry pick a fix up for.   Want you and didrocks on the same page thought before we do.
<jdstrand> slangasek, cjwatson: ok, updated the bug with the installer logs and an updated description for what install options I used
<didrocks> skaet: hum, it's changing the behavior
<didrocks> skaet: so if you click on an icon in the launcher, you won't get the same action
<didrocks> skaet: my recommendation is either get it early next week, like before tuesday
<didrocks> or not
<didrocks> as changing a behavior post release is bad
<infinity> didrocks: It's bringing the behaviour in line with 2d, and yeah, if there's a solid patch ready to do, I say soon, soon, soon.
<infinity> s/do/go/
<didrocks> infinity: agreed, I'm arguing on that one for 8 monthes as you can see on the bug :)
<skaet> didrocks,  yes,   agree,  by monday actually would be the preference if we want to cherry pick this up.     Not happy with it, at all.
<infinity> Yeah. :/
<didrocks> skaet: so am Iâ¦
<infinity> didrocks: If it can be done over the weekend, some of us are a bit flexible in what we call "work hours" (ie: me)
<skaet> Don't think it should be SRU0 material.
<infinity> didrocks: I'd happily review and accept it anytime, as long as it's Really Soon.
<skaet> i'll be around as well this weekend.
<didrocks> infinity: I won't be here on the week-end, I'm already crossing the 80 hours this week ;)
<didrocks> but let me try to get people on that
<infinity> didrocks: Great.  Have your people call our people.
<infinity> didrocks: (Our people can sponsor too, if you're the only uploader they have...)
<didrocks> infinity: sure, just bzr branch lp:~ubuntu-desktop/unity/ubuntu and bzr merge the branch
<didrocks> (full source derived from upstream branch FTW \o/)
<ogra_> ++
<didrocks> I'm just trying to find anyone right now ;)
<infinity> didrocks: Check. ;)
 * ogra_ wishes that bug would have come up this morning
<ogra_> we could have easily included the fix
<ogra_> while waiting for arm testbuilds
<didrocks> ogra_: indeed
<slangasek> infinity:  gcc patch looks safe enough
<slangasek> infinity: michaelh1's gcc patch looks good to me... will you test that armel doesn't get broken before uploading?
<infinity> slangasek: Yeah.
<infinity> slangasek: I've got a weekend to burn CPU time, I'll make sure I get it all just right.
<slangasek> great, thanks
<infinity> (I do like that he tested so extensively, though, gives me some confidence)
<cjwatson> slangasek: hmm.  good news, it didn't crash when I forcibly corrupted a file; bad news, it didn't notice either
<cjwatson> bah
<slangasek> heh
 * cjwatson goes to do a better job
<cjwatson> (or rather, it did crash, but not any worse than before)
<cjwatson> sorry, I clearly should have tried that
<skaet> ogra_,  is there an ordering between the linux-ac100,  and linux-meta-ac100 we're going to need to worry about in the acceptance ordering.   (ie. don't accept meta until the linux-ac100 is through?)
<slangasek> that's the general rule for linux meta packages, yes
<ogra_> skaet, well, same as for the normal kernels
<ogra_> (what slangasek said)
<skaet> NCommander,  can you please look at the linux-ac100 and linux-meta-ac100?
<cjwatson> though it doesn't break the archive if you don't
<infinity> skaet: Accepting it all at once is fine.
<cjwatson> oh, wait, *that* ordering
<cjwatson> it doesn't break the archive if you accept linux-ac100 without linux-meta-ac100
<cjwatson> the other way round would
<infinity> Yeah, but the other way around shouldn't happen.
<infinity> Since linux-ac100 is in binary NEW.
<cjwatson> indeed, would have to be archive admin asleep at the wheel
<skaet> yeah, spotted it and didn't realize initially that linux-ac100 was in NEW.
<infinity> So, it's all the same round.
 * skaet noting
<infinity> Did someone already accept the armhf build?
<skaet> not sure...
<infinity> Looks like.
 * infinity accepts the armel.
<infinity> (and the meta)
<skaet> thanks infinity,   NCommander, ignore request.
<zul> can someone accept horizon..it fixes a regression that was introduced in the last upload
<infinity> zul: It might have to be in the queue first.
<zul> it is..
<zul> -queuebot/#ubuntu-release- Unapproved: accepted horizon [source] (precise-release) [2012.1-0ubuntu4]
<infinity> zul: Err, note the "accepted" there.
<zul> right...nm.....im going back to sleep :P
<skaet> launchpad is timing out on trying to approve software-center for me.  (It has fixes we want to get in, and seems sane from scan perspective).
<skaet> can someone else try and see if they have better luck goosing it through the queue?
<skaet> I've been trying and timing out for last 15+ minutes
<infinity> skaet: Done.
<skaet> Thanks infinity.
<cjwatson> slangasek: ah, I think my ubiquity workaround just failed to handle epochs
<cjwatson> silly python-apt making life hard
<slangasek> heh
<infinity> pitti: I assume this apport workaround is just meant to be closing a large race window with a smaller one?
<infinity> pitti: Did mvo's small patch to GTK+ scare you too much to go that route?
<slangasek> jdstrand: thanks for this bug - I've never seen a value like that passed to chmod before, makes for interesting reading ;)
<slangasek> jdstrand: is your filesystem perms audit something that could be wired up to QA's daily upgrade+install tests as a pass/fail?
<cjwatson> slangasek: wow what
<slangasek> cjwatson: when you failed to reproduce this, were you on i386 by chance?
<cjwatson> yes
<cjwatson> but jdstrand said i386
<slangasek> oh, did he?
<cjwatson> wait, no he didn't
<cjwatson> gah, I managed to misread 12.04 as i386, I think
<cjwatson> that would have saved some time :-/
<slangasek>         org_mask = cur_mask = (mode_t)-1L;
<slangasek> haha what
<jdstrand> no
<jdstrand> I was on amd64
<jdstrand> slangasek: sure-- it is just part of qrt
<jdstrand> pass fail might be difficult
<jdstrand> but someone interested could do it
<slangasek> jdstrand: well, "pass" could be "no bogons found", and everything else a failure?
<cjwatson> (mode_t)-1L is a sentinel value there
<jdstrand> (it is part of the security team's release cycle duties to run these tests and compare to previous releases/milestones
<jdstrand> )
<cjwatson> I suspect the bug is in parse_mode
<cjwatson> er bb_parse_mode
<jdstrand> QRT/install/get_file_info
<cjwatson> hm, maybe not actually, mkdir -m isn't used here
<slangasek> jdstrand: would having it in the jenkins automation save you guys time?
<jdstrand> slangasek: eh..
<jdstrand> probably not
<slangasek> ok then
<jdstrand> it isn't a pass/fail with me
<jdstrand> there is a lot of manual inspection
<slangasek> I was just thinking it might be nice to know about this sort of thing earlier in the cycle
<jdstrand> eg, things like those permissions are pass fail, but then even just changing group ownership on a directory, etc
<cjwatson> so why is mkdir calling chmod when called without -m?
<jdstrand> we investigate it and see if it is ok and then document it
<cjwatson> oh
<cjwatson>     mode_t mode = (mode_t)(-1);
<cjwatson> != (mode_t)(-1L)
<ubot2> Factoid 'mode_t)(-1L)' not found
<jdstrand> slangasek: I can try to make these happen earlier in the cycle
<cjwatson> shut up ubot2
<cjwatson> that's in coreutils/mkdir.c
<jdstrand> normally we shoot for beta and then again with rc
<jdstrand> but beta didn't happen due to being crazy busy
<cjwatson> slangasek: http://git.busybox.net/busybox/commit/?id=af36ba206f7cf0eef77a82af741766a2d03c51ad
<slangasek> bingo
<slangasek> cjwatson: thanks
<cjwatson> np
 * skaet --> appt,  back later.
<slangasek> though this only fixes mkdir, so doesn't explain what jdstrand saw under /dev
<slangasek> so maybe there's a corresponding bug + fix for mknod
<cjwatson> not sure I see anything relevant upstram
<cjwatson> +e
<cjwatson> surely udev doesn't shell out to mknod though?
<slangasek> I'm not convinced these are udev's doing
<slangasek> /dev/autofs?  what the heck is that?
<cjwatson> rules/rules.d/50-udev-default.rules:94:KERNEL=="tun",                   MODE="0666", OPTIONS+="static_node=net/tun"
<slangasek> no /dev/autofs in my /var/log/udev
<cjwatson>                         /* set sticky bit, so we do not remove the node on module unload */
<cjwatson>                         mode |= 01000;
<cjwatson> in udev
<slangasek> so do we think that's non-buggy?
<cjwatson> so that will account for at least some of those
<cjwatson> it's an exotic use for the sticky bit, but it seems entirely deliberate (it's in the udev ChangeLog for 174, even) and not totally unreasonable
<jdstrand> oh
<jdstrand> fascinating
<slangasek> ok
<cjwatson> it's not like it means anything else
<slangasek> uploading just the busybox fix then
<jdstrand> I will document that
<jdstrand> does that account for all of the sticky bits?
<cjwatson> I think so; udev forces the sticky bit on devices that the kernel tells it to create in some cases, too
<cjwatson> you can grep -r sticky yourself :-)
<cjwatson> I can't think how it would be security-harmful
<jdstrand> cjwatson: cool. thanks
 * jdstrand documents
<slangasek> bdmurray: when you reproduced bug #874774... did it only happen for you on the first boot after install?
<ubot2> Launchpad bug 874774 in cryptsetup "could not mount /dev/mapper/cryptswap1" [High,Triaged] https://launchpad.net/bugs/874774
<slangasek> bdmurray: because that's what I've gotten here :P
<cjwatson> I don't know at the moment why it's only applied to some device nodes and not others
<cjwatson> busybox LGTM, accepting
<cjwatson> we'll probably want a d-i upload later to pull that in
<bdmurray> slangasek: I didn't watch the 2nd boot closely but could check again
<cjwatson> can somebody review my go-around on ubiquity?
<jdstrand> cjwatson: thanks for looking at those sticky files btw-- I got distracted by the tty business and forgot to circle back around
<cjwatson> this time it correctly detected corruption and smoothly elected not to install language packs
<cjwatson> np
<cjwatson> hmm, busybox-initramfs doesn't actually call update-initramfs on upgrade; I hope there'll be something else that does that before release
<cjwatson> there was a circularity problem with it doing so way back in the old days
<cjwatson> I don't know if there still is, and there may not be since that was before we had triggers, but I'm not entirely certain I want to find out just now
<slangasek> unless jdstrand thinks this is USN-worthy, I'm inclined not to worry about it... it's a DoS if someone fills /run, but it seems to only be that one dir that's affected and we can count on a kernel SRU soon enough
<slangasek> looking at ubiquity
<slangasek> webkit's cache> oho
<cjwatson> not quite sure if it will do the job but certainly worth a shot
<slangasek> yep
<cjwatson> and it doesn't regress installation, at least
<slangasek> ubiquity accepted
<slangasek> reviewing django-nose (MIR prereq, python-support deprecation)
<jdstrand> slangasek: and thank you for digging in and fixing busybox. kinda a neat bug :)
<slangasek> no worries
<slangasek> those are always the fun amd64 bugs
<slangasek> the unfun ones are the 50th time a GNOME application segfaults in gobject because the upstream gtk docs give bad advice that seduces people into not being 64-bit-clean
<slangasek> y'know, I've never done an install in asturianu before
<slangasek> let's give it a try
<jdstrand> heh
<slangasek> lamont: welcome to final freeze? :P
<lamont> slangasek: I discussed it with scottk before uploading
<slangasek> ok :)
<lamont> bind9 is me fixing my "chown 644" typo
<jdstrand> SpamapS: fyi, just noticed that python-ceph Depends on librgw1, but we don't build librgw1 any more
<lamont> postfix is one that fails to _start_ _sometimes_ because of a typo in the ssl cert handling
 * jdstrand looks curiously at the same version of unity building in two different native ppas and taking up powerpc's resources
<jdstrand> SpamapS: ok, filed 981130 and assigned to you so we wouldn't lose it. feel free to reassign/etc
 * ScottK is reviewing bind9 and postfix
<ScottK> jdstrand: I'm sure it's critical due to the large Unity on Power userbase.
<jdstrand> hehe
<jdstrand> one finished. it just looked funny
<SpamapS> jdstrand: will look into it.
<bdmurray> slangasek: the cryptswap message appeared again on my 3rd(?) bot
<slangasek> bdmurray: interesting, ok
<slangasek> so it seems to be racy in some way
<slangasek> or there are multiple causes
<slangasek> bdmurray: do you have /var/log/upstart/cryptdisks-enable.log on this system?
<cjwatson> ah, good, openjdk-{6,7} have both finished
 * cjwatson copies
<bdmurray> slangasek: http://paste.ubuntu.com/928514/
<slangasek> bdmurray: yep, looking familiar
<cjwatson> yay for job logging
<slangasek> yep :)
<cjwatson> made use of it in anger yesterday when working on mountall, too
<cjwatson> cleaned up the pad too
<cjwatson> copying ubiquity, which has built
<cjwatson> stgraber: ^- "/primary"?
<cjwatson> syncs from a PPA causing confusion maybe?
<cjwatson> or something to do with them being new?
<cjwatson> ... they're syncs from Debian, not from a PPA, it seems
<cjwatson> SpamapS: is there an FFe for all the node-* stuff?
<ScottK> cjwatson: There is.  I'm taking care of it.
<cjwatson> OK, cool
<stgraber> cjwatson: Were these new source packages or just binary?
<cjwatson> stgraber: source
<cjwatson> syncs of source packages from Debian, not previously in Ubuntu
<stgraber> cjwatson: I seem to remember writting some code where it'd print the archive name (primary or partner) when it can't figure out a component (as a new source, as far as LP is concerned, doesn't have a component yet)
<stgraber> that's mostly useful to spot partner uploads really
<cjwatson> mm - but in this case it's printing the archive name from Debian, which is dubiously useful without qualification
<stgraber> >>> list(lp.distributions['ubuntu'].archives)
<stgraber> [<archive at https://api.launchpad.net/1.0/ubuntu/+archive/primary>, <archive at https://api.launchpad.net/1.0/ubuntu/+archive/partner>]
<stgraber> cjwatson: ^
<cjwatson> stgraber: oh, the web UI said "Sync from Primary Archive for Debian GNU/Linux" or some such, so I thought that was what you were using
<cjwatson> OK, fair enough
<cjwatson> >>> list(lp.distributions['debian'].archives)
<cjwatson> [<archive at https://api.launchpad.net/1.0/debian/+archive/primary>]
<slangasek> cjwatson: 848915> I'm getting the overall impression that "partial upgrade" is more trouble than it's worth and we should kill it off as an option
<slangasek> cjwatson: there's a bug from mpt about this which I think mvo has weighed in on, let me fetch
<cjwatson> slangasek: so am I, but I'm not going to do that now
<cjwatson> yeah, I believe I've seen it
<slangasek> ok
<slangasek> you think it's too high-risk?
<slangasek> it would be a small change to just never present that option
<cjwatson> I don't want to suddenly find out that we needed it after all for some reason and then have to fix this bug anyway ...
<slangasek> sure
<cjwatson> I don't feel I know u-m well enough to judge that
<cjwatson> but based on experience from ubiquity it seems that this bug shouldn't be too hard to fix directly - *if* we can reproduce it
<slangasek> fair enough
<slangasek> bug #955022 was the one, fwiw
<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
<cjwatson> slangasek: I'm sceptical that this actually has anything to do with partial upgrade mode, anyway
<slangasek> fair 'nuff
<cjwatson> slangasek: out of 17 duplicates, only two have "PythonArgs: ['/usr/bin/update-manager', '--dist-upgrade']", and the rest have other arguments
<cjwatson> slangasek: also, only one of those bugs is from the final oneiric version or newer
<slangasek> interesting
<cjwatson> which might just mean poor duplication, but
<slangasek> or was there a bug pattern for this?
<cjwatson> oh, could be, I should check
<cjwatson> I don't see a bug pattern
<cjwatson> there's one mention in bug 350988 of running update-manager from cron and it getting upset
<ubot2> Launchpad bug 350988 in update-manager "update 8.10 to 9.04 ==> Pb with udevinfo (not found)" [Undecided,Opinion] https://launchpad.net/bugs/350988
<cjwatson> to which I say meh
<NCommander> skaet: bah, sorry about that
<cjwatson> all but three of the bugs had recently upgraded from natty to oneiric, and two of the remainder from oneiric beta to oneiric; recently enough that they might not have restarted yet, perhaps
<cjwatson> two of the bugs used --no-focus-on-map, I think implying that it was launched from update-notifier
<cjwatson> can't reproduce it that way either.  trying a natty install
#ubuntu-release 2012-04-14
<cjwatson> perlqt LGTM
<slangasek> bdmurray: I think I have the cryptsetup fix.... it's a 'udevadm settle' before 'dmsetup rename' :P
<slangasek> bdmurray: I can't be 100% sure I've caught it since it's racy... care to give lp:~vorlon/cryptsetup/lp.874774 a try on your machine?
<cjwatson> slangasek: when you get a moment (no rush, I'm off to bed), what do you think of my analysis of bug 979661?  I'm not entirely convinced that the libc6/libnih1 pre-depends resolution bug is in fact the same as bug 850264, although that was the primary symptom that dupondje presented with earlier and you said that that was his bug
<ubot2> Launchpad bug 979661 in update-manager "oneiric to precise: debconf: unable to initialize frontend: Gnome and falls back to Dialog" [High,New] https://launchpad.net/bugs/979661
<ubot2> Launchpad bug 850264 in apt "given a foreign architecture of i386 on amd64 machine, and an outdated libc, apt tries to remove libc-bin" [High,Fix released] https://launchpad.net/bugs/850264
<slangasek> cjwatson: that's not the bug number of the libc6/libnih1 issue, is it?
<slangasek> so my analysis that it was the same issue was based on the logs attached to the bug... whichever one it was now
<slangasek> bug 946709
<ubot2> Launchpad bug 946709 in update-manager "Upgrade 11.10 ->12.04 fails with "Couldn't configure pre-depend libc6 for libnih1, probably a dependency cycle." (dup-of: 850264)" [Undecided,Confirmed] https://launchpad.net/bugs/946709
<ubot2> Launchpad bug 850264 in apt "given a foreign architecture of i386 on amd64 machine, and an outdated libc, apt tries to remove libc-bin" [High,Fix released] https://launchpad.net/bugs/850264
<slangasek> I quoted the relevant of apt.log in the bug
<slangasek> I certainly didn't think the debconf frontend issue was related :)
<cjwatson> ah, I think this is a bit different, because in that case apt is refusing to do the operation at all; in this case, it's doing it but getting the ordering wrong
<cjwatson> (ignoring the debconf warnings for a moment, you can see it failing to unpack libnih1)
<cjwatson> ok, so not dupondje's bug
<slangasek> right
<cjwatson> but nasty; do you happen to know of a bug for this bit/
<cjwatson> ?
<cjwatson> I couldn't find one in a quick changelog trawl
<slangasek> no, don't think I'd seen this one before
<cjwatson> unless it's the giant unpack/configure ordering rearrangemnet
<cjwatson> it wouldn't totally surprise me
<slangasek> yeah... that would be no fun
<cjwatson> things that are hard to SRU, #43
<cjwatson> oh, wait, maybe I'm wrong
<cjwatson> it says "Configuring libc6:amd64", so maybe the debconf confusion caused that to fail
<cjwatson> and that's before it unpacks libnih1
<cjwatson> OK, false alarm
 * cjwatson -> bed, since I think my analytical abilities are fading
<slangasek> :)
<slangasek> night
 * ScottK ^^^
<ScottK> I'll look at muon in a moment too.
<wgrant> cjwatson: It's been back for a while now. LVM decided to hang a couple of times, it seems.
<slangasek> ^^ that cryptsetup fixes bug #874774, I believe
<ubot2> Launchpad bug 874774 in cryptsetup "could not mount /dev/mapper/cryptswap1" [High,Fix committed] https://launchpad.net/bugs/874774
<infinity> Ahh, udevadm settle, the new sleep.
<infinity> Accepting on "I can't see how it can be worse" grounds.
 * infinity tries to decide what to do with doko's gdb upload...
<slangasek> infinity: it's much better than sleep, when used correctly :)
<infinity> That's true of a lot of things.
<slangasek> heh
<slangasek> the only way to improve on udevadm settle here would be an interface that lets us wait for a *specific* event to finish processing... and that would be unwieldly
<slangasek> infinity: so how goes the compiling?
<infinity> slangasek: Nothing's exploded yet?
<infinity> GCC seems happy, eglibc's building, at which point, I expect to discover I did something dumb.
<infinity> Because I'm a pessimist.
<slangasek> assuming it continues not exploding, what's the ETA to an upload?
<infinity> It'll be done by the end of the weekend for sure, but if everything goes smoothly, I expect tomorrow.
<slangasek> ok
<slangasek> I'm out all day tomorrow and won't be able to help pushing it in
<infinity> Turns out that you're not the only Release/Archive dude that doesn't understand "core hours".  I'm sure I can find some reviews. ;)
<slangasek> ;)
<slangasek> just letting you know not to expect me :P
<infinity> Oh, crap.
<infinity> Hrm.
<infinity> dpkg-shlibdeps is about to outsmart me.
<infinity> slangasek: It's entirely possible that, short of not shipping .symbols files, I might not be able to represent the ABI break in the PI move.
<slangasek> this is sounding familiar
<slangasek> how are you doing the override?
<infinity> slangasek: Override isn't the issue, the .shlibs file is correct.
<infinity> slangasek: It's that dpkg-shlibdeps prefers .symbols, if present.
<infinity> slangasek: And some packages (like, uhm, gcc), only use symbols from 2.11 and earlier, apparently. :P
<infinity> But, maybe there's a way for me to represent the PI itself in the symbols file.
<slangasek> right... but if the package uses dpkg-gensymbols (perhaps via dh_makeshlibs), the symbols file in the binary is a munging of the .shlibs and the sourceful symbols, I think?
<slangasek> ld-linux.so.3 #PACKAGE# #MINVER#
<slangasek> that #MINVER# token can be replaced directly, IIRC?
<infinity> That doesn't seem to be replaced by anything on build...
<slangasek> no - but you can manually replace it
<slangasek> in the source
<infinity> Oh, sure.  Will that be enough to fake out dpkg-shlibdeps?
<infinity> I guess I can find out with a minimal hello or something.
<slangasek> I believe so
<infinity> In that case, I don't even need to muck with shlibs versions, which would be much cleaer.
<infinity> cleaner, too.
 * infinity sets about doing some manual testing.
<infinity> Depends: libc6 (>= 2.4), dpkg (>= 1.15.4) | install-info
<infinity> Looks like a good candidate.
<slangasek> the alternative would be to artificially bump the dependency for some of the symbols in the PI (probably the symbol-version-symbols)
<slangasek> either way, it needs fixed in the .symbols, yes
<infinity> Do dee do...
<infinity> Oh, I found my oops.  Carrying on.  Nothing to see hre.
<infinity> Nor here.
 * infinity blinks.
<slangasek> don't mind the rejects
<slangasek> :)
<infinity> Oh, I mind.
<infinity> http://www.youtube.com/watch?v=92IkddsjtAA <-- I mind this much.
<slangasek> heh
 * infinity wonders if he might be able to find time in the next week to heroically fix dpkg-divert --rename --package
<infinity> Not that it does us any good right now if I do, but at least then it would be fixed pre-release in an LTS, which bodes well for transitiony things.
<cjwatson> excellent, powerpc has cleared
<doko> and the rebuild is finally finished on x86 too
<stgraber> I just requested an ldm sync (not shown by queuebot as it was down), that's for the ldm bugfix I mentioned in my e-mail to the release mailing list and during the meeting
<stgraber> The diff should be fairly easy to review and from my point of view is all bugfixes, including the one for the typo breaking OpenGL on thin clients (that we really want for release)
<stgraber> let me know if you have any question
<cjwatson> slangasek: I've moved bug 848915 to rls-p-nottracking; rationale in the bug
<ubot2> Launchpad bug 848915 in ubuntu-release-notes "$DISPLAY not set in some cases, resulting in cryptic traceback" [Undecided,Fix released] https://launchpad.net/bugs/848915
<slangasek> cjwatson: ok
<cjwatson> stgraber: ldm LGTM; accepted
 * cjwatson copies gnome-shell, which has finished building in -proposed
<cjwatson> ps3-kboot fixes the last powerpc-only build failure in main
<cjwatson> entertaining race there - I accepted gnome-shell shortly before the bot finished processing it, which I think is what caused it to say "3.4.0-0ubuntu3 => 3.4.0-0ubuntu3"
<doko> could somebody review the two outstanding python2.6 issues? plus the zope2.12 removal request?
<cjwatson> pygobject-2 is fine
<cjwatson> python-stdlib-extensions is fine
<cjwatson> out of time for the removal request though
<cjwatson> (I mean I need to go and do other things rather than sitting aimlessly in front of the computer :-) )
<slangasek> that's an apt SRU we'll want in before release, one of two package manager bugfixes wanted for a clean multiarch upgrade for oneiric->precise
<doko> ok, thanks, afk for the evening
<slangasek> if there's an SRU team member around to approve it who *isn't* overdue for some afk R&R ;)
<gotwig> hey
<gotwig> SpamapS: hey there
<gotwig> Streamstormer: dont have much; have you read my mail; do you know the problem?
 * gotwig does not have much time
<Streamstormer> gotwig, sorry what do you mean?
<gotwig> Streamstormer: sorry.. wrong guy :X
<gotwig> SpamapS: dont have much; have you read my mail; do you know the problem?
<Streamstormer> gotwig, ok np
<stgraber> cjwatson: thanks
 * ScottK ^^^
 * ScottK took care of node too.
<Laney> wdyt to opennebula? bug #959087
<ubot2> Launchpad bug 959087 in ubiquity "with the newly burned cd-r it crashed in the same way as the last time (dup-of: 892846)" [Undecided,New] https://launchpad.net/bugs/959087
<ubot2> Launchpad bug 892846 in ubiquity "ubiquity crash during installation after failed grub install" [Undecided,Confirmed] https://launchpad.net/bugs/892846
<Laney> erm
<Laney> bug #959097
<ubot2> Launchpad bug 959097 in opennebula "FFe: Sync opennebula 3.2.1-2 (universe) from Debian sid (main)" [Wishlist,New] https://launchpad.net/bugs/959097
<ScottK> I was just reading the bug and hoping you would decide.
<Laney> the diff is huge
<Laney> but we might be against the wall with the refusal of support thing
<ScottK> It's probably better to lean forward than back in such cases.
<Laney> done.
 * ScottK just said no to distro-info.
<ScottK> "nice to have" and "final freeze" don't mix.
 * ScottK took care of ^^^
<cjwatson> ^- fixes last NBS entry
<stgraber> I'll have a look as soon as I get a diff from LP
<stgraber> cjwatson: looks good, feel free to accept
<cjwatson> done, thanks
 * ScottK accepted ps3-kboot too.
<ScottK> ^^^ fixes a high impact bug for UbuntuOne.  I'd appreciate it if someone would review/accept.  Then we can get it built/tested and decide if it ends up in -release or -updates.
<infinity> ScottK: Looking.
<infinity> Or, will in a bit.
<ScottK> infinity: Thanks.  Diff is from upstream.
<infinity> ScottK: Patches that remove copyright notices are kinda uncool (unless Phil works for Riverbank, and he just got the attribution wrong the first time?)
<ScottK> infinity: He does.
<infinity> Kay.
<ScottK> He's been gradually changing them from his name to the company's as he touches files.
<infinity> This sort of implies this is non-deterministic...
<ScottK> It is.  But since he's both the guy doing the work for Riverbank and an employee of Riverbank it doesn't make much difference.
<infinity> ScottK: I meant the patch, not the copyright notice. :P
<ScottK> Oh.
<ScottK> That too.
<infinity> ScottK: I'd have to hunt down what dbus_watch_handle() actually does, but I'm concerned that it might "sometimes" kill the socket?
<ScottK> It was only failing ~a third of the time.
<infinity> Or, more likely, this is trying to close an external threading race with... A slightly smaller race window.
 * infinity shrugs.
<ScottK> There's a reduced test case in the bug if you want to investigate.
<infinity> It's not any more broken than it was before.
<infinity> I guess that's all I can hope for from upstreams.
<ScottK> ;-)
<ScottK> One day turn-around was nice too.
<infinity> I have no interest whatsoever in looking into it more, no.  I'm currently fighting with making ld.so rewrite SONAMEs on the fly.
<infinity> But yeah, this looks a lot like someone just trying to close a race window.
<infinity> Which, like I said, isn't more broken than it was, and given dbus lag, probably makes it look "fixed" most of the time.
<infinity> So, whatever. :P
<ScottK> Thanks
#ubuntu-release 2012-04-15
<ScottK> ^^^ is my upload, so I'd appreciate some other archive admin reviewing/accepting.
<infinity> Erm.
<infinity> Now that we have multiarch, why not make an arch:all package that depends on the arch:ppc one?
<infinity> Oh, I guess that's overkill.
<infinity> Either way, I guess qemu and the like still can't depend on it. :/
<infinity> ScottK: Did you at least make it Multi-Arch: foreign, so I can install it?
<infinity> Oh, I guess I can do that manually wihthout the M-A header, things just can't depend on it.
<ScottK> infinity: No.  I just beat it into a arch dependent package that only builds on powerpc from an arch indep package that only builds on powerpc.
<infinity> It's a shame it's GPL. :/
<infinity> If it was BSD, I'd just toss the binary blob in multiverse and call it done.
<infinity> Anyhow, this situation is no worse than what we had before.
<ScottK> Before we had no binary at all.
<infinity> ScottK: Have you downloaded the deb from the build and confirmed that qemu appears to like it in some meaningful way?
<infinity> Yeah, hence no worse than before. :P
<ScottK> No.  I haven't.  I've assumed that it builds something useful since it does in Debian.  I figured all I needed to do was trick it into building on LP.
<ScottK> It builds and there's some binary file in there is all I can tell you.
<infinity> Heh.
<infinity> I'm not sure how useful it is, unless people are really willing to turn on multiarch for one deb.
<infinity> But meh.
<infinity> Like I said, better than the previous situation.
<ScottK> Thanks.
<infinity> doko_: Do you have a valid argument for the GDB upload in the queue?
<infinity> doko_: Actually, on second though, I'm going to reject it so no one else accepts it, and you can argue the point later. :P
<infinity> ScottK: Want to review a diff for me and have a bit of a cry?
<infinity> ScottK: http://lucifer.0c3.net/~adconrad/eglibc.debdiff
<ScottK> As soon as I saw the package name, I knew there would be tears.
<ScottK> It seems not unreasonable, but I by no means feel comfortable with saying it's OK or not.  Way over my head.
<infinity> If it doesn't seem unreasonable, I think that's proof it's over your head, yes. ;)
<infinity> But thanks for the vote of confidence.
<ScottK> Not unreasonable in that I suspect is does what you want.
<ScottK> That saws nothing about the reasonableness of what you want.
<infinity> It appears to, yes.  No kittens have died thus far.
<ScottK> Also, if some guy is going to be they guy that approved the upload that broke eglibc during final freeze, I do not want to be that guy.
<infinity> ScottK: Wuss. ;)
<ScottK> I chickened out on approving the last openssl merge too.
<nigelb> sssss/ws 36
<nigelb> gah
<infinity> *slow clap*
<nigelb> infinity: What are computers? How do I use 'em? :)
<infinity> Try not to pass out on the "s" key, and you'll be fine.
<nigelb> heh
<ScottK> infinity: ^^^ just makes the version numbers line up pretty.  It turns out to affect the Kubuntu dvd, but I think we should do it anyway.  Otherwise it's 5 years of "Why is python3 at 3.2.3~rc1 and python3.2 is at 3.2.3?"
<infinity> Yeah, doko did the same for python-defaults, didn't he?
<infinity> I was going to accept it as soon as I saw the diff.
<ScottK> He did.
<infinity> (rather, as soon as I've reviewed it)
<ScottK> It won't take much longer to review it than to see it.
<infinity> ScottK: You dropped the maintainer mangling in debian/control.
<infinity> -Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
<infinity> -XSBC-Original-Maintainer: Matthias Klose <doko@debian.org>
<infinity> +Maintainer: Matthias Klose <doko@debian.org>
<ScottK> It's suppose to do that automagically.
<ScottK> Hang on.
<ScottK> infinity: Found it.
<ScottK> I can't spell Ubuntu.  Please reject that one.
<infinity> Oh, hah. 0ubunu1
<infinity> I didn't even see that.
<ScottK> The maintainer magic did though.
<ScottK> I guess that's why we review them all at this stage.
<ScottK> New one is uploadded.
<infinity> Every time I see something like that, I'm reminded that I want to revisit my pam_dwim module.
<ScottK> ;-)
<infinity> Your scripts totally should have noticed and fixed the typo.
<infinity> Just like a computer should log me in if my password is "close enough".
<infinity> Picky things.
<ScottK> And not log someone else in on your account even if it's close, because that's not what you want.
<infinity> That logic might be harder to write, but yeah.
<infinity> pam_dwim would just try a few simple and common typo transpositions and home-row offsets and such before giving up, with a scaleable fuzziness level.
<infinity> At sufficiently high fuzz levels, it'll offload to an opencl library and get your video card to log you in.
<ScottK> At one UDS, apachelogger_ had a facial recognition module for kdm working reasonably well.
<ScottK> Thanks.
<infinity> I'd do facial rec for unlocking phones with front-facing cameras, except that it's so touchy.  Not being able to log in because my face is partially in shadow, or I'm wearing a hat, could prove annoying.
<ScottK> Finished 1 minute ago (took 55.4 seconds)  <--- buildds are getting faster, I guess.
<infinity> Well, the i386 chroot is fresh, and sbuild no longer purges build-deps.
<infinity> So, yeah.
<ScottK> Also, until it gets reliable enough to disable password access, it's a convenience thing, not a security feature.
<infinity> On roseapple, we were seeing langpack builds in 20ish seconds after I landed that change.
<ScottK> Nice.
<infinity> Well, okay, the chroot *was* fresh.
<infinity> Silly people and their uploading.
<ScottK> Speaking of which, I see you cracked into the top ten uploaders this cycle.  You've been a busy boy.
<infinity> I've been slacking.
<infinity> Didn't do a single transition...
<infinity> Though, I still have time to do an fpc one.
<infinity> But that's a tiny package set.
<ScottK> Doesn't it need bootstrapping on armhf?
<ScottK> IIRC, I only did one library transition and it had 3 rdepends.
<infinity> Yes, hence the transition.
<ScottK> Ah.  Right.
<infinity> Since I'll be updating to 2.6.x at the same time. :P
<infinity> Cause, hey, that's the sort of thing one does 1.5 weeks before release.
<infinity> Looks like the only thing we'll be missing on armhf is gnat.
<ScottK> Meh.  Universe.
<infinity> Which is unfortunate, but we all just ran out of time to make it go. :/
<infinity> Well, ada's not hip and cool anyway.
<infinity> If it had been haskell, people would have been upset about their pet language.
<ScottK> There was one discussion about if a package update had new features (and thus would need an FFe) and part of the conversation was "It's written in haskell, so it's hard to tell."
<infinity> I only had 385 uploads in oneiric.
<infinity> I *am* slacking.
<infinity> Hahaha.  Yeah.  My friend's doing a haskell course at university right now, and I help him with his homework occasionally.
<infinity> It's pretty much gibberish to me.
<ScottK> I'm not sure how many uploads I have but for Oneiric I was #5 on the uploaders list and this time I'm #26.
<infinity> I have you at 641 for oneiric.
<infinity> Where is this shiny list?
<infinity> I'm just grepping -changes. :P
<ScottK> http://people.ubuntuwire.org/~stefanor/ubuntu-activity/
<ScottK> Oneiric was also the cycle where Riddell was on the bzr team, so I stepped up my game.  $WORK was a bit slow too, which also helped.
<infinity> Heh.
<infinity> Colin totally cheated this cycle with transitions.
<infinity> I demand half of his life-saver chunk be equally redistributed.
<infinity> Man, you can so see when I moved from distro to IS...
<infinity> #7 in breezy, #12 in dapper, then.. Gone.
<infinity> Sad.
<ScottK> Looking back, I'm quite surprised.  Feisty was the first release I was involved in development in and I made the top 50 despite not being a MOTU yet and not starting until halfway through the cycle.
<infinity> That's not that surprising.
<infinity> A) there weren't a lot of us, and B) even as we've expanded the ranks, a few really involved people always do most of the heavy lifting.
<infinity> I'm a bit confused by my not showing up in hoary, though.
<ScottK> Gotta love these helpful debian/changelog entries, "Update packaging bits.".
<infinity> ;)
<micahg> meh, I was hoping for top 5 this cycle, but not making it for +1 maintenance threw that out the window
<infinity> Oh, maybe I didn't start until the tail end of hoary.  I suck at history.
<ScottK> micahg: There's more than enough unseeded Universe FTBFS to fix to resolve that concern.
<infinity> micahg: I haven't uploaded much with a +1 maint hat on.
<micahg> ScottK: I'm aware, the only thing I'm lacking is time
<infinity> micahg: Also, what Scott said.  Fix every FTBFS please.
<micahg> infinity: that's why I still have more uploads than you :)
<infinity> You have time right now!
<micahg> infinity: yeah, I'm taking a look at a few things now
<ScottK> I used to look at my LP karma and go 'wow'.  No I check it every now and then to make sure it hasn't gotten too high.
<infinity> My LP karma sucks.
<infinity> I should probably register and needlessly manipulate a blueprint every morning with my coffee.
<infinity> I'm sure I could automate that.
<ScottK> It's hight than mine (which is good).
<ScottK> My current goal is to stay under 25K.
<infinity> Yeah, but I only compare to doko and cjwatson.
 * micahg would like to break 30k again, but that will require a bit of effort
 * infinity would like to remove karma from LP.
<infinity> Maybe I'll do that in my next commit, in the name of "every new line should remove two others".
<ScottK> No.  How else would I know to go do something else for a few days?
<infinity> Get a dog.
<infinity> They're needy.
<ScottK> Got a dog.
<infinity> Hrm.
<ScottK> It's very old and very needy.
<ScottK> Got kids too (3).
<infinity> I'm stumped, then.
<ScottK> Also very needy and distracting.
<ScottK> The dog gave up and went to bed about two hours ago.
<infinity> lobotomy?
<ScottK> If the amount of alcohol I consumed in my 20's didn't do it, I don't think so.
<infinity> Could explain the KDE fetish, though.
<ScottK> That's purely what I started on.
<ScottK> Other stuff feels wrong.
<infinity> That's how I explain my sexuality.
<ScottK> Gee.  Look at the time.  I should probably go get some sleep.
<infinity> Hahaha.
<infinity> G'night. ;)
<infinity> (I win!)
<infinity> I'm probably not being useful by staring at parallel glibc builds scrolling by, maybe I'll nap too.
<micahg> ScottK: congrats on fixing openbios-ppc :)
 * micahg wonders if we should SRU the fix
<infinity> Nah.
<infinity> People still need to do some hand-installing anyway.
<infinity> So pointing them at the precise deb is just as easy. :P
<infinity> I'm wondering if it might not be almost "saner" (for some messed up value of "sane") to just have all the openbios* stuff be downloader packages that grab the Debian version and unpack it. :P
<ScottK> micahg: If someone cares, they can ask for a backport.
<infinity> Then we could still have sparc too.
<infinity> And whatever other ones there may be.
<micahg> can someone please retry libcomplearn in the rebuild?
<infinity> micahg: Done.
<micahg> infinity: thanks
 * infinity thinks he's finally tracked down the last place(s) where the linker change will affect us.
<infinity> Although, the d-i bit will need some trial and error to get right.
<micahg> bug 982232 \o/
<ubot2> Launchpad bug 982232 in yada "Please remove yada source and binaries as well as its reverse dependencies" [Wishlist,Confirmed] https://launchpad.net/bugs/982232
<infinity> micahg: Done.
<micahg> infinity: awesome :), I at least met one of my release goals
<infinity> Hahaha.
<infinity> "Kill yada" has been an Ubuntu goal since our inception.
<infinity> We got it out of main in a hurry, but... Today's a good day.
<cjwatson> reminder to self: we should sync golang 2:1-5 once LP knows about it, to fix the armel build failure
<infinity> cjwatson: Because disabling tests is always a winning notion. ;)
<infinity> cjwatson: Say, want to eyeball a diff for me?  I'm waiting for my laptop to have some spare CPU time to actually do a test build. :P
<infinity> cjwatson: http://paste.ubuntu.com/931060/
<infinity> cjwatson: Err, context is bug #852101
<ubot2> Launchpad bug 852101 in ia32-libs "32-bit applications do not start on 64" [High,Fix released] https://launchpad.net/bugs/852101
<cjwatson> at this point in the cycle, disabling tests may be all we have :-/
<cjwatson> infinity: LIBC is substituted?
<infinity> True.  And I'm trying my best to make sure people don't run armel anyway. :P
<infinity> cjwatson: Yeah, is gets munged to the current package/pass.
<cjwatson> /lib/ld-linux.so.2 won't ever be a dangling symlink?
<cjwatson> I'd quote $(readlink -f /lib/ld-linux.so.2) because I'm paranoid
<infinity> Heh.
<cjwatson> also would be inclined to use rm -f but that's probably superstition
<infinity> I tend never to force in maintainer scripts.
<infinity> My theory is that if you're screwing with the package manager in ways that make root unable to do things, you've got bigger problems.
<cjwatson> mm
<infinity> And yeah, /lib/ld-linux.so.2 can end up dangling, which is why the elif nukes it.
<infinity> Because libc6:i386 and libc6-i386:amd64 both ship it, and both replace each other.
<cjwatson> but [ ! -f ] will pass on a dangling symlink so that ln -s could fail.
<infinity> So, due to the fun of package takeovers, and then me cowboying the ln -s...
<cjwatson> indeed, you could just [ -h /lib/ld-linux.so.2 ] && [ ! -f /lib/ld-linux.so.2 ] rather than bothering with readlink; -f follows symlinks anyway
<infinity> Oh, right.  I forgot about that property of -f.
<infinity> Is that POSIX?
<cjwatson> yeah
<cjwatson> derives from stat
<infinity> Kay.  I'll scrap the readlink, then.
<cjwatson> I'm a bit perturbed that the two branches of the if leave the system in wildly different states
<infinity> And change the first to a -h
<cjwatson> not sure I quite understand it at this stage of caffeination
<infinity> So, basically, it's combating two seperate issues:
<infinity> 1) installing both libc6:i386 and libc6-i386 and then removing one will leave you with no ld.so
<infinity> 2) One we fix (1) with the first if branch, we end up pooping a symlink on the filesystem that's no longer owned by any packages, once you remove both.
<infinity> The proper solution for this would be a diversion, but a bug in dpkg-divert makes that infeasible. :P
<infinity> (And I hope to fix said dpkg-divert bug before release, if I can find the time, so this code can go away in LTS+1 when we know we have a trustworthy dpkg on all upgrade paths)
<infinity> cjwatson: Actually, in the first, I think making the ln force would be what I want.  Testing for fileness seems sane (some weirdo might have put a real file there), but if it's a dangling link, I'll just want to overwrite it with a sane one.
<cjwatson> OK; maybe -nsf for real weirdos
<cjwatson> but OK, I think I understand now
<cjwatson> seems sane, then
<infinity> If someone's symlinking their PI to a directory, I kinda want their computer to explode...
<infinity> Twice.
<cjwatson> :-)
<ScottK> We ought to decide if we'll take Bug 982109 or not.  Technically it's not RC and we're in final freeze, but I have this suspicion it should go in.
<ubot2> Launchpad bug 982109 in ubiquity-slideshow-ubuntu "[FFe] New screenshots for Ubuntu installer slideshow" [Undecided,New] https://launchpad.net/bugs/982109
<Laney> What's the size change?
<infinity> Yeah, if they didn't increase size (bonus points if they reduced it), I think it's a no-brainer that we want the slideshow to match the OS.
<infinity> Shame it took so long. :/
<stgraber> I was planning another upload of the slideshow on Tuesday anyway for a last translation update, so I'm happy to include the new screenshots
<infinity> stgraber: Cool, mention that in the bug, then?
<stgraber> FWIW I'm the one who reverted these out of the previous upload because of lack of UIFe but I'm certainly not against having them in
<infinity> stgraber: And we can leave it up to you to make sure they didn't muck up the size. ;)
<stgraber> IIRC the size was fine but I'll triple check
 * Laney thinks it is naughty that stuff like this and the wallpaper is coming in so late
<stgraber> as in, the new translations will probably take more space than the size difference in the screenshots :)
<infinity> Laney: Not inclined to disagree.
<stgraber> got to run now but I'll leave a comment in the bug and will make sure the branch looks good for an upload on Tuesday
<infinity> Is Monday a holiday in Quebekistan?
<infinity> Or do you really plan your uploads more than a day in advance? :)
<micahg> could I get someone to address Bug #982487 please?
<ubot2> Launchpad bug 982487 in djview4 "Please remove the blacklist for djview4" [Wishlist,Confirmed] https://launchpad.net/bugs/982487
<ScottK> infinity: ^^^
 * tumbleweed is glad to see lots of FFe rejections :)
<micahg> if whoever accepts the lua binaries can wait for lua5.2 and dh-lua together, that would be great
<ScottK> OK.
<stgraber> infinity: Tuesday is the LanguagePackTranslationDeadline so even though this package doesn't contain langpack translations, skaet and I agreed that it'd be the last reasonable upload date for it
<stgraber> infinity: I'm actually off on Monday and Tuesday (with the Ubuntu definition of "off" ;))
<infinity> stgraber: Yeah, note my definition of "weekend". :P
<infinity> # cjwatson, 2011-04-30
<infinity> djview4 # overrides djvulibre-plugin
<infinity> micahg: ^^
<infinity> micahg: Is this no longer true?
<infinity> micahg: I tried to read your bug report, but I think you had a serious English fail this morning. :P
<ScottK> micahg: lua5.2/dh-lua all in together.
<micahg> ScottK: thanks
<micahg> infinity: since https://launchpad.net/ubuntu/+source/djvulibre/3.5.24-7, djvulibre was no longer providing that package, before that it was a transitional package, so not sure why the blacklist was added in the first place
<infinity> micahg: Ahh, okay, I think I made sense of your bug report.
<micahg> infinity: yes, I didn't mean seeded, didn't quite wake up yet when I filed that
<ScottK> jbicha: Got FFe?  (gnome-applets)
<jbicha> ScottK: no, would you like one?
<infinity> ScottK: It's GNOME.
<ScottK> infinity: That's not relevant anymore.
<ScottK> Gnome got a pass when we were doing new version exceptions.
<infinity> I missed that memo.
<stgraber> jbicha: do you have any screenshot of the installer slideshow in the docs?
<stgraber> jbicha: (I just commented in bug 982109)
<ubot2> Launchpad bug 982109 in ubiquity-slideshow-ubuntu "[FFe] New screenshots for Ubuntu installer slideshow" [Undecided,Triaged] https://launchpad.net/bugs/982109
<ScottK> Now that we're doing FFe, it doesn't make sense as we've got features in already.
<jbicha> stgraber: no
<ScottK> Going from, say 3.3.90 -> 3.4.0 should be bugfix only.
<stgraber> jbicha: cool, thanks. One less potential problem with that change then.
<ScottK> jbicha: In theory, I think it should have one, but as long as you've tested it, I think it's fine.
<infinity> ScottK: Oh, I didn't notice the 3.2
<ScottK> You've tested it, right?
<jbicha> ScottK: yes
<ScottK> jbicha: OK.  We'll call this FFe over IRC then.
<ScottK> In case anyone asks.
<jbicha> thanks
<infinity> Someone should email me some cafeine.
<jbicha> gnome-applets had one change this cycle which was I didn't bother packaging the dev snapshot
<jbicha> *only one
<infinity> Yeah, now that the diff's showed up, I'm going to retroactively declare that not a feature release. :P
<ScottK> OK.
<infinity> I have i386 opportunistically on manual so I can aim gcc-4.6 at roseapple.
<infinity> FYI.
<infinity> slangasek: gcc-4.6 and eglibc landing in the queue, would appreciate one last review before jamming them in.
 * ScottK steps away from the queue.
<infinity> slangasek: There will be more to follow shortly. :P
<infinity> cjwatson: Alternately, you? ;)
<infinity> stgraber: Or you?  Surely, someone wants to review this. ;)
 * infinity curses lazy Sundays.
<nigelb> lazy for whom? :P
<infinity> Not me, that's for sure. :P
<nigelb> yeah, I've seen you type more than queuebot in this channel today.
<infinity> That's just because queuebot's shy.
<stgraber> infinity: I'm having a look at eglibc
<infinity> stgraber: Take an antiemetic first.
<stgraber> (though I'm really not familiar with it, so it's most typo-checking and making sure changelog seems to match the changes)
 * infinity goes for a smoke and to find a beverage to wake him up.
<slangasek> infinity: eglibc needs to go to -proposed (multiarch installs, if you recall)
<slangasek> infinity: gcc-4.6 does for the same reason (libgcc1)
<slangasek> stgraber, infinity: in fact, I'm rejecting eglibc per the above so it doesn't get accidentally accepted :P
<stgraber> slangasek: ok. I'll keep reviewing the diff anyway as only the pocket should be different
<stgraber> infinity: if [ "${ARCH}" = "amd64" ] && [ "LIBC-FLAVOR" = "libc6-i386" ]; then
<stgraber> infinity: surely LIBC-FLAVOR != libc6-i386 or is there some sedding magic changing LIBC-FLAVOR to the right value at some point?
<slangasek> infinity: you've confirmed then that this change to libc6.symbols.armhf DTRT?
<slangasek> stgraber: these are tokens substituted with sed in the package build, yes - note the path is debian/debhelper.in/libc-alt.postinst
<infinity> slangasek: I have.
<infinity> slangasek: A trusty build of GNU Hello confirmed it.
<infinity> As did a rebuild of gcc.
 * slangasek nods
<infinity> Oh, I can push them to proposed, sure.
<stgraber> slangasek: ok, makes sense I guess, that must get you some interesting things in the resulting postinst ;)
<stgraber> infinity: right, so I didn't spot anything obviously wrong (keeping in mind that it's the first time I look at eglibc ;)). I tend to prefer using -L for symlink checks and always put strings between "" in the checks but that's just personal preference.
<infinity> Reuploaded to proposed.
<slangasek> yeah; it would be a bit nicer to have this block substituted at build time rather than doing a runtime comparison of two static strings, but eh
<slangasek> no time to be clever
<slangasek> infinity: btw, have we seen the upstream commit for this yet? :)
<infinity> slangasek: That's pretty much how all glibc maintainer scripts work.  A lot of no-op code with substitutions.
<infinity> And I'm not sure if it's been committed.  But I'll hound people during the work week.
<infinity> Right now, I just want things building.
<stgraber> doing clean multi-line substitution/removal with sed is pretty much impossible, so yeah, some no-op code is probably the cleanest :)
<infinity> Multi-line sed isn't impossible, just unreadable.
<stgraber> infinity: right, for me, unreadable != clean ;)
<infinity> slangasek: gcc-4.6 and eglibc back in the -proposed queue now.
<infinity> slangasek: I'm assuming you don't care as deeply about the old compilers?
<slangasek> except we're already doing multiline sed substitutions in parts of the eglibc maintainer scripts, so :P
<slangasek> infinity: gcc-4.6 has to go to proposed because of libgcc1; the others don't AFAIK cause multiarch skew
<infinity> Check.
<infinity> Does anyone have the hacked up copy of sru-release that pitti's been using to do proposed->release promotions?
<slangasek> infinity: what are the consequences of debian/patches/arm/unsubmitted-soname-hack.diff not being applied?
<infinity> slangasek: Err, what?  Am I that asleep?
<slangasek> infinity: it *is* applied, I'm trying to understand why
<infinity> Looks applied to me...
<infinity> Oh.
<slangasek> s/are/would be/
<infinity> The consequence is that all the old binaries in the archive fail to work.
<infinity> Nothing major.
<slangasek> if (strcmp(name, "ld-linux.so.3") || strcmp(soname, "ld-linux-armhf.so.3"))
<slangasek> strcmp returns true (non-zero) on non-match, so that's always true?
<infinity> Basically, we're spoofing the linker's SONAME in the linker.
<infinity> Note the continue.
<slangasek> my point is that the above reduces to "True"
<slangasek> because it will always *not* match at least one of the two strings
<slangasek> so that looks wrong to me
<infinity> Yeah, that's where you're wrong. ;)
<infinity> Because we have a file named ld-linux.so.3 with an SONAME of ld-linux-armhf.so.3
<slangasek> oh
<stgraber> the first checks name, the second checks soname
<slangasek> right, missed the differing variable, sorry
<infinity> Basically, if something is linked to the ld-linux.so.3 linker, we spoof its SONAME as ld-linux.so.3, instead of the ld-linux-armhf.so.3 that's burned into the headers.
<infinity> Without that, every old binary just happily segfaults.
<infinity> It's unpleasant.
<infinity> I might argue that segfaulting isn't the ideal failure mode there, but I'm not sure I care precisely why that is today.
<infinity> (And even if it didn't segv, the best you could hope for is a complaint and a failure to load)
<infinity> And, generally, I'd say that a binary having two PIs (which is effectively the problem) shouldn't be a common use case for ld.so.
<infinity> Anyhow, this is all pretty extensively tested with some serious paranoia on my end.
<slangasek> the multiple layers of symlinks fill me with a general unease; I don't see any actual bugs though, or think we should do anything differently for now
<slangasek> +       elif [ -h /lib/ld-linux.so.2 ] && [ ! -f /lib/ld-linux.so.2 ]; then
<slangasek> +           rm /lib/ld-linux.so.2
<slangasek> +       fi
<slangasek> shouldn't actually happen, should it?
<slangasek> in libc:i386's postrm
<slangasek> libc6:i386 has been removed; while installed it was the only possible owner of /lib/ld-linux.so.2, which gets removed on package removal
<infinity> Hrm, I suppose if libc6 is installed, the symlink would be owned.
<infinity> That block is probably a no-op.
<ScottK> infinity: It would be nice if you could put one i386 builder back on auto long enough for lua-gl to start building.
<infinity> I'm not entirely sure I care to re-test right now.
<slangasek> infinity: ack
<slangasek> infinity: please drop it when pushing to Debian, anyway
<slangasek> +if [ "$1" = deconfigure ]; then
<slangasek> +    :; # blah, do something useful with ldso
<slangasek> +fi
<slangasek> ^^ was that cut'n'paste from somewhere else?
<infinity> That was copying libc.postrm to libc-alt.postrm, yeah.
<slangasek> ok
<infinity> It seemed like a healthy reminder.
<slangasek> does accept/build order for eglibc+gcc-4.6 matter?
<infinity> Though perhaps obsolete in both cases by now.  I'd have to figure out why it was there in the first place. :P
<infinity> Both together are fine.
<slangasek> eglibc accepted
<infinity> Erk.  You can't be serious, soyuz.
<slangasek> ?
<infinity> My packages that happily upgrade locally... Didn't on the buildd.
<infinity> ^*&$!
 * infinity checks quickly WTF.
<infinity> Oh, ugh, I wonder if it's the libc-bin/libc6 ordering.
<ScottK> ^^^ was me.  No FFe.
<ScottK> I emailed the uploader.
<ScottK> Is broken libc expected on armhf right now?
<ScottK> https://launchpadlibrarian.net/102038392/buildlog_ubuntu-precise-armhf.lua-lgi_0.4%2B29%2Bg74cbbb1-1_CHROOTWAIT.txt.gz
<infinity> ScottK: Expected, no.  Noticed, yes.
<ScottK> OK.
<ScottK> I'll leave it in your capable hands and go to the store then ...
<infinity> Aww, crap.  Found it.
<infinity> I must have always had a compat symlink sitting around on upgrade.  Grr.
<infinity> http://paste.ubuntu.com/931655/
 * infinity goes to test that.
<stgraber> infinity: so apparently the new screenshots will take us an extra 10kB on the CD, I guess we can live with that
<infinity> stgraber: I dunno, pitti might have a sad. ;)
<stgraber> infinity: I looked on cdimage and we seem to be in pretty good shape at the moment (ignoring powerpc), as these are .jpg we can always recompress a bit if we need to save a few kBs ;)
<infinity> Yeah, I have no idea how to fix PPC, short of dropping one of the kernels.
<infinity> Or just randomly dropping some big application.
<infinity> Okay, hacked-up version tested in a CLEAN chroot. :/
<infinity> There's always one bug, right?
<infinity> stgraber: http://paste.ubuntu.com/931680/ <-- uploading that.
<infinity> (as well as a fixed libc6 to the bootstrap archive)
<stgraber> infinity: does what it says it does, assuming all the required sed magic.
<infinity> RTLD_SO = /lib/ld-linux.so.3 and SLIBDIR = /lib/arm-linux-gnueabihf
<stgraber> infinity: k, looks good. Please approve so we get working armhf again :) (sadly I'm in ENOARMHF here as my panda is back home some 7000km away and currently on armel 11.10 ...)
<infinity> Someone remind me to never move a PI again.
<infinity> Though, on the flip side, I'm getting really good at it?
<infinity> Err, not accepting yet.  *sigh*
<infinity> I need to stare at this for a second to figure out why it worked here, and not there.
<phillw> stgraber: if powerpc size is a possible problem, do you want me ask the guys testing it what should be dropped? They have said some of the stuff cannot be used..
<stgraber> infinity: what was wrong with it?
<infinity> stgraber: Okay, small thinko on that one (I had it right in the one I did by hand, of course, but not in the source package...)
<infinity> Cause I'm that awake.
<infinity> stgraber: http://paste.ubuntu.com/931711/
<infinity> stgraber: ld-linux-armhf.so.3 doesn't exist yet in /lib/triplet/ until after unpack.
<infinity> stgraber: So, have to symlink to the OLD location.
<infinity> Derp.
<infinity> I'm going to sleep for a week after this.
 * infinity tags that one in bzr, assuming you'll just say "yeah, whatever, I'm done with you crazy man".
<stgraber> infinity: ah right, so what you pasted above "RTLD_SO = /lib/ld-linux.so.3" was wrong? (otherwise basename(RTLD_SO) == ld-linux.so.3 so your new debdiff would effectively be identical to the previous one)
<infinity> stgraber: That was me being half asleep, RTLD_SO is /lib/ld-linux-armhf.so.3
<stgraber> right, all makes sense then ;)
<infinity> And now that that mess is taken care of...
<infinity> Odds on getting gcc-4.6 approved?
<infinity> It's much less scary. :P
<infinity> (thankfully)
<slangasek> except that I can't prove to myself that this fix for a segfault won't change other code generation
<infinity> slangasek: Or did you already approve, but not accept gcc-4.6?
<infinity> Oh, you're looking at the PR patches still?
<slangasek> yes
<infinity> I did a test build on amd64 and didn't see any testsuite regressions.
<infinity> Beyond that, I'm a bit hopeless at reviewing compiler bits, unless they're dead simple.
<infinity> Reading the bugs, in one case, it looks like we're suffering from carrying half a patch set.
<infinity> (And this is the other half, matching mainline 4.7)
<ScottK> infinity: Drop libreoffice on powerpc.  That's what I did on the Kubuntu images and I've never had a size problem since.
<slangasek> infinity: I understand that these are both worthwhile bugs to fix, but I'm not comfortable taking either of these pr patches because I can't hold the side-effects in my head
<slangasek> so I think they're inappropriate for final freeze and need to be backed out
<infinity> slangasek: Can do.  It's doko who'll be grumpy, not me. ;)
<infinity> I'll just go re-do all the 4.6-based packages really quick-like.
<slangasek> doko_: ^^ sorry, I can't approve these gcc-4.6 PR patches for a final freeze exception; I'm asking infinity to upload without them, they can go in as an SRU after gcc-4.6 gets copied to -release
<infinity> ScottK: Did you replace it with something else, or just drop it entirely?
<ScottK> infinity: Just dropped it.
<ScottK> One can still apt-get install it, unlike a kernel if that's the one you reallly need.
<infinity> Fair point.
<infinity> And yeah, we need both kernels. :P
<ScottK> lua-lgi was me.
<infinity> slangasek: Re-uploaded.  And re-doing the other 4.6-based packages to remove those patches for when I upload them in a bit.
<infinity> (Where "a bit" is "after gcc-4.6-source is published")
<kklimonda> what's the process for syncing unseeded almost-no-new-features-in package this close to the release? I'm thinking of bug 981044 for example
<ubot2> Launchpad bug 981044 in znc "Sync znc 0.206-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/981044
<kklimonda> (I've tried reading through the current docs, but they are a bit messy)
<Laney> Which documents do you think are messy?
<kklimonda> Laney: how nominal is Final Freeze for unseeded packages? Does that mean that we are not limited to release-critical/security-critical/exceptional cases?
<ScottK> kklimonda: For unseeded packages, final freeze didn't happen yet, so no, we aren't so restricted.
<ScottK> Feature changes still need FFe though.
<kklimonda> one man's feature.. ;)
<infinity> slangasek: That one should be less scary.
<ScottK> kklimonda: I did look at the bug.  I think it should go in.  Please subscribe ubuntu-release and change the body to indicate it's a FFe and I'll approve it.
<kklimonda> ScottK: ah, that was my second question - we still subscribe ubuntu-release, wait for exception, and then upload?
<infinity> Not much waiting in this case.
<ScottK> Yes.  Since Universe is not technically frozen, stuff may just get pushed through, so ask first.
<ScottK> No.
<kklimonda> ScottK: ah, that makes sense - thanks
<ScottK> micahg: ^^^ is that bugfix or am I just failing to find the FFe?
<infinity> He had two bugs for it, if I recall.
<infinity> Neither was fiffie.
<ScottK> kklimonda: Approved.
<kklimonda> ScottK: thanks
<ScottK> No problem.
<micahg> ScottK: I thought you approved it :) bug 982211
<ubot2> Launchpad bug 982211 in djview4 "FFe: Sync djview4 4.9-1 (universe) from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/982211
<infinity> slangasek: Hrm.  I don't think your diff is coming. :P
<infinity> ... he says as it shows up.
<infinity> slangasek: If you can accept the three compilers, I'll stop bugging you for the night (and find another sucker for the next round of compilers) ;)
<micahg> ScottK: sorry, I closed the bugs too quickly
<ScottK> That would explain why I didn't see it on the bug list.
<slangasek> infinity: gcc-4.6 accepted.  Just to be sure, which are the others you want accepted right now?
<ScottK> micahg: Accepted.  Thanks.
<infinity> slangasek: 4.5 and 4.4 as well.  They can all build in parallel.
<slangasek> ok
<micahg> ScottK: thank you :)
<infinity> slangasek: I won't upload gcj/gdc/cross-toolchain/etc until after all the gcc's spit out their respective gcc-*-source.
<slangasek> is there a 4.7 to follow?
<ScottK> It would be nice, if someone with powerz has a moment, to get a respin for kubuntu daily and daily-live.  I just fiddled the language packs and I want to make sure I didn't go overboard.
<infinity> slangasek: 4.7 is only in doko's PPA.
<infinity> slangasek: Except for gccgo-4.7, which is queued here, yeah.
<infinity> ScottK: Sure.
<slangasek> ok
<infinity> ScottK: Building.
<ScottK> Thanks.
<ScottK> Can eglibc 2.15-0ubuntu8 be shot in the head?  powerpc's backlogged again and that would help.
<infinity> ScottK: Already asked.
<ScottK> Thanks.
<infinity> And PPC will be backlogged for a while with all these compilers.
<infinity> :/
<ScottK> No doubt, that's why I figured every little bit helps.
 * infinity nods.
<infinity> Though, it's already 2/3 done anyway.
<infinity> ^--- PowerPC diet.
 * ScottK looks
 * ScottK waits for a diff
<infinity> It looks remarkably similar to the changelog.
<ScottK> Probably, but final freeze and all, I'm obligated to look.
<infinity> ;)
<infinity> pitti: When you wake up, where does that forked version of sru-release that can do proposed->release live?
<infinity> Oh, wait, maybe that's committed.
<ScottK> I'm glad I asked for the respin.  My language pack math was way off.
<ScottK> fixed.
<infinity> I suppose I could actually add some languages to PPC after scrapping LibO.  Novel idea.
<infinity> But I'll worry about it another time.
<stgraber> infinity: ubuntu-meta matches .changes so looks good :)
<stgraber> infinity: might be worth opening a bug against ubuntu-releases-notes or making a note somewhere to mention that powerpc won't have libreoffice by default
<ScottK> For both Ubuntu powerpc users?
<ScottK> Accepted.
<infinity> I'm an Ubuntu powerpc user.  But not on the desktop currently.
<ScottK> That makes you an Ubuntu Server powerpc user.
<ScottK> Ubuntu Desktop isn't called that anymore, it's just Ubuntu, so the term is a bit overloaded in any case.
<infinity> Yeah, yeah.  I know.
<infinity> Fine, I'm an Ubuntu Server PowerPC user who sometimes dabbles with Ubuntu (desktop) on his PowerStation, but not often.
<infinity> Mostly cause I still need to buy a sound card for it.
<infinity> Anyhow.  Someone baked me a ham.  I think I'll go eat it.
<ScottK> Sounds nice.
<phillw> stgraber: oh, sorry, i was thinking about lubuntu-ppc, the guys struggle to run ubuntu-ppc as it is a little too hungry for resources, but they will go test for you.
<cjwatson> micahg: sync-source.py -a used to get really upset about syncs of sources that overwrote binaries from other sources that had Ubuntu modifications and require manual untangling, so blacklisting was generally the first step there; that bug is fixed with the new auto-sync script so those blacklist entries are no longer necessary
<micahg> cjwatson: ah, ok, thanks
<cjwatson> infinity: sru-release> use the -r option, it's committed
<micahg> can someone please give back denemo in the rebuild?
<cjwatson> micahg: done
<micahg> cjwatson: thanks
<micahg> cjwatson: can you do one more please? https://launchpad.net/ubuntu/+archive/test-rebuild-20120328/+build/3329862
<cjwatson> micahg: done
<micahg> please give back geda-gaf in the rebuild as well
<cjwatson> micahg: done
<micahg> cjwatson: gfccore also please
<cjwatson> micahg: done
<micahg> gfcui please as well
<cjwatson> micahg: done
<micahg> thanks
<micahg> glabels also
<cjwatson> micahg: done.  you know, I have scripts to search these things, if you just want to give me a build log regex ...
<micahg> cjwatson: glib.h include :)
<micahg> #error "Only <glib.h> can be included directly."
#ubuntu-release 2013-04-08
<jamespage> please could rtslib be demoted back to universe
<cjwatson> jamespage: done
<jamespage> thanks cjwatson
<jamespage> doko, tomcat7 and jenkins both fixed fyi
<doko> jamespage, already accepted =)
<jamespage> so I see :-)
<doko> infinity, did you look at the newlib ftbfs?
<jamespage> doko, that jenkins update fixes the other two jenkins-* ftbfs as well
<doko> ok, will give them back later
<jamespage> doko, ta
<doko> jamespage, I did subscribe you for review of my ecj update
<jamespage> doko, lemme take a look
<doko> Riddell, ScottK: uploaded a hack for the qt-assistant-compat ftbfs. but if you want to track this down properly ...
<Riddell> thanks doko
<doko> Riddell, should I accept it?
<Riddell> doko: tracked down pykde issue, patch added to pyqt by someone
<apw> looking to sync eventstat for QA use for power testing and the like, is unseeded
<cyphermox> hi, could someone please review https://bugs.launchpad.net/autopilot-qt/+bug/1157697 ? we'd like to add a package to ship the new unit and integration tests being added to autopilot-qt, so that they can be reused
<ubot2`> Launchpad bug 1157697 in autopilot-qt "[FFE] autopilot-qt lacks testing" [Critical,In progress]
<dobey> can i get anyone to look at the freeze request on bug #1151621 ?
<ubot2`> Launchpad bug 1151621 in Ubuntu Software Center stable-5-6 "[UIFe] TypeError when opening edit menu" [Undecided,Triaged] https://launchpad.net/bugs/1151621
<dobey> or i need to attach a debdiff?
<Ursinha> stgraber, infinity, hey guys, is our call now or in one hour or so?
<stgraber> Ursinha: not sure, though I'm not supposed to be around today (day off) and will be leaving for the airport in a few minutes
<stgraber> Can someone from ubuntu-release review bug 1166286?
<ubot2`> Launchpad bug 1166286 in lxc (Ubuntu) "[FFe] LXC 0.9 final" [Undecided,New] https://launchpad.net/bugs/1166286
<Ursinha> stgraber, ah, safe travels :)
<stgraber> I mentioned this when asking for the 0.9~rc1 FFe, final is now there and is ready for upload. If this gets approved in the next 45min I can even get this uploaded before I switch continent and become unreachable for a few days.
<infinity> Ursinha: I think the later time is the right one, though it'll be cutting it close with a doctor's appointment I have, so I might end up skipping it too.
<infinity> stgraber: Looks good to me, go for it.
<stgraber> infinity: thanks
<Ursinha> infinity, that's right, I talked to cjwatson already and pgraner won't be around as well, maybe there's no point having a call this week
<Ursinha> ccccccbfuiiktniktllkncrlvuhlnvrnjgbutjvticbi
<Ursinha> argh, sorry
<infinity> My Portuguese is a bit weak, I'm not sure what that means.
<infinity> cjwatson  / slangasek: In light of pgraner getting remarried by Elvis, stgraber being on an airplane, and me being prodded by medical professionals, you may want to cancel the sync call.  Or have a friendly gathering of three people.  Your call.
<cjwatson> Heh, we just figured we'd cancel
<cjwatson> I'm mostly swearing at ghc today anyway
<cjwatson> As well as a prototype that Steve asked me for, not release-relevant
<cjwatson> infinity: Did you end up needing to brutalise publish-release any more at the end of last week?  I didn't see any patches
<infinity> cjwatson: I mangled publish-image-set, didn't do anything to publish-release.
<infinity> cjwatson: publish-release DOES fail in dry-run though.
<cjwatson> Oh, yes, you said something about that
<infinity> cjwatson: I just opted for not caring at the time, since it worked fine otherwise.
<infinity> cjwatson: It tries to write out the html/htaccess bits even when dry.  Probably just needs the whole thing wrapped in a big "if: nu uh", unless you want some pretty "would be doing" output.
<cjwatson> Yeah, that's easily fixed
<cjwatson> I've got a self.do wrapper method for that kind of thing
<cjwatson> infinity: fixed, r1236
<infinity> Cheers.
<doko> jamespage, https://launchpad.net/ubuntu/+source/rtslib/2.1.fb27.isreally.2.1-0ubuntu1/+build/4477711
<doko> Missing build dependencies: python-simpleparse
<bdmurray>  .disk/info on a live cd still says Alpha fwiw
<jamespage> doko, it needs demoting to universe
<doko> jamespage, ahh, was already in raring, but not -proposed
<apw> infinity, as per our discussion i have uploaded a linux-lowlatency/linux-meta-lowlatency pair for raring
<apw> thanks for keeping up queuebot :)
<dobey> should i just upload something that's pending approval for UIFe in raring to proposed?
<doko> UIFe?
<dobey> apw: yay, maybe i can finally switch back to the lowlat kernel now :)
<antarus> slangasek: is there actual documentation for these /usr/share/pam-configs and I'm jus missing it?
<antarus> https://wiki.ubuntu.com/PAMConfigFrameworkSpec is rather...sparse?
<slangasek> antarus: that's the documentation, such as it is
<slangasek> antarus: there's a need for better documentation in the package, which I haven't done yet.  What's your question?
<antarus> so we have...I'll call them 'complicated' pam configurations
<antarus> right now they are all puppet templates, and we just do everything 'wrong'
<antarus> so auth-type is sort of like 'required vs optional' ?
<antarus> and what is the difference between 'auth' and 'auth-initial' ?
<doko> h
<antarus> just some sort of ordering?
<doko> oops
<antarus> slangasek: I guess one more important question; this only affects common-* right?
<antarus> slangasek: is there no way to specific a per-service pam offering?
<dobey> doko: sorry, yes a ui freeze exception: bug #1151621
<ubot2`> Launchpad bug 1151621 in Ubuntu Software Center stable-5-6 "[UIFe] TypeError when opening edit menu" [Undecided,Triaged] https://launchpad.net/bugs/1151621
<slangasek> antarus: 'auth' and 'auth-initial': some modules require different behavior depending on whether they're the first password-prompting module in the stack, or not
<slangasek> antarus: 'required vs optional'> not exactly; per the wiki page, it's "Primary" == find any one that is okay, vs. "Additional" == run all without regard to success of other "Additional" modules
<slangasek> antarus: so for instance, if you wanted to authenticate via Unix password OR kerberos OR fingerprint reader, these would all be "primary"; if you wanted to impose additional auth requirements serially, you would use "Additional"
<slangasek> antarus: and yes, this is all only for common-* - per-service pam configs are out of scope
<antarus> slangasek: great, thanks for the clarification
<infinity> doko: That's a pretty impressively large gdb update this late...
<doko> infinity, sure, but what would it break?
<infinity> gdb, presumably? :)
<doko> that we can fix
<doko> but it's unlikely to break anything else
<doko> well, maybe apport, but that will get disabled anyway for the release
<doko> but look at the test results yourself
<infinity> I assume the retracers also use the gdb native to the release.
<infinity> Is there a PPA build?
 * infinity looks in toolchain-r
<doko> toolchain-r/ppa
<infinity> Alright, I'll have a poke.
<infinity> If the only argument for this is aarch64, I'm not sure it's worth any risk, since you can just land it in three weeks in S instead.
<doko> ohh, it's python3 too, any general goodness like dwarf4
<doko> s/any/and/
<cjwatson> Laney: Hmm, I found a bug in the GHC ARM linker, essentially in passing - could cause it to jump into space sometimes
<cjwatson> Laney: I'm not going to pretend I know it's http://hackage.haskell.org/trac/ghc/ticket/7316, and will file it separately, but it will be interesting to see if it turns out to cover that
<cjwatson> Laney: (there was a sign handling error in Thumb relocation)
<infinity> cjwatson: Hrm.  Thumb-only?  That could explain the armel/armhf differences in some cases.
<cjwatson> infinity: Indeed.
<cjwatson> The ARM encoding of BL doesn't use a sign bit in the same way.
<cjwatson> ^- Could somebody review that apt-cacher-ng, which I sponsored?  Biggish customer waiting for it.
<cjwatson> (And the previous state of acng appears to have sucked)
<cjwatson> infinity: This isn't ARM's only problem, but I think I may have figured out ghci's woes as well; building a test package overnight to find out
<infinity> cjwatson: Dude.  You're a machine.
<infinity> (And I'll poke that acng when LP spits out a diff)
<cjwatson> The other part of the patch looks like http://paste.ubuntu.com/5690839/, and similar though a bit modified for ghc-7.6
<cjwatson> If you were to deduce that this has been a metric pain to figure out you'd be right
<cjwatson> Anyway, with any luck tomorrow morning I'll be able to see if conduit now builds ...
<cjwatson> If so then I just need to persuade GHC maintainers to apply patches and then it should be a few days from that to a completed transition, or good enough to remove the remaining blockers
<infinity> \o/
<infinity> I suspect convincing the Debian maintainers won't be hard. :P
<infinity> They take porting patches very nearly blindly.
<phillw> cjwatson: please be gentle, I've just emailed you re: mini-iso / netboot.
<slangasek> cjwatson: this acng patch is surprisingly large for what it purports to do?
<cjwatson> I looked at it myself a while back, it's quite hard to reduce
<slangasek> well, e.g.:
<slangasek> +-      off_t m_nRangeFrom, m_nRangeTo;
<slangasek> ++      off_t m_nReqRangeFrom, m_nReqRangeTo;
<cjwatson> But happy to go back to Chris to ask for further reductions if need be
<cjwatson> Yeah, true, that could be reduced
<slangasek> and the SetOption() API change also looks unrelated
<slangasek> in fact, the only use of the new API discards the dupeCheck result
<cjwatson> The reason I didn't go round myself was that the test cycle involves a bunch of laptops at a customer's site, so I was preferring the one that I knew to already have been tested
<cjwatson> (The main symptom is racy)
<cjwatson> But if you think it's too risky as it stands then that should take precedence
<slangasek> well, it's at least more time-consuming to review than it otter be
<slangasek> I'll probably finish the review & accept, but ask arges to send cleaner patches next time
 * cjwatson -> bed, feel free to follow up with arges directly ...
#ubuntu-release 2013-04-09
<cjwatson> Laney: Did you have plans for dealing with haskell-platform?  7.4 -> 7.6 is a fairly big change, but it looks like the next upstream platform release is May, so we can't really wait
<cjwatson> Laney: Maybe it's best to just not claim to provide the platform when we can't ...
<ScottK> infinity or slangasek: If you're around ^^^ is a straightforward backport from upstream that it'd be nice to get in soonish.
<infinity> ScottK: Will look when launchpad gets diffy with it.
<ScottK> infinity: Thanks.  Diff can also be found at http://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging/kdepim/diff/260 if you'd rather not wait.
<infinity> ScottK: I don't trust reviewed branches to match packages. :P
<infinity> (If I'm impatient, I could download and diff, but I'm in no rush)
<ScottK> OK.
<ScottK> Thanks.
<seb128> hey release friends
<seb128> could anyone review the indicator stack in the queue?
<seb128> (I hoped it would have happened over night and be on today's iso but they are still sitting in there :-()
<Laney> cjwatson: I think that could go away and be backported when it appears if we don't see release candidates from upstream
<Laney> https://github.com/haskell/haskell-platform/blob/master/haskell-platform.cabal
<Laney> impressive effort debugging btw
<seb128> Laney, \o/
<cjwatson> hmph, not good enough yet to get haskell-conduit/armhf building :-/
<cjwatson> ### Error in Data/Conduit.hs:8: expression `runResourceT $ sourceFile "input.txt" $$ sinkFile "output.txt"'
<cjwatson> fd:11: hGetLine: end of file
<cjwatson> doctests: fd:10: hClose: resource vanished (Broken pipe)
<cjwatson> Test suite doctests: FAIL
<cjwatson> which at least is different ...
<seb128> whoever is reviewing indicators, thanks ;-)
<slangasek> seb128: do you know what the story is with 'friends'?  It's an autolanded package with no bugs mentioned at all in the changelog; I'm not confident this is really meant to be going in post-freeze
<seb128> slangasek, look at https://code.launchpad.net/~super-friends/friends/trunk
<seb128> slangasek, you have the commits between the bot tags
<seb128> slangasek, I assume that all the stuff autolanding are landing from the right (stable) vcs
<slangasek> seb128: so why did we not get useful changelog entries?
<slangasek> these autoland branches are already a pain wrt queue reviews, without me having to hunt down branches besides
<slangasek> and really, the commit messages there aren't any more enlightening - I don't see why these are freeze-appropriate changes, it looks like a refactor with no justification given
<slangasek> robru: ^^ these seem to be your changes, perhaps you could comment why this should go into raring this late in the cycle?
<Laney> You get a changelog entry if the branch is linked to a bug, AIUI. I've previously argued that it should fall back the commit message rather than insert no message, but I didn't win that one.
<slangasek> hmph
<slangasek> seb128: anyway, all done except for friends
<seb128> slangasek, you have 2 options to get a changelog entry
<seb128> - edit the changelog with your commit
<seb128> - link to a bug
<seb128> (either with commit --fixes or by adding a bug reference like (lp: #...)
<Daviey> it does seem crackful to maintain a changelog file, for something which is stored in VCS and built automatically.. but what do i know :)
<seb128> slangasek, but I agree, that commit/update seems like weakly justified
<seb128> it's more a problem with the person who did the commit that with the system though
<seb128> slangasek, thanks for reviewing the other ones!
<seb128> Laney, issue with "fall back to commit message" is that if your project has translation commits you could end up with 15 "updated translations" entries in the changelog
<seb128> and nothing else
<slangasek> Daviey: I don't care how the information in the changelog is generated, I just insist that there should be some - in this case it seems the missing changelog is caused by them not being bugfixes
<seb128> which is not the end of the world, but suboptimal as well
<Daviey> seb128: I thought the recommended way of handling translations was having LP commit to a separate branch, and a single merge commit - when it is suitable for the maintainer of trunk?
<didrocks> thanks slangasek for looking at them ;)
<didrocks> Laney: see what seb128's told. If you have any commit message, I think this is making a lot of noise for nothing
<xnox> seb128: I remember writting hooks that strip "translation commits" but leave the rest in.
<didrocks> Laney: but I'm happy to revisit this decision if needed at the sprint/UDS
<seb128> Daviey, I'm not sure what's the "recommended" way, but see e.g http://bazaar.launchpad.net/~lightdm-team/lightdm/trunk/changes/1572?start_revid=1632
<slangasek> didrocks: hey, just trying to clear the deck for my compiz fix to land ;)
<seb128> Daviey, 1/3 of that page is "Launchpad automatic translations update."
<didrocks> slangasek: ahah, it was interested ;)
<infinity> didrocks: Some commits may be "noise" (like "fixed typo from previous commit" or whatever), but there must be a clever way to tag "I want this commit message in the changelog" that isn't always "it must be a bug reference".
<didrocks> slangasek: however, the integration tests for the unity stack failed today. I think mterry will have a look once around
<seb128> infinity, you can manually add it to the changelog
<infinity> didrocks: Cause "I fixed this nasty bug or addeed this cool new feature before anyone noticed or asked for it" is pretty valid for a changelog. :P
<infinity> seb128: Okay, but I suspect that feels like duplicate effort, which is why it's not happening.
<didrocks> infinity: yeah, what seb128 told, that's why you can reference directly to the changelog
<seb128> infinity, suggesting of smarter way to flag commits as "should show in the changelog" are welcome I guess ;-)
<didrocks> infinity: I doubt that they will use a tag if they don't care about linking to a bug or adding a changelog entry TBH
<seb128> we could add tags in the commit message
<seb128> but that would be weird
<slangasek> didrocks: bah, thwarted at every turn
<seb128> that would add "noise" in the history log
<infinity> Works for the kernel team.
<Laney> that's what git-dch has you do
<slangasek> didrocks: oh that reminds me, why is compiz's test suite not run at package build time?
<didrocks> slangasek: probably a leftover of when it didn't run without X (they didn't separate that part). I'll just have a try in a pbuilder right now
<slangasek> didrocks: ah, ok.  I'm pretty sure it doesn't need X now, it was running fine for me here
<didrocks> slangasek: great, let me have a try quickly ;)
<didrocks> well quickly == as fast as compiz will build ;)
<Daviey> seb128: Just tried to find where it is documented, and the only references i can find from an official source is because of it's forceful overwriting - which seems weak.
<didrocks> Laney: infinity: let's discuss that during the sprint, having upstream on board and knowing why they don't do dch -i or link to a bug report will be useful
<didrocks> Laney: infinity: and seeing if another workflow will be easer for them to respect for important changes
<didrocks> Laney: infinity: btw, I wrote that and linked them to https://wiki.ubuntu.com/DailyRelease/FAQ#My_name_deserves_to_be_in_the_changelog.21 a while ago
<Laney> Sure. I just see empty changelogs fairly often and it's something that I'd like to work to avoid. I know that the process is supposed to block if this happens, but that doesn't always seem to work for whatever reason. :)
<cjwatson> Another suggestion: fall back to commit message, but have a way to tag commits as not to be included in the changelog (e.g. "[SILENT]" in the commit message or something)
<didrocks> cjwatson: ah, so on by default and off on demand?
<cjwatson> Yeah
<didrocks> cjwatson: TBH, we tried tag to UNBLOCK merge when being in a freeze a year ago
<Laney> Right, with git-dch you put Git-Dch: Ignore in your changelog and it's skipped
<didrocks> and most of the time, they forgot to add it
<cjwatson> Seems like that would address the "too much noise" problem in the case where it actually bothers people
<didrocks> I'm afraid the same thing will happen in a commit
<cjwatson> You could for example turn it off centrally for translation processing
<infinity> If a trivial commit slips into the changelog, that's not world-ending.
<infinity> The inverse is annoying.
<Laney> not that it's the end of the world if a few extra entries are added
<Laney> ha
<didrocks> we can maybe try that, I want first to talk with them about it
<didrocks> and see what's the best way to get in
<Laney> That or have the merger reject stuff if it's got no commit message
<infinity> *nod*
<didrocks> Laney: it's already the case
 * infinity decides to find a bed.
<didrocks> infinity: have a good night :)
<Laney> ah, this one was a direct commit to the trunk branch
<Laney> is that what shouldn't be done?
<infinity> Well, I was going to watch some TV before bed, but pulseaudio now hates me.
<didrocks> slangasek: how did you run the tests? I'm getting:
<didrocks> /usr/bin/ctest --force-new-ctest-process -j1
<didrocks> Test project /tmp/buildd/compiz-0.9.9~daily13.02.28/obj-x86_64-linux-gnu
<didrocks> No tests were found!!!
<didrocks> Laney: it should never be done, right
<Laney> iiiiiiiinteresting
<didrocks> robru: kenvandine ^
<slangasek> didrocks: ah, did you add the missing build-dep on libxorg-gtest-dev?
<slangasek> didrocks: (and enable it in the configure arguments?)
<didrocks> slangasek: yeah, it's installed
<didrocks> ah, there is a enabling
<didrocks> ok, found it
<didrocks> slangasek: hum, tests enabled, but nothing. I need to look closer when I've time for it
<apw> infinity, ^^ is the ftbfs fix for the config issue you spotted, process changed to cover for next time
<kenvandine> didrocks, slangasek: i'll make sure merges get rejected without changelog entries or bug references, sorry about that
<kenvandine> slangasek, those fixes are pretty important
<xnox> kenvandine: didrocks: maybe jenkins should reject branches without bug/ref and/or comments in debian/changelog for "stable" branches (post FFe & for SRU)
<kenvandine> xnox, didrocks i'd be fine with that
<Laney> didrocks said earlier that it does that
<Laney> but this was a direct commit to trunk so no merger was involved
<kenvandine> humm.. the fixes i cared about weren't directly committed, but maybe there was some fix direct to trunk
<kenvandine> oh, last night
<kenvandine> robru pushed the fix for python compatibility for quantal directly to trunk..
<kenvandine> ohhhhh.... he's been merging himself after the branches get reviewed
<kenvandine> instead of waiting for the merger...
<seb128> Laney, no, the merge reject merge requests without a commit message
<kenvandine> robru, lets not do that :)
<seb128> Laney, there is no requirement for bug reference or debian/changelog entry
<seb128> oh maybe I'm wrong
<kenvandine> indeed, so that wouldn't help here
<kenvandine> i don't think there is anything that rejects without the changelog entry
<seb128> right, what I though
<Laney> ah ok, well that would be useful then
<kenvandine> i've seen plenty of those uploaded with just a snapshot entry
<didrocks> kenvandine: it's because upstream is not respecting the deal: for things important, it's either a bug linked or a direct changelog update
<Laney> some other merger we have definitely does do that
<didrocks> kenvandine: I don't think you want to have every commits listed
<Laney> I've had to go back and set commit message before before a merge would be done by a bot
<didrocks> and I'm not talking about a feature being merged with hundreds of commits :)
<kenvandine> didrocks, then it's hard to decide when there should be something listed
<didrocks> Laney: yeah, this is the commit message for bzr
<Laney> I mean one on the MP
<Laney> which is probably the right level to do it at?
<kenvandine> these were all small bug fixes
<didrocks> kenvandine: you would prefer to have everything listed?
<kenvandine> but not LP bugs for them
<Laney> anyway, back to what we said would be a topic for the sprint :P
<kenvandine> so the issue is when it is optional,  it'll often get left out
<kenvandine> i know our upstreams :)
<kenvandine> i do really want the friends update that is in the queue to get through, fixes the dee cache :)
<kenvandine> didrocks, i just don't like uploads to the archive with a one line changelog entry  "Â * Automatic snapshot from revision 179"
<Laney> is there a convenient way to fetch the source of copies in the queue? queue can't do it.
<cjwatson> Might be worth just teaching queue how
 * Laney nods
<didrocks> kenvandine: well, that's because of upstream basically, it's like "I don't like upstream not following our guidelines" :)
<didrocks> kenvandine: you should lead by example and not have that on friends for instance :p
<kenvandine> yeah... i know :)
<kenvandine> but you know... none of those were my changes :)
<kenvandine> but i did review them... i should have rejected :)
<didrocks> right, we have 2 people to ack the change :)
<didrocks> I can add the commit message when no bugs is linked
<didrocks> but I want upstream to agree first
<didrocks> let's see during the sprint
<kenvandine> ok
<doko> finally, cython didn't fail for random reasons on armhf ...
<ScottK> Laney: dgetlp mostly works if you have the path to othe .dsc.
<Laney> ScottK: Yep, but that's the other side of 'convenient' to me.
<ScottK> Sure.
<Laney> Apparently package_upload objects which are copies don't have a reference to the originating archive
<ScottK> Apparently adding branding is a bug fix (ngnix)
<ScottK> err nginx
<Laney> Bug: there is no branding
<Laney> Fix: add branding
<kenvandine> hehe
<ScottK> I don't think adding (Ubuntu) to the version string for a web server is a great idea.  I'm going to reject it.
<jbicha> ScottK: apache on Ubuntu has done that for quite a while, see http://cdimage.ubuntu.com/404 for instance
<ScottK> Right, but there are also some significant differences in Debian/Ubuntu on where data files are located and such for Apache, so it's actually relevant to know for troubleshooting.
<ScottK> I don't think that's true for nginx, but whatever.
<ScottK> If Daviey wants it, he can accept it.
<rtg_> infinity, cjwatson: please accept Raring linux-meta with Highbank Q->R upgrade fixes. Vanhoof has the wherewithal to test.
<antarus> all hail cjwatson !
<dobey> can i bug anyone to look at a couple of UIFe requests please?
<infinity> ScottK: Differences between Debian and Ubuntu apache packaging?  Back when I maintained it, the only difference was the branding. :P
<ScottK> infinity: Sorry.  I meant Debian/Ubuntu different from the rest of the world, not from each other.
<infinity> (And the point of the branding is entirely to hint people who like to do silly "which OS is more popular" statistics gathering).
<slangasek> dobey: bugs numbers?
<ScottK> infinity: I won't object if someone wants to accept it from rejected.
<dobey> slangasek: bug #1151621 and bug #1166356
<ubot2> Launchpad bug 1151621 in Ubuntu Software Center stable-5-6 "[UIFe] TypeError when opening edit menu" [Undecided,Triaged] https://launchpad.net/bugs/1151621
<ubot2> Launchpad bug 1166356 in rhythmbox-ubuntuone (Ubuntu Quantal) "[UIFe] Old music store interface going away on server" [Undecided,New] https://launchpad.net/bugs/1166356
<hallyn> is now a bad time to push a small lxc fix for bug 1166870?
<ubot2> Launchpad bug 1166870 in lxc (Ubuntu) "lxc-clone fails silently" [High,In progress] https://launchpad.net/bugs/1166870
<hallyn> (FinalBetaFreeze link on https://wiki.ubuntu.com/RaringRingtail/ReleaseSchedule leads to nonexistant wiki page0
<hallyn> oh, should final beta freeze be taken out of topic, as final beta release should have happened?
* slangasek changed the topic of #ubuntu-release to: Ubuntu 12.10 and 12.04.2 released | Archive: Frozen for release | Raring Ringtail 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
<slangasek> hallyn: done
<hallyn> slangasek: so i guess that's a no about uploading lxc? :)
<slangasek> hallyn: "frozen" in the sense of "gated", not "immobile"
<slangasek> bugfix uploads are still accepted
<hallyn> ok thx
<slangasek> dobey: I don't understand from bug #1151621 what you're requesting a UIFe on
<ubot2> Launchpad bug 1151621 in Ubuntu Software Center stable-5-6 "[UIFe] TypeError when opening edit menu" [Undecided,Triaged] https://launchpad.net/bugs/1151621
<slangasek> dobey: UI Freeze governs changes to text strings and window layout that would invalidate documentation, translations, screenshots - fixing a UI bug doesn't need a UIFe
<infinity> Well, introducing a UI bug to work around a crash.  But yeah.
<infinity> If there are screenshots of people pulling down the Edit menu in software-center, I'd be surprised.
<dobey> slangasek: i don't know if it breaks any docs or not. hence the request for a UIFe for people who own docs/translations to say that it doesn't.
<dobey> slangasek: my understanding was that all UI changes needed to request freeze exceptions at this point
<slangasek> dobey: and bug #1166356 seems to be about an SRU rather than an upload to raring that needs a UIFe?  You've marked the raring task 'fix released'
<ubot2> Launchpad bug 1166356 in rhythmbox-ubuntuone (Ubuntu Quantal) "[UIFe] Old music store interface going away on server" [Undecided,New] https://launchpad.net/bugs/1166356
<dobey> slangasek: yes, the new version is raring, i want to SRU the new version to quantal/precise
<slangasek> dobey: well, you haven't given any information in that bug to /tell/ the docs people what's changing that might impact them
<slangasek> I don't see how a crash fix has any impact on docs
<dobey> slangasek: because generally docs tend to document the UI, the edit menu of which is one aspect of said UI
<infinity> dobey: I appreciate that you're being careful and cautious here.  In this case, probably a bit too much so, that's all. :)
<infinity> dobey: If we have application specific docs that tell users all the ways to copy/paste, those docs are probably wrong. :P
<slangasek> dobey: ok, on reread I see that the question is about removing one of the menu entries - right, that's reasonable
<slangasek> dobey: UIFe approved
<dobey> thanks
<dobey> and the rhythmbox-ubuntuone one is about removing the UI on quantal/precise as well (it's already gone in raring)
<slangasek> dobey: yeah, I think that's fine.. invalidating any screenshots of a UI that needs to go away is the lesser evil
<dobey> yeah, i suppose we'll need to drop the screenshot from the 12.04 installer for the next point release
<dobey> should i add ubiquity to that bug report?
<slangasek> dobey: if there's a screenshot of this in the installer, it'd be in ubiquity-slideshow-ubuntu
<dobey> ok
<slangasek> balloons, tjaalton; tjaalton, balloons
<tjaalton> balloons: yo
<tjaalton> balloons: so, I'd need more people to test a new mesa release
<tjaalton> which has a FFE bug open
<tjaalton> balloons: I sent a CFT to ubuntu-devel@ last friday, but it didn't attract that many people, or they are shy to report success/failure to LP
<balloons> tjaalton, hello :-)
<balloons> we can certainly organize something for you
<tjaalton> balloons: so it's for raring, and available on ppa:ubuntu-x-swat/x-staging
<slangasek> balloons: basically, I've told tjaalton just now on #ubuntu-devel that I'm not comfortable accepting mesa in as a freeze exception without some wider testing; do you think it's realistic to gather info on it by next Tue at the latest?
<slangasek> we would need assurance that a wide assortment of GPUs still work without regression
<slangasek> I would say we'd want evidence from at least 4 different GPU flavors in each of the three families
<tjaalton> something like that
<balloons> slangasek, we can try -- now is a quite busy time of course, but a week should be enough time to get people testing. 4 different gpu flavors from each of intel, amd, and nvidia yes?
<tjaalton> we already have piglit testing done
<slangasek> balloons: yse
<slangasek> yes
<balloons> has this gone into the lab?
<balloons> that's your best bet at the moment to get specific testing on different gpus
<slangasek> plus some specific spot-checking for regressions on ARM (LLVM?), and spot-checking that it doesn't regress anything in combination with the binary drivers
<tjaalton> nope
<tjaalton> llvm is still a no-go
<tjaalton> on arm
<balloons> arm is broken..
<balloons> :-(
<ogra_> arm image should be fine again and you can at least test swrast
<balloons> ogra_, did you fix it?
<balloons> maybe I wasn't subbed on the bug, i didn't see anything about a fix
<ogra_> nope, mlankhorst did
<ogra_> you mean the "black screen after install" one, right ?
<balloons> yes
<ogra_> yup, a fix went in for that one
<slangasek> tjaalton: well, llvm is "too slow to be worth anything for unity" on ARM because it's not ported to NEON... but someone should check in some capacity that LLVM isn't broken
<ogra_> bug 1161981
<ubot2> Launchpad bug 1161981 in xorg-server (Ubuntu) "Boot stalls after Ubuntu Raring desktop ARM (Panda board) install" [High,Fix released] https://launchpad.net/bugs/1161981
<slangasek> maybe just an x86 VM test?
<ogra_> balloons, ^^^
<ogra_> went in yesterday ... should be fine on todays images
<balloons> ogra_, ty.. must not have subbed :-)
<tjaalton> slangasek: sure thing
<tjaalton> I have a speedy panda for it..
<ogra_> heh
<ogra_> speedy ...
 * ogra_ pets his chromebook
<tjaalton> and nexus7 of course
<ogra_> yeah, thats for the binary drivers :)
<slangasek> so
<slangasek> tjaalton: that sound like enough testing to you? :)
<tjaalton> slangasek: yeah
<balloons> ok, so I missed the response.. Has this been run in the lab tjaalton ?
<tjaalton> balloons: nope
<balloons> tjaalton, ok, so let's make that happen.. that will be the best thing to do to make sure it passes Steve's feel good test.. and after all you need him to feel good ;-)
<balloons> alongside we'll pull community results to
<tjaalton> sounds like a plan :)
<slangasek> is the lab testing something we should be doing more systematically wrt mesa uploads?
<slangasek> seems like a good candidate package for "critical ppa" pre-acceptance testing
<slangasek> to at least give you X guys solid data about any possible regressions
<balloons> slangasek, I think that's something worth chatting with the qa team about.
<tjaalton> yeah
<balloons> have them track the xorg-edgers crack ppa or something :-)
<slangasek> this is indeed something that should happen
<balloons> where's the ffe link btw?
<slangasek> I'm surprised that's not already a priority for the lab, but I guess unity regression-testing is more critical
<tjaalton> hmm actually there's a graphics test suite of some sorts they should be running when certifying new platforms
<tjaalton> or is this the same lab we're talking about?
<tjaalton> balloons: https://launchpad.net/bugs/1164093
<ubot2> Launchpad bug 1164093 in mesa (Ubuntu) "FFe: new upstream release 9.1.1" [Wishlist,Triaged]
<slangasek> tjaalton: different lab
<tjaalton> ah
<tjaalton> one thing I know the new version fixes is user-switching no longer hangs compiz on intel, like it sometimes does on mesa 9.0.x :)
<slangasek> cyphermox_: huh, so this nm upload only changes the test suite?
<slangasek> I guess that's a pretty safe change
<cyphermox_> slangasek: yeah, only adds tests
#ubuntu-release 2013-04-10
<SpamapS> Can I get a quick IRC FFE for git-review 1.21 ? (unseeded leaf package)
<SpamapS> debdiff is here: http://paste.ubuntu.com/5694217/
<ScottK> SpamapS: You've tested this?
<SpamapS> ScottK: have done 3 review submits with it to openstack projects. Not 100% code coverage .. but itI don't smell any smoke.
<ScottK> SpamapS: OK. Got for it.
<ScottK> Got/Go
<SpamapS> ScottK: cool thanks :)
<ScottK> You're welcome.
<SpamapS> ugh, what a wonderful time for my home cable connection to die
<bkerensa> heh
<SpamapS> ScottK: finally got internet back on in my build box, so if you're still around git-review is uploaded now.
<ScottK> OK.  I'll have a look when it appears.
<ScottK> SpamapS: Accepted.
<SpamapS> ScottK: ^5
<jamespage> please could the rtslib update be accepted into raring-proposed
<ScottK> doko: I absolutely don't have time to deal with this today because I need to leave for $work meetings soon, but ypur python3-defaults SRU moves py3versions from python3-minimal to python3 and causes Bug 1167183 and some dupes.
<ubot2> Launchpad bug 1167183 in python3-defaults (Ubuntu) "package python3 3.2.3-5ubuntu1 failed to install/upgrade: trying to overwrite '/usr/bin/py3versions', which is also in package python3-minimal 3.2.3-5ubuntu1" [Undecided,Confirmed] https://launchpad.net/bugs/1167183
<ScottK> Anyone who's in the SRU team ^^^^
<doko> ScottK, ok, looking ...
<ScottK> I didn't check if anything else changed.
<doko> ScottK, hmm, there is more ... looking to fix it for raring first
<xnox> dobey: slangasek: Old U1 music store screenshot is removed from the slideshow in raring images the day before UI freeze, and replaced with my rhythmbox playing Adele =)
<xnox> not sure if we want to fix 12.04.3 slideshow as well.
<dobey> xnox: i think we'll want to fix the slideshow for 12.04, once the rhythmbox-ubuntuone changes land in 12.04 updates, i think
<xnox> dobey: ok. i will check if we can reuse the raring slide image & change the screenshot to have e.g. precise theme on the window decorators.
<xnox> dobey: what was the bug number such that I can assign it to myself.
<dobey> bug #1166356
<ubot2> Launchpad bug 1166356 in ubiquity-slideshow-ubuntu (Ubuntu Raring) "[UIFe] Old music store interface going away on server" [Undecided,New] https://launchpad.net/bugs/1166356
<rtg_> infinity, I think linux-ti-omap4 should be removed from raring-proposed. I think armhf generic should supersede that kernel. That will also get it off the FTBS list.
<ogra_> rtg_, err, nope
<ogra_> panda will stay with the quantal kernel
<rtg_> why?
<ogra_> becauase we will keep the desktop image
<ogra_> (dont ask )
<ogra_> and we have no way in i.e. flash-kernel to easily handle both
<rtg_> so, should the Raring mainline kernel still be supplying omap4-panda-es.dtb ?
<ogra_> so the quantal one has to stay for server too
<ogra_> optionally for the brave i'd say
<ogra_> and in 13.10 we actually want to drop that mess
<rtg_> ogra_, ah, we talked about this a week or so ago, didn't we.
<ogra_> yeah
<rtg_> doh!
 * ogra_ would have happily dropped desktop panda
<ogra_> as woulld infinity i think
<rtg_> this was the case where infinity was going to re-sync from Quantal if that kernel ever changed.
<ogra_> right
<ogra_> in 13.10 server we should actually use generic ... so i dont think it makes sense to artificially rip it out now
<rtg_> yeah, there is no harm in carrying the DTB.
<rtg_> so I guess at the very least linux-ti-omap4 should get promoted to release ?
<ogra_> yeah
<doko> RAOF, ^^^
<kenvandine> can someone please look at friends?
<didrocks> kenvandine: finally having a changelog content from what I saw? ;)
<seb128> slangasek, infinity, cjwatson: do we have any work in progress/release notes for raring somewhere?
<kenvandine> yes, we are going to make sure that always happens :)
<didrocks> \o/
<seb128> Laney, do you do approval in freeze times? ;-)
<seb128> it seems a bit suboptimal that almost nothing from the main/desktop goes through on european hours atm
<Laney> yeah, I can do
<Laney> will do some in a bit
<seb128> Laney, thanks
<Laney> slangasek was looking at friends though wasn't he?
<seb128> I think so
<seb128> but I see -intel s-c rhythmbox glib etc in the queue
<seb128> im-config
<seb128> sessioninstaller
<seb128> note, I uploaded some of those, but still would be good to have stuff going during the european day ;-)
<kenvandine> Laney, last i saw slangasek said he was going to leave friends, so not sure if he still is
<kenvandine> i am mostly anxious for a fix that landed on friday to make it in, people keep bugging me about it :)
<doko> seb128, I'm not -release, and only doing the ftbfs fixes
<seb128> doko, thanks for approving the build fixing, that's useful ;-)
<seb128> we just need a release team member as well to approve the other uploads...
<Laney> well, my ported indicator-session seems to mostly work so I'll do some queue reviews now and tidy that up tomorrow
<seb128> Laney, thanks
 * Laney rejects 3 of the 4(!) friends in the queue
<seb128> joys of daily landing :p
<ogra_> poor friends
 * Laney the loner
<ogra_> you kept one at least :)
<kenvandine> :)
<skellat> Hello.  I've got a Fix Committed flag on Launchpad Bug #1158431 and haven't seen yet if the new package has built and hit the queue to fix this bug for Xubuntu.
<ubot2> Launchpad bug 1158431 in shimmer-themes (Ubuntu) "lightdm graybird login issues on raring" [Undecided,Fix committed] https://launchpad.net/bugs/1158431
<ochosi> skellat: i set it to "fix committed" because the fix is in git (this is what mr_pouit and i settled on for bug management)
<ochosi> skellat: so i guess the bug status should be changed to whatever the "general public" here sees as fit
<skellat> Crud
<skellat> ochosi: Let us take this back to #xubuntu-devel
<ochosi> skellat: sure
<cjwatson> fix committed for "fix is in version control" is generally fine
<cjwatson> at least for development releases.  rules are different for stable updates
<skellat> Okay
<skellat> Since our developers are tied up it looks we need a sponsor too to navigate this in
<ochosi> yes, please
<ochosi> it's a bit unfortunate that i'm only the artwork lead and can't update my own packages...
<ogra_> bdmurray, the seed change and upload for g-c-c-u happened i didnt edit the changelog, can you close the bug by hand ?
<bdmurray> ogra_: will do
<ogra_> thx
<slangasek> seb128: release notes> https://wiki.ubuntu.com/RaringRingtail/TechnicalOverview, unfortunately it went out very bare for the desktop at beta time...
<slangasek> Laney: I was no longer looking at friends; happy for someone else to take it
<seb128> slangasek, hum, yeah, not a lot of desktop there ... is that the right page to edit toward release?
<doko> slangasek, could you look at the two python3-defaults uploads? RAOF doesn't seem to be there
<slangasek> seb128: "joys of daily landing" - well, I think there's a bug in how the autolanding code handles the unapproved queue, it seems to think that because it hasn't reached the archive yet it needs to upload *again* with no other changes
<seb128> slangasek, that's another side effect of "can't get content of the syncs in the queue" :-(
<slangasek> seb128: for the moment, yes - we usually refactor between beta and release, but we haven't started that yet so anything you put there now will be ported over
<seb128> slangasek, but yeah, agreed it's a bug
<slangasek> doko: I'm about to step away from the keyboard for a bit, but can look when I return.  This is for precise/quantal?
<doko> slangasek, yes
<antarus_> slangasek: wow this nvidia thing is really screwed up ;)
<cjwatson> seb128: you can't get the content but you can get their versions easily enough
<cjwatson> seb128: after all, the queue tool shows that
<Laney> all of the friends had genuine changes
<seb128> cjwatson, the version doesn't tell us if there is an actual diff between the version in the queue and the current daily though :-(
<seb128> or we would need to add special logic to reconstruct the version of the queue from the vcs to debdiff it
<Laney> can't you map from that back to a vcs tag?
<Laney> Have you seen this behaviour though? I don't believe friends to be a case of it, like I just said
<seb128> Laney, we could, but same, we would move from a standard workflow to a special logic that needs to trace back to the vcs used and do diffs in there
<Laney> or you know which PPA you uploaded to and the package name so you can easily download from that
<seb128> the version is not in the ppa anymore
<seb128> it got replaced by the new daily
<seb128> since that's a daily ppa
<seb128> and ppas don't keep deprecated versions
<Laney> you're deciding whether to push a new daily at this point aren't you?
<Laney> so this is before the upload
<seb128> no
<seb128> we always push dailies in the ppa
<Laney> even if there's no change?
<seb128> even if we don't copy to distro
<seb128> yes
<seb128> because that's part of ensuring that things keep building
<didrocks> hum, what do you mean?
<seb128> no?
<didrocks> that's not the case at all
<seb128> ok
<didrocks> only component which have a diff between the vcs and latest published version in distro are rebuilt
<didrocks> components*
<seb128> didrocks, what was the reason you couldn't avoid queuing new versions in freeze time when there is no diff?
<Laney> I'm not sure I believe that does happen
<didrocks> seb128: I told "published version"
<Laney> do you have evidence?
<didrocks> seb128: if I want to support the "things in the queue", there is a little bit of logic needed
<didrocks> from launchpad api to get what's in the unapproved queue
<didrocks> then, trace back to something downloadable
<Laney> we'd see it for every component every day if it was, surely?
<didrocks> because as it's a sync, you can't download the source
<Laney> and we don't, at least AFAIK ...
<didrocks> so trace that back to the ppa
<didrocks> and download from it
<didrocks> and making a second diff against it
<didrocks> so quite a little bit of work, but doable as told
<seb128> didrocks, right, that's exactly what I was saying (the sync, can't download the source, need extra logic, bits)
<didrocks> when we evocated the idea with seb128, we decided it didn't worth the pain as the queue is normally reviewed within 24 hours
<didrocks> (and this is only for things having stalled changes)
<didrocks> 18:26:18     seb128 | we always push dailies in the ppa
<didrocks> 18:26:24      Laney | even if there's no change?
<didrocks> 18:26:26     seb128 | even if we don't copy to distro
<didrocks> 18:26:31     seb128 | yes
<didrocks> seb128: I think people would think from that that we are rebuilding everything ^
<didrocks> which is not the case ;)
<didrocks> only the things not published in distro
<didrocks> (which has a change)
<Laney> so you could have <daily release> <change> <daily release stuck in queue> <daily release> <daily release ...> ?
<seb128> yeah, that was not really clearly written
<didrocks> so yeah, it's possible to skip it, but the launchpad api with sync will make it quite some extra work
<Laney> If it's like ^, you might be able to get away with just comparing versions
<didrocks> so I think we just need to assess if reviewed in freeze period not being in 24 hours is that annoying compared to "reject olds"
<didrocks> Laney: what version do you want to compare?
<seb128> Laney, comparing versions don't tell you if you have actual content change between daily_stuck_in_queue and new_daily
<didrocks> right
<Laney> if there are changes then you don't need to check the queue
<didrocks> as we don't require debian/changelog change
<seb128> Laney, how do you determine if there are changes?
<Laney> a commit since the last daily release
<didrocks> Laney: doesn't work
<didrocks> Laney: that was the old logic I removed
<Laney> how the bot decides whether to do a daily release or not
<didrocks> like, you can have a manual upload
<didrocks> then backport that to the vcs
<seb128> Laney, it compares/diff to the archive version
<didrocks> so comparing commit revisions is way more complex than it sounds
<didrocks> comparing the diff from the archive is version 2
<didrocks> and the only reliable way
<Laney> I thought that stuff put it into manual mode
<seb128> Laney, which is the "canonical" version
<didrocks> Laney: it's in manual if the version in distro is more advanced than the release
<didrocks> (well, it doesn't put it manual, it skips it + got the component hilighted)
<didrocks> basically, as seb128 told, the reference version is always what is published in distro
<didrocks> that's the gold rule to ensure we don't loose anything
<didrocks> (and yeah, it's way more complicated than just comparing commits, the whole code being 3000 lines prooves it ;))
<Laney> I thought it was something like "if there's something in the distro that I didn't upload, then a human needs to take a look"
<didrocks> Laney: yeah, it's hilighed and need to be ported back to the vcs
<didrocks> but if you wanted to compare commits numbers to know that "something is new" or not
<didrocks> you need to count the number of potential manual uploads
<didrocks> (sometimes, there is more than one in a rawâ¦)
<didrocks> and rely on the fact there is one commit per backport
<didrocks> which doesn't always happened as per experience ;)
<didrocks> so reliable on just commits to think "there is something new to consider for release" doesn't work
<Laney> so what's the issue? that manual uploads which get stuck in the queue can mess up the machinery?
<didrocks> Laney: I meant that if there has been 3 manual uploads in a raw
<didrocks> and you expect then 3 backport commits
<didrocks> + 1 commit for the release
<didrocks> so, you are telling "only if the diff is 5 commits, there is something to release"
<didrocks> now, imagine the 3 manual uploads were done in a short time
<didrocks> and someone only backport those 3 manual uploads in one commit
<didrocks> you are waiting for 2 additional commits to tell "there is something to release", even if it's not true
<didrocks> as the 3rd commit had something significative
<Laney> I don't know why we're counting commits or diffing - isn't that all done by a human when they reconcile it and manually kick a daily release?
<didrocks> that's why counting commits doesn't work
<didrocks> Laney: you proposed counting commits
<didrocks> that's what I did for a while
<didrocks> and it doesn't work, hence the diff today :)
<infinity> rtg_: It'll migrate its way out of proposed when I do the next d-i upload.
<Laney> no, I proposed seeing if there were /any/ commits
<didrocks> and I explain you why it doesn't work :p
<didrocks> Laney: so, if there is any commits
<didrocks> Laney: imagine, you have a manual upload
<rtg_> infinity, ack
<didrocks> then, you have to put that back in the vcs, right?
<didrocks> so you have /any/ commits, being one
<didrocks> and you daily release exactly the same content
<didrocks> than the manual upload
<cjwatson> you know I'm not totally certain you can't get hold of the source by URL hacking
<cjwatson> it must still be in the librarian
<didrocks> cjwatson: that would help to not hack around to get a version from the ppa as a source
<Laney> yeah that's right --- I had a working assumption that this doesn't happen often enough to make it a big problem ;-)
<didrocks> Laney: you will notice that -V is using latest version published in distro so that we don't miss anything :)
<didrocks> Laney: it did happen and it's not right that we reupload if someone did a manual upload, that's when I introduce diff as a source of truth
<didrocks> (which makes more sense, it's authorative)
<Laney> anyway, if this does indeed happen before you upload again to the PPA then you can trace back because you know which PPA it came from
<didrocks> Laney: yeah, the question is "it's adding quite a bunch of logic, is it something which should be supported?" (as it uploads with the right -V and we don't miss anything)
<didrocks> the other day, we went to the "no" conclusion with seb128, I'm happy to look at it back
<Laney> like I said earlier I haven't personally seen repeated uploads with the same content, so I'm not convinced it happens very often
<didrocks> Laney: btw, the commit I removed the "count commits" check is at http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/revision/276
<seb128> Laney, right, the conclusion was "we don't have so many hard freezes, and the issue only happen if reviews take over 1 day in hard freeze time"
<seb128> and the "issue" is small, we just have outdated versions in the queue
<seb128> the most recent one will be published when accepted
<seb128> so it's just a small annoyance
<Laney> in the friends case you'd have pushed them all anyway because there were commits every day
<didrocks> I think there was one since start of the hard freeze
<didrocks> one indicator thing
<Laney> seb128: that glib patch is funny
<seb128> Laney, talk to desrt :p
<didrocks> desrt is funny ;)
<seb128> Laney, they went "no, you can't do that anymore" but it broke bindings so desrt agreed to put an exception for the bindings until they are fixed
<cjwatson> Laney: your agda and agda-stdlib uploads should be available for syncing now
<Laney> woot
 * Laney retires to the climbing centre
<seb128> Laney, thanks for the reviews, have fun!
<cjwatson> Laney: oh, we'll need geniplate, of course ...
<cjwatson> oh, it's in raring-proposed already
<cjwatson> fine
<zul> can someone reject the horizon upload please?
<ScottK> zul: Done
<zul> thanks
<rbasak> I don't understand why the armhf binary for samba4 was rejected. Help? https://launchpad.net/ubuntu/+source/samba4/4.0.0+dfsg1-1ubuntu1/+build/4482847
<ogra_> rbasak, looks like a launchpad bug ... (iirc there is one open thatr cjwatson opened for a similar issue i once had years ago)
<ogra_> https://launchpadlibrarian.net/136881857/upload_4482847_log.txt
<ogra_> INFO Rejection during accept. Aborting partial accept.
<ogra_> oh, wait, binary you said ... mine was source
<rbasak> Thanks. But does someone need to do something? :)
<ogra_> i would ask an LP person in #launchpad
<ogra_> it looks definitely buggy
<ogra_> (if the other bianries just got accepted)
<ogra_> *binaries
<infinity> rbasak: It's an LP oops, retrying is the simplest way forward.
<ogra_> infinity, retrying for a binary ?
<ogra_> how would he do that
<infinity> Retrying the build...
<infinity> Which I did.
<ogra_> ah
<rbasak> infinity: thanks!
<rtg_> can I get some love for Raring linux-firmware and pciutils ?
<slangasek> antarus_: nvidia> you mean the fact that we have to ship a billion upstream versions of the driver to make sure everybody has one that works?
<antarus> slangasek: no, 295 => 300
<antarus> slangasek: not saying there was anything else you could have done
<antarus> slangasek: just that we had a fun morning ;_)
<mdeslaur> antarus: what happened?
<antarus> mdeslaur: well 295 doesn't support RANR, 304 does
<antarus> we have some bits that need to be flipped to migrate
<antarus> been plannign the migration for about 6 weeks ;)
<mdeslaur> antarus: ah, I see...yeah, quite unfortunate, but we didn't have much of a choice
<antarus> I know ;)
<slangasek> doko: why does this python3-defaults upload include so much reordering of debian/rules?
<slangasek> doko: AFAICS, the only bit related to the bug is a one-line change, and all the rest should be omitted from the SRU:
<slangasek> -       dh_link -ppython3 /usr/share/python3/py3versions.py /usr/bin/py3versions
<slangasek> +       dh_link -ppython3-minimal /usr/share/python3/py3versions.py /usr/bin/py3versions
<Laney> cjwatson: yeah, I uploaded that one straight away
<doko> rejected and reuploaded python3.3 to fix the testsuite-dbg autopkg test
<doko> whoever did accept the python2.7 upload yesterday, could you accept the python3.3 upload too?
<infinity> doko: That was me, I'll look at it tonight.
<doko> infinity, thanks, afk now
#ubuntu-release 2013-04-11
<dtchen> blarg. Would an archive admin please reject gtkgl2 from precise*?
<infinity> dtchen: Sure.
<infinity> dtchen: Also, thanks for all the FTBFS fixes lately.
<dtchen> infinity: danke :)
<Daviey> stgraber: Can you confirm who said bug 1057358 wasn't urgent?
<ubot2> Launchpad bug 1057358 in isc-dhcp (Ubuntu Precise) "dhcpd in isc-dhcp-server-ldap cannot read /etc/ldap/ldap.conf due to missing entry in apparmor profile" [Medium,Fix committed] https://launchpad.net/bugs/1057358
<stgraber> Daviey: stokachu at last week's foundations team meeting
<Daviey> stgraber: ok, thanks
<stgraber> 15:09 < stgraber> stokachu: isc-dhcp, what's the priority on that? Currently it's on bug to-bundle-with-next-SRU list, should it be bumped to fine-to-upload-on-its-own?
<stgraber> 15:10 < stokachu> stgraber: nah just as long as its on your radar
<stgraber> 15:10 < stgraber> ok, definitely still on my radar. (I go through all netstack bugs weekly)
<stgraber> 15:10 < stokachu> stgraber: cool, thats good enough for me, thanks
<stgraber> so as it wasn't urgent, my plan was to look at it post-release and post-client-sprint (so 2nd to 3rd week of May)
<Daviey> stgraber: I didn't doubt you.  I just wanted to be sure when asked, i had an answer :)
<Daviey> stgraber: I do think bug 1069570 requires more careful consideration.  It is the only way that has been determined so far, that avoids multiple IP leases being issued.  There can be upto 3 leases issued for each boot, which quickly exhausts pools.
<ubot2> Launchpad bug 1069570 in MAAS "1 MAC Address, two IPs - DNS is "out of sync" with DHCP leases databases, I think..." [Critical,Triaged] https://launchpad.net/bugs/1069570
<seb128> stgraber, if you want others to stay away from things that you have on your list you should comment on the bug saying you will handle uploads and unsubscribe sponsors
<Daviey> (MAAS isn't specifically relevant for that bug)
<Daviey> seb128: he did this :)
<stgraber> seb128: I know, I thought I did but when checking this morning I noticed I hadn't (fixed now).
<seb128> Daviey, well, I think I sponsored the debdiffs on that bug once and when I did he hadn't done that
<Daviey> ah.  He has now.. Which promoted me for more info :)
<seb128> should be all good now ;-)
<stgraber> seb128: yeah, I think you sponsored the first one which was broken. At the time the bug wasn't even on my radar, so I didn't actually mind someone sponsoring the fix, just nobody testing it pre-upload (not your job, but the submitter should have) ;)
<seb128> right; well I sanity check what I sponsor but I didn't catch, from the diff, that the series was sorted in a special way there
<stgraber> seb128: I'd have thought that after one broken upload the sponsors or SRU team member would at least look at the bug history and notice that re-uploading the same thing wasn't going to work any better ;)
<stgraber> seb128: yeah, I don't blame you, I blame the submitter for that one. However I certainly blame whoever re-uploaded the exact same thing and I'm very surprised the SRU team didn't see it when they went through the bug report...
<stgraber> I mean, it's fairly easy to see in the diff:
<stgraber>  #ldap backend for dhcp server (docs and code)
<stgraber>  #these get reverted during the build, so put non-ldap
<stgraber>  #patches earlier
<stgraber> anyway, I hope that my last comment will keep everyone away from this bug for the time being until someone bumps the priority high enough that I have to take care of it immediately or until I prepare the next batch of isc-dhcp SRUs
<seb128> should be fine ;-)
<jamespage> please could the horizon update for raring be accepted; this fixes from problems that early adopters are seeing with compressed assets
<cjwatson> Laney: I think I'm going to have to do http://paste.ubuntu.com/5697878/ to unblock conduit et al; any objections?
<Laney> Yeah I suppose having YES there is a bit of a lie isn't it?
<Laney> Make completely sure that the ABI hashes don't change ...
<cjwatson> Laney: In particular doctest looks at whether it says YES or NO
<cjwatson> If it's NO it'll automatically skip doctests
<cjwatson> Laney: Damn, I was hoping to avoid an N-hour test build
<cjwatson> Or do you mean on i386?
<Laney> any arch
<cjwatson> It wouldn't surprise me if the libghc-ghc-dev hash justifiably changed as a result of disabling ghci
<cjwatson> But its rdep chain is fairly short
<Laney> Right; I mean base or similar
<ogra_> cjwatson, do you plan a livecd-rrotfs upload today ?
<ogra_> *rootfs
<cjwatson> ogra_: no
<ogra_> do you mind if i do one ?
<cjwatson> ogra_: not at all
<ogra_> good :)
<cjwatson> Laney: OK, guess I'd better get started on test builds then
<Laney> IME if it changes on one arch it'll change on all of them, so just do it on your local machine and debdiff the binary you get
<Laney> I'm less worries about ghc-dev changing on arm as that's expected and dealable-with
<cjwatson> Mm, I can see the possibility for a single-arch configuration change of this nature to change the base hash, so worth a full build on arm I Think
<cjwatson> *think
<cjwatson> hopefully it'll be a bit quicker without ghci
<Laney> you could build it in canonical-arm-dev and then copy over if it's alright
<cjwatson> I guess, but I might want to debug locally - might as well just go ahead with a local build I think
<xnox> \o/ thanks
<xnox> wikimedia foundation should be happy =)
<stgraber> I just requested the sync of ltt-control from Debian for bug 1163358
<ubot2> Launchpad bug 1163358 in ltt-control (Ubuntu) "[FFe] Sync ltt-control and remove lttng-tools to fix broken lttng in 13.04" [Undecided,Triaged] https://launchpad.net/bugs/1163358
<stgraber> this is showing up as source New because the source in Ubuntu was named lttng-tools. The packaging is 90% identical (some missing transitional package in Ubuntu) and I've done basic testing on it.
<stgraber> it'd be appreciated if an AA could therefore let this one through, binNEW any of the new debs then remove lttng-tools (the source) from the archive
<Laney> didrocks is an archive admin who was interested in it ;-)
<Laney> (revenge ping :P)
<didrocks> but but butâ¦ :p
<didrocks> ok, what I wouldn't do for PS in the endâ¦ :p
<stgraber> ah good point, didrocks^ (it's been +1ed by the release team, so it's an AA thing now ;))
<didrocks> (mean Laney ;))
<stgraber> didrocks: I can paste you the packaging diff between lttng-tools and ltt-control if you want, but besides that, I don't think it's worth a full review as it's essentially a source rename (from the right name to a wrong name, but well, that's how Debian likes it apparently ;))
<didrocks> stgraber: oh, that would be lovely! Yeah, I'll just double check the transition
<didrocks> so a diff will avoid me having to deal with it :)
<stgraber> at least the binaries use the same name, it's just adding a bunch of transitional packages that will be of no use to us
<didrocks> sounds good, i'll just do a quick sanity check with the diff, just in case ;)
<stgraber> didrocks: http://paste.ubuntu.com/5697941/ (that's the diff for debian/ from our current source to the debian source)
<didrocks> stgraber: thanks!
<didrocks> stgraber: looking good, acking ;)
<cjwatson> Laney: you dropped a modification from BenC in haskell-hint to build on any architecture - was that intentional?
<Laney> cjwatson: I can't remember but I suspect not - could go to Debian in any event
<cjwatson> OK, I'll have a look at that
<Laney> I think it was from before the ghc-ghci days
<cjwatson> ah, so it should just build-dep on ghc-ghci and leave it at that?
<cjwatson> ... which indeed is what Ben's patch does, roughly.  OK
<GunnarHj> cjwatson: Hi Colin, can you ask someone to test https://launchpad.net/ubuntu/+source/openssh/1:5.9p1-5ubuntu1.1 for the openssh SRU at bug 952185? Guess you can't just refer to the gdm comment this time. ;-)
<ubot2> Launchpad bug 952185 in gdm (Ubuntu Precise) "~/.pam_environment not parsed by default" [Medium,Fix committed] https://launchpad.net/bugs/952185
<cjwatson> GunnarHj: mm, I can probably manage to test it but it'll have to involve a VM
<GunnarHj> cjwatson: Ok, good. It's the last thing at that bug report. :)
<ochosi> hm, could any of you help out a poor xubuntu developer get a tiny bugfix sponsored upload for raring? (doing it out of pity is totally fine by me ;))
<jbicha> stgraber: um, how do we handle bug 1162478? other distros have been shipping it for a while and I really think we should have it for raring
<ubot2> Launchpad bug 1162478 in libnss-myhostname (Ubuntu) "[FFe] [MIR] libnss-myhostname" [Undecided,New] https://launchpad.net/bugs/1162478
<seb128> jbicha, hey
<jbicha> I apologize for not filing a ffe because it felt like just a bugfix to me
<seb128> jbicha, stgraber: I've a revert ready, let me know what you conclude so I know if I should upload
<stgraber> jbicha: as I've said in the bug, I don't think adding a new NSS plugin that close to release is a good idea. I'm not saying we'll reject that for 13.10 (and it won't really be our call anyway as it's already in main), but for 13.04, I'd prefer we live without it
<stgraber> slangasek: not sure if you're awake already, if you are, this sounds like the kind of things you'd be interested in ^
<jbicha> stgraber: the Release Team does have power to reject features but I think it would be good to come to a decision before having us revert (in case we just end up adding it back tomorrow)
<stgraber> jbicha: as far as I'm concerned, this is a "not for 13.04" kind of thing. If you turn it back on in 13.10 it should be fine, provided nobody finds it to break things badly (which it unfortunately has the potential to do)
<jbicha> ok, could I get a second release team member to weigh in on libnss-myhostname?
<seb128> jbicha, stgraber pinged slangasek, but it's still a bit early for him
<seb128> so let's wait a bit
<cjwatson> could somebody have a quick look at haskell-word8 and haskell-project-template in NEW?  they're fairly trivial syncs needed to unblock builds
<cjwatson> Laney: http://paste.ubuntu.com/5698672/ - look sane to you?
<cjwatson> (drops ghc-ghci, changes libghc-ghc-dev ABI hash, drops a bunch of associated files)
<cjwatson> s'pose I should check that conduit can now build, otherwise it's a pointless exercise
<seb128> cjwatson, looking
<seb128> ups
<cjwatson> ups?
<seb128> I had a moment of "should it be a r-t member looking at those/approving"
<seb128> sorry ;-)
<seb128> looking in any case
<cjwatson> well, I think at this point it's fairly obvious that we're committed to finishing the ghc transition
<cjwatson> from an r-t point of view
<Laney> cjwatson: Looks sane. I didn't know what the .o files were but checking with a Debian binary built without ghci showed that they weren't there either
<seb128> cjwatson, ^
<cjwatson> seb128: thanks
<slangasek> seb128, jbicha, stgraber: I'm not keen on libnss-myhostname as a technology, period; I consider it an unnecessary moving part when /etc/hosts already points the hostname at 127.0.1.1
<seb128> slangasek, "the hostname"?
<seb128> slangasek, what should be updating /etc/hosts when the hostname changes?
<seb128> slangasek, oh, and good morning ;-)
<slangasek> seb128: whatever tool updates the hostname should update /etc/hosts as well
<slangasek> libnss-myhostname is a bandaid
<seb128> basically you are saying "lennart should merge libnss-myhostname in systemd"
<seb128> ?
<seb128> it's hostnamed from systemd-services that allows changing the hostname
<slangasek> seb128: well, I think updating the hostname should also update /etc/hosts according to the distro policy, yes :)
<slangasek> seb128: didn't lennart write libnss-myhostname anyway?  Not sure it matters whether it's in systemd ;)
<seb128> slangasek, k, in any case I guess you second the FFe nack for raring ;-)
<seb128> jbicha, ^
<slangasek> seb128: followed up
<seb128> slangasek, thanks
<doko> all the GCC 4.7.3 packages in unapproved
<stokachu> stgraber: why did they remove isc-dhcp 4.1.ESV-R4-0ubuntu5.7
<stokachu> stgraber: i thought we just bump the rev and move on
<cjwatson> "SRU abandoned (verification-failed)"
<cjwatson> https://launchpad.net/ubuntu/+source/isc-dhcp/+publishinghistory
<cjwatson> we bump the rev and move on *if somebody actually gets round to uploading that and it gets reviewed*
<cjwatson> removing is the fallback option
<stokachu> i fixed both with this https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1069570/comments/42
<ubot2> Launchpad bug 1069570 in MAAS "1 MAC Address, two IPs - DNS is "out of sync" with DHCP leases databases, I think..." [Critical,Triaged]
<stokachu> but doesn't matter it was declined anyway
<stgraber> stokachu: my understanding from the tester is that it was yet again the wrong debdiff which was uploaded for the ldap isc-dhcp bug, so we removed it again and this time I left a clear comment that I'm going to take care of it
<stokachu> yea that was after i did those changes
<stgraber> stokachu: for 1069570, I see why people want it, but I still very much don't like the idea of adding a new config option to a released version of the package, especially as another package will then be SRUed to migrate user to use said option
<stgraber> considering the option isn't upstream and it's only landed in Ubuntu pretty recently, I'm not terribly confident we won't get another breakage as a result
<stokachu> ok
<stgraber> (there's also the issue the config options in ISC are numbered and that every option we had makes it even more painful to rebase, though I've already had to accept that fact when I accepted the patch in raring...)
<stokachu> you'll probably be getting a lot of pushback on this
<stgraber> I'm also still not sure that there wasn't another way to deal with the problem and that could be used as a workaround for the SRU
<stgraber> isc-dhcp can do pattern matching on fields, so someone could very easily pattern match iPXE and set a 30s lease for those
<stgraber> which avoids the problem of pool exhaustion that Daviey described in the bug
<doko> cjwatson, what effect does have disabling the ghc interpreter?
<cjwatson> doko: it will cause haskell-doctest to not try to run doctests, which allows building at least haskell-conduit, haskell-attoparsec-conduit, haskell-wai
<cjwatson> (as far as I've tested so far)
<doko> hah!
<cjwatson> I've spent several days trying to get the interpreter to actually work, and while I've made progress, it's incomplete and I don't know how much longer it would take
<cjwatson> so I think it's better not to advertise that the interpreter works
<bdmurray> unity-chrome-extension can be removed from quantal-proposed due to lack of verification
<cjwatson> we'll have to rebuild about 6 packages with the new ghc, but that's perfectly manageable
<cjwatson> and with any luck the only remaining bits of the transition after that will be removing a handful of packages
 * cjwatson looks forward to regaining his sanity
<bdmurray> disregard my comment about unity-chrome-extension
<bdmurray> however, I'm working on a change to sru-report to identify bugs tagged removal-candidate.  Are there any suggestions for a color or something to identify them?
<seb128> whoever rejected totem, please accept both next time of the changes doesn't use -v
<seb128> or is there any issue to accept 2 versions?
<barry> i think mvo may have beating me to apt 0.9.7.7ubuntu4 for raring
<barry> *beaten
<rtg_> slangasek, can you approve the raring kernel packages ? linux, linux-meta, and linux-signed.
<slangasek> rtg_: ah, today must be kernel freeze :-)
<rtg_> indeed
<rtg_> everything from now on is subject to SRU
<slangasek> can linux-signed be accepted in parallel, or does it need to wait for linux to publish first?
<rtg_> slangasek, I think you can do them all at the same time
<slangasek> rtg_: I'll hold you to that :)
<slangasek> accepted
<rtg_> slangasek, guess we'll find out.
<bdmurray> slangasek: https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/gray-removals/+merge/158502
#ubuntu-release 2013-04-12
<Laney> cyphermox: I can't tell if light-themes needs a UIFe - does it or are these changes not relevant for desktop?
<cjwatson> sigh, I so desperately wish we had binNMU support
<Laney> been there
<cjwatson> (I probably shouldn't have synced haskell-lifted-base yesterday)
<cjwatson> could somebody wave through those haskell-*?  they're the bottom of a many-level stack
<seb128> cjwatson, I can (it's ok for me to ack them right, no release team material there?)
<Laney> too slow old man
<seb128> Laney, being slow pays out, less work to do, you need to learn youngster :p
 * Laney hangs his head in shame
<iulian> Heh.
<cjwatson> seb128: indeed I don't think there's any release team material in these
<cjwatson> also could somebody please review libdebian-installer?  it's syncing up with current kernel layout
<cjwatson> (I can't, I sponsored it)
<ogra_> mknjl;ipo98oiuyjbn Â·/[p#]=-09iuo,m @:}#[
<jokerdino> hmm
<jokerdino> that could be the password i wanted.
<ogra_> jokerdino, heh, nope,  but probably the cat you want
<jokerdino> it turns out to be a nice cat after all!
<ogra_> she is a good pwgen :)
<jokerdino> haha.
<ogra_> (we feed her cryptic food at times ... that helps
<ogra_> )
<jokerdino> more entropy than the universe.
<stgraber> cjwatson: taking a look
<stgraber> done
<cjwatson> ta
<Daviey> cjwatson: You'd like binNMU to help with transitions?
<cjwatson> yes
<cjwatson> I sat down with the soyuz folks of the day about four or five years ago to thrash out a design, but implementing it never made it to the top of the list
 * cjwatson accepts language packs
<apw> infinity, new linux-{,-meta}lowlatency to match linux in the queue ^^
<cjwatson> ^- next batch of rebuilds
<cjwatson> would be helpful if somebody could process the haskell syncs in NEW too
<Laney> what are they for?
<cjwatson> if I'm very lucky I might be able to get this wrapped up today, or mostly so ...
<cjwatson> deps of project-template
<cjwatson> which was a dep of something I now forget
<cjwatson> new yesod which works with new conduit, I think
<Laney> aha, yes, yesod is depwait
<cjwatson> haskell-strict-concurrency is IIRC FTBFS with GHC 7.6, but I'd sort of like to upload a rebuild so that the build failure is visible on LP before removing it - does that make sense to anyone else or am I just being anal?
<cjwatson> also: it's becoming increasingly clear that the haskell stuff that was raising random signals in armhf builds is also stuff that build-depends on ghc-ghci
<cjwatson> chell, shakespeare-css, ...
<Laney> well, strict-concurrency was an easy fix ...
 * Laney better upload that
 * ogra_ would appreciate if someone could let livecd-rootfs free 
 * apw would prefer linux*lowlatency was built with the same compilers that the main kernel was, ie started building before gcc-4.7 starts
<ogra_> upload a -build1 ?
<cjwatson> Laney: oh, ok
<cjwatson> apw: will accept shortly
<cjwatson> I was staying clear of livecd-rootfs since I contributed to that upload
<Laney> There's a pattern to those OldException fixes, at least if they only use catch
<cjwatson> who rejected gcc-4.7?
<apw> cjwatson, i don't know who did, but there was two at the same version number in my listing
<Laney> Move to Control.Exception and use a ScopedTypeVariable with IOException on the second argument
<cjwatson> ah
<Daviey> ogra_ / cjwatson: Approved livecd-rootfs
<cjwatson> thanks
<ogra_> thx
<cjwatson> apw: just looking to see what's up with LP queue diff generation - it might just be behind due to lots of language packs
<apw> cjwatson, np no rush
<cjwatson> ah, process-pending-packagediffs has a limited maximum throughput of 50 packages every 12 minutes
<doko_> cjwatson, me, uploaded a new one fixing #1168267
<cjwatson> ok
<doko_> would be nice to get these accepted before the weekend
<cjwatson> doko: noted
<cyphermox> Laney: yeah it's only changes for touch, doesn't affect desktop
<rtg_> infinity, cjwatson, slangasek: please NEW the Nexus4 kernel and meta: linux-nexus4, linux-meta-nexus4
<stgraber> the ubiquity-slideshow-ubuntu diff is likely pretty long but should be reasonable once you ignore all the translation updates, then you should just be left with the removal of the skype icon
<cjwatson> stgraber: ack
<Laney> Does UIF cover Xubuntu too or are they supposed to handle docs themselves?
<Laney> They want to change their default wallpaper
<slangasek> Laney: I'm not aware of anything going through ubuntu-docs that would be impacted by Xubuntu - I guess I would turn the question back to them and just make sure they're confident they've done any coordination they need to
<slangasek> since UIF is all about "don't change without coordinating with the relevant doc/translation folks"
<Laney> Yeah. I'll say something like that, just thought I'd see if anyone knew offhand.
<bdmurray> cjwatson: could you have a look at my sru-report merge proposal? https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/gray-removals/+merge/158502
<cjwatson> bdmurray: trying to figure out how "if m_date.replace(tzinfo=None) < today - datetime.timedelta(16):" matches up with your description of "If a bug is tagged removal-candidate (not been verified for more than 90 days)"
<bdmurray> cjwatson: it gets tagged removal candidate after 90 days and says will be removed in 15 days
<cjwatson> (a) doesn't seem to relate to tags (b) seems to be 16 days not 90?
<cjwatson> oh
<cjwatson> right, gotcha
<bdmurray> https://bugs.launchpad.net/ubuntu/+source/print-manager/+bug/1091340/comments/7
<ubot2> Launchpad bug 1091340 in print-manager (Ubuntu Quantal) "print-manager spams .xsession-errors" [Undecided,Fix committed]
<cjwatson> ah, the commits make it clearer
<bdmurray> I should have been clearer in the description, sorry.
<slangasek> rtg_: hi, re: linux-nexus4, how is this being used in the context of raring?  Is this on the same footing with linux-nexus7 (universe, no security support)?
<cjwatson> bdmurray: should we perhaps be checking the tag and not the message?
<rtg_> slangasek, yes AFAIK
<cjwatson> bdmurray: ah, never mind, doesn't matter due to the > published_date check
<bdmurray> cjwatson: the message has a date associated with it and the tag doesn't (unless you parse the activity log). although we could double check the tag.
<cjwatson> bdmurray: merged
<bdmurray> thanks
<slangasek> rtg_: other q... having these kernels in the archive doesn't mean someone's expecting us to suddenly have nexus4 images released with 13.04, does it?
<rtg_> slangasek, the intent is to have Ubuntu touch images based on kernels from the archive. I'm working on getting flash-kernel to work on the N4 and N7 devices.
<slangasek> ok
<slangasek> rtg_: does that mean these kernels are both androided up?
<rtg_> slangasek, it'll likely be a few weeks before the touch images actually use these kernels, but I'm laying the groundwork. The N4 kernel actually works on the device. We've still got some issues with the N7 kernel.
<slangasek> ok
<rtg_> so, yeah, they are androided up
<slangasek> rtg_: anyway, just making sure there's no expectation for a last-minute n4 image - it's fine to have the kernels in universe in the meantime
<rtg_> slangasek, no expectation as far as I know.
<ogra_> rtg_, btw, has the last linux-nexus7 been tested on the n7 desktop images to make sure we didnt regress ?
<rtg_> ogra_, AFAIK Paolo is still working on the touchscreen issue. I think the desktop image works, but not touch image.
<ogra_> regarding our discussion in #ubuntu-touch i'm a bit worried now
<ogra_> ok
<ogra_> just wanting to make ksure there didnt sneak the wrong android config options in (paraniod network would be a desaster)
<rtg_> ogra_, do we have a desktop image for the N4 ?
<ogra_> nope
<slangasek> no, nor should we
<rtg_> good, thats what I thought
<ogra_> and we might drop the n7 one to not clash with the kernel stuff in 13.10
<ogra_> (not sure though, we need *one* desktop image and need to decide which HW that will run on)
<balloons> so, I'm curious what the timetable for the rc milestone will be
<balloons> who's going to run it? when can I expect it to appear? I want to line up testing properly :-)
<ogra_> there is an RC ?
<ogra_> i mean ... a specific milestone
 * ogra_ thought the last beta was the last milestone until final
<ScottK> It is
<slangasek> ogra_: we have the desktop image for Panda still
<balloons> I thought so too, but the release schedule lies to me.. Or I'm misreading it :-)
<balloons> so I thought I'd come confirm and see what's up
<slangasek> balloons: where do you see this?  Let's fix it
<slangasek> tjaalton, balloons: btw, any progress on the mesa testing question?
<balloons> slangasek, yes, indeed.. I think tjaalton is gone by now. But we've had representative testing from all vendors
<balloons> lots of intel coverage too.. no issues reported by anyone :-)
<balloons> slangasek, https://wiki.ubuntu.com/RaringRingtail/ReleaseSchedule.. notice it has release canidate on april 18th
<ogra_> slangasek, in 13.10 ?
<ogra_> slangasek, the kernel will start smelling by then
<slangasek> ogra_: it smells already ;)
<ogra_> its already moldy
<balloons> slangasek, let's see.. 2 amd, 2 nvidia, and 6 intel, plus some virtual machine testing :-)
<ogra_> and pray that we dont need some new kernel features for udev or upstart :)
<slangasek> ogra_: well, it's already missing kernel features that upstart /wants/... I don't expect our kernel requirements to uplift further in that regard
<ogra_> no, but udev is usually really evil if it comes to such stuff ... upstart has always been graceful here
<ScottK> balloons: That's not a milestone.  That's when we start working images for the release milestone.
<ogra_> i doubt anyone will want  to invest time into that image
<slangasek> balloons: so yeah, we still refer to "release candidate" there, and it accurately describes what we're doing, but it's not a milestone... I think I'm going to leave the pages as-is for right now
<ogra_> anyway, 13.10 is still far out ...  :)
<balloons> slangasek, ScottK no worries.. you just asked why I was confused :-) So we'll simply test dailies as planned
<slangasek> ogra_: we're certainly not going to invest tremendous amounts of effort into panda going forward, no; only the minimum needed to ensure we can continue validating the desktop stack on arm, and when that becomes too time-consuming we can look at other approaches but there's no point second-guessing the plan because some other component *might* become incompatible with that kernel
<slangasek> ogra_: bear in mind that we've got android BSP kernels in the mix now, too... the panda 3.5.0 is not the worst kernel we have to deal with in terms of Ubuntu userspace compatibility
<ogra_> slangasek, heh, true
<ogra_> i would personally prefer an n7 desktop image though, because the tegra driver is lots easier to handle (and we have confirmation from nvidia to support the next xserver) ...
<ogra_> but that would likely mean two kernels
<knome> Laney, slangasek: i think steve is right. i've never really seen anything related to xubuntu in other than xubuntu, or online, docs
<Laney> knome: Okey doke. You could check with the docs team if you want, but it's up to you.
<knome> i'll do them personal favors and send cookies if there's anything that affects them i'm not aware of.
<knome> i think it's fine
<xnox> knome: have you seen bug 1163504 lubuntu artwork package is using trademarked icon without permission (skype)
<ubot2> Launchpad bug 1163504 in lubuntu-artwork (Ubuntu Raring) "Trademarked assets" [Undecided,Confirmed] https://launchpad.net/bugs/1163504
<knome> xnox, no, and i'm also not very much on top of lubuntu's development
<knome> xnox, is there something i can do for the bug though=
<knome> ?
<xnox> hmm... sorry thought you are in lubuntu as well.
<xnox> need to find relevant people, or I will simply upload.
<knome> nope :)
<knome> would you be willing to help with the xubuntu package as well?
<knome> our next task is to find a sponsor for that one...
<knome> (and we have another one waiting as well :/)
<knome> (that's a bugfix, but needs sponsoring)
<phillw> xnox: I was led to believe that lubuntu need take no actions over the trademark issue?
<phillw> I do recall asking :)
<tjaalton> slangasek, balloons: yep, the mesa testing seems to go fine
<slangasek> tjaalton, balloons: IIRC the target I asked for was "4 different subfamilies for each major chipset, plus binary driver regression testing" - are we going to reach that?
<tjaalton> slangasek: binary drivers aren't affected, but seeing more radeon/nouveau testing would be nice
<slangasek> tjaalton: so when binary drivers are in use, there's no mesa code loaded in memory by any programs?
<slangasek> if so, then full ack
<phillw> xnox: I'm the 'other' person on release managers for lubuntu, https://launchpad.net/~lubuntu-product-managers
<tjaalton> slangasek: right, they have their own libGL
<tjaalton> slangasek: i'll prepare the official upload after the weekend, thanks
<tjaalton> slangasek: can I include a commit or two to fix known bugs? or take this as golden and sru the rest?
<slangasek> tjaalton: I think we would want to review those extra commits separately since they're not currently undergoing user testing
<slangasek> tjaalton: doesn't mean we can't have them in, but they should definitely be called out separately on the FFe bug
<slangasek> tjaalton: also, I feel strongly that the radeon/nouveau testing is more than "would be nice", I think it's essential that it happen
<slangasek> tjaalton: did we get any lab testing of this, like was discussed?
<tjaalton> slangasek: aiui not yet, balloons?
<balloons> slangasek: tjaalton no no lab testing.. It was non-trivial to do so. but I do have a list of potential machines
<balloons> it's not setup like I thought it would be to facilitate this easily
<balloons> I plan to discuss this at the next UDS :-)
<tjaalton> slangasek: we'll prepare 9.1.2 as first sru, so no problem doing another round then
<tjaalton> k, back to wknd mode :)
<phillw> any of the release team about for a real short chat?
#ubuntu-release 2013-04-13
<smartboyhw> Hello Release Team.
<smartboyhw> Recently we got a bug in ARandr. There is a new version fixing that bug.
<smartboyhw> However I'm not sure if I need an FFe to get somebody upload for me.
<smartboyhw> http://paste.ubuntu.com/5704407/
<smartboyhw> Since I am updating from 0.1.6 -> 0.1.7.1 I only pasted the changes for 0.1.7 and 0.1.7.1
<smartboyhw> I want to get it fixed before Final Freeze so...
<smartboyhw> Anyway I need to requestsync for this.
<smartboyhw> But I am just wondering would this need FFe.
<iulian> smartboyhw: arandr is seeded in ubuntustudio. If it works fine then I suggest you leave it as it is.
<smartboyhw> iulian, the trouble is that it isn't.
<smartboyhw> Some people filed bug reports that it just simply can't launch.
<phillw> smartboyhw: bug number?
<smartboyhw> phillw, wait wait:)
<smartboyhw> Bug 1167553
<ubot2> Launchpad bug 1167553 in Ubuntu Studio raring-13.04 "Arandr won't start on Ubuntu Studio 13.04 Beta 2" [High,Confirmed] https://launchpad.net/bugs/1167553
<smartboyhw> Um the fix is in the new version.
<phillw> indeed :D
<smartboyhw> Even I don't want to upload such a thing in such a time, but it is a high (if not criticial) bug.
<phillw> smartboyhw: if the bug fix is already upstream, it does not require a FFe, there is a distinct difference between "fix a bug" and "add new / alter stuff"
<smartboyhw> phillw, I'm not sure will the other stuff in the new versions bring new features.
<smartboyhw> And since it introduces new translations, I'm not sure if that needs an UIFe.
<phillw> Bug fixes can be accepted. But, if there is doubt then having the proposer chat to the release team is handy, in the meantime I'd suggest making a case for FFe
<smartboyhw> phillw, OK
 * smartboyhw goes requestsync
<phillw> smartboyhw: it is possible that it may affect lxrandr or it may be that it is solved in that area. Do please keep me updated (I've subscribed to the bug).
<smartboyhw> phillw, OK:)
<smartboyhw> phillw, I will give you the requestsync bug afterwards also:)
<phillw> smartboyhw: try adding lxrandr and see if it solves the issue, if it does, then it is a bug fix :)
<smartboyhw> phillw, we won't want LXDE I think.
<phillw> smartboyhw: it is not lxde, it is a simply a variant of RanR, which all have :)
<smartboyhw> phillw, xrandr works.
<smartboyhw> phillw, just that arandr doesn't.
<smartboyhw> (At least, according to the bug reporter)
<phillw> smartboyhw: can we pop back to -quality? this is not a -release topic
<smartboyhw> phillw, jaja sorry:)
<smartboyhw> phillw, the FFe bug is at Bug 1168693.
<ubot2> Launchpad bug 1168693 in arandr (Ubuntu) "FFe: Sync arandr 0.1.7.1-1 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1168693
#ubuntu-release 2013-04-14
<micahg> doko: FYI, Bug #1167177
<ubot2> Launchpad bug 1167177 in python-defaults (Ubuntu Precise) "package python-dev 2.7.3-0ubuntu2 failed to install/upgrade: tentative de remplacement de Â« /usr/lib/pkgconfig/python2.pc Â», qui appartient aussi au paquet python2.7 2.7.3-0ubuntu3.1" [High,Triaged] https://launchpad.net/bugs/1167177
<Laney> synced too soon ...
<smartboyhw> Laney, ping
<micahg> can I get the SRU team's opinion on bug 701544?  it needs phpunit needs 5 new sources in precise to work correctly, but it's broke without them
<ubot2> Launchpad bug 701544 in phpunit (Ubuntu Precise) "phpunit requires PHP_CodeCoverage" [Medium,Triaged] https://launchpad.net/bugs/701544
<ScottK> micahg: Are all the packages you need in 12.10 and can you "backport" those to -proposed?
<micahg> yes
<micahg> well, I haven't tested the whole stack yet, but I believe so
<micahg> the dependencies are sane
 * micahg throws it in his PPA for a test
<ScottK> micahg: Assuming it all works, I think it's fine to fix in precise via SRU.
<micahg> ok, thanks, will upload for review after I test it tomorrow
<ScottK> smartboyhw: ^^^
<smartboyhw> ScottK:^?
<ScottK> arandr is updated.
<smartboyhw> ScottK: \o/
<ScottK> I thought you'd be interested.
<smartboyhw> ScottK: Thanks.
<ScottK> You're welcome.
#ubuntu-release 2014-04-07
<Mirv> I'm wishing for a FFe Debian sync approval for pitivi bug #1253009 - 0.93-3 in Debian unstable. there's another positive report on my PPA offering in the bug.
<ubot2> Launchpad bug 1253009 in pitivi (Baltix) "[FFe] Please sync latest upstream release (0.9x) from Debian unstable - Pitivi developers recommends to use 0.92 or later" [Medium,Triaged] https://launchpad.net/bugs/1253009
<infinity> Mirv: Can you get the opinion of the ubuntustudio guys (it's in their seeds) before we look any further?
<infinity> Mirv: And perhaps ask mterry if he has reasons for not merging it.
<infinity> s/has/had/
<Mirv> infinity: thanks, doing those two
<dholbach> hiya
<dholbach> can somebody take a look at https://bugs.launchpad.net/ubuntu/+bug/1302619 https://bugs.launchpad.net/ubuntu/+source/qtcreator/+bug/1302620?
<ubot2> Launchpad bug 1302619 in Ubuntu "[FFe] New package qtcreator-plugin-remotelinux " [Undecided,New]
<ubot2> Launchpad bug 1302620 in qtcreator (Ubuntu) "[FFe] Remove remotelinux plugin and its dependencies from the QtC package" [Undecided,New]
 * seb128 offers cookies to the release team, can we get some trusty queue reviews? ;-)
<seb128> some of the items are waiting since thursday...
<seb128> (not asking for people to work on the w.e but what happened on friday? ;-)
<Laney> seb128: will do some after lunch / piloting
<seb128> Laney, thanks
<sil2100> Hello release team! Sorry to disturb you, but things waiting in the unapproved queue again seems to be a bit troublesome for the CI Train infrastructure - could anyone take a look at some of our packages in the queue? Things like: indicator-application, indicator-appmenu or unity-control-center
<sil2100> Thanks!
<cjwatson> sil2100: I think I have to kick indicator-application back
<cjwatson> sil2100: the new code is:
<cjwatson> +       if [ "x$DESKTOP_SESSION" == "xubuntu-touch" ] ; then
<cjwatson> but that's a bashism, and fails in our default /bin/sh
<sil2100> cjwatson: ah
<sil2100> seb128: ^
<sil2100> cjwatson: thanks for the heads-up and action :)
<seb128> cjwatson, thanks for spotting it, runtime is fine here but it doesn't mean it's correct, I'm going to get ted to fix it (do you want to comment on https://code.launchpad.net/~ted/indicator-application/startup-cleanup/+merge/212726 maybe if you have a suggestion of what should be done instead)
<seb128> sil2100, ^
<sil2100> Thanks!
<cjwatson> seb128: done
<seb128> cjwatson, thanks
<cjwatson> seb128: out of interest did you/whoever test on touch or only on desktop?
<cjwatson> it *looks* as though it'll fail to do the "stop; exit 0" on touch
<seb128> cjwatson, only on desktop, indicator-application uses gtk/doesn't work on touch atm
<seb128> seems like ted added that snippet in case somebody would end up installing it there
<matttbe> Hello Ubuntu-Release team! I'm also sorry to disturb you but I'm part of the Cairo-Dock team and we have to reupload a previous version due to... a lack of time: we were not able to fix some bugs, etc.... We are really sorry to do this request now :(. I guess we need your ACK before uploading the previous version and this is why I create a new bug report: LP: #1302246. If you have some time to have a look at this bug report, it will be greatly appr
<matttbe> eciated :-)
<ubot2> Launchpad bug 1302246 in cairo-dock-plug-ins (Ubuntu Trusty) "[FFe] Revert back to the 3.3.2 version for Ubuntu 14.04" [High,In progress] https://launchpad.net/bugs/1302246
<didrocks> cjwatson: hey, so, preparing the final freeze, are we going to do the same thing than last cycle for things that are seeded in other flavors? (using -updates IIRC)
<Laney> matttbe: Is this "revert, then cherry-pick some fixes from the package already in Trusty"?
<Laney> & have you tested this package out much?
<Laney> there's no issue with configuration to migrate back or anything like that?
<cjwatson> didrocks: I think we probably only need to do that once we're in candidate building mode
<cjwatson> didrocks: but yeah.  it shouldn't make any difference for uploading; uploads go to -proposed either
<didrocks> cjwatson: is that plan for Thursday/Monday?
<cjwatson> way
<cjwatson> didrocks: I would guess about Monday
<didrocks> ok :)
<matttbe> Laney, hello. I just tested this package and it seems there is no crash. The user will just see that the menus will look like the one in the previous version but it shouldn't be a problem.
<didrocks> thanks cjwatson, I've move the train to care about -updates as well
<didrocks> moved*
<cjwatson> didrocks: for deciding when to merge&clean?
<didrocks> cjwatson: right
<cjwatson> didrocks: makes sense as a permanent measure, thanks
<Laney> matttbe: ok, there you go
<didrocks> yeah, it checks the release pocket at the destination first, then -updates
<matttbe> Laney, thank you for your help :-)
<knome> cjwatson, hah, "xubuntu-touch" ...
<cjwatson> knome: well, that's just the x-prefixing idiom for ancient shells
<knome> yeah ;)
<cjwatson> which is ironic to see in conjunction with the == bashism, but anyway
<knome> just giggled for that..
<cjwatson> sil2100: ^- that's unapproved clear of ci-train stuff for now
<sil2100> cjwatson: excellent! Thank you :D :)
<seb128> cjwatson, thanks
<dholbach> hiya
<dholbach> can somebody take a look at https://bugs.launchpad.net/ubuntu/+bug/1302619 https://bugs.launchpad.net/ubuntu/+source/qtcreator/+bug/1302620?
<ubot2> Launchpad bug 1302619 in Ubuntu "[FFe] New package qtcreator-plugin-remotelinux " [Undecided,New]
<ubot2> Launchpad bug 1302620 in qtcreator (Ubuntu) "[FFe] Remove remotelinux plugin and its dependencies from the QtC package" [Undecided,New]
<dholbach> and bug 1303706 too please
<ubot2> Launchpad bug 1303706 in libxkbcommon (Ubuntu) "FFe: new upstream version 0.4.1" [Undecided,New] https://launchpad.net/bugs/1303706
<Laney> Who's reviewing the queue?
<Laney> Want to avoid duplicate reviews
<stgraber> I am
<stgraber> I'm going through the syncs now
<Laney> ok, looking at other things
<Laney> By that I mean non-syncs
<Laney> By that I mean anything that's not gccgo-4.9
 * Laney flees
<stgraber> ;)
<ScottK> If someone is around processing the queue, I need qtruby accepted and built before I can fix korundum (part of ruby1.8 removal)
<stgraber> ScottK: looking
<ScottK> Thanks.
<jamespage> please could I get a release team ack on bug 1287147
<ubot2> Launchpad bug 1287147 in juju-core (Ubuntu Trusty) "[FFe] juju-core 1.18" [High,New] https://launchpad.net/bugs/1287147
<jamespage> I've spent most of the day testing 1.18.0 on 14.04 and I think its good for upload now
<jamespage> Daviey, ^^
<sil2100> Hi release team! Can anyone unblock unity8 from -proposed? Due to the faux package thing ;)
<sil2100> (the package needs bumping, as always I guess)
<cjwatson> sil2100: looking
<cjwatson> sil2100: done
<sil2100> cjwatson: thank you :)
<Daviey> jamespage, looking
<jamespage> Daviey, ta
<cyphermox> could someone please review bug 1280546 and bug 1280548 ?
<ubot2> Launchpad bug 1280546 in usb-modeswitch (Ubuntu) "[FFe] merge usb-modeswitch 2.1.1+repack0-1 from Debian unstable" [Wishlist,New] https://launchpad.net/bugs/1280546
<ubot2> Launchpad bug 1280548 in usb-modeswitch-data (Ubuntu) "[FFe] sync latest version of usb-modeswitch-data 20140327-1 from Debian unstable" [Wishlist,New] https://launchpad.net/bugs/1280548
<Laney> cyphermox: how safe is it? :)
<cyphermox> Laney: pretty safe
<cyphermox> I can't possibly test all the devices myself but of all those I have, 5 use usb-modeswitch and they all successfully switch without crashing the app
<cyphermox> then they don't connect, but that's because I don't have SIMs for some of them
<cyphermox> many new devices don't need this at all; they get in the right state from different drivers
<cyphermox> Laney: but to be fair, there is always an element of risk in landing this so late as this kind of crappy port to C
<Laney> cyphermox: okay, if you think it's the way to go then let's do it
<jamespage> Daviey, I've been documenting changes to the plan in comments rather than changing the original bug report - but as that appears to be causing confusion I've updated that as well now
<mhall119> hello release team, can somebody take a look at https://bugs.launchpad.net/ubuntu/+source/qtcreator/+bug/1302620
<ubot2> Launchpad bug 1302620 in qtcreator (Ubuntu) "[FFe] Remove remotelinux plugin and its dependencies from the QtC package" [Undecided,New]
<mhall119> Laney: ^^ ?
<bzoltan> mhall119:  and release team, these are the FFe bugs -> https://bugs.launchpad.net/ubuntu/+bug/1302619 https://bugs.launchpad.net/ubuntu/+source/qtcreator/+bug/1302620
<ubot2> Launchpad bug 1302619 in Ubuntu "[FFe] New package qtcreator-plugin-remotelinux " [Undecided,New]
<bzoltan> this change is dogfooded well here: https://launchpad.net/~ubuntu-sdk-team/+archive/tools-development
<robru> Laney, infinity: question about packaging changes. I need to take the gsettings schema from libunity9 and split it into it's own -common package so something else can depend on that. will this change need an FFe? no features are changing, just administrative shuffle with a new binary package.
<robru> cjwatson, maybe, whoever's around ^
<xnox> robru: we already have 2 packages for gsettings schemas only, please pick one of them to hold the keys - gsettings-desktop-schemas or gsettings-ubuntu-schemas
<robru> xnox, ah, thanks. mhr3 ^
<mhr3> robru, 2? just looking at my installed schemas, they're coming from 89 different pkgs
<robru> mhr3, just put the schema in gsettings-ubuntu-schemas
<robru> saves having to create a new package and go through that hassle
<ScottK> It would be nice to get korundum accepted since it's part of ruby1.8 removal.
<oSoMoN> hi gentle release team, I have a couple of packages (webbrowser-app and unity-webapps-qml) in the unapproved queue and was wondering if I could get an ETA on their hitting the archive
<oSoMoN> as it stands webbrowser-app and the webapps container in the archive are broken by a recent upload of oxide-qt, the packages in the queue fix that
<doko> please could somebody approve icedtea-web?
<dbarth> hello
<dbarth> ii'm coming to request a nudge for the new oxide upload which got into the unapproved queue
<dbarth> it's currently blocking 2 other silos where we have more fixes for webbrowser-app
<dbarth> thanks in advance
<oSoMoN> hey dbarth, looks like weâre here for the same reason :)
<dbarth> yup
<cyphermox> Laney: still around? I noticed you didn't confirm the bugs for usb-modeswitch(-data); just want to be very sure before I upload ;)
<dbarth> cyphermox: hey, do you know who can help with the oxide upload in this timezone?
<dbarth> oSoMoN and I are trying to get it approved; this is also to avoid that an image gets made with mismatching versions of oxide and webbrowser-app
<Laney> cyphermox: oh, okay, yeah will do
<cyphermox> Laney: sorry to bother with this
<dbarth> Laney: hi, if you still have time, could you look into that oxide upload? ^^
<Laney> dbarth: Not in the right mode for that, did you try any of the NA folks?
<dbarth> Laney: hmm,nope; what's NA?
<Laney> north america
<dbarth> ahem ;)
<dbarth> no, i was asking who was usually around in this tz
<Laney> https://launchpad.net/~ubuntu-release/+members is the magic list
<dbarth> slangasek maybe? we need help with the last oxide upload
<dbarth> Laney: thx, that should help
<Laney> dbarth: Actually, I checked and those diffs look simple
<Laney> Never mind, I'll do it
<Laney> Why aren't these qml package names versioned?
<Laney> dbarth: It's a bit mad that people can just upload a change like that and break all reverse depends
<dbarth> Laney: yeah:/ i think we need to fix that qml declarative deps one way or the other
<Laney> Include the version of the QML API in the package name
<Laney> unless I'm missing something, that should work
<ScottK> dbarth: There was recently a discussion in Debian on qml package naming conventions that I think it would make sense to look at for "U" so we stay in alignment.
<dbarth> ScottK: hey
<cyphermox> +1
<dbarth> ScottK: ok, i'll take a look
<dbarth> right, i think we shouldn't fiddle with that this late
<Laney> Clearly not, but it is an issue worth solving
<dbarth> but i will feel more comfortable when that's done
<Laney> as we're seeing now :)
<Laney> You haz accepts
<dbarth> Laney: thank you
<Laney> ScottK: where's this discussion?
<ScottK> Looking for it.
<Laney> Did Mirv or mitya57 or anyone Ubuntuish participate?
<ScottK> I don't recall.
<Laney> okay
<Laney> I'm sure the outcome will be sane either way
<Laney> With pusling involved, what could possibly go wrong!
<ScottK> Laney: Thread starts here: http://lists.alioth.debian.org/pipermail/pkg-kde-talk/2014-March/001889.html
<ScottK> dbarth: ^^^
<dbarth> yup
<Laney> ta
<ScottK> And yes, mitya57 did participate.
<Laney> I'll proxy it to $somewhere so that $people are aware
<ScottK> Thanks.
<mdeslaur> can someone approve openssl please, it's pretty important
<ScottK> mdeslaur: Looking
<mdeslaur> ScottK: thanks
<utlemming> Any chance one a release team member could look at FFE for Bug 1304023?
<ubot2> Launchpad bug 1304023 in walinuxagent (Ubuntu) "[FFE] update walinuxagent to 2.0.4" [High,New] https://launchpad.net/bugs/1304023
<utlemming> s/change one a/change a/g
<utlemming> s/chance one a/chance a/g ... it could help if I could type this afternoon
<slangasek> doko: so... gccgo-4.9, you want to give me more of why this is a safe change 10 days before release?
<doko> slangasek, no changes to libgcc, regression fixes only (GCC is in stage4), test-built juju-core and go-gccgo
<slangasek> doko: perfect, thanks
 * slangasek spot-checks the diff
<doko> ahh, and I need to file the sru for the 4.9.0 upload
<slangasek> doko: debian/patches/cross-install-location.diff has changes to libmudflap/Makefile.am that are not obviously correct and not explained in debian/changelog
<slangasek> doko: and I'm pretty sure debian/rules2 has a typo, though it's not relevant to us (sparc64-linux-gnuA vs. sparc64-linux-gnu)
<doko> slangasek, mudflap is dropped in 4.9, this fixes the cross build. the typo is fixed in the vcs
<slangasek> ah, ok
<slangasek> accepted
<doko>   * Provide the gnu triplet prefixed gcov symlink.
<doko>   * Add ppc64el as a native gcj architecture.
<doko>   * Drop mudflap from cross-install-location.diff since mudflap was removed
<doko>     from gcc 4.9. Closes: #742606
<slangasek> doko: and the icedtea-web jump from 1.4.2 to 1.5?
<doko> slangasek, we have a standing exception to update openjdk to newer releases in stable releases anyway, so better update it now than after the release. or do you want a separate FFe?
<slangasek> doko: well, I can't tell from the version numbers how 1.4.2->1.5 fits the openjdk SRU exception model (which, btw, doesn't seem to be documented anywhere)
<doko> filing a FFe
<robru> can i get someone to unblock unity-webapps-qml in -proposed? it's blocked by oxide on the three arches, a known regression
<mdeslaur> can openssl be released out of -proposed before all the autopkgtests finish, as it's pretty critical
<mdeslaur> pleeze
<mdeslaur> slangasek: ^
<mdeslaur> stgraber: ^
<mdeslaur> cjwatson: ^
<stgraber> looking
<stgraber> looks like that libreoffice one never passes anyway, so yeah, I'll force it
<mdeslaur> thanks stgraber
<doko> slangasek, lp: #1304086
<ubot2> Launchpad bug 1304086 in icedtea-web (Ubuntu) "FFe: icedtea-web 1.5" [Undecided,New] https://launchpad.net/bugs/1304086
<stgraber> mdeslaur: openssl should be copied on this britney run
<mdeslaur> stgraber: cool, thanks!
<antarus> thanks a bunch folks ;)
#ubuntu-release 2014-04-08
<Mirv> the qml naming scheme presented by lisandro is sane, he discussed it on IRC before putting to mailing list
<zequence> Another last minute fix, bug 1304214
<ubot2> Launchpad bug 1304214 in ubuntustudio-lightdm-theme (Ubuntu) "[UIFe] New default wp for ubuntustudio-lightdm-theme" [Undecided,New] https://launchpad.net/bugs/1304214
<seb128> hey there
<seb128> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-control-center
<seb128> can somebody make sense of that?
<seb128> "unity-control-center/arm64 unsatisfiable Depends: indicator-datetime "
<seb128> "Not considered "
<seb128> but that situation is not new...
<cjwatson> Somebody removed indicator-datetime from arm64?  Why just that arch I wonder?
<seb128> it fails to build there
<seb128> but that's not new
<cjwatson> Oh, me apparently
<cjwatson> Well it is somewhat new, saucy had indicator-datetime/arm64
<infinity> Why would it be FTBFS on only arm64?
<seb128> right, but saucy was not using url-dispatcher
<cjwatson> We could probably get that back with a no-change of indicator-datetime though
<seb128> infinity, it bubble up to some touch component not being available there
<seb128> iir
<seb128> iirc
<cjwatson> Since the reason it was removed no longer applies
<cjwatson> Wonder if I can copy it back
<seb128> oh, no
<infinity> seb128: No, it's FTBFS in the testsuite, not a missing build-dep.
<seb128> build failed on test issue
<cjwatson> Oh, yeah, OK
<seb128> infinity, sorry, my memory is probably from < qt5.2 times
<seb128> should I retry the build?
<seb128> in case it's a flacky test
<infinity> Can't hurt, but probably won't help either.
<infinity> Racey tests don't usually segfault.
<cjwatson> seb128: And it *is* new - unity-control-center in -proposed Depends: indicator-datetime, the one in release doesn't.
<seb128> cjwatson, oh indeed, sorry
<seb128> I confused that version with the one in unapproved
 * Laney tries a test build
<seb128> cjwatson, infinity: thanks for the help, I guess the easiest way out is to get indicator-datetime to build on arm64
<infinity> seb128: Certainly the preferred way out anyway.
<cjwatson> Yeah, unity-control-center has enough rdeps that I'd rather not remove its binary.  The next (icky) fallback would probably be to make that dep arch-specific
<infinity> Or disable the testsuite on arm64 with a massive XXX FIXME OH GOD LOLZ comment.
<infinity> But I'd definitely prefer someone investigating the crash a bit first.
<infinity> At least get some backtraces of the segv, it might be something one of us has seen before in other contexts.
<seb128> infinity, right, I'm going to talk to charles about it later
<Laney> dpkg-deb: building package `indicator-network' in `../indicator-network_0.5.1+14.04.20140318-0ubuntu1_arm64.deb'.
<infinity> Laney: If only that was indicator-datetime.
<Laney> haha
<Laney> I was shitting myself a bit
<Laney> I blame... something that's not me not paying attention
<Laney> I'd even done apt-get build-dep on the right package /o\
<dholbach> could somebody take another look at https://bugs.launchpad.net/ubuntu/+bug/1302619 https://bugs.launchpad.net/ubuntu/+source/qtcreator/+bug/1302620?
<ubot2> Launchpad bug 1302619 in Ubuntu "[FFe] New package qtcreator-plugin-remotelinux " [Undecided,New]
<ubot2> Launchpad bug 1302620 in qtcreator (Ubuntu) "[FFe] Remove remotelinux plugin and its dependencies from the QtC package" [Undecided,Incomplete]
<dholbach> and bug 1303706 too please :)
<ubot2> Launchpad bug 1303706 in libxkbcommon (Ubuntu) "FFe: new upstream version 0.4.1" [Undecided,New] https://launchpad.net/bugs/1303706
<brendand> hey, i have a couple of FFEs that i'm sheperding:
<brendand> https://bugs.launchpad.net/ubuntu/+source/checkbox/+bug/1302615
<ubot2> Launchpad bug 1302615 in checkbox (Ubuntu) "[FFe] [UIFe] Checkbox GUI needs to be able to send test results to Launchpad" [Undecided,New]
<brendand> https://bugs.launchpad.net/ubuntu/+source/checkbox/+bug/1303849
<ubot2> Launchpad bug 1303849 in checkbox (Ubuntu) "[FFe] The Checkbox UI needs a way to be customised" [Undecided,New]
<brendand> is there a big backlog of FFEs?
<dholbach> brendand, https://bugs.launchpad.net/~ubuntu-release/ as 150 bugs - not sure if that's the best indication though
<brendand> dholbach, can we em, 'encourage' someone to look at them?
<dholbach> brendand, I could imagine that a lot of people on the release team are very busy people :/
<infinity> We could encourage people to stop filing FFes seven months after feature freeze and a week and a half before release.
<dholbach> infinity, weeks?
<brendand> infinity, i know, it's quite late in the day, but we had to do a lot of groundwork to make this feature possible
<apw> "if we did this by the book hours would seem like days"
<infinity> dholbach: No, months, the hyperbole was intentional. :P
<dholbach> ok :)
<Laney> brendand: The idea is that if a feature's not ready then it gets in next time
<maclin> infinity, the re-building  of ubuntu kylin does not take effect again. Could you help to check it ?
<infinity> maclin: Looks like it's in progress right now.
<brendand> Laney, well yeah, but this is the LTS release. The feature in question is the ability for the system testing application (checkbox) to submit data to Launchpad's hardware db
<brendand> Laney, so if it doesn't make it in, we won't have any of that data for the LTS release
<brendand> Laney, unless we could get it through the SRU process
<infinity> SRUing features is worse.
<infinity> brendand: I understand why everyone wants all their features polished and good to go for LTSes.  I just wish they'd realize they have almost two years to make that happen, and not leave it to the last two weeks to land them.
<maclin> infinity, thanks! Is there a way for us to see wether the rebuilding is  right or not?
<infinity> maclin: Nope.
<maclin> thanks, I get it:)
<brendand> infinity, i think that's oversimplifying it a bit. but i can totally understand that it's frustrating as a release team member to see everything build up in the last few weeks/days
<infinity> brendand: It's not oversimplifying at all.  We have a very well-known and rigid release schedule.  Yes, some things won't occur to you as being a killer feature until it's too late.  And some of those, we'll let in, but the expectation that we'll let all, or even most, of them in is just wrong.
<infinity> brendand: So, we'll look at this.  And we may deem it low risk and useful enough to be necessary, but asking people to develop to a schedule and accept that "late" might mean "next release" is just part of the time-based release bag.
<seb128> infinity, imho there would be some value at accepting feature backports to LTS series through SRUs, for things that have been well tested/validated in newer series
<infinity> brendand: There are no unique snowflakes here.  If everyone kept uploading new features into the last week or two of release, we'd never be able to stabilise.
<infinity> seb128: Sometimes.  And we occasionally do.  But that's a slipperly slope of breaking the promise of what a "stable" release means, too.
<infinity> seb128: Stable UI, stable ABIs, stable APIs.  New features usually break one or all of those.
<seb128> infinity, right
<brendand> infinity, if it gets looked at, we'll be happy. i'm blowing my own trumpet here, but it is very low risk, overall. the absolute worst that could happen is checkbox not working at all, but without it sending results to launchpad, it has little overall value anyway
<infinity> (FWIW, I just self-rejected an FFe of my own after some investigation and deciding I was too late to effectively test the change, so I'm practicing what I preach)
<infinity> brendand: Point taken on the general uselessness of the package without this feature working, then.  One could probably call that a bugfix. :P
<brendand> infinity, then we don't need an FFe! \o/
<seb128> could somebody review/accept unity-control-center from the queue?
<seb128> it's a one commit to mark string translatable
<Laney> Are all of these https://launchpad.net/ubuntu/+source/checkbox versions of checkbox useless then?
<seb128> getting it through would let me get a silo back to land the indicator-datetime buildfix
<Laney> seb128: looking
<seb128> Laney, thanks
<brendand> Laney, all of them? no - the ones before trusty had this feature
<brendand> Laney, currently in trusty it doesn't
<brendand> Laney, the thing is we rebuilt checkbox
<brendand> Laney, rewrote it really
<infinity> brendand: Can you attach some debdiffs to these FFes?
<Laney> seb128: is this kind of translation normal?
<brendand> infinity, debdiffs? sure. the lp:ubuntu/checkbox MR is there though
<seb128> Laney, "kind of translation"?
<Laney> datetime format strings
<seb128> Laney, that's a backport of https://git.gnome.org/browse/gnome-control-center/commit/panels/user-accounts/um-history-dialog.c?id=aa3af401147c9550bc19d14b5cdaf5588083f7c1
<Laney> I see
<seb128> Laney, but yeah, https://developer.gnome.org/glib/stable/glib-I18N.html#C-:CAPS
<Laney> yeah I know C_, was just wondering if using it on format strings like that is a done thing
<seb128> Laney, well, that just returns a string, you could put a strdup() or something there as well
<seb128> Laney, in any case I'm running that version, works fine (and upstream shipped it in a stable release/didn't do followup commits)
<brendand> infinity, looks like there are none: http://paste.ubuntu.com/7221079/
<brendand> infinity, i can mention that in the ffe's
<infinity> brendand: The source, not the debs.
<infinity> brendand: Though I'm actually really curious now, since the UIFe seems to imply there should be some conffiles or something new in the packages. :)
<infinity> Anyhow, I'm going to back away from the laptop, drug myself, and be back tomorrow.
<Laney> seb128: done, doubt anyone will translate that before release but you never know
<seb128> Laney, I uploaded an updated template to launchpad last week so translators already did some work ;-)
<Laney> manually?
<seb128> yes
<seb128> run intltool-update in my build tree and uploaded
<seb128> don't worry, it's a documented workflow and not the first time I use it ;-)
<Laney> heh
<Laney> is there a problem with extracting from uploads?
<seb128> Laney, no, it's just that if I had waited for the mp to be review/approved/CI trained/unapproved accepted/landed/imported we would have had the new strings available on launchpad this afternoon
<seb128> Laney, where my manual update meant translators had an head start on it during the w.e ;-)
<Laney> If only launchpad had a way of making translations available from the VCS :-)
<seb128> hehe
<didrocks> ubuntu-ui-toolkit uploaded: this is a revert to have gallery-app passing again tests. We want to kick an image soon, can anyone from release team consider it? Thanks ^
<Laney> seems queuebot hasn't made it back
<didrocks> yeah
<didrocks> he's gone for long ;)
<Laney> didrocks: ok, done
<didrocks> Laney: thanks! there is an unity8 coming as well
<didrocks> Laney: which was linked to that change
<didrocks> (same, revert of one commit)
<didrocks> Laney: unity8 7.85+14.04.20140404.is.7.85+14.04.20140403.1-0ubuntu1 coming to a queue near you :)
<xnox> Laney: imho it's a bug fix, but also change in the UI, can you peak at bug #1304363 the proposed diff is "s/1/0/" on left,right & bottom border widths.
<ubot2> Launchpad bug 1304363 in ubuntu-themes (Ubuntu Trusty) "[UIFe] enable borderless windows under metacity (e.g. for ubiquity)" [High,Confirmed] https://launchpad.net/bugs/1304363
<xnox> this would make ubiquity look sexy.
<Laney> xnox: Check with docs for screenshots
<Laney> (didn't load the bug, maybe you did that)
<Laney> (also going to lunch now :P)
<Laney> xnox: And get larsu to review that
 * Laney biab
<xnox> Laney: but the screenshot is soooo pretty =))))
<didrocks> actually, unity8 was autoaccepted
<didrocks> Laney: but we'll need someone to bump the fauxpackage if possible
<xnox> Laney: larsu approved =)
<jamespage> Daviey, fyi just updating ceph to 0.79 for testing prior to upload
<jamespage> I'll request an ack once I'm happy its OK
<sil2100> Dear release team! Sorry to poke once again about things related to this, but could we ask for pushing platform-api forward from the UNAPPROVED queue? Thank you!
<cjwatson> looking
<cjwatson> lack of queuebot is slowing us down :)
<cjwatson> sil2100: done
<sil2100> cjwatson: thank you o/
<sil2100> :)
<Laney> xnox: did you test metacity itself?
<Laney> also, please inform docs team
<Laney> after that, should be fine
<Laney> didrocks: did it get done?
<jamespage> could someone from the release team please review bug 1295093
<ubot2> Launchpad bug 1295093 in docker.io (Ubuntu) "[FFe] Sync docker.io 0.9.0 from Debian testing" [High,New] https://launchpad.net/bugs/1295093
<jamespage> its been there for a while with no comment whatsoever
<jamespage> 0.9.1 is now in unstable....
<jamespage> (I'll look at that now)
<didrocks> Laney: not sure if you have done anything, but unity8 is a valid candidate now :)
<xnox> Laney: hm, not sure i need to inform docs team, as we don't have ubiquity screenshots in docs, we only have them on ubuntu.com website. And i have a task to pass updated screenshots for the release to the website team already.
<xnox> will double check if that has changed.
<Laney> Usually it's polite to do so
<Laney> I'd just ask them instead of trying to figure it out yourself
<Laney> You can ask GunnarHj
<stgraber> oh, reminds me I probably should do a last minute ubiquity slideshow upload
<stgraber> (the usual last minute translation update)
<seb128> Laney, indicator-datetime in the unapproved queue
<Laney> someone else better review that one :-)
<didrocks> :p
<seb128> could somebody review indicator-datetime in the queue?
<seb128> it's a one liner (init a variable to null) that fixes the arm64 ftbfs
<marrusl> Hi all.  Can someone look into nvidia-graphics-drivers-331 for precise ?   It seems like it's stuck in the "New" queue.
<cjwatson> seb128: done
<seb128> cjwatson, thanks
<jamespage> Daviey, if you have time - https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1295093
<ubot2> Launchpad bug 1295093 in docker.io (Ubuntu) "[FFe] Merge docker.io 0.9.1 from Debian unstable" [High,New]
<jamespage> or any other release team members :-)
<Daviey> jamespage, i dont feel able to look closely at that issue right now.
<bdrung_work> hi, may i upload the new source package versiontools to fix the build failure of gevent-socketio?
<jamespage> stgraber, would you have time to review https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1295093 ?
<ubot2> Launchpad bug 1295093 in docker.io (Ubuntu Trusty) "[FFe] Merge docker.io 0.9.1 from Debian unstable" [High,New]
<stgraber> jamespage: not at the moment, no
<jamespage> ScottK: I need a review of https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1295093 - its been kicking around for a while
<ubot2> Launchpad bug 1295093 in docker.io (Ubuntu Trusty) "[FFe] Merge docker.io 0.9.1 from Debian unstable" [High,New]
<jamespage> would you have time to review?
<jamespage> ScottK, I spoke with the Debian maintainer and he's preparing an upload including the required apparmor patch so we can just sync it over
<zul> Can someone accept qemu and libvirt it has a regression that affects virtio devices
<cjwatson> zul: done
<zul> cjwatson:  thanks
<tjaalton> could someone ack https://bugs.launchpad.net/ubuntu/+source/libxkbcommon/+bug/1303706 so I can upload it. RAOF tested it as reported on mir-devel@
<ubot2> Launchpad bug 1303706 in libxkbcommon (Ubuntu) "FFe: new upstream version 0.4.1" [Undecided,New]
<robru> cjwatson, oops, I goofed up the bamf upload. can you accept the 0408 version over the 0407.1 that just got into proposed?
<cjwatson> robru: sure, one sec
<robru> cjwatson, thanks
<cjwatson> done
<robru> cjwatson, sweeet, thanks again
<roaksoax> can someome please take care of 'maas' which is in the approved queue? It has 3 important fixes! Thank you!
<rsalveti> slangasek: updated qtbase-opensource-src to make sure all the symbols are up-to-date per arch
<rsalveti> slangasek: before we actually propose the changes needed for the gl x gles work
<rsalveti> doing a bunch of rebuilds now in a ppa to see if what you proposed in that thread is enough (which should be, unless we get some other issues)
<marrusl> Hi folks, can someone take a look at nvidia-graphics-drivers-331-updates in the precise New queue?  It's needed for compatibility with the trusty backport kernel.
<chrisccoulson> hi, can someone please accept that flash package? ^
<jdstrand> chrisccoulson: oh, I asked you to come here, but I forgot this was for partner
<jdstrand> I'll do it
<jdstrand> chrisccoulson: for some reason I was thinking it was flashplugin-nonfree
<chrisccoulson> ah, thanks :)
<chrisccoulson> jdstrand, just uploading the others now as well
<jdstrand> chrisccoulson: when you update flashpugin-nonfree for trusty, do ask here though
<jdstrand> chrisccoulson: ok, I accepted all the partner packages
<chrisccoulson> jdstrand, thanks
<slangasek> rsalveti: great, glad to hear you're making progress on the glesing.  Can you give me a pointer to the ppa, so I can follow along?
<chrisccoulson> could someone please approve that? ^^ :)
<rsalveti> slangasek: did a few tests with local builds and I'm now starting to push stuff to https://launchpad.net/~canonical-arm-dev/+archive/ppa/+packages, but will ping you back later today with more results
<rsalveti> slangasek: will test initially with a different src package providing just the packages we care (gui, opengles, etc)
 * slangasek nods
<rsalveti> that can later be integrated in the same src package, but it needs a bit of rework and too close to the release to work on that now
<xnox> Laney: got an ack from docs team. So all good to silo that baby up tomorrow \o/
<utlemming> stgraber: we need to add a whole bunch more targets for EC2 testing....can we change HVM to "HVM EBS", with one for each region, and then add "HVM Instance" with one for each region?
<stgraber> I'm sure we can, lots of manual changes though (and not really worth scripting)...
<xnox> slangasek: is it a requirement for newly introduced upstart jobs in trusty to be precise compatible? (those that e.g. replace init.d scripts) the upgrade story is not nice, init.d script is stopped upon upgrade and not started since upstart job is rejected, thus one must reboot.
<xnox> i guess the question is, is it support to run precise upstart with trusty userspace =)
<xnox> s/support/supported/
<xnox> ?
<slangasek> xnox: I don't think this question had ever been brought up explicitly; it's certainly a requirement that "upgrades work", but I'm not sure I understand the implications here - are you finding upstart jobs using particular features that aren't precise-compatible?
<xnox> slangasek: bug #1272788
<ubot2> Launchpad bug 1272788 in php5 (Ubuntu) "php5-fpm upstart job is not compatible with precise upstart" [High,Triaged] https://launchpad.net/bugs/1272788
<xnox> slangasek: due to "reload signal USR2", my cunning plan is to ship .override file with "reload signal USR2" -> precise will ignore .override, but trusty will use the .override. Thus compatible with both releases, without compromise on trusty.
<slangasek> xnox: also, is a versioned dependency on upstart sufficient here?  Since running services in chroots is not a common use case, we generally speaking only have to worry about the running init when installing packages in the "host" environment, and versioned dep is sufficient to get upstart restarted
<slangasek> override> yuck :)
<xnox> slangasek: alternatively maintainer scripts should fall back to initd script.
<slangasek> also yuck!
<slangasek> why not add a versioned dependency?
<xnox> slangasek: versioned dep does not help. so the bug is after upgrade and util reboot.
<slangasek> xnox: how does it not help?  upstart is upgraded; it re-execs
<slangasek> and then the new syntax is supported
<apw> heh
<apw> erp
<xnox> slangasek: i thought precise upstart can't do stateful re-exec and hence it only re-execs on shutdown....
<slangasek> oh man
<slangasek> you could be right
<slangasek> was that only two years ago?
<xnox> slangasek: it was during my time, and i've joined after precise got released.
<slangasek> yeah, maintainer script in ge 1.9 || 1.8-ubuntu-full-serialization
<slangasek> so you're right, versioned dep is no good
<xnox> slangasek: at first oakland keybuk was briefing myself and jodh on how to serialise upstart.
<slangasek> xnox: yes, I believe you - I'm just old, and so my perception of time is lacking ;)
<xnox> slangasek: hence the question of how to support this case, if at all....
<xnox> slangasek: i guess we should be falling back to init.d script if the job is unknown to upstart (even though it's present on disk)
<slangasek> xnox: that means we would be falling back to init.d in the case of bugs in the upstart job, too; maybe not desirable
<slangasek> xnox: you could both 'check if job is known' and 'use init-checkconf on disk to parse the file', and only fall back to the init script if the current upstart on disk likes it but the running upstart doesn't
<infinity> Quick, backport stateful re-exec to precise?
<infinity> slangasek: That would be a workable (ish) solution for this one package, but that doesn't really scale if other packages are also precise-incompatible.
<xnox> slangasek: but init-checkconf in precise, no-worky without X..... (we fixed that in trusty i believe)
<slangasek> infinity: eh, you would put it in invoke-rc.d.
<infinity> Not that I like the obvious alternative (tell people they must reboot or their services won't be running).
<xnox> because dbus =0
<slangasek> xnox: but short circuit behavior saves us, no?
<xnox> slangasek: what do you mean by "short circuit" ? =)
<slangasek> xnox: if $job_is_not_known && init-checkconf $myjob; then sysvinit_fallback=true; fi
<slangasek> xnox: so the only case in which you're even trying to invoke init-checkconf is if the job is unknown in the first place
<slangasek> *and*, you really care about getting the answer from the *new* init-checkconf anyway, so you'd have a versioned dep on upstart for those packages where it matters
<xnox> slangasek: i care about servers only. we are in the state where init-checkconf will not work. init-checkconf might be precise one - in which case it needs dbus-launch/X to work.
<xnox> slangasek: init-checkconf from trusty needs trusty pid1 to be able to use user-session to check the job.
<slangasek> xnox: oh, then scrap the entire idea.  I assumed init-checkconf worked without talking to pid1
<slangasek> if it doesn't, then it doesn't provide any additional info
<slangasek> in which case, "if $job_is_not_known" isn't perfect, but probably the closest we can get
<xnox> wait, when init-checkconf is trusty one, /sbin/init is also trusty so yeah that will tell you that job is fine, if you'd re-execed.
<xnox> and how would this "sysvinit_fallback=true" work? given that init.d scripts per policy would bail on us and so would the $ service command.
 * xnox goes to check how many jobs are affected
<slangasek> hah, sigh
<slangasek> omg, xnox is sending my mail client into a busy loop
<xnox> slangasek: so far i see it's just that one php job. I might opt in for e.g. not stopping it on upgrade from precise -> trusty?!
<slangasek> xnox: or just dropping the use of 'reload'?
 * xnox will run full init-checkconf on all jobs from trusty on a precise box.
<xnox> slangasek: or that.
<JackYu> hi release team, who could help to take a look at FFe bug #1293299?
<ubot2> Launchpad bug 1293299 in Ubuntu Kylin "[FFE]upload ubuntu-kylin-software-center into archive" [High,Confirmed] https://launchpad.net/bugs/1293299
<slangasek> JackYu: hi - it's on my list to look at this afternoon
<slangasek> JackYu: FYI, FFe bugs should be left in state 'New', not 'Confirmed' so that the release team sees them
<JackYu> slangasek, sure, thanks:)
<slangasek> rsalveti: how'd the rebuild go?  FWIW I don't seem to have access to https://launchpad.net/~canonical-arm-dev/+archive/ppa/+packages
<slangasek> would be nice to have these builds in a public ppa... :)
<rsalveti> slangasek: yeah, need to get a public ppa with armhf
<rsalveti> slangasek: but anyway, will copy them over once the build is done
<slangasek> ok
<rsalveti> finishing qtbase, next is qtdeclarative, and building the gles versions in parallel
<rsalveti> but it takes time
<rsalveti> qtbase takes almost 4 hours to build on armhf
#ubuntu-release 2014-04-09
<cyphermox> if someone's around; I'd need somebody to check in on autopilot which seems to be stuck believing its autopkgtests are still running... well because technically the job is still running but should have returned with success a few hours ago it seems
<ScottK> slangasek: re qtcreator and remotelinux - Do we really want to fork from upstream going into an LTS on something upstream hasn't agreed they will ever do?
<ScottK> As far as I know, this hasn't been coordinated with the Kubuntu team and I find it quite disappointing after having gotten the Ubuntu SDK module out of hte qtcreator source package to have the package run off on another tangent from upstream.
<infinity> ScottK: Bug?
<ScottK> bugs/1302620
<ScottK> Seems to me that no agreement with upstream on a long term release is a pretty good reason to wait a cycle.
<ScottK> BBIAB
<infinity> ScottK: I'm not sure splitting a package out is quite the same level of awful as adding random bits TO the package.
<infinity> Even if upstream never wants to split the tarball, that's no reason for Ubuntu to not have split tarballs (or, at the very least, split binaries, which is a very Debian thing to do anyway).
<infinity> (The timing is a bit crap, but it doesn't seem to have wide impact currently)
<darkxst> infinity, can you take a look at ubuntu-gnome-wallpapers in NEW?
<infinity> darkxst: Did you guys not have a wallpapers package before?
<infinity> Where did your wallpaper come from? :P
<darkxst> we use the stock gnome wallpapers previously
<infinity> Ahh, kay.
<infinity> darkxst: So, will this invalidate all your docs and screenshots, or do you not particularly care?
<darkxst> this was the first cycle we had a community wallpaper contest
<infinity> (And I assume this will need to be seeded, etc)
<infinity> darkxst: Will your default wallpaper also come from this package, or will it not change?
<darkxst> infinity, it will be seeded, but not set as default wallpapers
<infinity> Kay, cool.
<infinity> Will review based on that knowledge, then.
<darkxst> thanks
<ScottK> infinity: I don't see it as any different since our package if forked, possibly permanently.
<slangasek> ScottK: bzoltan made a strong case to me that the sensible way forward for these plugins is to have them out of tree so that they can be developed without wrangling all of qcreator; I was pushing back hard so long as I thought this was being regarded as a temporary workaround, but given that this is their long-term goal it seems sensible to me.  Would you prefer they do something differently wrt getting this into the archive (aside fro
<slangasek> ScottK: the other point was that AIUI they've already done this for the cmake module
<stgraber> slangasek: you cut at "(aside fro"
<slangasek> really?  odd
<slangasek> (aside from the timing)?
<ScottK> slangasek: I think he should be making the case to upstream and it shouldn't be done as a distro thing.
<ScottK> Didn't know about the cmake thing.  See my earlier points about coordination.
<ScottK> slangasek: I'd say let them sort it out with upstream, get it into "U" and backport as necessary.
<ScottK> I don't particularly buy their whining about it being hard to upstream stuff with Digia either.  If it's hard for them, it's only because they aren't working with them (which it a problem).  To the extent they are having trouble it's a symptom of a problem that is exactly why I don't want stuff in our packages upstream hasn't agreed to.
<ScottK> Bed time for me.
<darkxst> infinity, will ubuntu-gnome-wallpapers project get created automatically or do I need to add it manually ?
<darkxst> (to be able to push the vcs-bzr branch)
<zyga> hi, I'd like to coordinate/review syncs of checkbox releated packages
<zyga> the full list of packages is https://lists.launchpad.net/checkbox-dev/msg00111.html
<zyga> this is also heavily related to https://bugs.launchpad.net/ubuntu/+source/checkbox/+bug/1302615
<ubot2> Launchpad bug 1302615 in checkbox (Ubuntu) "[FFe] [UIFe] Checkbox GUI needs to be able to send test results to Launchpad" [Undecided,New]
<brendand> infinity, hey - i added those debdiff's to the bugs. i also put a clarification for you on the bug about ui customization
<zyga> plainbox debdiff: http://paste.ubuntu.com/7225244/
<zyga> checkbox-support debdiff: http://paste.ubuntu.com/7225250/
<zyga> checkbox-ng debdiff: http://paste.ubuntu.com/7225251/
<zyga> plainbox-provider-resource-generic debdiff: http://paste.ubuntu.com/7225256/
<zyga> plainbox-provider-checkbox debdiff: http://paste.ubuntu.com/7225270/
<brendand> is anyone able to look at https://code.launchpad.net/bugs/1302615
<brendand> and
<brendand> https://code.launchpad.net/bugs/1303849
<brendand> i'm ready and willing to follow up on any questions and comments
<jamespage> Daviey, ceph 0.79 was out yesterday; I've tested quite a bit - details in bug 1278466
<ubot2> Launchpad bug 1278466 in ceph (Ubuntu Trusty) "[FFe] ceph firefly stable release" [High,In progress] https://launchpad.net/bugs/1278466
<jamespage> (last comment)
<jamespage> Daviey, can I get an ack for upload please
<Daviey> jamespage: Oh, that is great news.  Please upload.
<jamespage> Daviey, ack
<Daviey> jamespage: To clarify, we have the release goals for 14.04 here... or is there something else we wanted from 0.80?
<jamespage> Daviey, other than to lineup with the release that upstream will actually push point releases against - no
<jamespage> all the features are now in
<Daviey> Great!
<jamespage> Daviey, uploading now
<Daviey> superm1: Hmm, mythbuntu-live-autostart includes .bzr with the upload and inconsistent historic d/changelog.. I assume this is an accident..
<Daviey> superm1: Going to reject it, if this is intent - please let me know, and we can retrieve it from the rejected queue for review.
<dbarth> hi
<dbarth> please hold webbrowser-app in the unapproved queue when it arrives, we have another fix coming down silos right after
<zyga> hey, can we do something to move plainbox|checkbox packages forward?
 * zyga is unsure how this process works
<sil2100> Hi release team! I would need some help on investigating something - there has been a account-plugins version (0.11+14.04.20140401-0ubuntu1) that has been put into the rejected queue - we have another release for this component and because of that I would like to know the reasons for why it was rejected the last time
<sil2100> https://launchpad.net/ubuntu/trusty/+queue?queue_state=4&queue_text=account-plugins
<sil2100> Does anyone remember by any chance what were the reasons for rejecting this one?
<ScottK> Whoever uploaded it should have gotten a mail with the reason.
<sil2100> It's all part of CI Train, so hm, not sure where to look
<cjwatson> No clear sign of it in IRC logs
<cjwatson> The archive robot requested it, so I might have it
 * cjwatson looks in that gigantic mailbox
<sil2100> o/
<cjwatson> hmm, nothing
<sil2100> cjwatson: thanks for looking into that - mardy (one of the upstream developers) says that it might have been infinity rejecting the upload
<cjwatson> maybe it's the account that did the original copy that gets the sync?
<cjwatson> s/sync/mail/
<cjwatson> That'd be ~ps-jenkins I suppose
<cjwatson> Maybe find somebody who can read the archives of https://lists.canonical.com/mailman/listinfo/ps-jenkins ?
<ScottK> Yet another pitfall of a process without a human uploader.
<cjwatson> To be fair it's not clear why the archive robot shouldn't have got mail here
<cjwatson> It probably also ought to use the facility for sponsoring syncs on behalf of other people
<cjwatson> ci-train should I mean
<cjwatson> It knows who's logged into Jenkins to request it, hopefully it can map that back to an LP username ...
<cjwatson> didrocks: ^- can citrain get at the requesting user's LP username?  if so it could add sponsored= to its copyPackage calls
<didrocks> cjwatson: it will need some testing. I'm unsure what the jenkins plugin is sending and if we can map back to a user name
<cjwatson> I'm not totally sure that that would let LP rejection messages go to the requesting user, but it would at least make it *possible* to do that
<cjwatson> which would have helped this
<didrocks> yeah
<didrocks> cjwatson: I'm not really sure with the amount of churn we are having right now I can look at it, but definitively adding to the backlog of things to investigate
<cjwatson> yep, thanks
<mvo> hello, sorry for naging, but any thoughts on https://bugs.launchpad.net/ubuntu/+source/ansible/+bug/1302947 ? or should I use my own judgement (given that I'm the debian maintainer of ansible as well?)
<ubot2> Launchpad bug 1302947 in ansible (Ubuntu) "[FFe] ansible 1.5.4" [Undecided,New]
<bfiller> hi guys, we need to land a new package sync-monitor as part of the Touch FFE - will only be seeded on touch. didrocks has done the archive admin review already
<jpds> Can someone poke my ima-* tools in the NEW queue?
<superm1> Daviey: i'll double check
<superm1> Daviey: yeah it was a mistake that tgm committed something to bzr with the wrong changelog entry, and me using a different computer that configured in bashrc to not include .bzr, i'll upload again momentarily
<zyga> how can I get some cooperation on checkbox|plainbox packages? what do we need to get them approved?
<stgraber> zyga: we currently have 261 uploads in the queue
 * cjwatson accepts a load of langpacks then
 * doko greats from PyCon
<Daviey> cjwatson: What are you looking for with a langpack review?
<Daviey> superm1: accepted, thanks
<cjwatson> Daviey: not a lot
<cjwatson> Daviey: I generally wave through the bulk ones because I know langpacks get some testing in advance and I'm not liable to add much with a manual review compared to the effort it would take
 * cjwatson approves the two checkbox ffes, rolls up sleeves, and prepares to plough through diffs
<roadmr> cjwatson: thanks!!!
<cjwatson> I may be some time ...
<roadmr> cjwatson: I can do the checkbox upload, maybe that'll save you some time?
<cjwatson> I'm not clear how that would save me time, given that I wasn't planning to upload checkbox :)
<roadmr> cjwatson: heheh :) I'm not the time-saver I thought I was :P
<cjwatson> ok, let's see how this goes
<Daviey> In the queue is an upload called folks, well - a sync from a PPA.  It looks like it was uploaded to the PPA by a developer, without upload access.  The requester in the queue just shows the Archive Robot.  How do i tell who 'sponsored' this?
<cjwatson> you have to go look at the PPA, that's the CI Train stuff
<cjwatson> ci-train.ubuntu.com will have the requesting user
<Daviey> cjwatson: The PPA shows the user that doesn't have upload access
<Daviey> Oh
<cjwatson> see above discussion of why it'd be good for the ci-train system to use sponsored=
<cjwatson> https://ci-train.ubuntu.com/job/landing-009-2-publish/5/console says Mirv published it
<Daviey> cjwatson: Amazin' I don't have ACL to view that url.
<cjwatson> really.  you're meant to
<cjwatson> didrocks: ^- I thought those were meant to be community-visible
<didrocks> hum
<didrocks> it should
<Laney> yeah it's SSOing me too
<didrocks> maybe the move to prodstack prevented that? It seems to forcingly forces me to log in
<didrocks> I guess I'll have to file an IS RT for investigating
<cjwatson> is it just "you have to log in with SSO but then anyone can see it"?
<Daviey> No, i did the logout+login dance
<Daviey> Still apache SSO blocked
<didrocks> I'll have a look, cant' right now, but I'll follow up with #webops
<didrocks> the canonistack instance wasn't forcing you to log in
<Daviey> didrocks: thanks
<Laney> Doing source packages through CI is quite new, and I'm not sure what the governance there is meant to look like
<Laney> Interesting
<Daviey> Well, I was looking for a responsible name of someone that virtually sponsored it, ie - requested but not signed.
<cjwatson> yeah, in this case the answer is Mirv
<Laney> But that set of people is not the same as the set of uploaders of the package, and now any package can be uploaded through this process
<Laney> The people who can upload to the PPAs in the first place is a different team too (~ci-train-ppa-service)
<Daviey> cjwatson: Sorry to labour this... but unless I am mistaken, Mirv doesn't have upload access to this package - how can he sponsor it?
<cjwatson> the landing procedures require a core-dev ack for anything that's a substantive packaging change
<cjwatson> otherwise I suggest you look through the diff and decide whether you're happy with it
<Daviey> cjwatson: How is substantive defined, and is there an audit history of which core-dev ack'd it?
<cjwatson> don't ask me
<cjwatson> I just do my best with this stuff, I didn't set any of it up :)
<cjwatson> the diff is 104 lines here so seems pretty straightforward to review
<Daviey> cjwatson: Oh, Sorry I wasn't waving a finger.. I appreciate that. :)
<Laney> how> The CI train generates a request which is executed by a script with Ubuntu Archive Robot's credentials
<Daviey> cjwatson: Right.. No problem with the diff... But I feel uncomfortable reviewing stuff without the backstory, i suppose.  The audit history.
<Laney> So what you need are the right permissions to generate those requests
<cjwatson> right, it's delegated; anything that goes through the ci-train stuff has been built everywhere, run through autopilot tests, and manually tested on a device, aiui
<cjwatson> I certainly agree that it's pretty cumbersome to dig up the audit trail right now ...
<zyga> stgraber: thanks, I see, where can I monitor th4e queue?
<stgraber> zyga: https://launchpad.net/ubuntu/trusty/+queue
<stgraber> look for the Unapproved queue
 * zyga sees versiontools and is quite surprised
<cjwatson> I could use reviews of attr and grub-installer since those both have other changes I need to land behind them
<cjwatson> seb128: I'm having trouble seeing how this language-selector upload relates to bug 1008344.  Was that a typo?
<ubot2> Launchpad bug 1008344 in language-selector (Ubuntu) "checks "admin" group membership instead of querying polkit" [Medium,Triaged] https://launchpad.net/bugs/1008344
<seb128> cjwatson, yes, sorry, I had both bugs in tabs :/
<seb128> it's bug #1165626
<ubot2> Launchpad bug 1165626 in language-selector (Ubuntu) "Details pane is dysfunctionally small in package installation prompt." [Low,Triaged] https://launchpad.net/bugs/1165626
<seb128> cjwatson, I can reupload if you want
<cjwatson> yes please, I'll reject this one
<Daviey> smoser: This will not affect curtin http://launchpadlibrarian.net/172345441/grub-installer_1.78ubuntu19_1.78ubuntu20.diff.gz ?
<smoser> Daviey, i dont think so .
<cjwatson> curtin would probably be broken if it did - if you don't have an EFI System Partition then grub-efi won't work
<cjwatson> unless some arcane detail has leaked out the back of my head :)
<smoser> cjwatson, when does that code run ?
<cjwatson> smoser: in the installer phase that installs the boot loader (i.e. well after partitioning)
<smoser> should be fine then.
<xnox> excellent a quick php upload just before release =)
<jdstrand> hey, so we have an oxide upload in https://launchpad.net/~ubuntu-security-proposed/+archive/ppa/+packages that is need to fix issues on touch, add file picking support (required for touch and webapp-container parity on desktop), along with bug fixes
<jdstrand> oxide is in main now and technically this is adding features, but this is all part of the FFe imo (ie, it is for feature parity)
<jdstrand> can someone from the release team review/ack. at that point I will coordinate with citrain
 * jdstrand -> reboots real quick
 * jdstrand back
<infinity> slangasek: +MANIFEST-NETBOOT_DIR = "PXE boot directory for tftp server"
<infinity> slangasek: Didn't you just break your own rule there? :)
<xnox> =))))
<infinity> jdstrand: If it's well-tested in any context that applies to desktop, go for it.
<jdstrand> infinity: it is undergoing said testing and won't be pushed until it is completed. thanks!
<seb128> cjwatson, ^ with right bug ref this time, thanks for spotting it ;-)
<slangasek> infinity: sighhhh.  Cut'n'paste error :(
<infinity> slangasek: Well, given the lack of pxelinux.cfg, I'd call that a complete lie.  Want to reject and fix the manifest?
<slangasek> infinity: yeah, reuploaded
<slangasek> infinity: ^^ new debian-installer in the queue
<ScottK> Who's the release POC for Ubuntu Studio these days?
<stgraber> zequence: ^
<ScottK> Thanks.
<ScottK> zequence: I'd like your opinion on bug 1291675 (please comment in the bug too).
<ubot2> Launchpad bug 1291675 in lmms (Ubuntu) "[FFe] LMMS 1.0.0" [Wishlist,New] https://launchpad.net/bugs/1291675
<tjaalton> stgraber: hey, could you accept sssd 1.11.5 from the queue, it has MRE and all :)
<stgraber> yeah, I'll take a look in a tiny bit
<tjaalton> thx
<tjaalton> modified the upstart job too
<stgraber> oh, yay for the upstart job!
<tjaalton> the failure was easy to test, like when my local ipa server is down the ipa backend on the client fails to start
<stgraber> I've been hitting that problem quite a few times this week with boxes that are provisioned through a configuration manager (sssd starts before the machine is joined)
<tjaalton> so sssd is running, but not doing much
<tjaalton> stopping it will fail
<tjaalton> yeah this should finally fix that..
<tjaalton> I should probably reply to the folks who complained about this on sssd-users@..
<tjaalton> long ago
<stgraber> ok, upstream changelog seems fine and packaging changes too, accepted
<tjaalton> great
<zequence> ScottK: Yep. I'll give it a testrun shortly.
<ScottK> Thanks.
<kirkland> can someone please push pollinate through?  this upload is required to enable pollinate to handle the new ssl certs, per the heartbleed ssl fixes
<stgraber> kirkland: unseeded packages are auto-accepted
<marrusl> Hi folks.  I was wondering if someone can look at nvidia-grpahics-drivers-331-updates in the precise queue (in new).   this update is required for compat with 3.13 and it's blocking for people wanting to test the trusty backport kernel early.  thanks!
<novel> Good day for all!, i am searching for ubuntu studio 10.4, but i cant find it, can any body give me an advice.
<novel> were can i download it?
<stgraber> tjaalton: around?
<stgraber> tjaalton: I have a few systems where sssd now crashes since the upgrade...
<tjaalton> stgraber: gah..
<stgraber> tjaalton: oh, one obvious mistakes at least, s/-f/-i/
<stgraber> I should have caught that one in my review...
<tjaalton> where was that?
<tjaalton> the upstart job?
<stgraber> yeah
<stgraber> well, the default file
<stgraber> but even with that one fixed, authentication is broken
<tjaalton> it worked for me without -i
<tjaalton> err
<stgraber> (Wed Apr  9 20:34:06 2014) [sssd] [mt_svc_exit_handler] (0x0040): Child [SAMBA] terminated with signal [11]
<stgraber> (Wed Apr  9 20:34:06 2014) [sssd] [mt_svc_exit_handler] (0x0010): Process [SAMBA], definitely stopped!
<tjaalton> so I have -f, it just means send debug to logfiles
<stgraber> right, it won't guarantee sssd will stay in the foreground
<stgraber> just did a quick check and sssd died post-upgrade on all of my 50 or so trusty systems
<stgraber> so I effectively can't login to any of them without some hacks
<tjaalton> ouch..
<tjaalton> so much for upstream qa.. this was supposed to be all bugfixes in the ad backend
<stgraber> I'm trying to get one of my machines to give me a .crash file
<stgraber> got one from an arm box, trying to get it sent to LP
<stgraber> oh and LP isn't IPv6 yet so I can't submit the report...
<tjaalton> :/
<tjaalton> pinged upstream as you probably noticed
<stgraber> tjaalton: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1305303
<ubot2> stgraber: Error: launchpad bug 1305303 not found
<tjaalton> thanks
<stgraber> let's hope the retracers will get us a stacktrace soon
<tjaalton> should the link work already?
<stgraber> yeah, but it's private
<stgraber> added you to it now
<tjaalton> ah
<stgraber> I'm trying to find a machine I can still log into to do a manual retrace
<ScottK> Riddell: ^^^ please review/approve.
<ScottK> (penance for forgetting to update bzr after your last upload, if nothing else)
<stgraber> tjaalton: http://paste.ubuntu.com/7228102/
<tjaalton> hmm did you use the ldap backend or ad?
<tjaalton> and mind posting that on #sssd too..
<stgraber> tjaalton: http://paste.ubuntu.com/7228110/
<tjaalton> ok, sort of a hybrid then as i remembered :)
<tjaalton> seems to work fine on my ipa client :/
<tjaalton> which is a simple setup, admitted
<stgraber> tjaalton: I'll upload the old sssd to my PPA for now with an higher version number, so that my systems start working again. If we don't get a resolution for this by final freeze time tomorrow, I'll push it to the archive too.
<tjaalton> stgraber: that's fine
<tjaalton> I'm out of cycles for today, so you're probably better off working directly with sgallagh on this.. I'll check the scrollback in the morning
<stgraber> tjaalton: ok. I just uploaded my revert to my PPA, will keep one container broken on purpose for testing
<tjaalton> stgraber: i just realized that they don't test against samba4, since fedora/rhel doesn't have dc functionality for it
<tjaalton> since they're mit-krb only
<jdstrand> fyi, oxide-qt should be coming in here soon. it was discussed earlier and is tested, passed citrain, etc
<jdstrand> I will be afk for a while
<stgraber> tjaalton: yeah, that's why things always blow up for me ;)
<tjaalton> :)
<tjaalton> i'll remember to ask you test stuff _before_ the fan gets smelly
<jdstrand> btw, oxide-qt has two NEW packages. oxideqt-codecs for main and oxide-codecs-extra for universe
<jdstrand> I can handle that later if needed
 * jdstrand is really gone now
 * cjwatson tries to sneak a >300000-line diff in before final freeze
<cjwatson> <joeyh> debconf-updatepo... also known as "I'm feeling unproductive today.
<cjwatson>         Please give me a huge diff to check in"
<stgraber> tjaalton: ok, so that patch seems to do the trick, now I'm just trying to figure out the upstart problem.
<stgraber> tjaalton: so on your system. If you do "status sssd" it reports it as running with the right pid?
<tjaalton> hum no :)
<stgraber> right, so we have a problem there :)
<stgraber> and -i doesn't improve things for some weird reason...
<tjaalton> right
<stgraber> oh, I think I see why
<stgraber> try: sssd -i < /dev/null
<stgraber> it'll fail immediately
<tjaalton> yep
<stgraber> I've got a fix
<stgraber> tjaalton: I'll upload the patch and the upstart fix to the archive now
<tjaalton> sure, thanks
<tjaalton> push to git too :)
<stgraber> yep, will do
<cyphermox> stgraber: hey, could you please review mtp?
<cyphermox> nevermind, I fail at reading
<stgraber> tjaalton: http://paste.ubuntu.com/7228326/
<tjaalton> stgraber: 'stding', a typo?
<stgraber> typo indeed, let me fix that quickly
<tjaalton> yep, works fine now
<tjaalton> a peculiar looking fix though :)
<stgraber> slangasek, infinity, ScottK: if one of you is around, could you review sssd in the queue? anyone who like me is using samba4 currently can't authenticate because of that bug...
<stgraber> tjaalton: one could certainly argue that the bug is upstream and that sssd should deal with stdin being /dev/null, but whatever, easy enough to make it happy :)
<tjaalton> didn't know daemons get passed input like that
<ScottK> stgraber: Done
<bdmurray> slangasek: Could we release the SRU fixing bug 1286161 early?
<ubot2> Launchpad bug 1286161 in ubuntu-release-upgrader (Ubuntu Trusty) "13.10 -> 14.04 upgrade failed: initramfs failed to ugprade, udev is not configured yet" [High,In progress] https://launchpad.net/bugs/1286161
<Laney> speaking of, we should get that gdk-pixbuf sru verified
<Laney> that could possibly cause upgrade failures
 * Laney notes down for tomorrow
<stgraber> ScottK: thanks
<seb128> Laney, btw your bamf fix is in the unapproved queue
<Laney> excellent
<Laney> I'm sure one of these kind fellows will look at it in due course
<rsalveti> slangasek: ^ qtbase-opensource-src
<stgraber> tjaalton: ok, I think I pushed things to alioth properly. I pushed everything in debian-unstable first, added an UNRELEASED changelog entry there, then merged that into the ubuntu branch, did a proper merge of the changelog and committed the result.
<tjaalton> stgraber: yup, sounds good
<gaughen> Would someone pretty, pretty please review the FFe for python-seamicroclient - https://bugs.launchpad.net/ubuntu/+source/python-seamicroclient/+bug/1305220
<ubot2> Launchpad bug 1305220 in python-seamicroclient (Ubuntu) "FFE: python-seamicroclient new upstream release" [Critical,New]
<roaksoax> and can please some review MAAS upload? it is just important bugfixes
<robru> hello, just wondering if somebody can take a look at account-plugins in UNAPPROVED. it has an important facebook app token update, all facebook-connected apps are broken without it
#ubuntu-release 2014-04-10
<stgraber> tjaalton: so the sssd upstart fix ends up taking 100% of CPU... I found an alternative that seems safe, will upload that now...
<jdstrand> can someone also look at oxide-qt? it was approved earlier
<jdstrand> if you tell me to just do it, I can myself
<cjwatson> I don't suppose there's any chance of bug 1297804 being approved?
<ubot2> Launchpad bug 1297804 in libpipeline (Ubuntu) "FFe: libpipeline 1.3.0" [Wishlist,New] https://launchpad.net/bugs/1297804
<stgraber> cjwatson: approved
<cjwatson> oh, that was quick, thanks :)
<infinity> stgraber: That sssd exec is icky...
<stgraber> infinity: does the trick, though I agree that upstream is just buggy there and should be fixed to not fail or eat all your CPU when using a sane stdin...
<infinity> stgraber: Why not just start it with -D and expect fork?
<infinity> Or expect daemon.
<infinity> Whatever.
<stgraber> infinity: because sssd is also buggy in that case
<infinity> stgraber: Err, srsly?
<stgraber> infinity: as in, it'll daemonize before it's done parsing your config
<stgraber> so if your config isn't valid, it daemonized, then exits before the second fork, confusing the hell out of upstart in the process
<stgraber> and you end up with upstart thinking it's running when it's not, with the only solution to fix the state being a reboot of the system
<infinity> stgraber: util/server.c seems to imply and attempt to make that not happen. :/
<stgraber> clearly failing :)
<infinity> Bleh.
<infinity> Seems like it would be worth fixing correctly instead of working around weirdly.
<stgraber> setup sssd to use a krb5 ticket to authenticate, forget to setup said ticket before starting sssd => boom, upstart thinks it's running but sssd exitted
<stgraber> totally agree that having sssd be a bit more sane when running in either foreground or background would be nice, though it's not something I have much time to debug and resolve properly right now, so the hackish upstart job at least does the trick and make things work reliably
<stgraber> (sssd basically spawns 5-6 sub-daemons, all of which read their part of the config, failure from any of those may cause the main daemon to exit. So making sure that the daemonizing case is sane may be a bit challenging...)
<infinity> Wow, it actually scans stdin.  That explains why /dev/zero drove it nuts.
<infinity> And it reads an EOF as an explicit kill.
<infinity> WHO WRITES SOFTWARE LIKE THIS.
<cjwatson> Running stuff in the foreground is generally the right answer with modern inits anyway ...
<infinity> cjwatson: It is when it's not written by nutters.
<cjwatson> Well yes
<infinity> stgraber: With /dev/null as stdin, did you get "EOF on stdin - terminating"?
<infinity> Oh, FFS, how do I configure this to run it? :P
<infinity> stgraber: Erm.  So, I can't make it die with "sssd < /dev/null" ...
<infinity> Oh, maybe -D is the default.
<infinity> Indeed it is.
<infinity> stgraber: http://paste.ubuntu.com/7228797/
<infinity> stgraber: That makes it stop doing Very Stupid Things with stdin, and </dev/null works again.
<jdstrand> infinity: hey, shall I approve oxide-qt-- it got the testing and is in unapproved. I'm happy to have someone else do it too of course
<stgraber> infinity: well, the question then is whether there's a case where something spawns sssd and actually wants to feed it stuff on stdin or kill it by closing it
<infinity> jdstrand: Is it identical to what I reviewed in your PPA before?
<jdstrand> yep
<stgraber> infinity: that'd seem pretty unlikely, but upstream did write those lines and the stdin handler for some reason after all...
<jdstrand> bit for bit
<infinity> jdstrand: Then go nuts.
<jdstrand> thanks! :)
<jdstrand> (it was just a binary pocket copy)
<infinity> stgraber: I'd guess it's for debugging.  Not even the testsuite uses it, can't fathom why a user would.
<infinity> stgraber: Besides, Ctrl-C still works.
<infinity> stgraber: Take it or leave it.  If you think the mangled upstart job is better, I can confirm that also works, I just think it's awful. :P
<stgraber> infinity: so I think I'd rather stay away from distro changes to the upstream code at this point and bring this upstream, then hopefully the next point release will contain their fix and we can use that and drop the upstart job hack
<stgraber> though tjaalton is the one who does most of the work on sssd in Debian/Ubuntu so he may have a different opinion
<infinity> tjaalton: ^
<infinity> stgraber: Does either of you have a good relationship with upstream?
<infinity> (Given that upstream seems to be very Fedora-centric, I can't see how this hasn't also been an issue with systemd... Does systemd play differently with FDs by default?)
<stgraber> yeah, we have a pretty good relationship with upstream and they tend to be pretty quick at fixing issues (like that samba4 crash we reported and got fixed within the hour earlier today)
<infinity> stgraber: So, I think they should fix their buggy -D implementation, but I imagine that will take Serious Thought(tm).  But making -i not bugger stdin should be trivial.
<infinity> stgraber: And I can honestly see no reason why it does, except for debugging convenience.
<infinity> But.. *shrug*
<infinity> stgraber: I'll accept your upstart job fix for now, I confirmed that it works.  I'm just going to register my formal grumpiness with it being poop. ;)
<stgraber> infinity: I'll file an upstream bug report now so I can forward your grumpiness where it belongs ;)
<infinity> Okay, based on commit messages, looks like they're using -D under systemd, which would be why this weird -i behaviour isn't biting them.
<infinity> And it could just be luck of job timing that they're not seeing the bug you do with -D.
<stgraber> bug filed upstream
 * infinity washes his hands of it.
<slangasek> bdmurray: yeah, early release of 1286161 seems ok to me
<slangasek> hmm, was qtbase-opensource-src auto-accepted, or did someone else review that?
<cjwatson> I think I accepted the symbols changes
<cjwatson> well, not the gles thing if that's been uploaded
<cjwatson> the previous change
<slangasek> stgraber: do you know why the logind upstart job is in a Multi-Arch: same pam package instead of in systemd-services - and why the service doesn't get started on install?
<slangasek> stgraber: I ask because I happened to have my system in a state affected by bug #1302264 and found myself needing to reboot... NM was unhappy :P
<ubot2> Launchpad bug 1302264 in systemd (Ubuntu) "systemd-logind assert failure: error.c:319: Assertion failed in nih_error_get: context_stack != NULL" [Critical,Fix released] https://launchpad.net/bugs/1302264
<slangasek> cjwatson: ah, ok - yeah, it's only the gl side that's been uploaded for now
<stgraber> slangasek: I don't know why the packaging was made this way... pitti may know.
<slangasek> ok
<slangasek> the first part seems to have been bug #1156074
<ubot2> Launchpad bug 1156074 in systemd (Ubuntu Raring) "installing systemd-services without libpam-systemd loses device ACLs" [High,Fix released] https://launchpad.net/bugs/1156074
<slangasek> the second part is a bug introduced in saucy when trying to avoid restarting logind on upgrades
<rsalveti> slangasek: ^ for qtdeclarative
<slangasek> rsalveti: so libqt5quick5's exported ABI doesn't change with the gles switch, but two variants need to be built because it will depend on GL-specific symbols when built against it?
<slangasek> (just confirming that my understanding of the patch matches your intent)(
<rsalveti> slangasek: 2 things, it'll depend on gl directly and will also depend on the packages built with gl by default, but they export the same abi
<slangasek> ok
<slangasek> accepting
<rsalveti> one thing we need to better investigate later is what to do when a package depends on a common set of gl/gles symbols
<rsalveti> I know in linaro we had a small library that could do runtime detection and decide gl/gles in runtime
<rsalveti> but not so sure why nobody put a lot of more effort on that
<slangasek> because glue libraries are messy :-)
<rsalveti> but in this qt case, we might just follow directly with qt upstream, as they are doing a similar check in trunk (but currently just on windows)
<rsalveti> yeah :-)
<tjaalton> stgraber, infinity: heh, so it wasn't just the old upstart job that was buggy.. good to know. And I'm fine with the current workaround
 * infinity curses component-mismatches trying to yank random universe kernels in again.
<seb128> hey release
<seb128> could somebody review bamf/compiz/nux in the queue?
<dbarth> good morning, so today i'm trying to land a few things:
<dbarth> account-plugins
<dbarth> webbrowser-app
<dbarth> and libunity-webapps and related (they come from silo 8)
<seb128> Laney, so, nobody reviewed that bamf changes during the night :/
<Laney> I imagine it'll get cleared out before final freeze
 * Laney will look at other things now
<seb128> k, fair enough
<sil2100> seb128: I see compiz, nux and bamf still in the queue - any hope those will move out of UNAPPROVED soon? :)
<seb128> sil2100, I do as well
<seb128> I pinged about that earlier
<seb128> seems like the US team didn't get to those during their shift, let's see if the europeans do
<sil2100> o/ Thanks
<seb128> stgraber, infinity, slangasek; did you guys reviewed the queue during your day/kept those on hold for a reason, or it's just that nobody has slots for reviews?
<infinity> seb128: Did some, but not many.  I'll do a few more before I head to bed.
<infinity> seb128: Hard freeze tomorrow (well, tomorrow for me) anyway, so it should slow down after that. :P
<seb128> infinity, thanks ... and yeah, "should", I don't see that really happening though
<seb128> well, a part of the uploads is going to turn into SRU
<seb128> but I can see a steady flow of SRUs between release and .1
<infinity> Inevitably, yeah.  Seems to be the way with LTSes.
<maclin> slangasekï¼hiï¼ I am maclin from Ubuntu Kylin.  I have push new source code of software center to launchpad. All the problems you found have been modified except python2. Could you help to review it?
<JackYu> slangasek, maclin means the FFe bug #1293299.
<ubot2> Launchpad bug 1293299 in Ubuntu Kylin "[FFe]upload ubuntu-kylin-software-center into archive" [High,Confirmed] https://launchpad.net/bugs/1293299
<seb128> sil2100, ^ things got accepted, we should have some silos we can m&c in the next publisher runs
<seb128> (thanks to whoever did the reviews btw!)
<cjwatson> yw
<cjwatson> would be nice if somebody could review libpipeline (it has an approved ffe now) so that I can sync man-db
<Laney> ha, gexiv2 was what I was referring to in #ubuntu-devel
<cjwatson> oh, whoops
<cjwatson> sorry
<cjwatson> I was motivated by seeing several things in p-m that were blocked on it ...
<Laney> never mind, fixable
<cjwatson> it'll hit NEW anyway, so you have a chance :)
 * cjwatson suppresses his "auto-NEW stuff from Debian" twitch
<sil2100> \o/
<sil2100> Thanks guys!
<sil2100> Can't wait for those to migrate out of proposed ;)
<cjwatson> libpipeline> thanks
 * infinity tips hat.
 * infinity falls asleep in hat.
<infinity> ^-- Can someone do a quick review of that flash-kernel?
<infinity> I'm told it's tested to DTRT, and I verified the strings are correct.
<cjwatson> infinity: LGTM
<Riddell> possible kde-l10n spam ahead
<doko> jibel, pitti: https://jenkins.qa.ubuntu.com/job/trusty-adt-python3.4-armhf/22/?  looks like the armhf test is run too early. the armhf build is not yet available as you can see from the log
<jibel> doko, it's possible, armhf are triggered when x86 tests pass. I'll restart it.
<jibel> (when the build is available)
<doko> need to fix the aarch64 build anyway
<jpds> Can someone please poke ima-evm-utils through NEW?
<jamespage> could the neutron upload in proposed be rejected please - I missed a bit
<infinity> jamespage: Done.
<jamespage> infinity, thanks
<didrocks> Laney: sorry to nag you, we have a regression fix from today's landing in webbrowser-app which is really needed for next image
<didrocks> Laney: it should be easy enough to review :)
<didrocks> https://code.launchpad.net/~dbarth/webbrowser-app/notitle/+merge/215166
<didrocks> (and there is a new unity8 coming which will need a bump in the fauxpackage)
<Laney> didrocks: ok, sec
<didrocks> thanks man :)
<didrocks> Laney: lost in space and time? :p
<Laney> have patience my child
<didrocks> thanks Laney
<Laney> np!
<bdmurray> slangasek: did you want to release ubuntu-release-upgrader to saucy-updates or shall I?
<slangasek> bdmurray: please go ahead
<jamespage> infinity, neutron with missing bits included now in the queue
<infinity> jamespage: I assume that means you added bits, not that more are missing? :P
<jamespage> infinity, I did indeed add the missing bits :-)
<zequence> Any core-dev around, that could lend us some upload rights? Bug 1291675
<ubot2> Launchpad bug 1291675 in lmms (Ubuntu) "[FFe] LMMS 1.0.0" [Wishlist,Triaged] https://launchpad.net/bugs/1291675
<zequence> This package has some major improvements to the released one. Has been tested and is pretty much ready to go.
<infinity> zequence: Wasn't ScottK asking you about that last night?
<zequence> infinity: Yep. He approved it as a FFe. There was a repackaging since
<Laney> I probably ought not to review gnome-screensaver since it's my own
<Laney> Would appreciate it being looked at
<cjwatson> accepted gnome-screensaver
<Laney> Cheers
<Laney> happy mostly working lockscreen
<cjwatson> that fixes the double-lock?
<Laney> unity mainly, but that has a hand
<Laney> It takes over the D-Bus interface from gnome-screensaver, but g-s needed patching to allow itself to be replaced on the bus
<Laney> (Which is quite a neat facility in D-Bus that I wasn't familiar with)
<cjwatson> right
<slangasek> maclin, JackYu: is someone taking care of sponsoring ubuntu-kylin-software-center?  I doubt I will have time to review it today, the best thing is to get it uploaded and get it reviewed by whoever's available at the time
<slangasek> roaksoax: why is bug #1294323 private?  public bugs only for FFes, please
<JackYu> slangasek, hi, we don't have the rights to upload it.
<JackYu> slangasek, and neither happyaron...
<slangasek> JackYu: understood; so you don't have any sponsor lined up for this?
<JackYu> slangasek, yep, that's the situation:(
<slangasek> ok
<slangasek> let me see what I can do about that
<JackYu> slangasek, great, thanks.
<JackYu> slangasek, we are waiting for ubuntu-kylin-software-center and ubuntukylin-keyring being uploaded. Then we could upgrade the ubuntukylin-default-settings, so that these two packages would be included into the distribution.
<slangasek> JackYu: right.  I've uploaded ubuntukylin-keyring, it's in the NEW queue now and should get review from another archive admin
<slangasek> infinity: ^^ could you slot that in maybe?
<infinity> Phrasing.
<infinity> slangasek: So, this is the keyring with the agreed-upon generated-by-IS key?
<slangasek> infinity: that's what I'm claiming
<infinity> slangasek: Can I independently validate this key in the DC somewhere?
<roaksoax> slangasek: yeah I filed a different public bug
<slangasek> infinity: you can check it against the RT
<slangasek> infinity: RT #69080
<infinity> slangasek: Ta.
<infinity> slangasek: Is this just a cargo-cult of ubuntu-keyring?
<slangasek> infinity: yes, as noted in the linked FFe bug
<infinity> Oh, who reads bugs?
<infinity> slangasek: I was just going to whine about the lack of build-* targets, but if it's derived, I don't much care.  debdiffing against ubuntu-keyring to see how close they are.
<infinity> slangasek: Is it expected that installing this keyring makes apt trust it, or will an installer mangle that?
<slangasek> infinity: isn't that what the postinst does? (apt-key update)
<infinity> slangasek: You'd think.
<infinity> slangasek: Maybe it doesn't like ascii armored keys and wants an actual keyring?
<slangasek> JackYu: xnox is reviewing ubuntu-kylin-software-center now for sponsorship
<slangasek> infinity: ah; I would think that and did think that, but did not in fact test it
<JackYu> slangasek, xnox, thanks. maclin and I are here waiting for your questions:).
<xnox> JackYu: so far it's ok, one minor dependency is missing which i'll fix up before uploading.
<xnox> JackYu: and i'm writting up review comments on the bug report.
<xnox> JackYu: no blocking issues found yet, but i'm not done reviewing.
<Saviq> who do I bribe to push unity8 through to release? ;)
<xnox> Saviq: as per topic "we accept payment in cash, check or beer" and https://launchpad.net/~ubuntu-release/+members#active for the list of people
<infinity> Saviq: I'll sort it.
<Saviq> infinity, awesome, thanks, infinity.beer++
<JackYu> xnox, got it.
<infinity> I'll take a raincheck on the beer.
<apw> the xen and libvirt combination are best viewed together and are a fix for the migration of machine definitions on upgrade
<JackYu> xnox, sorry for my bad understanding, you mean you will upload it now and review it later, or you just upload it and we should find another sponsor to review it?
<slangasek> JackYu: he is reviewing and once he is done reviewing, if there are no blocking problems, he will upload
<JackYu> slangasek, ah:).
<infinity> slangasek: Okay, so.  Two things.  It does seem to want to be a gpgp keyring, not an ascii art masterpiece.  But, also, I can't seem to get apt-key update to add it to trusted.gpg.  I *think* it only looks at archive.gpg
<infinity> slangasek: Shipping it in /etc/apt/trusted.gpg.d/ubuntukylin-archive-keyring.gpg works, though.
<infinity> slangasek: So, perhaps a symlink in postinst from /etc/apt/trusted.gpg.d/ubuntukylin-archive-keyring.gpg to /usr/share, and skip the other bits?
<slangasek> infinity: ok.  Since you've looked at this and understand what's needed, do you want to reject, change, and bounce it back in my direction for counter-review, or do you want me to fix it up and resubmit?
<infinity> slangasek: Sure, I can do that.
<slangasek> infinity: do you intend to generate the binary keyring at build time, OOI?
<infinity> slangasek: We don't seem to for ubuntu-keyring.
<slangasek> infinity: yeah; I would argue that this is a bug in ubuntu-keyring too :)
<infinity> slangasek: Perhaps, yeah.  But I'm not sure it's one I want to fix this instant.
<infinity> slangasek: We can do both together some day.
<slangasek> yep
<infinity> slangasek: Not like an .asc is really any more readable than a .gpg, it's just more vi-friendly.
<slangasek> just makes it a little harder for me to review and make sure you're not MITMing me ;)
<cjwatson> grub2 won't be until early tomorrow morning I suspect, by the time I've built this, uploaded to Debian, and synced
<cjwatson> The grub2 patch will be http://paste.ubuntu.com/7231546/ unless something goes horribly wrong for some reason
<cjwatson> I guess I could hack the .changes and upload the exact same thing to Ubuntu if people think I should
<cjwatson> Would be nicer to have the proper audit trail though
<infinity> cjwatson: Letting the sync happen $later seems fine.
<slangasek> I think it's unfortunate that the better we do at keeping things in sync with Debian, the slower it makes our updates in Ubuntu during critical times
<slangasek> considering Debian was discussing reducing dinstall back down to daily, we should probably think about getting better syncing support from incoming
<cjwatson> Yes, I agree on that
<infinity> To sync securely from incoming, all we need is access to the buildd repo.
<cjwatson> Incoming is signed these days, isn't it?
<infinity> We probably just have to ask nicely, and retool the LP sync stuff.
<infinity> cjwatson: incoming isn't, but incoming/buildd is.
<cjwatson> Oh, right
<cjwatson> Dunno if it would need that much retooling, it could just be another suite?
<infinity> slangasek: Okay, try that one on for size.
<cjwatson> I assume incoming/buildd is only private so that the world doesn't add it to their apt sources
<slangasek> infinity: I have a call now, it'll be a couple hours before I can look at it - is that ok?
<infinity> slangasek: Doesn't bug me.
<infinity> cjwatson: Yeah, pretty sure that was the reasoning.  And so we could unaccept if really, really necessary.
<infinity> cjwatson: But I don't think the unaccept case matters for Ubuntu syncing, we'd just sync a newer version in that strange case.
<infinity> (or revert manually, or whatever)
<cjwatson> Right, so auto-sync should still work off unstable, and we could shove it into Debian/incoming and people could use syncpackage -d incoming if they're in a rush
<infinity> cjwatson: Yeah, that seems ideal to me.
<cjwatson> gina will do its usual tracking of what's in what suites without much trouble AFAICS
<cjwatson> wgrant: ^- any qualms with the above?  otherwise I can go ask ftpmaster
<infinity> cjwatson: Assuming we poll something not too unfriendly, I can't see that they'd mind.  I hope.
<cjwatson> I was thinking hourly
<infinity> cjwatson: (And, really, buildds hit those Packages/Sources files constantly, one more buildd-like machine only hitting Sources.gz every 15-60m or something would be nothing)
<infinity> The queue runs every 15 or 20, doesn't it?
<infinity> I always forget.
<cjwatson> And it'd be debmirror, but could be debmirror over HTTP if buildds don't get rsync
<cjwatson> Not sure
<infinity> cjwatson: Well, we could check a cached Sources for freshness, then trigger a mirror, I assume.
<infinity> Though, I imagine debmirror has such a facility anyway.
<cjwatson> debmirror fetches Packages/Sources and only grabs what it doesn't have
 * infinity nods.
<infinity> And we only want Sources, so just that.
<cjwatson> Er right
<cjwatson> So --arch=none
<infinity> If we could get a push trigger, that would be even better, but I won't push my luck.  A shortish poll would still be way ahead of our current situation.
<infinity> And unless they've gone high tech since I ran a Debian buildd, if we want to do polling, it's literally just them generating a u/p pair for us in htaccess and letting us loose.
<cjwatson> Could just ask what's reasonable, indeed.
<infinity> Possibly also IP limited, now that DSA demands buildds not be on sketchy cable modems. :P
<xnox> slangasek: JackYu: given the time constraints I have sponsored the package, with a few changes which are proposed for merging back into trunk at https://code.launchpad.net/~xnox/ubuntu-kylin-software-center/14.04-release/+merge/215258
<infinity> Ahh, phew.  "Good" news.  That testsuite regression on POWER8 isn't a regression.  Breaks in the old version too.
<JackYu> xnox, got it, thanks.
<apw> Laney, whoopsie-preferences as requested
<Laney> fanx
<JackYu> xnox, since it is in the NEW queue already, should I request another sponsor to review and accept it?
<infinity> JackYu: We'll get to it.
<JackYu> infinity, wow, great!
<Laney> apw: Soz, LP's having a little nap and now I've got to go
<Laney> Someone else'll probably get to it
<apw> yep, np
<Laney> or me if I come back on later
<Laney> see you
<jamespage> please could the neutron upload for trusty be accepted - I'd quite like to cycle that through our test lab with the rest of the rc packages today
<infinity> slangasek: In light of your previous verbal agreement on pulling the IBM branch, can you review the above? ^^
<infinity> slangasek: It was tested in a PPA on all arches and then independently on POWER8 as well.
<slangasek> infinity: will queuediff eventually give me a diff for that or do I need to download the whole schleblottle?
<infinity> slangasek: I see a diff in the queue...
<infinity> slangasek: Missing -Q unapproved?
<slangasek> infinity: queuediff doesn't take a -Q
<slangasek> infinity: ok, diff has shown up now
<infinity> cjwatson: Is https://bugs.launchpad.net/maas/+bug/1306164 relevant to partman as well?
<ubot2> Launchpad bug 1306164 in MAAS "MAAS fast-path EFI install creates ESP that's too small" [Critical,Fix committed]
<rsalveti> slangasek: ^ another simple one (qtlocation-opensource-src)
<slangasek> rsalveti: ICMP redirect infinity; I have a few reviews on my plate already
<infinity> ;)
<rsalveti> slangasek: sure np, just a heads up as this is related with the gl/gles topic
<tjaalton> slangasek: I'll reply to the mesa sru email in a bit, but another matter is that I pushed a change to pam adding pam-configs/mkhomedir, disabled by default. it's in bzr
<tjaalton> slangasek: it's not of much use for any automatic setup, since pam-auth-update doesn't know how to enable such configs
<tjaalton> uninteractively, there's a bug for that I'll try fixing soon
<cyphermox> could any archive admin check on the archive machine where the cupstream2distro code runs, to see if it has received a file like "packagelist_rsync_landing-018-trusty" recently?
<cyphermox> ci train publishes don't seem to be working atm
<cyphermox> robru: ^
<cyphermox> I'm currently unable to provide a clearer indication of where this data is supposed to end up though :(
<robru> cyphermox, the two logs showing publication are https://ci-train.ubuntu.com/job/landing-018-2-publish/7/console and https://ci-train.ubuntu.com/job/landing-018-2-publish/8/console
<robru> but that package hasn't shown up anywhere
<robru> cyphermox, also https://ci-train.ubuntu.com/job/landing-019-2-publish/1/console
<robru> basically we're looking for phablet-tools and indicator-keyboard, they should have been published but got lost in the ether
<cjwatson> infinity: people's usual complaint about partman's are that they're too large, so I don't think so
<cjwatson> infinity: partman-auto has the minimum set to 512M
<cjwatson> infinity: although there might be a decimal confusion there ...
<Laney> cyphermox: I guess it's /home/ubuntu-archive/cu2d/incoming on snakefruit, which is empty
<infinity> cjwatson: Oh, if it's already 512M in partman, then this curtin upload matches that.
<cjwatson> infinity: I think we may be using 512MB rather than 512MiB though
<cjwatson> infinity: but don't have time to investigate tonight
<infinity> cjwatson: I think the changelog claimed 100, and I didn't go digging.
<cjwatson> Somebody should check whether we're at least 512MiB rather than just MB.  If nobody else does then I will tomorrow.
<cyphermox> Laney: thanks
<cyphermox> Laney: any idea if something appears to be stuck running there, or something?
<Laney> cyphermox: only vaguely educated guess though ...
<cyphermox> Laney: it seems reasonable anyway
<Laney> sec
<cyphermox> Laney: I'm trying to figure out what part is breaking that makes the packages not get really published, so if there's nothing in the incoming directory (seems the right one) on snakefruit, then maybe the jenkins instance is unsuccessful at pushing the rsync files
<cjwatson> There's eight auto-accepts running, which is kinda odd
<cjwatson> But unrelated
<cyphermox> aye
<Laney> snakefruit pulls the files
<cyphermox> Laney: could you check if maybe the crontab got deleted?
<cyphermox> assuming it's as I expect, a cron job running to do this
<Laney> it did not
<cjwatson> I think LP had a hiccup and a job got stuck
<robru> LP certainly had a hiccup...
<cjwatson> Just checking, please excuse slow network
<Laney> there's an instance of it running
<cjwatson> 20814 17:20:01      \_ /usr/bin/python /home/ubuntu-archive/cu2d/cupstream2distro//copy2distro --no-filter
<cjwatson> elderly
<cyphermox> ah
<cyphermox> could well be that yeah
<cjwatson> I've killed it
<cyphermox> thanks
<robru> cyphermox, so do we have to republish now?
<cyphermox> robru: let's wait, I expect the next run to pick up the files... hopefully
<robru> cyphermox, ok
<cjwatson> please don't republish until we've traced
<cjwatson> unfortunately I'm uploading grub2 over wet string at the same time ...
<cyphermox> cjwatson: in the meantime I'm trying to check which packages we're expecting to see published by citrain that haven't made it yet
<robru> cyphermox, it's phablet-tools and indicator-keyboard
<cjwatson> ha, there, it hadn't pulled because an old job was stuck
<cyphermox> yup
<cjwatson> so kill old job -> next one runs and pulls
<cjwatson> good
<cyphermox> thanks!
<robru> cjwatson, Laney, cyphermox: thanks
<cjwatson> Laney: sorry if I stepped on your toes, I think I took a while to remember that you had access and I was IRC-lagged ...
<cjwatson> (and was half-expecting to have to check the package copy job logs, which are more restricted)
<Laney> No worries, glad it was easy enough to sort out
<infinity> slangasek: Unsure if thorough review or distracted vorlon.
<slangasek> ELUNCH
<slangasek> or maybe that's SIGLUNCH
<slangasek> back now though
<infinity> ELUNCH is so 1998.  It's iLunch now.
<infinity> HAHAHA.  Such a shameless copy and paste that I forgot to change the name/.
 * infinity rejects and resends the u-d-a one.
<Laney> Fix "fozen" too
<infinity> <3 fozen.
<infinity> I'm half asleep.
<infinity> There, slightly less typoey.  My turn for lunch.
<elfy> infinity: aah - good, so we're not releasing Saucy Salamander again then :)
<infinity> elfy: We could try.
<wgrant> cjwatson: That's probably fine.
<infinity> slangasek: Oh, there's also the kylin-keyring there that I ping-ponged back to you.
 * infinity lunches harder.
<slangasek> infinity: yah, am reviewing it now; was just comparing to how other things set up shop under /etc/apt/trusted.gpg.d
 * slangasek gets very confused by the output of 'mk-build-deps' telling him this package has no build-deps
<infinity> slangasek: I'm not sure if there's a precedent here.  There's apt-add-repository which adds keyrings directly to the directory, but that's cause it's only mangling config, not shipping packaged files.
<infinity> slangasek: Shipping in /usr/share and having a non-dpkg-owned symlink felt right to me, since deleting the symlink should be preservable configuration IMO.
<slangasek> infinity: debian-archive-keyring installs files directly under /etc, but I don't /like/ that precedent
<slangasek> infinity: your maintainer scripts aren't set -e
<slangasek> what happens if ln -s fails!
<slangasek> (accepting anyway; you can fix it in postproduction :P)
<slangasek> infinity: if you happen to have a chance to throw a bzr mp at lp:~ubuntukylin-members/ubuntukylin/ubuntukylin-keyring, I'm sure JackYu and maclin would appreciate it
<infinity> Well, now I hope it does fail, just to spite you.
<infinity> slangasek: If by "MP", you mean "commit directly, because core-dev obviously has rights", sure!
<slangasek> infinity: or that
<infinity> Hey neat, did someone just upload firefox in my name? :P
 * infinity was holding off on that to batch up some porting fixes, but... Whatever.
<robru> any chance we could get unity, indicator-session, and webbrowser-app in before the freeze? they're all bugfixes
<robru> (published in citrain earlier today)
 * infinity really wishes the queue told me who signed uploads, it's disconcerting to see uploads from me that arent.
 * slangasek blinks at the linux package in the queue
<infinity> slangasek: You said you wanted half the base system.
<infinity> slangasek: We live to give.
* infinity changed the topic of #ubuntu-release to: Released: Trusty Final Beta | Archive: Final Freeze | Trusty Tahr Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or beer | melior malum quod cognoscis
<cyphermox> infinity: I ship you beer to which address re: this 11-second-late indicator-bluetooth upload? :)
<infinity> Looks like you might owe slangasek a beer.
<cyphermox> indeed
<stgraber> cyphermox: you owe me a beer now, I was the one ignoring the time and clicking accept ;)
<slangasek> yeah, wasn't me
<cyphermox> stgraber: yeah, but I was obvious telling you about it when it showed up here
<cyphermox> stgraber: next lunch at McKibbins ;)
<stgraber> sure :)
<bdmurray> slangasek: shouldn't we disable apport sending crash reports to launchpad now?
<stgraber> 20 minutes ago would have been better, but yes, we should
<bdmurray> I'm sorry I was slow thinking about someone else's thing
<bdmurray> Anyway, shall I upload it?
<Noskcaj> Is https://code.launchpad.net/~noskcaj/ubuntu/trusty/xfburn/bugfixes/+merge/215094 safe to upload? it's a new bugfix release for xfburn
<bdmurray> uploaded apport
<stgraber> Noskcaj: that package is seeded and we are in final freeze, so my guess would be, no
<Noskcaj> ok
<slangasek> bdmurray: hmm, did we never get to the point where we keep whoopsie enabled throughout the cycle but keep launchpad disabled by default throughout the cycle?
<slangasek> this is probably one of those questions I ask every 6 months and then forget the answer
<slangasek> so what's the story with the linux in the queue?  Is that for the first SRU?
<bdmurray> slangasek: there is still a fair bit of development that needs to happen on errors for that to be the case
<slangasek> bdmurray: ok - sounds like something we should talk about immediately after opening unctuous umbrellastand
<gilir> any chances to accept lxsession + lubuntu-default-settings ? They fix some annoying bugs on the lubuntu ISO
<stgraber> gilir: so lubuntu-default-settings seems to introduce a new package, yet I don't see anything depending/recommending it, what's the purpose of this?
<barry> uvular uakari
<gilir> stgraber, it's a new binary to add only on the ISO, it should be only on the seed
<gilir> stgraber, it only adds a .desktop to disable light-locker on the ISO
<stgraber> ok, accepted that one and will binNEW the package to universe when it's built
<infinity> slangasek: No, that's for the archive.
<infinity> slangasek: Just not bothering to accept until all the binaries roll in.
<stgraber> gilir: lxsession is realistically impossible to review because for a bugfix release it's pretty massive. I assume you tested it well before upload?
<gilir> stgraber, thanks
<gilir> stgraber, yes, sorry about this, I tested it during last days and it's working fine
<Riddell> KDE incoming!
<stgraber> gilir: ok, the .vala seems vaguely sane, so I'll accept it
<gilir> stgraber, if it's easier, you can check the git tree directly, it's the last 7 commits : http://git.lxde.org/gitweb/?p=lxde/lxsession.git;a=shortlog
<stgraber> nah, the diff is fine once you ignore all the generated .c files
<stgraber> Riddell: you're aware you're past final freeze right? :)
<stgraber> Riddell: you'll owe us at least one beer per package
<Riddell> stgraber: too late, kde4libs was in before freeze and so the rest must follow
<gilir> stgraber, ok, thanks :-)
<slangasek> gilir: while we're at it, there's a lubuntu-artwork in the queue; I don't understand the changelog entry, there are no bugs listed, and we're at the deadline - what should be done with this?
<slangasek> Riddell: er, how does it follow that they must be accepted because kde4libs was?
<slangasek> infinity: ok, *why* is there a new kernel in the queue, post-kernel-freeze?
<slangasek> infinity: since when are we playing fast and loose with the kernel freeze deadlines?
<infinity> slangasek: You'd have to ask the kernel team why they felt it was appropriate, but it seemed sane enough (well, sane as can be) when I reviewed it, at least.
<gilir> slangasek, it's not critical for the release, just moving a directory in the same binary package (from 1 theme to another), it can be SRUed if you prefer
<slangasek> infinity: but the kernel freeze doesn't just exist for the benefit of the kernel team, revving the kernel also impacts the rest of the team during a critical window (because we have to futz with d-i etc)
<infinity> slangasek: we have to upload d-i anyway, to be fair.
<slangasek> gilir: I don't see how "moving a directory in the package" qualifies under either the SRU or freeze guidelines, maybe you could explain this in terms of user-facing impact?
<slangasek> infinity: oh, do we?  For grub, or?
<infinity> slangasek: eglibc, grub, flash-kernel, kmod...
<slangasek> infinity: heh, ok.
<infinity> slangasek: There've been a fair few udebs changed since the last build.
<infinity> udev...
<stgraber> roaksoax: hey, so you know we're past final freeze right?
<gilir> slangasek, basically, metacity theme is currently in an inherited theme, not the main artwork theme. This commit moves the metacity theme to the main artwork theme, so both themes have the settings available (main and inherited). It's not critical because we don't use metacity by default on lubuntu.
<stgraber> seems to me kinda late to land new maas features
<slangasek> stgraber: there was an FFe request before final freeze, with discussion that took until now to converge on an upload
<stgraber> slangasek: ok
<slangasek> gilir: ok, so if "it's not critical" I would say it's best to reject this and leave it for 14.10 entirely, unless you want to argue otherwise?
<stgraber> slangasek: hmm, the FFe was never acked
<stgraber> slangasek: bug 1305839
<ubot2> Launchpad bug 1305839 in maas (Ubuntu) "FFe: Support for Third Party Driver Installation" [Critical,New] https://launchpad.net/bugs/1305839
<gilir> slangasek, no, I'm fine with rejecting it
<slangasek> gilir: ok, rejecting - thanks
<slangasek> stgraber: not sure if the FFe ack happened outside the bug, but infinity was involved in the discussion
<slangasek> (in fact, he was the one driving the changes required)
<stgraber> slangasek: ok, I'll let infinity deal with the upload then
<jamespage> is anyone in the release team looking at the neutron upload I put in the queue ~8 hrs ago?
<xnox> looks like kubuntu will be bug-free rock-solid by thursday =)
<slangasek> jamespage: I'm looking at it now
<slangasek> xnox: are you cherry-picking bug #1303891 in?
<ubot2> Launchpad bug 1303891 in upstart "new initctl should fallback to old reload signal semantics, if pid1 doesn't export reload dbus method" [High,Triaged] https://launchpad.net/bugs/1303891
<xnox> slangasek: yes, had a volleyball match, now back to complete upstart upload.
<slangasek> xnox: no spiking the packages over the queue
<xnox> =))))))))))))))))))))))))
<xnox> slangasek: i dig what you did there.
<slangasek> jamespage: looking at this neutron upload, I'm concerned you may have some missing Replaces between neutron-common and neutron-*-agent; conffiles have moved between the packages, but neutron-common doesn't Replace the previous owners
<slangasek> jamespage: I've reuploaded neutron with proper breaks/replaces, I think I'd like someone else to review it now before it goes in to make sure I didn't screw anything up
<roaksoax> s
<roaksoax> slangasek: are we good to accept maas too?
<slangasek> tjaalton: yes, I saw your mkhomedir commit, launchpad told me ;)  and yeah, there's no noninteractive way to enable profiles, that's been a longtime request and something it would be great to see fixed
<slangasek> roaksoax: I think we were going to let infinity review maas since he's already familiar with the pending changes
<slangasek> stgraber: if you're around and can review the neutron reupload, I'd appreciate it
<xnox> slangasek: i'm treating all uploads from now on as SRUs, thus requiring bug # references and sru template / test-case in good standing. E.g. would help in case an upload doesn't make into "release" but gets re-diverted to be an SRU.
<xnox> infinity: "final release of Saucy Salamander in a week." looks like it's not just timezone challenged =)))))
<slangasek> xnox: that will certainly make the release team's job easier when reviewing
<JackYu> hi, release team, good morning:)
<xnox> JackYu: i still didn't sleep yet =)
<JackYu> xnox, I see. You are very busy today. Hope you have a nice weekend:)
#ubuntu-release 2014-04-11
<JackYu> xnox, hi, Did ubuntu-kylin-software-client and ubuntukylin-default-settings get accepted? Maybe I miss something from the queuebot:)
<xnox> JackYu: i didn't get email, let me check queue
<JackYu> sorry, ubuntu-kylin-software-center (not client):(
<xnox> JackYu: ubuntu-kylin-software-center is still in the new queue.
<roaksoax> slangasek: sounds good to me! thanks
<JackYu> xnox, oh, thanks.
<slangasek> JackYu, xnox: I'm reviewing ubuntu-kylin-software-center now
<xnox> JackYu: ubuntukylin-default-settings 1.1.4 is in the arhive since 8th of april
<slangasek> xnox: yes, but there's one in unapproved that goes in once uksc is accepted
<JackYu> slangasek, great! It's 8 am here. Our QA team is waiting for the latest ISO:)
<xnox> slangasek: ah, yeah i see it now.
<slangasek> hmm, is archive.ubuntukylin.com:10006 the production port for the service?
<xnox> slangasek: queue names like search thing is not substring based search =(
<JackYu> xnox, slangasek, yep. We will upgrade something in ubuntukylin-default-settings 1.1.5.
<JackYu> slangasek, yep.
<slangasek> ok
<xnox> my old job only allowed 80, 443 and 22 out =)
<wgrant> Yeah, that sounds pretty bad for firewalls...
<xnox> and 443 had to be ssl traffic, they inspected it.
<slangasek> wgrant: there's only one firewall that matters for this particular archive, and it's the one at the border ;)
<wgrant> Heh
<xnox> wgrant: it's like kees "ssh over dns queries" backdoor into buildds =)
<wgrant> xnox: +queue text search is a per-term prefix search, not a full substring search, for performance reasons.
<slangasek> xnox: was the switch to a native package discussed with upstream? Because upstream did have a tarball release on LP
<xnox> slangasek: the upstream had "_2.9.2.orig.tar.gz" and debs uploaded into 2.9.2 release that did not match their trunk branch -> and clearly came from a daily recipe builds that generated the tarball.
<slangasek> xnox: ah, ok
<slangasek> xnox: but - you did also discuss this change with upstream, right? :-)
<xnox> slangasek: and upstream accepted my merge proposal to switch to native.
<slangasek> ok good
<xnox> slangasek: and i'm upstream committer now as well
<xnox> slangasek: i should merge that reviewed branch now =)
<xnox> slangasek: done, upstream trunk is tagged 0.2.9.1 and matches the upload.
<slangasek> xnox: aren't you missing some from __future__ import print_function here?
<slangasek> I see an awful lot of print->print() changes, but no print_function anywhere
<slangasek> not a NEWing consideration, but it might be useful if the app doesn't fail immediately with python backtraces
<xnox> slangasek: i did not do that. let me check.
<xnox> slangasek: yeah i see that introduced / used refactored in a few places.
<slangasek> xnox: you want to fix/upload?
<xnox> slangasek: yeah.
<xnox> slangasek: shokingly "pyflakes" doesn't tell me about them.
<slangasek> otherwise, the package as a whole looks fine, so accepted
<slangasek> xnox: right, I noticed because it was in the debdiff vs. the previous version
<slangasek> (that I had been poking at locally)
<xnox> slangasek: clearly i didn't manage to generate any exceptions while testing it =) cause they'd crash
<JackYu> slangasek, xnox, thanks a lot. Would you help to take a look the ubuntukylin-default-settings 1.1.5?
<xnox> slangasek: i'm opting in for revert - http://paste.ubuntu.com/7232982/
<xnox> slangasek: adding "from __future__  import print_function" results in invalid syntax errors, as only a handful of print's are functions, the rest are statements. Refactoring everything to print function is a huge diff, better done as part of porting to python3.
<xnox> slangasek: and the revert to a consistent print statement is smaller diff.
<xnox> and i'd rather have 1 style through all code base.
<slangasek> xnox: ack
<xnox> ./ui/uksc.py:140: undefined name 'data'
<xnox> ./backend/search.py:315: undefined name 'get_query_for_pkgnames'
<xnox> ./backend/search.py:366: undefined name 'time'
<xnox> ./backend/search.py:369: undefined name 'time'
<xnox> ./backend/search.py:375: undefined name 'log_traceback'
<xnox> ./backend/aptdaemon/dbus_service/apt_dbus_service.py:408: undefined name 'Daemon'
<xnox> hm....
<slangasek> JackYu: does ubuntukylin-default-settings still need an upload sponsored, too?
<xnox> slangasek: i see one in rejected.
<xnox> slangasek: also did keyring got sorted out?
<slangasek> xnox: yes
<slangasek> hmm, yes, it is in rejected
<JackYu> slangasek, happyaron uploaded 1.1.5
<slangasek> who rejected that?
<JackYu> oh...
<slangasek> ok, I'll look - but am on the way to dinner right now, so it'll be a little bit
<xnox> JackYu: that's fine, sometimes reviewers stash things into rejected, which are waiting for some other packages to be uploaded.
<JackYu> xnox, sure. lol.
<JackYu> slangasek, have dinner first:) I think it's middle night at United States.
<xnox> JackYu: usa - west coast is 6 PM =) middle of the night is here in the UK for me - 2AM
<JackYu> xnox, :)
<xnox> JackYu: please review https://code.launchpad.net/~xnox/ubuntu-kylin-software-center/invalid-syntax/+merge/215325
<xnox> JackYu: and please assign / get warnings from https://bugs.launchpad.net/ubuntu-kylin-software-center/+bug/1306313 fixed - i'm not familiar with the code and somebody who understand it better should address those
<ubot2> Launchpad bug 1306313 in Ubuntu Kylin Software Center "pyflakes serious warnings" [Undecided,New]
<JackYu> xnox, got it. Thanks. We will review it asap.
<xnox> i'll poke ubiquity after i wake up =)
<JackYu> xnox, good night:)
<jamespage> slangasek, uh - yes - I did indeed add the breaks/replaces to the wrong package and I did use the wrong version - apologies
<slangasek> jamespage: no worries.  The adjusted version is still waiting in the unapproved queue for a second set of eyes; maybe you'd like to check it over and do some upgrade tests, and if it looks ok I can accept it?
<jamespage> slangasek, ack - will do.  Oddly enought I did upgrade test this - does the fact that its only conffiles moving package make a difference?  I def had no problems
<jamespage> slangasek, either that or my mind is playing tricks on me
<slangasek> jamespage: well, if you happened to get the packages unpacked in the right order, it would've worked even without the Replaces
<jamespage> slangasek, the combination with the new conflicts might have done that
<jamespage> slangasek, certainly looks right - testing now
<slangasek> jamespage: how's the testing?  I'm afraid it's bedtime here
<Daviey> alangasek, if this is for neutron.. i don't mind taking over.
<Daviey> err, slangasek ^
<oSoMoN> hello all
<oSoMoN> can I have an ETA on when webbrowser-app will leave the unapproved queue?
<jamespage> Daviey, is slangasek is now eod that would be appreciated
<Daviey> jamespage: how did the testing go?
<jamespage> Daviey, +1
<jamespage> Daviey, I tested an upgrade from 0ubuntu1 -> 0ubuntu3 with both the vpn and l3 agents installed; upgraded OK - l3 agent bumped off the install (as expected - I installed the vpn-agent)
<Daviey> jamespage: silly question.. but has upgrade from 12.04 been tested? Essex, and UCA versions?
<jamespage> Daviey, I've tested the upgrade path via the UCA from folsom->grizzly->havana->icehouse
<jamespage> Daviey, upgrading straight from essex is hard as the overall architecture of openstack has changed - specifically neutron (grizzly) and cinder (folsom)
<Daviey> jamespage: if it has to be sequential updates is this documented?
<jamespage> Daviey, it will be - I'll make sure it gets into the release notes
<jamespage> Daviey, technically I think nova is the only bit that needs that - its the only project that has rolled up db migrations
<jamespage> Daviey, we can jump other things directly
<Daviey> (i can't imagine anyone is still using Essex.. but you never know, right)
<jamespage> Daviey, you do never know - I triaged a bug report from a 12.04 user who had tried to go essex->havana the other day
<Daviey> oh. ;)
<jamespage> Daviey, not in a serious way - they just happened to have nova-common installed from 12.04 at the time
<Daviey> That makes more sense.
<dbarth> good morning, i'm pinging about the last webbrowser-app upload in the approval queue; we have (sorry) other webbrowser-app fixes stuck in silos after that
<dbarth> thanks for your attention if you can rview those this morning
<seb128> hey release team ;-)
<seb128> xdg-user-dirs and shared-mime-info uploads are translation updates from launchpad (they don't use langpacks)
<seb128> those didn't get uploaded yesterday because the DoS/launchpad downtime made I didn't get the exports before my eod
<Laney> dbarth: you know we're in final freeze?
<Laney> seb128: looking
<seb128> Laney, thanks
<didrocks> Laney: I guess the goal was to open as soon as we can't get things into the release pocket for seeded packages -updates pocket for things seeded in desktop and touch
<didrocks> that's the plan cjwatson discussed about. However, he talked about Monday
<didrocks> so unsure for today, but we'll need to find something IMHO
<dbarth> Laney, didrocks: let me know if we can still land updates today and next week, or if we need another approach for continuing to accumulate fixes for a potential SRU
<didrocks> dbarth: nothing will change from your POV as long as you do bug fixes
<dbarth> i totally understand the need to stabilize the distro before the release, just need a direction
<dbarth> ok
<didrocks> we just need to find which channel it's going to :p
<Laney> I don't know how such redirection works so I'm going to leave things like that for now
<Daviey> dbarth: erm, why is the source PPA for webbrowser-app showing depwait?
<Daviey> Ie, build failure
<dbarth> uh, not sure; let me check with oSoMoN
<Daviey> Hmm, Arm64, armf,  PowerPC and ppc64
<Laney> It doesn't build on those arches
<oSoMoN> thatâs because oxide itself doesnât build on those arches
<Laney> not armhf
<cjwatson> Not armhf.  But yes, that's expected
<Daviey> I assumed armf at least was a release goal for this stuff?
<Daviey> Oh yes
<cjwatson> It only needs to build on the arches listed in "rmadison -s trusty -S webbrowser-app"
<dbarth> ah right, that's the same issue as before
<Daviey> Right, no worse.  My mistake, should have looked closer.
<cjwatson> I think we need to do a block-all in p-m, selectively unblock things that are allowed, and sru-release (or equivalent) anything else
<cjwatson> block-all source rather
<cjwatson> last time round we did that on 2013-10-15
<cjwatson> so this is a bit earlier, but meh
<didrocks> block-all source - stuff that are only seeded on touch and for the rest, go on a case by case? (either release or -updates?)
<Laney> Could do it for the intersection of touch and <stuff>, or something
<didrocks> - being "minus"?
<seb128> ^ telepathy-indicator is a small diff that should fix empathy online status in the indicator
<cjwatson> I don't have a mechanism for that, but we can do it manually
<seb128> would be nice to get in for release
<cjwatson> and for that matter the touch release team have unblock hint access
<didrocks> cjwatson: the FFe bug for Touch is a good list of things being "seeded in Touch only"
<didrocks> I'm happy to unblock on those
<seb128> https://code.launchpad.net/~larsu/telepathy-indicator/lp1103438/+merge/215271 is the corresponding merge request
<cjwatson> didrocks: there's no code for "block-all except stuff"
<didrocks> ah
<cjwatson> and I'm not going to write any now
<didrocks> so, then, it's only hints
<didrocks> from the release team?
<cjwatson> "block-all source" applied now, so ~ubuntu-release and ~ubuntu-touch-release should unblock as needed
<didrocks> yeah
<cjwatson> (in the latter case, for touch-only stuff)
<didrocks> so I can unblock all packages that are touch-only
<didrocks> listing them
<cjwatson> yes
<didrocks> one by one
<didrocks> ok, I'm using the FFe bug
<cjwatson> well, no, unblocks are versioned
<cjwatson> stop
<didrocks> ah
<cjwatson> you have to unblock selected uploads
<didrocks> that's going to be really painful
<cjwatson> deal with it :)
<didrocks> thanks
<didrocks> ok, let's say current Touch is finale then
<cjwatson> I wouldn't expect it'll take that long
<cjwatson> the need for any hints will be obvious in excuses
<cjwatson> that's an overreaction
<didrocks> well, "deal with it" as well
<cjwatson> it's first thing in my morning and I wake up to everyone shouting at me ...
<cjwatson> I would suggest that we can continue to unblock touch stuff pretty freely until Tuesday or Wednesday or so
<didrocks> cjwatson: I don't think I shouted at you, I just hinted you from that discussion and didn't jump on you on purpose on that one to let you catch up
<cjwatson> my point is that it is not really painful to unblock uploads
<cjwatson> if you don't want to bother I'm happy to
<didrocks> it's still for each package -> I have to check it's seeded only on touch only
<cjwatson> (you or your team)
<didrocks> then unblock
<cjwatson> like I say, if you (plural) don't want to bother I'll do it
<cjwatson> it's not a big deal
<didrocks> or beg the release team beyond upstream
<didrocks> for get things in
<didrocks> I would prefer not deal with those and get into -updates if needed
<cjwatson> I would prefer not to use -updates until we need to
<cjwatson> it's harder to track correctness there
<cjwatson> because the only check we have is "valid candidate" in excuses, we won't get the uninstallability check from the output phase
<didrocks> ok, that's a valid one if that's not supported by p-m
<cjwatson> we have -updates as an escape hatch, and we can use it when things are on both touch and something else and we decide we'd rather not take the risk elsewhere; but it's not a free pass, we don't have as good tools for it
<cjwatson> (unfortunately)
<cjwatson> using it is going to require extra manual checks
<cjwatson> so people shouldn't be labouring under the assumption that it's easier / less work
<didrocks> cjwatson: the issue is that the "you" plural is singular most of the time as the only one active on the list would be cyphermox, ogra and I
<cjwatson> like I say I have no problem helping out with that
<cjwatson> and I'm sure others could as well
 * ogra_ finds an old hints branch and sees kenvandine in there too
<didrocks> ogra_: yeah, ken isn't active on that though
<ogra_> ah, k
<ogra_> i just saw he has a file in there
<didrocks> cjwatson: well, seeing the amount of work you have to review unapproved already, I'm unsure the RT will have time to deal with it
<ogra_> hmpf ... and i seem to never have bzr pulled in that branch
<ogra_> what was the upstream url for it again ?
<cjwatson> didrocks: based on past experience it's fine
<cjwatson> ogra_: lp:~ubuntu-touch-release/britney/hints-ubuntu-touch you mean?
<ogra_> thanks !
<cjwatson> didrocks: also, generally unblocking can be done at the same time as accepting through unapproved, so it doesn't require thinking about it twice
<cjwatson> (IME)
<didrocks> cjwatson: so, anyway, seems there is no alternative, so I'll list all with versions
<didrocks> one by one
<didrocks> cjwatson: I wonder though
<didrocks> can't I set unblock <packagename>, then I just amend with a version?
<didrocks> or that will make the system bugging?
<cjwatson> if you do that right now I believe you'll crash proposed-migration
<didrocks> ok
<cjwatson> I would like unversioned unblocks to work
<didrocks> even commented?
<cjwatson> But I'd prefer not to mess with that code a week before release
<didrocks> I just want to have the list handy
<didrocks> so that I know if it's touch only or not
<cjwatson> just keep it in your homedir or in some other file in that branch
<cjwatson> proposed-migration only looks at a specific named list of files
<didrocks> ok, if you think the parser will be at risk
<cjwatson> commented is fine too
<didrocks> ok, let me create a file in that branch then
<cjwatson> but it'd be clearer for other people if it wasn't in your personal hints file, IMO
<didrocks> yeah
<didrocks> like touch-only.list
<cjwatson> yep
<didrocks> ok, doing this
<ogra_> i assume i can safely flush the entries from last release from my file in that branch ?
<didrocks> ogra_: I did for mine some time ago
<Laney> I'm seeing if I can quicly extend generate-freeze-block to come up with this list
<didrocks> Laney: well, I think cjwatson's "don't risk production code" before release makes sense
<cjwatson> generate-freeze-block isn't production code as such
<didrocks> cjwatson: so, for the webbrowser-app one, this will be reviewed as usual and unblock if RT is happy with it?
<cjwatson> that would be replacing block-all with a gigantic block that affects the whole archive
<cjwatson> or something
<cjwatson> ogra_: yes
<ogra_> done, thanks
<didrocks> but you are not afraid with britney crashing with the gigantic block list?
<cjwatson> no
<cjwatson> we use gigantic block lists elsewhere
<cjwatson> sigh, KDE didn't all clear through automatically so we'll have to unblock that
 * cjwatson looks through the ftbfs pile
<cjwatson> Laney: thinking about it, I think we only applied block-all last time once we needed the archive to quiesce for release
<cjwatson> Laney: so maybe your big freeze block approach would in fact be better for this
<cjwatson> not that it isn't helpful for people to remember how to unblock stuff, but :)
<Laney> cjwatson: Yeah, I think so
<Laney> Trying to get the logic right
<didrocks> Laney: if you need any help from me, I'm happy to check with you
<Laney> I'll share a list when I get one that I think is right
<didrocks> ok
<cjwatson> It would certainly be nicer to do less work even if it's not too hard :)
<didrocks> cjwatson: Laney: seems there is again 2 new MPs for webbrowser-app coming which are the same kind of fixes than the one in UNAPPROVED. So that you don't have to review the same package 3 times as upstream planned at first, I asked them to get that in one landing
<didrocks> so I'm kicking out the current version in UNAPPROVED
<cjwatson> mkay
<cjwatson> didrocks: do you know if qtcreator-plugin-remotelinux got prenewed?
<didrocks> cjwatson: yeah, I did that
<Laney> http://paste.ubuntu.com/7234140/ ?
<didrocks> (some worth and back and checked that my concerns were fixed in latest versions)
<Laney> Packages which are on touch and some other image
<Laney> Hopefully
<didrocks> Laney: looking
<cjwatson> Laney: for actually putting this in p-m, don't we need the list of all packages on any image other than touch?
<Laney> Depends what you want to block, I guess
<didrocks> Laney: so, you are also dealing with build-deps from what I see, right? (like autopilot)
<Laney> hrm, how did that get in there?
<Laney> It's not there when I run it again ...
<didrocks> *magic*
<didrocks> lxc-android-config?
<didrocks> that looks weird
<Laney> oh
<cjwatson> didrocks: yeah, looks ok, accepted (q-p-r)
<Laney> that's because I forgot the flag when I ran this
<Laney> http://paste.ubuntu.com/7234167/
<cjwatson> so, yeah, last time round we apparently didn't block anything for final freeze, only in the unseeded freeze right at the end
<Laney> so I was thinking the idea was to let touchies carry on as normal ish, blocking their shared things in proposed so that they can be considered as discussed earlier
<didrocks> cjwatson: thanks!
<cjwatson> it wasn't what I was initially thinking, but it makes sense
<Laney> for everything else use the unapproved queue
<Laney> then use the block-all source instead at T-2 days as for Saucy
<cjwatson> yep, bit confusing but I can deal with that
<Laney> Might be worth a mail
<didrocks> Laney: this list is what is seeded on touch and desktop it seems?
<didrocks> not things that are seeded on any flavor (but Touch only)?
<didrocks> like I would have except to see some unity-lens-*
<didrocks> or gnome-*
<Laney> right
<Laney> it's shared touch and other things components
<didrocks> ok, and so, desktop-only will be blocked by something else?
<didrocks> (taking ubuntu desktop as an example)
<darkxst> Laney, I would rather the touchies didnt touch anything on our image now, given it won't be tested before upload
<Laney> unapproved
<Laney> darkxst: this block catches that
<Laney> but really it's mainly about the CI train stuff
<Laney> Qt possibly to a lesser extent
<darkxst> Laney, there is stuff in that list seeded on our images
<cjwatson> darkxst: this is a list to block, not a list to allow
<Laney> darkxst: that's good, it's the list of things that will get blocked
<darkxst> ah, ok
<didrocks> but the unapproved -> autoaccept already had the interesect of Touch + any other flavor?
<didrocks> intersect*
 * didrocks is probably silly, but doesn't understand
<cjwatson> auto-accept is: not in a package set, not listed in seeded-in-ubuntu other than ubuntu-touch
<didrocks> unapproved -> autoaccept was for Touch-only
<didrocks> yeah
<Noskcaj> Is it ok for me to make a upload of parole for a missing recommends? It fixes a high importance bug, and xubuntu (where it's seeded) approves the change
<cjwatson> didrocks: I think the idea is that this allows people to accept touch-related stuff (touch-only or not) into -proposed without having to carefully check whether it affects desktop
<cjwatson> didrocks: and then anything that isn't touch-only out of that, we can have in -proposed in a place where we can then move it to -updates if we need to
<cjwatson> Noskcaj: sounds fine
<didrocks> cjwatson: ok, this makes sense to me
<cjwatson> it's a bit twisty
<cjwatson> but I think it ultimately makes sense
<didrocks> right, I get it now
<Laney> I think so, if it turns out not to in practice then it's only a text file to edit
<Laney> the volume should be low at this point anyway :)
<didrocks> Laney: the list looks to be the right one to me :)
<didrocks> Laney: *if* only
<Laney> mini troll, sorry
<Laney> that Friday feeling
<didrocks> heh ;)
<didrocks> seems that some people committed still to features and so, features + stabilization is expected
<didrocks> (sure, so easy)
<didrocks> but that's out of my hands as you knowâ¦
<didrocks> Laney: thanks for building that list, after a second look, nothing bleeds through my eyes
<didrocks> (I thought we stopped shipping zg though=
 * didrocks checks
<Laney> It'll be interesting when it comes to trying to release a product on such a fast moving base (especially if the base of that is a development release)
<Laney> 'bleeds through my eyes' sounds funny to me - is that a translation of a French expression?
<didrocks> Laney: yeah, you know how French rules to directly translate expressions :p
<didrocks> Laney: and +1 on the "it will be interesting" :p
<didrocks> we still (ship zg-core in touch oh my)
<Laney> ok, updated hint pushed
<cjwatson> cool, thanks
<didrocks> thanks!
<cjwatson> I'm working on clearing out component-mismatches, BTW, it's just fairly slow going
<cjwatson> lots of checking ...
<cjwatson> NBS is clear at last
<Laney> what's happening with icedtea-web?
<didrocks> oSoMoN: you do have a FFe for https://code.launchpad.net/~michael-sheldon/webbrowser-app/file-upload/+merge/212605?
<didrocks> (I saw you approved it)
<didrocks> as webbrowser-app is not seeded by Touch-only, it's not in the blanket Touch FFe
<oSoMoN> didrocks, IÂ donât
<oSoMoN> didrocks, can you point me to a template FFe so I can file one?
<sil2100> Hi release team! There's a low-risk packaging fix upload of libaccounts-qt in -proposed - it fixes a packaging conflict - could anyone push it further to the archive?
<Laney> I'm going to be polling excuses for blocked packages and I expect others will too
<didrocks> oSoMoN: https://wiki.ubuntu.com/FreezeExceptionProcess
<oSoMoN> didrocks, thanks
<didrocks> yw
<didrocks> sil2100: Mirv: we need this FFe to ba acked before publishing the webbrowser-app silo ^
<sil2100> didrocks: ok, will remember that, let me put up a comment
<sil2100> Laney: thanks o/
<Mirv> right
<infinity> So, looks like mochikit still needs an MIR, or python3-paste needs neutering?
<infinity> Everything else wanting main promotion looks like fallout from bugs or FTBFS packages.
<oSoMoN> didrocks, here goes the FFe: https://bugs.launchpad.net/ubuntu/+source/webbrowser-app/+bug/1306528 , let me know if additional information is required
<ubot2> Launchpad bug 1306528 in webbrowser-app (Ubuntu) "[FFe] file upload implementation in browser and webapps container" [Undecided,New]
<sil2100> oSoMoN: adding it to the landing
<oSoMoN> didrocks, oh wait, I just realized that this MR (file-upload) introduces a runtime dep thatâs in universe: qtdeclarative5-ubuntu-content0.1
<didrocks> oSoMoN: yeah, you're going to fix/amend this?
<oSoMoN> didrocks, well Iâm not really sure how to fix that, I would have expected qtdeclarative5-ubuntu-content0.1 to be in mainâ¦ :/
<oSoMoN> IÂ could make it a suggests instead of a direct dep, that would work because on desktop itâs not used and on devices the content hub is guaranteed to be there
<didrocks> oSoMoN: that would be better
<oSoMoN> but Iâd like to get some input from Elleo and Ken as to why itâs not in main
<didrocks> oSoMoN: I guess it's too late for a MIR on content-hub
<oSoMoN> sounds way too late indeed
<didrocks> oSoMoN: maybe prepare both?
<didrocks> downgrade to suggest/rebuild
<didrocks> ensure it's still fine on desktop without it
<oSoMoN> didrocks, another option is to simply remove the dependency from debian/control: since itâs only loaded dynamically at run time and only on devices where the content hub is guaranteed to be installed, it wonât make a difference
<oSoMoN> (instead of a suggests which wouldnât make sense on desktop anyway)
<didrocks> oSoMoN: fine with me as well, your pick
<oSoMoN> didrocks, Iâll go for that one
<didrocks> ok, great, thanks!
<didrocks> oSoMoN: while you are doing that, let's see if you get an answer soon on your FFe :)
<oSoMoN> didrocks, I
<infinity> cjwatson: Want to make some seed vs. demote decision on the 300 new grub binaries?
<oSoMoN> didrocks, Iâve pinged Elleo whoâs the owner of the branch to do the change, if he doesnât answer in the next 10 min Iâll branch and submit a MR myself, to speed things up
<cjwatson> infinity: yeah, I was going to seed those
<cjwatson> somewhere
<cjwatson> I'll do it after coffee :)
<infinity> cjwatson: Oh, err, you're not doing overrides right now, are you?
<infinity> (Before I hit enter on this gtk-sharp and jquery* demotion and double-override the world...)
 * infinity takes the selince as a no.
<cjwatson> infinity: not right now
<oSoMoN> didrocks, Elleo acked the request, heâs working on the change as we speak
<didrocks> grea t;)
<infinity> Alright, knocked out maybe 10 or 15 lines from c-m, time for breakfast while that settles.
<seb128> Laney, ^ unity
<Laney> I see it
<seb128> ;-)
<seb128> Laney, thanks ;-)
<Laney> yw
<Daviey> infinity: Hey, do you have a view on bug 1305839?
<ubot2> Launchpad bug 1305839 in maas (Ubuntu) "FFe: Support for Third Party Driver Installation" [Critical,New] https://launchpad.net/bugs/1305839
<Daviey> infinity: did you 'unofficially approved the FFe'?
<oSoMoN> didrocks, dependency issue fixed for the file-upload branch of webbrowser-app
<didrocks> oSoMoN: great, keep us posted on the FFe status!
<oSoMoN> didrocks, it hasnât been updated yet, who can I ping to get it reviewed?
<didrocks> oSoMoN: normally, the release team pick up the FFe list. I think enough of them are in the channel to notice that discussion, or you can click on the team you subscribe and try to ping them :)
<oSoMoN> nah, Iâll trust weâve made enough noise in this channel already :)
<infinity> Daviey: Not in so many words, no.  I told them the reasons why I would flat our reject the upload (FFe or not), and they went and tried to fix those.
<infinity> s/our/out/
 * cjwatson does a few more bits of c-m
<Daviey> infinity: Hmm, Well. I guess as you had a prior discussion - can you follow up? I added my thoughts to the bug.
<infinity> Daviey: I followed up to the bug to clear up the invocation of my name.  If they can test the everliving crap out of it, I'm perhaps inclined to let them slip it in, but yeah, 1.5mo after FF is probably not the time for features. :P
<infinity> cjwatson: I'll keep my fingers out for a bit, then.
<cjwatson> done for now, will let that settle
<knome> hey release team! i'm personally unaware of how the process goes, but we have made a change in the xubuntu seed (dropping ibus to avoid 1284635 for now) and it's ready in the branch; should i just file a 'regular' sponsorship bug to get it in, and also, do you approve this change under the final freeze?
<knome> (process being process with seed changes, and more exactly, if we need any special ACK's)
<cjwatson> yes and yes
<knome> ok, will get that done, and thanks
<cjwatson> except that somebody already uploaded xubuntu-meta for that
<knome> oh!
<cjwatson> https://launchpad.net/ubuntu/+source/xubuntu-meta/2.180
<knome> hmm, weird, it's not showing on today's ISO..
<knome> maybe it'll propagate down tomorrow
<knome> that was quick and smooth
<cjwatson> you sure?  http://cdimage.ubuntu.com/xubuntu/daily-live/pending/trusty-desktop-amd64.manifest shows xubuntu-desktop 2.180
<cjwatson> but ibus is there for some other reason
<knome> elfy, ^
<knome> harumpf.
<cjwatson> http://people.canonical.com/~ubuntu-archive/germinate-output/xubuntu.trusty/desktop shows recommends from unity-settings-daemon
<knome> i guess we need to look at that then..
<knome> why do we even ship something like that
<cjwatson> follow the dependencies/recommendations back ...
<knome> yeah, will have to look at that
<knome> thanks for the pointer
<infinity> Hrm.
<knome> gnome-bluetooth, hmm..
<infinity> That alacarte upload in the queue... Doesn't that leading debian/control newline come from a broken gnome-tools (or whatever) version, and cause issues with some other parsers?
<knome> wondering if that should really recommend unity-control-center
<cjwatson> it's an alternate dependency
<cjwatson> you could try seeding gnome-control-center instead?
<cjwatson> though I see you don't have that right now
<knome> hmph, will have to look at the dependencies of that...
<cjwatson> you probably want to run germinate locally for this kind of thing
<knome> yes yes :)
<knome> cjwatson, would it sound completely insane to mark xfce4-settings-manager as another alternative?
<cjwatson> knome: I don't have enough experience around there to know
<ochosi> cjwatson: i've got a proposal for this problem
<knome> huzzah
<ochosi> we could hide the menuitem "bluetooth settings..." in xubuntu and put xfce4-settings-manager as an alternative depends
<ochosi> thing is: xfce doesn't have a separate bluetooth settings dialog anyway
<cjwatson> I don't have any more thoughts to offer on this; I wouldn't be able to review such a change
<ochosi> but the indicator offers all the core functionality
<ochosi> cjwatson: hm, who would? larsu?
<cjwatson> I don't know
<cjwatson> Sorry, I'm really not a desktop hacker :)
<ochosi> ok, np, i'll ask around ;)
<cjwatson> I was just looking at the raw dependency structure
<knome> thanks cjwatson :)
<cjwatson> infinity: ^- re discussion yesterday.  we'll need to bump ubiquity to include that
<infinity> xnox: You pulled the trigger on that d-i upload a little too quickly, keener. :P
<cjwatson> infinity: that was me ... why was it too quick?
<xnox> infinity: i didn't upload anything =)
<cjwatson> oh, I suppose it will want to have the new grub2-signed in it
<infinity> Oh, it was Colin who uploaded. :P
<infinity> cjwatson: And yeah, grub2-signed.
<cjwatson> I thought you were referring to partman-auto, which isn't in the initrd.
<xnox> infinity: and i still need d-i with that kernel to test the updated block-devices udeb. to make sure it works on the hardware it is suppose to enable.
<infinity> I think it might be time to re-examine my goal of adding (= ver) depends to debian-install-udebs.
<infinity> Just hard block migration until it's definitely in sync.
<infinity> installer*
<cjwatson> Probably won't help with grub2-signed.
<infinity> xnox: Right, I'll get it built as soon as grub2-signed settles.
<cjwatson> We'd need proper Built-Using support for that.
<infinity> cjwatson: Oh, does it not get it from the udeb?
<cjwatson> What udeb?
<infinity> Right. :P
<infinity> Is that perhaps a mistake?
<cjwatson> It's used quite differently from normal udebs.
<infinity> Fetching from the archive EFI location (and thus relying on the archive layout) seems wrong.
<cjwatson> d-i doesn't fetch from there, grub2-signed does.
<cjwatson> Oh, hey, it does.  I wonder why I did that.
<cjwatson> Maybe it was to avoid yet another archive cycle ...
<cjwatson> So I'm not sure d-i needs to wait for grub2-signed at all
<infinity> Yeah, you're probably right, now that I've thought it through.
<cjwatson> If we were going to change that, B-Ding on grub-efi-amd64-signed would make more sense than adding a udeb, I think, but that has extra settle-time problems.
<cjwatson> We do B-D on shim-signed; that changes less often though
<cjwatson> Dunno
<infinity> But also guarantees consistency, if done right.
<infinity> But meh.
<infinity> What we have works, it just seems hackish.
 * cjwatson does some more c-m
<cjwatson> Yeah
<seb128> could somebody britney unblock unity?
<seb128> why do we have britney blocks during the freeze? if things are approved from unapproved they should probably be good to get in?
<Laney> It was discussed earlier - things will be unblocked as appropriate
<cjwatson> so that we can let overlapping touch/desktop stuff into -proposed and aim it at -updates rather than release if we need to
<cjwatson> it's only for the overlap
<cjwatson> though I don't know why unity is in that overlap
<Laney> unity-services binary package
<cjwatson> ah
<Laney> I unblocked unity now anyhow
<seb128> cjwatson, Laney: thanks
<cjwatson> another batch of c-m done, letting it settle again
<infinity> doko: Are you going to fix gnat on powerpc?
<infinity> Err, wha?  That mochikit thing shouldn't be happening.
<infinity> Oh, derp.  py3-paste was promoted this cycle, and the Rec->Sug drop only happened on py-paste.
 * infinity fixes.
<seb128> would http://paste.ubuntu.com/7234846/ be an acceptable ubiquity change to land for release?
<seb128> see https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1306598
<ubot2> Launchpad bug 1306598 in ubiquity (Ubuntu) "Handle better missing indicators" [Undecided,New]
<seb128> basically make place to get https://code.launchpad.net/~ted/indicator-keyboard/startup-cleanup/+merge/207768 landing as a SRU maybe later
<seb128> (we missed to switch that indicator to upstart job and we might want to fix in a SRU since we are past the freeze)
<cjwatson> looks ok to me
<cjwatson> we have another ubiquity landing coming up for the partman-auto change - I'll include that
<infinity> ^-- That clears up the only legitimate universe->main promotion on c-m.
<cjwatson> seb128: well, except that's wrong, i isn't the full path
<cjwatson> I'll fix it
<seb128> cjwatson, oh, didrocks was about to mp his change
<didrocks> doing it
<didrocks> sorry
<cjwatson> didrocks: I was just going to commit it directly, unless you've already done it
<xnox> cjwatson: kylin downloads on ubuntu.com should point at http://cdimage.ubuntu.com/ubuntukylin/releases/14.04/release/ubuntukylin-14.04-desktop-i386.iso for final release?
<cjwatson> xnox: er, sounds right but I haven't double-checked, check 13.10 and substitute?
<xnox> cjwatson: is http://china-images.ubuntu.com/releases/ - a deprecated location? (hosted only Ubuntu Chinese)
<didrocks> cjwatson: ah ok
<cjwatson> xnox: yes
<didrocks> cjwatson: please go ahead then
<seb128> cjwatson, what about https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1306604 ?
<ubot2> Launchpad bug 1306604 in ubiquity (Ubuntu) "ubiquity-dm is missing the power indicator" [Undecided,New]
<seb128> cjwatson, adding indicator-power/indicator-power-service to that list
<xnox> cjwatson: right, that's what i did. so yeah if it looks roughly correct - that's good.
<cjwatson> xnox: any reason I shouldn't add indicator-power-service, that you know of?
<xnox> cjwatson: probably got lost when indicators transitioned to use profiles. As long as it declares ubiquity profile in /usr/share/unity/indicators/com.canonical.indicator.power it should be loaded.
<xnox> cjwatson: and added in ubiquity for loading.
<cjwatson> $ grep -i ubiquity /usr/share/unity/indicators/com.canonical.indicator.power
<cjwatson> $
<cjwatson> so that would have to be fixed first?
<infinity> cjwatson: Do you still need your 18G of crap on am1?
<cjwatson> infinity: probably not, I'll clear it out shortly
<infinity> cjwatson: Ta.
<seb128> cjwatson, xnox: I can get a landed up for the ubiquity profile
<cjwatson> I might keep the 7.8->7.6 bootstrap one of those trees, for future reference
<seb128> landed -> landing
<cjwatson> seb128: adding a task for that then
<seb128> cjwatson, thanks
<xnox> cjwatson: so if ubiquity profile is not declared, upon trying to launch/load indicator it will just exit. Once the profile has landed, it would start loading. So this can be fixed in any order.
<cjwatson> ah.  let me just try running this here ...
<cjwatson> actually, I think I'd be more comfortable if we could test that the power indicator comes up before including that code in ubiquity
<xnox> cjwatson: ack.
<xnox> cjwatson: do you want me to do this?
<cjwatson> sure, if seb128 isn't already on it
<cjwatson> I want to upload what I have in ubiquity though, we can do this separately
<seb128> I'm on adding the profile to the indicator
<seb128> not on changing ubiquity
<xnox> seb128: ok. please point me to the indicator profile branch/commit/patch
<seb128> what would happen if we had the indicator to the list without having a profile? error? or just no indicator?
<xnox> seb128: "<cjwatson> actually, I think I'd be more comfortable if we could test that the power indicator comes up before including that code in ubiquity"
<cjwatson> I dunno, if y'all really think it's safe then I can stick it in this upload
<cjwatson> it would just be easier to test the other way round
<xnox> seb128: so point me to profile, i'll apply it locally and will patch ubiquity locally, test it. and then land ubiquity after indicator lands, and this way it will be all tested before uploading anything.
<cjwatson> ok, uploading ubiquity without that now then
<cjwatson> seb128: I didn't know for sure which is why I was reticent :)
<xnox> seb128: you gonna use desktop_greeter mode for ubiquity? we have been mostly recycling that for ubiquity profile.
<seb128> xnox, I was going to use "desktop", do you prefer the greeter?
<seb128> xnox, desktop have entry points to the settings panel for configuration
<xnox> seb128: hm, let me logout and compare the two. I don't think we want configuration ui to be exposed in ubiquity-dm. people can laucnh "try ubuntu" to get "full" experience.
<seb128> xnox, ok, let me use the greeter one then
<xnox> seb128: yeah the greeter one is better - just the power level indicator.
<oSoMoN> Hi gentle release team, any chance someone could have a look at this FFe (bug #1306528) and give me some feedback?
<ubot2> Launchpad bug 1306528 in webbrowser-app (Ubuntu) "[FFe] file upload implementation in browser and webapps container" [Undecided,New] https://launchpad.net/bugs/1306528
<knome> infinity, heyyy... what about release notes, where do we put those, do we still do flavor-specific subpages?
<infinity> knome: I'd prefer single-page, with flavours just having their own sections in the notes.  Most of you probably only have a few bullet points to list on top of the Ubuntu generic ones.
<infinity> (new XFCE version, bug X in GNOME, edubuntu now ships actual children with every CD, etc)
<knome> http://pad.ubuntu.com/Xubuntu1404Final has our stuff for notes (scroll to bottom)
<knome> but we could probably cut that down a bit if it was for single notes page
<infinity> knome: Yeah, that seems reasonable (and perhaps cut down a tad) to stuff in a Xubuntu subsection of the primary page.
<knome> i understand the pros to both ways of doing it... for xubuntu users, i think a separate subpage is clearer, because we can only show stuff that affects our users most (and can strip off some of the stuff from the main page, and link to it), otoh, i can see why a generic release note pages would be better
<knome> i guess my only worry about a shared page is that stuff will get lost easier... users are already having "problems" reading the release notes
<infinity> knome: The obvious pro to the single page approach is not having everyone's release notes duplicate most of the content.
<infinity> knome: Wait, you have users that actually read the release notes? :)
<darkxst> knome, why not have your super glorious release notes page linked from the generic sub-page!
<knome> infinity, yeah, that's what i'm saying ;)
 * darkxst is pretty certain our users don't read them
<knome> making it a TL;DR page for most developers as well probably doesn't help the cause
<infinity> So, for Saucy, it looks like we just linked to external notes for everyone.
<knome> hmph,
<knome> here's what i think
<infinity> I'm okay with that, too.  Just not with the duplication of data.
<knome> we could make the regular release note page better
<knome> eg. improve the "table of contents"
<infinity> https://wiki.ubuntu.com/SaucySalamander/ReleaseNotes/Xubuntu was nice and Xubuntu-specific, without any generic stuff, and the generic page linked to it.
<knome> add some semi-graphical element to it
<knome> the current table of contents is pretty baffling..
<knome> and i guess i have slight problems having the new features and known issues separated and pulled so long apart
<knome> it's much harder to get an overview of the xubuntu stuff
<knome> (ok, granted, the release announcement should do that)
<infinity> Oh, wow, people have actually inserted content in the release notes.
<infinity> Look at that.
<darkxst> infinity, I did hear a rumour our docs team work working on something!
<infinity> knome: Would it perhaps make more sense to add "5. Flavours" to the TOC, and have new Xubuntu features and Xubuntu known issues be subcategories of that, so they're closer together?
<knome> infinity, yeah, that would probably be saner
<knome> infinity, what do you think of a more "graphical" toc somewhere?
<knome> let me dig up an example...
<infinity> Though, half the "generic" known issues also apply to everyone.
<infinity> So, I dunno.  Maybe it makes more sense the way it is right now.
<knome> https://wiki.ubuntu.com/Xubuntu/Processes#Release_Cycle
<knome> something like that?
<infinity> It is a bit long, though, I agree.
<knome> i don't know...
<knome> it would help to cut it in smaller pieces with something else than just text headers..
<infinity> knome: So, like, if the "known issues" section had a header that listed "General | Ubuntu Desktop | Ubuntu Server | Xubuntu | Edubuntu | Confubuntu | Etc"?
<knome> yeah.. or a header that lists the general subsections and then another that lists flavors
<infinity> I wouldn't be against someone doing that to the page. :)
<knome> something that makes the notes actually more "navigateable"
<infinity> Anything to make it prettier and more navigable is fine by me, really.
<knome> currently it's a wall of top-down text, take it or leave it
<knome> ok, i'll look into improving that in a sandbox page and then ping back to you
<infinity> But the more I look at it, the more I think "features" and "issues" should be separate sections, as they are now.
<infinity> If you care about issues, you'll look.  And if you look, you're as interested in "general" as you are in "lubuntu".
<darkxst> and for maybe 80% issues are shared amongst all flavours!
<infinity> Probably more interested in general, really, since those are the really scary ones (kernel sets you mouse on fire, mouse runs around installing Fedora in protest", etc.
<infinity> )
<knome> hah
<darkxst> infinity, really? best I had was dog taking mouse...
<knome> maybe some internavigation links between xubuntu issues and features then
<infinity> knome: That might do.  Or even every feature subheading could just have a quick link to "also see known issues" that goes to the top of the issues anchor.
<infinity> knome: So, I go check on cool new stuff in Ubuntu GNOME, and then see "hrm, maybe I should check out bugs", and zoom, there I am.
<knome> yep
<knome> but that leads to the question
<knome> is there any reason why the ubuntu gnome stuff can't be at one place
<knome> and then just have a link to general bugs?
<infinity> knome: Anyhow, documentation and navigation thereof are really not my forte.  I welcome any improvement to the current state of affairs, just really want to try to avoid a twisty maze of interdependent pages, if we can avoid it.
<knome> ...and that leads to the question that would it be just sane to keep what we have now, because that would help keep the main notes page from being a wall of text
<knome> the current stuff isn't too bad... the xubuntu subpage only do one include
<knome> as long as the main page can keep relatively clean, we wouldn't need more
<infinity> knome: If by "what we have now", you mean "the Saucy method, of a general page, and links to subpages with only flavour-specific stuff", I'm not sure that was terrible.  But it wasn't ideal.
<jdstrand> I'm testing a fix for bug #1306560 (and bug #1298021)
<ubot2> Launchpad bug 1306560 in lightdm (Ubuntu) "Oxide-based containers don't work in the guest session" [High,In progress] https://launchpad.net/bugs/1306560
<ubot2> Launchpad bug 1298021 in lightdm (Ubuntu) "Google Chrome (not chromium) won't start in guest session" [Undecided,In progress] https://launchpad.net/bugs/1298021
<jdstrand> it is a simple apparmor profile update in lightdm
<jdstrand> ok to upload?
<knome> infinity, that, or https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes/Beta1/Xubuntu
<knome> but i'm fine with either...
<knome> anyway, i'll look at it and bother my head with it
<darkxst> )knome, I am well out of the loop on the docs stuff, but feel free to chat with Ali and the rest of our (ubuntu GNOME) docs/wiki crew
<infinity> jdstrand: Yeah.
<jdstrand> infinity: thanks!
<knome> darkxst, i will look at general stuff, flavors can then adapt
<darkxst> knome, maybe the word should be collaborate
<knome> darkxst, well there's not much else i can do to set up the basic structure and tell others to use it
<darkxst> "adapt" is rather harsh!
<knome> what more do you expect me to do then?
<darkxst> knome, collaborate!
<knome> how?
<knome> or, on what?
<darkxst> chat with Ali + co, about your whole release not conundrum
<darkxst> ^note
<knome> they should take part in the discussion here if they have specific requirements
<superm1> can we get a respin of mythbuntu?  all 3 of the fixes from yesterday have landed in the archive and want to double confirm them
<knome> if i improve it, naturally i will make sure the links are up for every flavor; it would be insane not to do that
<knome> i fail to see what else i could do to help other flavors
<darkxst> knome, this is getting way off topic for -release, however I don't think that is a good attitude to take
<knome> except maybe send a mail to the -release list, which is again something that should be done only after we've actually landing stuff
<darkxst> knome, work together with other flavours maybe?
<knome> i'll take it to PM.
<stgraber> so we are expecting an upload of both LXC and systemd to fix bug 1303649â
<ubot2> Launchpad bug 1303649 in systemd (Ubuntu) "systemd-logind spins in cgmanager_ping_sync()" [High,Confirmed] https://launchpad.net/bugs/1303649
<stgraber> hallyn is currently testing a fix
<seb128> xnox, cjwatson: ^ indicator-power with ubiquity profile
<xnox> seb128: ah, excellent =)
<xnox> seb128: will upload ubiquity shortly then.
<dbarth> sorry, me again about https://bugs.launchpad.net/ubuntu/+source/webbrowser-app/+bug/1306528
<ubot2> Launchpad bug 1306528 in webbrowser-app (Ubuntu) "[FFe] file upload implementation in browser and webapps container" [Undecided,New]
<dbarth> i'd like to see if we should aim for the archive (if you ok) or for -updates instead
<dbarth> see my last comment https://bugs.launchpad.net/ubuntu/+source/webbrowser-app/+bug/1306528/comments/1
<dbarth> explaining that we are adressing a feature parity issue with the previous browser/container
<dbarth> let me know
<dbarth> (i know you guys are spammed with requests, so sorry again)
<bdmurray> infinity / slangasek: can we get some post 14.04 milestones set up? trusty-updates, 14.04.1?
<infinity> Yeah.
<infinity> bdmurray: Done.  No dates set yet, but we'll sort that soon.
<bdmurray> infinity: thanks!
<doko> infinity, probably not this weekend (PyCon)
<Laney> dbarth: What are the chances you will want to upload this again?
<dbarth> Laney: webbroser-app? hmm, we will have other fixes next week i'm sure
<dbarth> Laney: but i assume those will go into -updates
<dbarth> as to avoid disturbing the final freeze
<dbarth> (let me verify what's still in silos)
<dbarth> alex-abreu: ping?
<dbarth> no more in silos, and but we have 2 bugs, and one whci could be a x-day sru to fix some popup redirections (will be usefull on phone and desktop, but more minor)
<dbarth> Laney: hope that helps you judge the request
<dbarth> Laney: ahem, as a matter of fact, i'm told that a rebuild is indeed needed, ahem...
<dbarth> Laney: so apologies, please don't consider the packages in the queue right now
<Laney> nothing's in the queue yet
 * dbarth goes hiding now
<dbarth> ok
<jdstrand> that ^ is the apparmor profile updates I mentioned
<jdstrand> (for oxide and google-chrome)
<alex-abreu> dbpong
<infinity> jdstrand: Looking.
<infinity> How is "apt-listchanges" in "core"?  Meh.
<infinity> Someone want to look at that one for me?
<infinity> stgraber: Shall I trade you for one of your uploads?
<stgraber> infinity: sure, you can take lxc
<oSoMoN> alex-abreu, I would have written dbong, for an even shorter contraction of "dbarth: pong" :)
<alex-abreu> oSoMoN, ahah ... right 1 byte less :)
<dbarth> Laney: webbrowser-app packaging issues resolved now FYI, so the FFE is back for your consideration
<Laney> I'm replying now
<dbarth> ok thanks
<dbarth> alex-abreu: noticed youtube also needs the accounts.google.com treatment to be able to upload
<alex-abreu> dbarth, ok need a branch now?
<dbarth> alex-abreu: will silo on monday, no rush
<alex-abreu> ok
<infinity> stgraber: Yeah, already was looking at lxc, and then got distracted by some amazing drama.  Back to the review now. :P
<Laney> zul: did you manually cherry-pick those tgt patches or something?
<zul> Laney:  yeah
 * Laney hands zul git format-patch
<zul> Laney:  yeah that boo boo was really stupid of me
<infinity> Laney: When you were reviewing that, did you happen to notice that the one patch hunk jumped from patching one file to patching a completely different one?  I was going to ask zul wtf was up with that.
<infinity> zul: ^
<zul> infinity:  i totally applied the patch to the wrong file
<infinity> zul: Brilliant.
<zul> infinity:  not my finest moment
<slangasek> infinity: at what point are we freezing britney, to let us start staging SRUs in -proposed without automigration?
<slangasek> xnox: thanks for the plymouth fix!
<slangasek> xnox: I notice that bug #1298938 is marked as 'fix committed'; are you planning another upstart upload soon?
<ubot2> Launchpad bug 1298938 in upstart (Ubuntu Trusty) "grep: /etc/init/plymouth-shutdown.override: No such file or directory" [Medium,Fix committed] https://launchpad.net/bugs/1298938
<xnox> slangasek: it's fix committed in "SRU" speak.
<xnox> slangasek: it's in trusty-proposed.
<xnox> slangasek: oh, it looks like upstart built halted all buildds =)
<slangasek> mm?
<xnox> infinity: can you check what's hanging in all of https://launchpad.net/ubuntu/+source/upstart/1.12.1-0ubuntu2 ?
<xnox> slangasek: it does not take 3h+ to build upstart.
<slangasek> right
 * xnox ponders if my new dbus tests have left run-away processes again.
<cjwatson> xnox: that would be a plausible cause of this symptom, yes
<slangasek> jodh, xnox: erm, bug #1306361 - do we really want *hourly* rotation of log files?
<ubot2> Launchpad bug 1306361 in upstart (Ubuntu Trusty) "~/.cache/upstart/ logs are not rotated often enough" [Medium,Fix committed] https://launchpad.net/bugs/1306361
<slangasek> AIUI that means we'll have less than a day's worth of logs retained
<oSoMoN> Laney, hey, thanks for ackâing the webbrowser-app FFe, the package is now in the unapproved queue, weâre gonna need someone to accept it
 * ScottK suggests that if you think you want hourly rotation, the problem isn't having faster rotation, but the logs being too chatty.
<infinity> xnox: I'll have a poke.
<infinity> xnox: http://paste.ubuntu.com/7235878/
<slangasek> ScottK: yeah, I don't know where this "hourly" has come from
<slangasek> I think that's way too frequent
<ScottK> Always important to solve the right problem.
<infinity> xnox: Same story on other machines.
<infinity> xnox: So, uhm, what did you do? :P
<infinity> xnox: I'm going to keep one machine in this state in case you want some debugging info from it, and kill the other 5 builds.
<infinity> (But I assume this should be readily reproducible locally)
<robru> Laney, webbrowser-app FFe uploaded, please accept  https://bugs.launchpad.net/ubuntu/+source/webbrowser-app/+bug/1306528
<ubot2> Launchpad bug 1306528 in webbrowser-app (Ubuntu) "[FFe] file upload implementation in browser and webapps container" [Undecided,Triaged]
<infinity> xnox: Did you disappear on me? :P
<ScottK> Caught in a twisty turny maze of bdus tests.
<knome> bdus?
<jodh> slangasek: ironically, that's the problem with using cron. My first MP for this issue is better in that an admin or each user can modify the rotation period using a .override: http://bazaar.launchpad.net/~jamesodhunt/ubuntu/trusty/upstart/periodic-logrotate/revision/1538#debian/user-conf/periodic-logrotate.conf
<slangasek> jodh: I don't follow.  What's the problem with using cron?
<slangasek> you certainly can do daily rotation instead of hourly with cron, which should be more than sufficient
<jodh> slangasek: I mean a cron snippet - the user can't easily change the behaviour.
<infinity> I doubt the user would want to change the behaviour if the default was sane.
<slangasek> jodh: making it configurable does not address my point
<slangasek> which is that hourly rotation is unreasonably frequent
<jodh> slangasek: the reason for hourly is to attempt to combat all the "upstart at my 20TB disk" bugs.
<infinity> jodh: Just how much space can upstart eat in a day?
<slangasek> jodh: that goes to ScottK's point, that if your 20TB disk is full of logs in a day, log rotation is the wrong solution
<jodh> slangasek: hourly would work for me, but I'd personally prefer a solution that allowed the period to be changed since a server may have different requirements to a phone :)
<xnox> infinity: i think it is my new tests, cause they are testing initctl.
<xnox> infinity: killall test_initctl to hopefully succeed the builds
<xnox> infinity: and i'll look into fixing the tests
<jodh> infinity: not upstart (yet it gets the blame of course), but the apps it's running :)
<infinity> xnox: Yeah, not going to do that.
<infinity> xnox: I cancelled the builds.
<xnox> infinity: thanks!
<infinity> xnox: (As I already said)
<infinity> xnox: I have one buildd still hung intentionally if you want debugging info, but I assume you can reproduce locally.
<xnox> infinity: kill it
<slangasek> jodh: a) we don't have user sessions on servers so that's a non-issue, b) on any client, you don't want the logs rotating away that quickly
<infinity> Would be a massive power draw on phones to rotate logs hourly too.
<infinity> (Or ever, really, truncating would be better)
<jodh> infinity: exactly - that's why my original solution allowed a .override to modify the period :)
<slangasek> jodh: my previous login session lasted 35 days (hurray for a new and functional laptop) - having any logs from the start of my session rotate off the disk after 8 hours is not reasonable
<infinity> jodh: ...
<infinity> jodh: The default would still be wrong, even if someone could fix it. :P
<slangasek> infinity: not really /massive/, these logs should all be small
<infinity> slangasek: Waking up to do log rotation hurts phone-like objects a lot, even if they're small.
<jodh> slangasek: I have no problem with you changing it to daily, but will that work reliably for devices that are suspended a lot?
<xnox> jodh: yes, cause it would be anacron handled.
<jodh> infinity: so disable the job entirely, or specify 'console none' in the noisy jobs
<slangasek> infinity: phones wake up more often than once an hour anyway, and the rotation only happens if there's been something logged that needs rotating; so I'm not convinced this has real impact
<infinity> jodh: I'm not thinking about what programmers/packagers should do, just about what's sane for a user's device.
<slangasek> jodh: yes, as xnox says, anacron handles the jobs on wake-up
<xnox> jodh: so "daily" means at most daily, cron still wakes up regularly to kick off daily if it wasn't run.
<slangasek> xnox: so shall I push a cron.daily->cron.hourly change to bzr for inclusion in your next upload?
<jodh> slangasek: as I say, if you want to change it, I have no problems. But clearly, a single logrotate per session has proven to be inadequate
<xnox> slangasek: i'm not planning any more uploads.
<slangasek> jodh: right, the "per session" being inadequate is understandable - I log out as little as possible
<infinity> xnox: Yes you are.
<infinity> xnox: Unless you don't plan to fix your hanging tests...
<xnox> infinity: oh right, the dbus tests, yes.
<slangasek> xnox: :-)
<slangasek> you don't /have/ to upload it, you can pass the buck to me if you prefer :)
<slangasek> but I'd appreciate it if you fixed your tests
<xnox> slangasek: with dbus test-suite fixes?! =) i'm happy to pass it on to you ;-)
<xnox> slangasek: snap.
<slangasek> yeah ;)
<slangasek> jodh, xnox: fwiw I think we should also have a 'maxage' setting in the logrotate.conf
<slangasek> oh, n/m
<slangasek> that doesn't help the problem I'm trying to solve
<slangasek> (which is, basically, the generic form of bug #1306736)
<ubot2> Launchpad bug 1306736 in update-notifier (Ubuntu) "update-notifier upstart job should be silent by default" [Undecided,New] https://launchpad.net/bugs/1306736
<sconklin> question: Once freeze hits, is another 'release' made like beta1 and beta2, or are the dailies all that's available? Specifically, will something appear here?: http://uec-images.ubuntu.com/query/trusty/server/released-dl.current.txt
<xnox> fixed test_initctl's left around, locally i also see 2 test_job left around, but that was not in infinity's paste. will upload soon.
<ScottK> sconklin: The dailies.
<sconklin> ScottK: Thanks
<infinity> xnox: I don't like the sounds of that...
<infinity> xnox: If you have other hanging tests, could those maybe also be fixed? :P
<xnox> infinity: well, if i manage to reproduce it yeah.
<xnox> infinity: i've rebooted my machine into trusty's upstart and i cannot reproduce the hanging test_job anymore.
<infinity> xnox: Fun.  Though, I hope it's not dependent on the *host* upstart somehow, cause that's very much not trusty on the buildds. ;)
<xnox> infinity: so i think my unit-test got reparented to pid1, which was broke cgroups enabled one, and that one did not reap/sigcont it. But yeah, our tests are not meant to talk to pid1....
<xnox> infinity: yeah, scary, _meh_
<infinity> Fun, fun.
<infinity> xnox: Well, if the thing I had hanging on my machines is fixed, we're probably good.
<xnox> yeah, i did reproduce left around test_initctl processes and those are all cleaned up.
<infinity> xnox: Kay, cool.  Gimme, then.
<infinity> xnox: Oh, it's in the queue.  Derp.
<xnox> infinity: digging deeper, it seems to be caused by launching a chroot build from an upstart user session (which is also cgroups contained by logind/cgmanager) i've raised bug #1306799 for jodh to look into....
<ubot2> Launchpad bug 1306799 in upstart (Ubuntu) "test_job hangs" [Undecided,New] https://launchpad.net/bugs/1306799
<xnox> infinity: you love user and chroot sessions, don't ya =)
<infinity> xnox: Oh, ugh.  You guys never inverted the chroot session default for me, did you? :(
<xnox> infinity: you were meant to send a merge proposal, no?!
<infinity> Which means all trusty-based buildds need --disable-sessions on the kernel commandline, or they get a useless ringbuffer full of vomit.
<infinity> xnox: Thanks, Lennart.
<cjwatson> Ouch
<infinity> xnox: In the real world, filing bugs is enough. :P
<xnox> infinity: well, everyone seemed to disliked my --no-sessions=true idea, so i didn't make a merge proposal.
<infinity> xnox: Would it have been so hard to just invert the default and add --enable-sessions?
 * infinity sighs.
<infinity> Oh well.
<infinity> Whatever.
<infinity> I thought your bikeshedding about it was you being sarcastic.
<xnox> infinity: i am very rarely sarcastic =)
<xnox> infinity: it built \o/
<doko> In file included from src/mlx5.h:40:0,
<doko>                  from src/buf.c:44:
<doko> /usr/include/infiniband/arch.h:120:2: error: #warning No architecture specific defines found. Using generic implementation. [-Werror=cpp]
<doko>  #warning No architecture specific defines found.  Using generic implementation.
<doko>   ^
<doko> cc1: all warnings being treated as errors
<doko> xnox, ^^^
<xnox> doko: and which package is that?
<doko> ohh, I thought you were talking about libmlx5 before ...
<xnox> doko: nah, upstart.
<doko> disabling werror for these architectures
<infinity> xnox: Soomething like this is what I had in mind: http://paste.ubuntu.com/7236725/
<infinity> doko: I'd just toss out "CFLAGS="$CFLAGS -Werror"" from configure.in .. It wasn't in the previous version of the same driver.
<doko> infinity, ok, better
<infinity> doko: You doing that, or shall I?
<doko> doing
<infinity> I already made Chris use dh-autoreconf, so that one-liner should do it, I'd think.
<infinity> doko: Try to avoid reading any of the source for this.  It's nightmare-inducing.  I've struggled hard to not waste hours fixing this, and the application it's a driver for. :P
 * infinity lunches.
<infinity> doko: That seemed to do the trick, thanks.
<oSoMoN> hello again, the upload of webbrowser-app corresponding to FFe bug #1306528 is sitting in the unapproved queue, Iâd appreciate if someone could accept it
<ubot2> Launchpad bug 1306528 in webbrowser-app (Ubuntu) "[FFe] file upload implementation in browser and webapps container" [Undecided,Triaged] https://launchpad.net/bugs/1306528
<oSoMoN> thanks!
<xnox> infinity: all tests pass, and the change looks good. committed upstream.
<infinity> I can haz cherry-pick closing the Ubuntu bug?
<olli> hey there, do we have an official RC image yet? would that be the 4/10 or 4/11 one?
<xnox> olli: there don't make RC images. there is final beta, and the next released images will be final 14.04 LTS release.
<xnox> s/there/we/
<bfiller> xnox: can we get the webbrowser-app promoted out of the unapproved queue please?
<olli> xnox, ok, I guess he got confused by https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule
<olli> xnox, thx
<xnox> bfiller: i'm not release team member.
<xnox> olli: it's a milestone, but without published images.
<bfiller> xnox: who could do that?
<xnox> bfiller: people who are in http://pad.lv/~ubuntu-release
<xnox> bfiller: aka Ubuntu Release Team
<bfiller> thanks
<bfiller> Laney: can we get the webbrowser-app promoted out of the unapproved queue please?
<xnox> olli: see https://wiki.ubuntu.com/ReleaseCandidate "During the week leading up to the final release, the images produced are all considered release candidates."
<cjwatson> has it been tested on desktop as well as on touch?
 * olli goes rtfming
<knome> just wondering if it would make sense to mention that the RC doesn't have any specific images on the release notes itself (briefly), since many people have come asking for the images around the channels
<cjwatson> I guess we probably want the google calendar change on desktop
<bfiller> cjwatson: yes it has
<cjwatson> Laney: (stand down)
<xnox> olli: it's linkified from the release schedule. each link/milestone/freeze explains what it means in ubuntu. as the terms are very generic.
<cjwatson> bfiller,oSoMoN: reviewing, give me a few minutes
<olli> xnox, stop rubbing it in ;)
<bfiller> cjwatson: great, thanks
<oSoMoN> cjwatson, awesome, thanks
<xnox> EOW see you on monday =)
<cjwatson> bfiller,oSoMoN: not a new problem or anything but for future reference literal "." characters in regexes should be escaped, to avoid matching "mailagoogle.com" or whatever
<bfiller> cjwatson: noted
<ogra_> oSoMoN, bfiller, i assume that doesnt have the OOM fix yet ?
<oSoMoN> cjwatson, good point, Iâm making a note to fix that on Monday
<cjwatson> ogra_: the changelog says it fixes bug 1306037, which seems relevant
<ubot2> Launchpad bug 1306037 in webbrowser-app "[webapp-container] Do not load qtwebkit libs (used as fallback) when they are not needed" [Medium,Triaged] https://launchpad.net/bugs/1306037
<ogra_> oh !
<ogra_> great
<ogra_> the MP hasnt changed
<oSoMoN> ogra_, it should address at least partially the issue
<ogra_> yeah, we also need the upstart-app-launch change
<ogra_> https://code.launchpad.net/~ted/upstart-app-launch/process-group-kill/+merge/215475
<ogra_> both together seem to work fine for me
<oSoMoN> cool
<cjwatson> bfiller,oSoMoN: accepted/unblocked
<cjwatson> (since we've had plenty of other desktopy fixes today)
<bfiller> cjwatson: great, thank you
<oSoMoN> thanks a bunch
<ogra_> cjwatson, what are my chances to get the MP above in ? (and why is upstart-app-launch seeded in the desktop ?)
<infinity> xnox: Did you review that yourself before applying it, or just trust my angry programming skills? :P
<cjwatson> ogra_: well, um, I'm going to bed shortly so probably not my decision :-)
<ogra_> (i can alternatively ship an override in lxc-android-config so that it would only affect touch)
<ogra_> ah, k
<cjwatson> ogra_: I'd actively prefer not to have an override though
<ogra_> yeah
<infinity> cjwatson: Can you give a quick review of the upstart in the queue?  It's my patch, so I probably shouldn't. :P
<ogra_> me too
<cjwatson> libupstart-app-launch2 has an rdepends tree that probably ends up in desktop somehow
<ogra_> but its my last resort to have the phone usable without affecting desktop
<ogra_> in case thats needed
<cjwatson> infinity: I think it would be worth finding Laney's codesearch thing and searching for --no-sessions in it
<bdmurray> slangasek: could you have a look at update-manager in precise-proposed?
<infinity> cjwatson: upstart gracefully ignores unknown options.
<cjwatson> ah, hm, ok
<infinity>         /* Ignore invalid options */
<infinity>         { '-', "--", NULL, NULL, NULL, NULL, NULL },
<infinity> cjwatson: If that hadn't been there, I would have left the old option as a no-op.
<darkxst> infinity, bug 1300464
<ubot2> Launchpad bug 1300464 in ubiquity-slideshow-ubuntu (Ubuntu) "[UIFe] Ubuntu GNOME Trusty Slides Update" [Undecided,New] https://launchpad.net/bugs/1300464
<infinity> darkxst: Given that the point of UIF is to protect OS changes from affecting documentation like the slideshows, I'm going to go with the slideshow itself not needing a UIFe. ;)
<cjwatson> infinity: accepted/unblocked
<cjwatson> ogra_: We've evidently had this conversation before (not necessarily you and I, but in general), because upstart-app-launch is explicitly whitelisted for auto-accept, and it isn't part of the freeze block.
<cjwatson> ogra_: So any upload should sail in.
<ogra_> oh, sweet !
<cjwatson> (Presumably because it's present on desktop for linkage reasons but not actually really used much in practice.)
<ogra_> thanks ... i could have checked the freeze exception bug
<darkxst> infinity, ok, that works for me
<cjwatson> I thought the slideshows got screenshotted elsewhere
<darkxst> anychance you can upload?
<cjwatson> I would say it's probably fine but a note to ubuntu-doc or whatever wouldn't go amiss
<cjwatson> Ah, Gunnar signed off already
<darkxst> cjwatson, alfredo already sent that
<cjwatson> So I guess that's fine
<infinity> cjwatson: For Ubuntu, that might be true, I doubt it is for the flavours in any way that they wouldn't already be prepared to take care of or not care about.
 * cjwatson nods
<infinity> I think what the slideshow needs is a screenshot of a web browser showing the help.ubuntu.com page with a screenshot of the slideshow.
<infinity> And no one can ever change anything, ever again.
<cjwatson> You just have to construct a quine slideshow
<cjwatson> https://github.com/mame/quine-relay
<darkxst> infinity, you can keep your help.u.c! we would of course have to use help.gnome.org :)
<infinity> cjwatson: I'd very nearly forgotten that horror^wwonder existed.
<cjwatson> It has "PLEA SEGIVEUP" buried in the middle of it, which I think says it all
<cjwatson> darkxst: Put a screenshot of help.u.c on help.g.o
<slangasek> bdmurray: looking
 * darkxst can only imagine the shock and horror that would occur if I requested that from my artwork team!
<darkxst> infinity, cjwatso, so can one of upload? or should I go begging on -devel?
<cjwatson> darkxst: I'm going to bed pretty soon, I'm afraid.
<cjwatson> Just waiting to get into the next round of this package bootstrap
<bdmurray> slangasek: I've verified bug 1274704 now if we want to expedite the SRU
<ubot2> Launchpad bug 1274704 in update-manager (Ubuntu Precise) "apport does not upload apt-clone_system_state.tar.gz (permission denied)" [High,Fix committed] https://launchpad.net/bugs/1274704
<slangasek> bdmurray: releasing, thanks
#ubuntu-release 2014-04-12
<infinity> If someone's around to review, the above glibc is needed on arm64.  mwhudson may have tested one patch and then sent me another. :/
<infinity> (This one was definitely tested this time... *sigh*)
<knome> infinity, in the Release Notes, under "New Features in 14.04", does the subheading "Ubuntu" mean "Ubuntu Desktop" or "Common" (which i'd imagine what "Updated Packages" are)?
<cjwatson> infinity: done
<knome> infinity, the more i look at the release notes page, and the various ways how teams (want to?) do their release notes, the more i think we should just keep the flavors out of the generic release notes and make sure the generic page either (1) stays clean enough to be sane to link directly (2) has comments that allow "including" parts of the pages to the flavor-specific ones
<Laney> cjwatson: did you want to unblock it too?
<cjwatson> oh duh, yeah, done
 * cjwatson uploads the source change necessary for ghc/ppc64el to unstable
<cjwatson> last bootstrap stages should have finished by the time I can sync that
<knome> what's the general thought about fixing a low, but annoying bug along with a high/critical bug during the final freeze?
<knome> (in the same package)
<cjwatson> I'd probably be OK with it as long as the diff was clear and we could make a good estimate from it that the risk is low
<cjwatson> (but away for a while now)
<knome> ok, cheers
<zequence> We might need to make a change in our seeds, and update our meta source (bluetooth stuff). Also, it would be great if we could get this uploaded Bug 1291675
<ubot2> Launchpad bug 1291675 in lmms (Ubuntu) "[FFe] LMMS 1.0.0" [Wishlist,Triaged] https://launchpad.net/bugs/1291675
<zequence> (we == Ubuntu Studio)
<knome> zequence, you should be in touch with cyphermox about the bluetooth stuff, i think he could take care of that...
<knome> since it is, ultimately, a side-effect of what we're doing
<zequence> knome: Yep. I'll talk with him later. A bit in a hurry atm :)
<knome> yep
<zequence> anyways, we'll most probably need to rebuild our ISO
<knome> ^ re "bluetooth stuff", we're planning to (re)demote gnome-bluetooth in network-manager-gnome to "suggests" to avoid installing unity-control-center + ibus
<xnox> infinity: what's up?
<tumbleweed> I'm completely out of touch these days, but ginggs asked me to look at bug 1289463. it's a tiny transition, so I'm tempted to approve it. any other opinions? (we often release with a broken cuda stack, and then fix it with SRUs, so screwing up here wouldn't be the end of the world)
<ubot2> Launchpad bug 1289463 in starpu-contrib (Ubuntu) "[FFe] Merge nvidia-cuda-toolkit 5.5 from Debian, transition to libcuda 5.5" [Undecided,Confirmed] https://launchpad.net/bugs/1289463
<ScottK> tumbleweed: I'd go for it.
<maclin_> slangasek, there is a critical problem about ubuntu kylin software center: Bug #1306871. I have added first-run update funciton. Can we update this version to solve this problem?
<ubot2> Launchpad bug 1306871 in Ubuntu Kylin Software Center "software center only shows few apps before apt update(è½¯ä»¶ä¸­å¿åªæ¾ç¤ºå°é¨åè½¯ä»¶ï¼æ´æ°æºåæ­£å¸¸)" [High,Fix committed] https://launchpad.net/bugs/1306871
<tumbleweed> ScottK: thanks
<bluesabre> release team, is it possible to get this bugfix release in before final release?
<bluesabre> https://bugs.launchpad.net/ubuntu/+source/abiword/+bug/1306952
<ubot2> Launchpad bug 1306952 in abiword (Ubuntu) "Abiword bug fix update for trusty" [Undecided,Confirmed]
<bluesabre> I understand that knome discussed this with cjwatson yesterday
<knome> well not the specific issue but generally pulling a few low-priority, low regression potential fixes in with the high/critical fix
<knome> and this would be the bunch ^
<slangasek> maclin: hi, looking at the bug now. do you need sponsorship+review, or just review?
<slangasek> maclin: well, I'm not able to load the bug page for some reason.  Do you have a code branch you can point me at for the fix?
<maclin> slangasek, thanks, I need both of that:)
<maclin> slangasek, the code branch is: https://code.launchpad.net/~ubuntukylin-members/ubuntu-kylin-software-center/trunk
<xnox> slangasek: should plymouth in shutdown mode, be started with "--attach-to-session" like we do on boot, and thus redirect all console output? (possibly further improving message less shut-down, no?)
<xnox> slangasek: maclin: https://code.launchpad.net/~xnox/ubuntu-kylin-software-center/invalid-syntax/+merge/215325 hasn't been merged. So if we want another upload, i'd like that to be included as well.
<xnox> slangasek: i can review trunk and make another release.
<slangasek> xnox: that'd be great, thanks
<slangasek> xnox: --attach-to-session> I confess that the usage of this on startup but not shutdown predates me; not sure if that was a latent bug or if the semantics of the option changed since it was first deployed
<xnox> slangasek: i've used attach-to-session, and removed all lightdm "clear > /dev/tty7" and I still have messages-less shutdown. I'll open a bug about upgrading to that configuration and test it more. I guess it's for u-cycle, with possibly sru's.
<slangasek> xnox: are we currently starting plymouthd on shutdown before lightdm is killed, and have we determined that this is safe?  (The last time I tried this I got bad things on shutdown)
<slangasek> xnox: if not, then there's definitely a window between lightdm stop and plymouthd start where messages *may* be left on console
<maclin> xnox,  i will check the merge
<xnox> slangasek: we explicetely enforce that lightdm stops, before plymouthd for shutdown is execed. I've added wait-for-state stopped in plymouth-shutdown.conf pre-start.
<slangasek> xnox: in this case, I don't think you should drop the 'clear' from the lightdm job
<xnox> slangasek: right, i see. Was the problem with exec plymouthd, or executing "show-splash" whilst lightdm was still using it?
<slangasek> xnox: since the 'clear' is there to deal with any kernel messages that may have been printed underneath lightdm while running
<slangasek> xnox: I don't remember, sorry
<slangasek> I think I was seeing problems with just the exec plymouthd while lightdm was running, no show-splash
<xnox> slangasek: re:lightdm kernel messages -> right makes sense.
<xnox> ok.
<infinity> zul: Your swift upload drops a patch as "no longer needed", but I see no indication of a fix in the new upstream.
<slangasek> xnox: can confirm here that the serial console output here from plymouth-upstart-bridge is much prettier now, thanks
<infinity> zul: Also,
<infinity> +Breaks: swift-object (<< 1.12.0-0ubuntu2), swift-object (<< 1.13.1~rc1-0ubuntu1~)
<infinity> +Replaces: swift-object (<< 1.12.0-0ubuntu2), swift-object (<< 1.13.1~rc1-0ubuntu1~)
<xnox> infinity: what were your questions about upstart patch? i've tested it locally from test-build before uploading and I saw no ill effects. are there bugs that got uncovered somewhere?
<infinity> zul: That makes no sense.  "foo (<< 1), foo (<< 2)" just means "foo (<< 2)"
<xnox> slangasek: excellent! =)
<infinity> xnox: Hrm?  No, I haven't noticed any ill effects, I was just curious how carefully you reviewed it, since it was something I just banged out in a few minutes due to frustration, I didn't test or anything. :P
 * slangasek looks at https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1305961/comments/4
<ubot2> Launchpad bug 1153661 in cryptsetup (Ubuntu) "duplicate for #1305961 The disk drive for /dev/mapper/cryptswap1 is not ready yet or not present" [Medium,Triaged]
<slangasek> seriously, how do you think that's "confirming" a bug?
 * slangasek finds himself losing time studying the Chinese characters in the description of that uksc bug, and decides he should probably find something more productive to do with his time this morning
<infinity> slangasek: You could come do my laundry.  I wouldn't say no.
<slangasek> infinity: oh, given those options I think I'll stay here and be amused that "software" has a literal translation
<xnox> slangasek: i need help with efibootmgr vs UEFI spec =) where do ACPI(a0341d0,0)PCI(4,0)03171000010000000000000000000000HD(1,800,f3800,9265fded-5be9-4265-a2c7-d5ebeba33954)File(\EFI\ubuntu\shimx64.efi) values come from / what is their definition?
<infinity> slangasek: Like "squishy goods"?
<xnox> slangasek: e.g. efibootmgr is failing to generate "HD(1,800,f3800,9265fded-5be9-4265-a2c7-d5ebeba33954)" from my device, instead it generates e.g. HD(1,0,0,1b960301), which tianocore is not happy about.
<xnox> (and does not boot)
<slangasek> infinity: "soft goods", but yes
<slangasek> xnox: ah, I don't know the answer to this
<slangasek> xnox: is this nvme again?
<xnox> slangasek: yes =)
<slangasek> xnox: hmm, I thought you got that fixed already by virtuous upgrades
<xnox> slangasek: oh, tianocore now knows about nvme, and our kernel/ubiquity/grub-installer do, the last portion to get it reboot out of the box is to get efibootmgr to generate the right entry. At the moment, i need to go into tianocore boot manager and add the right boot entry to boot it.
<xnox> i guess instead of reading the UEFI spec i can check tianocore sources to see how it decides what "HD(1,800,f3800,9265fded-5be9-4265-a2c7-d5ebeba33954)" means.
<slangasek> xnox: ok, so all I can suggest is to look in the efibootmgr source; I suspect it's getting these values from EFI itself, so it might be a remaining edk2 bug
<xnox> slangasek: oh really, interesting.
<slangasek> (I'm assuming you mean edk2 when you say tianocore, rather than one on a physical system?)
<xnox> slangasek: correct, i mean edk2.
<slangasek> xnox: well, the one bit looks an awful lot like a UUID, which I'm sure efibootmgr isn't generating on its own
<maclin> slangasek: xnox:  I have merged https://code.launchpad.net/~xnox/ubuntu-kylin-software-center/invalid-syntax/+merge/215325, the new code is on https://code.launchpad.net/~ubuntukylin-members/ubuntu-kylin-software-center/trunk
<xnox> slangasek: i see, i thought it would be GPT UUIDs or some-such but those didn't match.
<xnox> slangasek: also can i disable 3second grub-efi timeout on boot? it's annoying.
<slangasek> xnox: ah, so I see (comparing with my own entries here) that the first field in the parens is the partition number; not sure about the others
<slangasek> xnox: you can't disable it /in the archive/, it's the only way to make the boot menu accessible in UEFI
<slangasek> you can override it locally if you like
<xnox> i've set timeout and hidden timouts to zero, but that's not it.
<xnox> what's the "feature" name?
<slangasek> not sure
<slangasek> that's a cjwatson question :)
<slangasek> (for my part, I think it was a mistake to upgrade to a version of grub that natively supports a rich scripting language, and then continue to generate the scripts from another language)
<xnox> slangasek: found definition of the headers. So it looks like NVMe support in edk2 is bogus. Second field is "Type an integer between 0-255 or else the keyword MBR or GPT" of which "800" is not it =)
<cjwatson> I don't know what timeout this is
<slangasek> xnox: and the error is on the edk2 side, not the efibootmgr side?
<cjwatson> (But I only just woke up from a nap, bit woozy)
<slangasek> cjwatson: the EFI-can't-detect-shift-modifier timeout
<slangasek> I seem to have that disabled here, but buggered if I know which of the settings in my /etc/default/grub actually did it
<xnox> cjwatson: with GRUB_HIDDEN_TIMEOUT_QUIET=false and GRUB_HIDDEN_TIMEOUT=0 and GRUB_TIMEOUT=0 i get a 3second count-down on boot, when fastpath boot is enabled on my laptop.
<slangasek> xnox: and with GRUB_HIDDEN_TIMEOUT_QUIET=true?
<xnox> slangasek: 3s delay without countdown printed on screen.
<slangasek> really?  I don't see any 3s delays in the source, only a 5s delay
<cjwatson> OK, I really don't recall, sorry, would have to look when I'm properly awake
<xnox> slangasek: i've tested it by setting a very visual grub2 background image which stays for 3 seconds. E.g.: cp /usr/share/backgrounds/warty-final-ubuntu.png /boot/grub && update-grub && reboot
<cjwatson> (Which isn't going to be today at this rate, urgh)
<infinity> cjwatson: Waking up on Saturdays is overrated.
<xnox> cjwatson: no worries, you'll be able to experiment  / see it on my laptop next week =)
 * knome pours cjwatson a big cup of coffee
<infinity> cjwatson: Do we want a udeb britney block, as a subtle reminder that we might need to respin d-i (as we currently do for my glibc upload, for instance)
<infinity> Well, we don't *need* to, but I really dislike d-i not matching the sources.
<cjwatson> I guess it might be helpful
<cjwatson> There's already code for it I think
<infinity> Yeah, block-all-udeb
<infinity> I think.
<infinity> Oddly, not mentioned in the README, or I'm blind.
<infinity> Okay, not mentioned in the source either, so I might be on something.
<infinity> Meh, if I have to generate a "block-udeb" for every source that generates one, I think I just lost interest.
<xnox> slangasek: i found NVMe in the UEFI 2.4A spec, which defines special device path nodes.
<bluesabre> everybody appears when I walk away :)
<bluesabre> cjwatson: we have a clean diff now, if you're interested
<bluesabre> https://bugs.launchpad.net/ubuntu/+source/abiword/+bug/1306952
<ubot2> Launchpad bug 1306952 in abiword (Ubuntu) "Abiword bug fix update for trusty" [Undecided,Confirmed]
<bluesabre> (or awake enough) ;)
<cjwatson> bluesabre: I was just answering briefly earlier, I'm not fit to be the reviewer right now (and wasn't volunteering earlier).  Hopefully somebody else can
<zul> infinity:  crap can you reject swift please
<ScottK> zul: Done.
<knome> ScottK, any possibility you could look at the bug bluesabre mentioned?
<ScottK> Don't have time to look at uploading stuff now, sorry.
<knome> we'd be fine with a release team ACK that it's ok to land it
<infinity> knome / bluesabre: Go ahead and upload.  We can review it in the queue if there looks to be anything amiss, but a quick once-over looks fine.
<infinity> (Sorry, in a panic mode today, don't have the time for a solid review until I get my laundry done... Maybe I can look from the airport)
<knome> infinity, cheers, now onto finding a sponsor :)
 * ogra_ reboots after upgrade and hopes that the screensaver now stops keeping the focus in xchat instead of the password field when locking
<apw> ogra_, we all hope for that ...
<ogra_> heh, i'm not alone then :)
<apw> ogra_, man no, though i know the signs now before hitting return
<ogra_> change user works quite well as workaround
<apw> in my case always type /b 1 first, then your password just ni case, and if there is no cursor, fiddle with the indicators to get it back
<apw> i find opening and closing an indicator gets focus back
<ogra_> ah
<apw> but noticing is the key
<ogra_> thats easier than change user
<ogra_> yup
<cjwatson> Right, that's ghc bootstrapped on ppc64el, so hopefully lots of rows will clear out of /ftbfs/
<apw> cjwatson, you are a machine ...
<cjwatson> Obsessive would be closer to the mark
<cjwatson> Given it's a language I don't actually use :-)
<apw> heh ... well i am impressed none the less :)
<infinity> Insane is the word I'd use.
<infinity> And have.
<maclin> slangasek, xnor, could you take a time to review the ubuntu kylin software center for a new release: https://code.launchpad.net/~ubuntukylin-members/ubuntu-kylin-software-center/trunk?  I have merged https://code.launchpad.net/~xnox/ubuntu-kylin-software-center/invalid-syntax/+merge/215325.
<maclin> sorry,  xnox,  i typed a wrong word^
<maclin> This is mainly for the critical bug of cache update: #bug 1306871
<ubot2> Launchpad bug 1306871 in Ubuntu Kylin Software Center "software center only shows few apps before apt update(è½¯ä»¶ä¸­å¿åªæ¾ç¤ºå°é¨åè½¯ä»¶ï¼æ´æ°æºåæ­£å¸¸)" [Critical,Fix committed] https://launchpad.net/bugs/1306871
#ubuntu-release 2014-04-13
<Laney> ScottK: You typoed in your mailman hints
<Laney> Fixing for you
<ScottK> Laney: Thanks.
<tumbleweed> ScottK: would you mind binNEWing nvidia-cuda-toolkit?
<maclin> slangasek,xnox, could you help to review ubuntu-kylin-software-center code for a new release which solved the critical #bug 1306871?
<ubot2> Launchpad bug 1306871 in Ubuntu Kylin Software Center "software center only shows few apps before apt update(è½¯ä»¶ä¸­å¿åªæ¾ç¤ºå°é¨åè½¯ä»¶ï¼æ´æ°æºåæ­£å¸¸)" [Critical,Fix committed] https://launchpad.net/bugs/1306871
<tumbleweed> caught that out of the corner of my eye. thanks.
<cjwatson> jpds: syncing new upstreams of haskell packages at this point in the cycle is not necessarily highly recommended ...
<cjwatson> jpds: http://people.canonical.com/~ubuntu-archive/transitions/ghc.html :-(
<cjwatson> jpds: and debian-haskell@ says it breaks rss2irc
<xnox> maclin: how did you merge my branch? did you use $ bzr merge as listed on the merge proposal page?
<cjwatson> jpds: I've fixed up the transition problems, I think, but that still leaves rss2irc
<xnox> maclin: at the moment it appears that you are the committer, and am not the author of that commit.
<cjwatson> jpds: And git-annex seems to have new building-without-GHCi problems
<cjwatson> jpds: (latter taken to #debian-haskell)
<maclin> xnox, i merged the modification maually
<xnox> maclin: you missed one hunk, and the copyright/author attribution got attributed to you.
<xnox> maclin: i will revert your commit, and merge using bzr merge, with a correct debian/changelog entry.
<xnox> maclin: typically we use dch to prepare a single multi-maintainer changelog entry.
<cjwatson> if you're going to merge things manually then it's worth taking time to learn about things like --author
<maclin> xnox, thanks,  I did not get known with that. I will learn about it.
<xnox> maclin_: no worries. all updated, and uploaded release.
<maclin_> xnox, great,  is it able to hit the coming ISO image?
<xnox> maclin_: not sure, i think it will still need release team review and approval.
<maclin> xnox, I got it, thanks:)
<slangasek> maclin, xnox: so I am quite happy to review and accept the package in the unapproved queue, but it'll be about 2 hours before I have a chance to do so; if some other release team member reviews it before me, that's fine
<maclin> slangasek, kind, either is fine for us:)
<slangasek> maclin: uksc accepted.  BTW, I notice the restart_uksc() function is rather strange; I would expect a restart to be done by calling os.execv(), not by spawning a new process that kills the old one
<knome> can somebody from the release team ACK if it's ok to land 1210898?
<jdstrand> fyi, ^ it is a security update with packaging changes to fix bug #1305317. that bug should be fixed for release since oxideqt-codecs on the image is broken (and needed by webap-container). it went through citrain, testing, etc
<ubot2> Launchpad bug 1305317 in oxide-qt (Ubuntu) "Youtube webapp reads fewer videos with the new oxideqt-codecs package" [High,In progress] https://launchpad.net/bugs/1305317
<jdstrand> oh, and it fixes a few other crash bugs
 * slangasek waits patiently for a download from the queue so he can look
<knome> slangasek, while you wait... what about an ACK for our issue? :)
<slangasek> knome: looking
 * knome bows
<knome> would suggest reading the last comment at least
<slangasek> jdstrand: trying to unpack oxide-qt into a tempdir is making me stabby.  I don't suppose you have a debdiff somewhere I could just look at?
<slangasek> knome: so, this is obviously a fix that has no effect on !Xubuntu; I would say it's appropriate if the Xubuntu team thinks it is
<slangasek> knome: it also seems like something that could be fixed in a 0-day SRU; so it mostly depends on where you are with ISO testing?
<knome> we will need a respin anyway for another bugfix
<knome> which is why i'm up at 1am and trying to get this ready for uploading for tomorrow
<knome> :)
<slangasek> knome: ok, so consider this an ack for upload
<knome> thanks
<slangasek> jdstrand: oxide-qt-1.0.0~bzr501/chromium/src/base/process/launch_posix.cc.orig :P
<knome> slangasek, for the record, it probably affects ubuntu studio too, but they have been happy to take all of our fixes so far and told us they pretty much want that in the future as well.
<slangasek> ok
<slangasek> jdstrand: sigh, unauditable json files; maybe in the future someone could insert a few newlines in these here or there, and only remove the dangerous, bandwidth-wasting whitespace at build time? :)
<slangasek> (but maybe this is a chromium upstream problem...)
<slangasek> chrisccoulson, jdstrand: a bug ref or two in the changelog would've been nice...
<jdstrand> slangasek: yes, it was omitted but already building by the time I reviewed it in the ppa
<jdstrand> which is why I mentioned the bug ref
<jdstrand> slangasek: thanks for the review
#ubuntu-release 2015-04-06
<infinity> stgraber: Your tests pass!
<infinity> stgraber: It's a miracle!
<stgraber> :)
 * infinity lets lxc in.
<infinity> And swift tests passing again.  Yay.
<infinity> cyphermox: Planning to upload that gub2 fix to Debian as well (or get Colin to do so)?
<infinity> s/gub/grub/
<cyphermox> yes, I've already pinged colin with a git branch for debian
<infinity> cyphermox: Kay, well if the plan is to get it in Debian, not much point in the Ubuntu upload, we can just sync.
<cyphermox> infinity: it would be nice to get it earlier, rather than later
<infinity> Mmkay.  Just remember to syncpackage -f after it's in Debian too.
<cyphermox> yes, I know :)
#ubuntu-release 2015-04-07
<infinity> (base)adconrad@cthulhu:~/review/lxd-0.5$ cat debian/compat
<infinity> 7
<infinity> 9
<infinity> (base)adconrad@cthulhu:~/review/lxd-0.5$
<infinity> stgraber: ^-- So, uh, which one is it?
<infinity> stgraber: (pls fix, the syntax error there confuses the crap out of pkg-create-dbgsym's toddler-level parser)
<stgraber> oh wow, how did that happen
<infinity> stgraber: My bet is it was 7, lintian whined "build-dep on 9, but compat is 7" and the fix was "echo 9 >> debian/compat" instead of "echo 9 > debian/compat".
<infinity> stgraber: But that's just a guess.
<stgraber> seems probable. Though it's odd nothing blew up before, git tells me it's been like that ever since the first lxd upload :)
<infinity> stgraber: I only noticed it in passing cause I was watching a build.
<infinity> stgraber: And it really, really confuses pkg-create-dbgsym. :)
<infinity> stgraber: Oddly, it doesn't seem to upset debhelper itself at all.
<stgraber> alright, fix uploaded, thanks for catching :)
<stgraber> also:
<stgraber> stgraber@dakara:~/data/code/lxc$ lintian -iI --pedantic lxd_0.5-0ubuntu3.dsc
<stgraber> stgraber@dakara:~/data/code/lxc$
<stgraber> lintian doesn't appear to have a very good debian/compat check :)
<kickinz1> doko: I've updated bug 1430760, with the modifications requested.
<ubot93> bug 1430760 in docker.io (Ubuntu) "[FFE] Bump up docker.io version to 1.5 in Vivid" [High,Triaged] https://launchpad.net/bugs/1430760
<rbasak> infinity: fancy taking another look at the Docker FFe please? Bug 1430760. Haven't heard from doko, but kickinz1 added the two changes suggested by him.
<ubot93> bug 1430760 in docker.io (Ubuntu) "[FFE] Bump up docker.io version to 1.5 in Vivid" [High,Triaged] https://launchpad.net/bugs/1430760
<rbasak> We still aren't expecting things to work on arm64, but I'm told that even though it built before, it never worked.
<infinity> rbasak: I can't see why one wouldn't expect it to work, to be honest, unless the libgo runtime is fundamentally broken on that platform.
<infinity> rbasak: I assume the debdiff in the bug is against sid?
<rbasak> infinity: it's against experimental
<rbasak> kickinz1: ^^ that's accurate, right?
<rbasak> The last change will make it attempt arm64 against gccgo now I think, so that might help.
<infinity> Err, yes.  I meant "against Debian" :)
<infinity> Apparently against a version that isn't in Debian anymore.  Whee, hunting in snapshot commences.
<infinity> rbasak: The 1.6.0~rc4 upload has "- enable "docker.service" on boot by default for restart policies to work" ... Do we want to cherrypick that?
<infinity> kickinz1: ^
<rbasak> jamespage: ^^ any comment please?
<kickinz1> infinity, I would say yes,
<jamespage> rbasak, what was the question?
<rbasak> jamespage: do we want to cherry-pick "- enable "docker.service" on  boot by default for restart policies to work"
<rbasak> from 1.6.0~rc4?
#ubuntu-release 2015-04-08
<Mirv> hi. we're trying to free up CI silos and there are 3 trusty landings in trusty unapproved queue that have been in the queue 1-4 weeks: indicator-session, unity and compiz
<infinity> Mirv: Lemme have a poke.
<infinity> rsalveti: 95% of the diff for that hybris upload seems to have nothing to do with the changelog.
<Mirv> infinity: thanks. oh right, there is some packages in vivid queue too.
<infinity> Mirv: vivid's sorted, except for the hybris I just asked Ricardo about.
<infinity> Mirv: BTW, is your team represented at the Launchpad stakeholders' meetings?
<infinity> Mirv: Cause there's an item there (soyuz redesign) that could use a vote from you guys, so you don't have to keep bugging is to clear your silos out. :P
<Mirv> infinity: which of my teams you mean? :) SDK, Landing team, ?
<infinity> Mirv: Any or all who might have interest in the silo->launchpad part of landings being more smooth? :P
<infinity> silo->archive, I guess.
<Mirv> I guess landing team, sil2100 do you know if anyone from our side participates in ^?
<infinity> Mirv: Well, sil2100 has representation from me, as the Foundations rep at the meetings. :P
<Mirv> infinity: re: rsalveti's libhybris there is a note: " Pkgdiff is huge because of git-buildpackage, real diff can be found at https://code-review.phablet.ubuntu.com/gitweb?p=ubuntu/libhybris.git;a=commitdiff;h=dae292c01471a1c5994c3e17befb90990cbef867;hp=0ecf8ff1f32b0ce360a1b4bc31560e9e4e19def8"
<infinity> Mirv: But I wouldn't mind people from !Foundations weighing in.
<Mirv> infinity: well then we have representation, and thanks for representing us! :)
<Mirv> seriously there is not too many besides sil2100's and robru's possible input that might be needed
<sil2100> Yeah ;p
<infinity> Mirv: I appreciate that Ricardo thinks that's the real diff, but the rest of his diff really isn't just noise...
<Mirv> ok
<infinity> Oh, ugh.  No, maybe it is.  WTF has happened here. :/
<infinity> Just randomly moving hunks around willy-nilly.  Gross.
<infinity> The word for this is "unreviewable".
 * infinity will attempt to read it anyway.
<infinity> rsalveti: Ahh, interdiff to the rescue, it sorted out the old debian-changes and new.
<infinity> Mirv: silo land should be happier.
<Mirv> nice
<rbasak> infinity: so are you waiting for us on the FFe docker bug? Or are you expecting us to do something more?
<infinity> rbasak: Sorry, no, I got sidetracked with 1001 things.
<infinity> rbasak: Though, I was waiting to see if you were going to cherrypick that one debian bit.
<infinity> rbasak: Also, does docker have a testsuite at all, or is it just "it builds, ship it"?
<rbasak> infinity: we can, but then I'd ask that we do another QA cycle, which is manual. There's no test suite of which we're aware, so we smoke it by hand ("can we get a shell prompt on an image from the registry?")
<rbasak> infinity: so I'd like a final answer, and then we can do it and test it and upload.
<rbasak> kickinz1: is there a test suite that upstream use that I don't know about?
<infinity> rbasak: If this is our only way out of the compiler/upstream mismatch, I'm not sure I can say "no", as much as I'd like to. :P
<infinity> rbasak: Are we going to run into that same problem inverted with the request to SRU newer docker versions to older releases?  Cause I really don't like the idea of random packages dictating insanity like uploading new toolchains to stable releases.
<rbasak> I'm not sure I'm clear on the mismatch. Apart from it being gccgo vs. golang, we're just using the toolchains in the archive, aren't we?
<rbasak> I'm relatively new to Docker - kickinz1 and I are taking it over from jamespage.
<rbasak> If a newer docker version SRU requires a newer toolchain, then we'll have a problem that we'll have to tackle somehow (which maybe will mean we won't do it as we want in an SRU)
<rbasak> But I don't think that really has a bearing on Docker in Vivid. Right now it's just in Vivid and we want to bump it.
<rbasak> Like any other package.
<rbasak> (that we might want an exception for)
<rbasak> If we don't bump it, we'll be in a worse situation. The only alternative is to remove it, which I don't think we want to do.
<rbasak> As it's pointless to ship an old version.
<infinity> rbasak: The mismatch I refer to was the claim that the compilers in vivid can't build the docker in vivid -- it's the entire argument for the FFe.
<rbasak> Oh, so it FTBFS?
<rbasak> I want 1.5 in VIvid for ppc64el support.
 * rbasak reads the bug
<rbasak> I see
<infinity> rbasak: This may be specific to the PPC situation, mind you.
 * infinity tries to remember those calls.
<infinity> rbasak: Anyhow, if your by-hand testing has proven that it's not crap, you have my blessing.
<infinity> rbasak: If I had my way, docker would be removed from the archive and, shortly thereafter, the internet, but I don't think I'll get to win either of those.
<rbasak> infinity: OK. Thanks!
<rbasak> kickinz1: do you want to do the cherry-pick then to produce a final debdiff, then test that across every architecture you can? Once that's done we can upload.
<rbasak> infinity: I assume arm64 is still if-it-works, and OK to upload if it doesn't?
<infinity> rbasak: Err.  Well, it should at least build.  And work as well as it used to, whatever that was. :P
<infinity> rbasak: But it would also be nice to look at why it doesn't work, if it's not working.
<rbasak> I believe it never worked, previously built, but now fails to build.
<rbasak> infinity: it would be nice, but I'm not sure we have the time this cycle. I have some other things I need to take care of, and kickinz1 is working on Docker for snappy too :-/
<infinity> rbasak: And snappy also exists on arm64...
<infinity> If it's fundamentally broken in the toolchain or something, I can accept that's the state of things today, but if it's just a "we can't be bothered to investigate" deal, I'm less sympathetic.
<rbasak> I'm just focused on doing one thing at once.
<rbasak> I wouldn't accept a regression in functionality.
<rbasak> But my understanding is that there is no regression in functionality. So I'm focused on enhancing what we have right now, which is to get 1.5 in with ppc64el support within the time we have.
<rbasak> I don't think it's fair to use that as a lever to get us to take on new functionality that didn't work before too.
<infinity> Well, I'd kinda like to know who decided there was no regression here.
<infinity> The mention in the bug is based on hearsay.  Not any actual first-hand testing.
<rbasak> Would it be sufficient to get a first hand report in the bug confirming that arm64 has never worked previously?
<infinity> I see no evidence that you'll get that. :P
<rbasak> I will ask
<infinity> The claim in the bug report is based on the first attempt in the changelog to enable it and subsequent failure.
<infinity> And then doko enabled it in another upload.
<kickinz1> rbasak, there is a test suite but it is used when built using docker in docker, I will look if wae can re-use it.
<rbasak> infinity: I was under the impression that it didn't work despite a build success.
<rbasak> If I'm wrong and it did work then it's reasonable to require that we don't regress it now.
<rbasak> I'll ask about it further.
<infinity> rbasak: There's no indication of that in the changelog (which was the source referenced in the bug).
<infinity> rbasak: Basically, jamespage "enabled" it in ubuntu4, it FTBFS, he disabled it in ubuntu5, and then doko fixed it in the combination of 6+7
<jamespage> infinity, rbasak: there was an issue in one of the go deps which caused the build failure
<jamespage> I think doko fixed that up and re-enabled the support
<jamespage> but afaik its untested in terms of function
<infinity> I'd bet some hyperscale people have tried it out, or their customers.
<jamespage> infinity, rbasak: that's quite likely - lemme check
<rbasak> I see, thanks. I was under the impression that it was actually verified to be broken on arm64.
<rbasak> kickinz1: can you see if the latest debdiff builds on arm64 now? doko's latest change makes it actually try gccgo which is what we want I guess.
<rbasak> kickinz1: and if it fails, could you post the latest failure log to the bug please?
<kickinz1> rbasak: I'll look, but I already tried to build with dyngccgo. Re-trying anyway.
<infinity> I'm trying...
<jamespage> rbasak, infinity, kickinz1: I've requested test status from the hyperscale engineering manager
<infinity> Man, dist-upgrading rugby was a bad idea.
 * infinity twiddles his thumbs.
<infinity> kickinz1|afk: I don't understand how that debdiff works at all, it has build-deps that aren't in Ubuntu...
<infinity> Should we, I dunno, sync those? :P
<infinity> Ahh, that was mentioned in the bug.  Someone should have done that.
<infinity> Doing it now.
<rbasak> infinity: I thought we needed the FFe approved before syncing those? :)
<infinity> rbasak: Nah.  Random leaf packages don't break FFe.  Hard to freeze features in a package that didn't exist before.
<rbasak> OK
<infinity> kickinz1: So, the arm64 build dies pretty quickly with:
<infinity> obj-aarch64-linux-gnu/src/github.com/docker/libcontainer/namespaces/init.go:202:19: error: reference to undefined identifier 'system.Setgid'
<kickinz1> YEs I got this error before (you can see i tin the build logs in the bug comments).
<infinity> That seems like something that really shouldn't be arch-specific...
<infinity> Oh, you're kidding...
 * infinity vomits at libcontainer/system/syscall_linux_*
<infinity> So, that looks like it'd be trivial to fix, but wow.
<rbasak> That sounds like fun.
<rbasak> An aversion to libc?
<infinity> WAY TO WRITE PORTABLE CODE, PEOPLE.
<rbasak> System call numbers are defined in a Linux include file too!
<infinity> rbasak: http://paste.ubuntu.com/10771978/
<infinity> kickinz1: ^-- That makes it build on arm64.
<infinity> Err, fix my bad whitespace in that first hunk. :P
<rbasak> Thanks!
<infinity> http://paste.ubuntu.com/10771992/
<infinity> There.
<infinity> Prettier.
<infinity> It still throws one compiler warning that should porbably be investigated, but otherwise seems fine.
<infinity> /usr/lib/gcc/aarch64-linux-gnu/5/libgo.a(syscall.o): In function `syscall.Ustat':
<infinity> /build/buildd/gccgo-5-5-20150401/build/aarch64-linux-gnu/libgo/libcalls.go:3356: warning: ustat is not implemented and will always fail
<infinity> THat sounds like a toolchain/libgo issue anyway.
<infinity> I think.
<infinity> rbasak: No idea if it works, given the warning, it might not, but that would be doko's bug, not yours, at least it builds.
<infinity> rbasak: Ahh, I don't think docker actually calls ustat, I think it just masks the syscall, so that should be fine.
<infinity> rbasak: So, this might actually work.
<infinity> mdeslaur: Ew.
<mdeslaur> infinity: yeah, Ew++
<infinity> mdeslaur: Another one for the "why static linking is bad" bin, if you guys are keeping track so you have ammunition.
<mdeslaur> infinity: it's a macro
<infinity> mdeslaur: I know.
<mdeslaur> oh, I see what you mean, yeah
<infinity> mdeslaur: Point being that if the few inline bits from some headers can cause this much hassle, hundreds of thousands of lines of static crap is probably worse. :P
<mdeslaur> yeah, exactly
<jamespage> ScottK, hey - how are you feeling re https://bugs.launchpad.net/ubuntu/+source/python-eventlet/+bug/1424639 ?  we've expanded testing - all of our kilo-3 testing was done with this version and I've covered off the other deps manually
<ubot93> Launchpad bug 1424639 in python-eventlet (Ubuntu) "[FFE] eventlet 0.17.1" [High,New]
<ScottK> jamespage: Approved.
<sturmflut-work> robru: ping
<rsalveti> infinity: hey, got 3 changes for NM, but only one is a bug fix (the other 2 are just removing old code and style cleanup), wonder what would be your opinion on uploading the 3, since while cleanups can help later on when maintaining the code, they are not fixing anything
<rsalveti> infinity: the mrs, if you want to take a look first: https://code.launchpad.net/~phablet-team/network-manager/ofono-format-cleanup/+merge/255306
<rsalveti> https://code.launchpad.net/~phablet-team/network-manager/ofono-rm-unused-code/+merge/255305
<rsalveti> https://code.launchpad.net/~phablet-team/network-manager/lp1418077/+merge/255285
<rsalveti> will prepare a landing depending on your feedback
<robru> sturmflut-work: hi
<infinity> rsalveti: The cleanups are fine, IMO, if they're definitely unused code (the stuff wrapped in "#if 0" is clearly unused, just grep seriously hard to make sure other removed bits aren't referenced or exported somehow)
<rsalveti> infinity: yup, cool, thanks
#ubuntu-release 2015-04-09
<kickinz1> infinity, I updated the bug page with the new debdiff and new build logs. Quick tests work also on arm64, thanks!
<kickinz1> infinity bug: 1430760
<ubot93> bug 1430760 in docker.io (Ubuntu) "[FFE] Bump up docker.io version to 1.5 in Vivid" [High,Triaged] https://launchpad.net/bugs/1430760
<infinity> kickinz1: Looks good.
<rbasak> infinity: happy for me to sponsor? Could you approve the FFe in the bug now please?
<infinity> rbasak: Go for it.
<infinity> rbasak: Happy to see it got smoketested on arm64 too, and my patch actually works. :P
<infinity> rbasak: If 1.6 doesn't already contain such a patch (I didn't look), I hope someone will take care to forward it on my behalf, since my love for docker is in the negative? :P
<rbasak> kickinz1: could you please send infinity's patch upstream?
<infinity> kickinz1: Actually, scratch that, I'll submit a github PR for it.
<kickinz1> infinity, rbasak read, I'll let infinity do its PR.
<infinity> kickinz1: powerpc might need a similar fix, testing that too.
<kickinz1> infinity, thanks, I don't have access to any powerpc host for now. I'll check again if I can access porterboxes.
<infinity> kickinz1: Huh.  And while looking at this, I noticed armhf is actually broken too.  I wonder how it works. :P
<kickinz1> infinity: I have it working on cloud.online.net
<kickinz1> infinity: Do you want access to it ?
<infinity> kickinz1: What kernel version is it running on?
<kickinz1> some custom 3.19-aufs, let me check precisely.
<kickinz1> Linux scw-158f0c 3.19.1-181 #1 SMP Thu Mar 12 15:57:27 UTC 2015 armv7l armv7l armv7l GNU/Linux
<kickinz1> infinity, I did my work on this to get better perf than on beagleBoard.
<infinity> Hrm.  Well, setns will be failing on that setup.
<infinity> The upstream code is off-by-one.
<kickinz1> infinity, kick@212.47.232.30; I imported you ssh key.
<kickinz1> infinity, I use byobu.
<kickinz1> infinity, ^that was if you wanted to check.
<flexiondotorg> infinity, Could you update the ubuntu-mate-meta package for me please?
<flexiondotorg> infinity, https://bugs.launchpad.net/ubuntu-mate/+bug/1441728
<ubot93> Launchpad bug 1441728 in ubuntu-mate "Unable to mount devices with exfat formatted media when connected via USB" [Medium,Fix committed]
<infinity> flexiondotorg: Running the update thingee.
<flexiondotorg> infinity, Thanks :)
<flexiondotorg> infinity, Are you in the position to take a peek at something else for me?
<infinity> flexiondotorg: Maybe, depends on the thing.
<flexiondotorg> infinity, In the PPA you'll see indicator-application-gtk2 which is patched for MATE.
<flexiondotorg> https://launchpad.net/~ubuntu-mate-dev/+archive/ubuntu/vivid-mate
<flexiondotorg> infinity, Here is the code with my patch - https://code.launchpad.net/~ubuntu-mate-dev/indicators-gtk2/indicator-application-gtk2
<flexiondotorg> infinity, Here is the Approved merge proposal - https://code.launchpad.net/~ubuntu-mate-dev/indicators-gtk2/indicator-application-gtk2/+merge/244116
<flexiondotorg> infinity, However. I can get the package to build in a PPA. But in what whatever your devs use to build packages it failed.
<flexiondotorg> infinity, I can't reproduce that build fail.
<flexiondotorg> infinity, Help? ;)
<infinity> flexiondotorg: Before we worry about the testsuite failure, has this been passed by the lubuntu people?  This ships on their desktop as well.
<flexiondotorg> infinity, Well, I tested lubuntu. No issues. I couldn't raise anyone on the lubuntu team to test and confirm.
<infinity> flexiondotorg: Does this look sane: http://paste.ubuntu.com/10782997/
 * flexiondotorg looking...
 * infinity isn't sure why update.log isn't getting cleaned...
<flexiondotorg> infinity, Those look right to me. Other than perhaps I should add [!powerpc] to grub-pc in the live seed.
<flexiondotorg> infinity, The other changes are what cjwatson has helped me with a couple of weeks back.
<infinity> flexiondotorg: grub-pc doesn't exist on powerpc, that would be a no-op.
<flexiondotorg> infinity, OK.
<flexiondotorg> infinity, Then looks like what I expected. All recent changes have been to fix bugs.
<infinity> flexiondotorg: Okay, uploaded.
<flexiondotorg> infinity, Many thanks.
<infinity> flexiondotorg: As for the indicator thing, I can't reproduce the test suie failure.  I'm mildly concerned about what happens if both indicator-application packages are installed at the same time, but if you claim it doesn't break, then alright...
<flexiondotorg> infinity, Thanks for checking the build.
<slangasek> ^^ would appreciate if someone could review this cloud-init package (I uploaded)
<infinity> slangasek: Can't, I'm in a meeting.
<infinity> :P
<slangasek> infinity: pff blow off the meeting this is more important
<infinity> slangasek: What did you do to the changelog?
<slangasek> infinity: oh shoot, what did I do?
<infinity> slangasek: And the changes it referenced...
<slangasek> I may have not re-checked the changelog
 * infinity hands slangasek an "always debdiff before upload" lapel pin.
<slangasek> infinity: the bzr branch was up-to-date and debdiff is for old people
<infinity> slangasek: You still trust the bzr branches?  That's so cute.
<slangasek> when it's up to date, yes :P
<infinity> Clearly it wasn't actually. :P
<infinity> You were lied to!
<slangasek> infinity: right, so one person committed changes to the bzr branch and the other didn't, /lovely/
#ubuntu-release 2015-04-10
<rbasak> infinity: ^^ pretty please
<rbasak> Oh. Auto accepted. Never mind. Of course it's in universe and not seeded.
<gaughen> stgraber, slangasek - Would one of you have a look at the walinuxagent FFE pretty please - https://bugs.launchpad.net/ubuntu/+bug/1442392
<ubot93> Launchpad bug 1442392 in Ubuntu "[FFE] update walinuxagent to 2.0.12" [Medium,Confirmed]
<zul> Can someone please promote python-pysaml2 please (lp: #1407695)
<ubot93> Launchpad bug 1407695 in xmlsec1 (Ubuntu) "[MIR] python-saml2, xmlsec1" [High,Fix released] https://launchpad.net/bugs/1407695
<stgraber> gaughen: added to my todo, should get to it later today if slangasek doesn't beat me to it
<gaughen> thanks stgraber!
<stgraber> oops, forgot to pass the auto-approve flag ^
<stgraber> gaughen, utlemming: so I'm confused, that FFe (bug 1442392) appears to only list bugfixes, what's the added/removed/changed "feature" in there?
<ubot93> bug 1442392 in Ubuntu "[FFE] update walinuxagent to 2.0.12" [Medium,Confirmed] https://launchpad.net/bugs/1442392
<LocutusOfBorg1> can anybody please process fglrx trusty new queue?
<infinity> rbasak: ^-- That one builds on all arches.
<infinity> rbasak: And submitted upstream as https://github.com/docker/libcontainer/pull/524
<utlemming> stgraber: in re to FFe (bug 1442392) for walinuxagent, this is mostly a bug fix upgrade. But there is code that supports other things that made me think that a FFe was in order.
<ubot93> bug 1442392 in Ubuntu "[FFE] update walinuxagent to 2.0.12" [Medium,New] https://launchpad.net/bugs/1442392
<utlemming> stgraber: for example, there is code for GPT partitioning of the ephemeral device, but it won't be hit by a normal Ubuntu user. Or CoreOS support.
<stgraber> utlemming: ok, granted
<gaughen> stgraber, thanks!
<utlemming> stgraber: awesome, thank you
<rbasak> infinity: thank you!
<infinity> rbasak: Of course, now I feel dirty because my name will end up in the docker AUTHORS file.
<rbasak> :-P
<infinity> rbasak: Not that it should, really, my commits weren't exactly copyrightable, but they don't seem to make the distinction. :P
#ubuntu-release 2016-04-11
<slangasek> darkxst: debug messages> many modules include a 'debug' option which will increase verbosity to syslog, provided you're logging syslog debug messages somewhere
<ypwong> cyphermox, we found a serious issue in grub that worth a look: https://bugs.launchpad.net/ubuntukylin/+bug/1559933
<ubot5`> Launchpad bug 1559933 in Ubuntu Kylin "[Grub] There are messy codes on displaying Chinese characters in grub after install xenial-desktop_0320." [High,Triaged]
<tyhicks> pitti, stgraber: hi - I believe that the failing lxc test that's preventing the apparmor migration is a bad lxc test: "There is no download available for release=xenial, stream=daily, arch=amd64"
<tyhicks> pitti, stgraber: I see the same failure when running the lxc tests locally without a the new apparmor
<stgraber> hmm, so something happened with simplestreams over the last few days which broke that test
<stgraber> but indeed, unlikely to have been caused by the apparmor upload
<tyhicks> thanks for the confirmation
<stgraber> I'm assuming you attempted a retry of the test already?
<tyhicks> yes
<tyhicks> twice on amd64 and i386
<tyhicks> both sets of retries failed
<stgraber> doing a local adt run here as a simple lxc-create does work fine for me
<stgraber> well, adt is crashing here (as in the tool) so not much luck with it, will let pitti figure it out
<stgraber> tyhicks: just got adt to run properly here and it passed fine, so looks like it's something in the adt environment which changed
<tyhicks> stgraber: ok, thanks for looking into that - I don't guess there's anything that I can do on my end
<stgraber> nah, though it means that if you ever run into that problem again, you can run adt-run locally and it should avoid that particular failure
<stgraber> might have been a firewall or proxy change in scalingstack, I'm sure pitti will take a look once he's around
<tyhicks> stgraber: I did do a local adt-run and saw the same failure
<stgraber> oh, odd
<stgraber> PASS: lxc-tests: /usr/bin/lxc-test-ubuntu
<stgraber> just got that 5min ago
<tyhicks> my run was ~2 hours ago (without the new apparmor)
<stgraber> adt-run -U --apt-pocket=proposed lxc --- adt-virt-qemu adt-xenial-amd64-cloud.img
<stgraber> that's what I ran here
<tyhicks> I'll give that a try in a bit
<stgraber> also odd that it doesn't affect ppc64el
<tyhicks> agreed
<stgraber> pitti: looks like ppc64el adt is kinda stuck, had a lxd adt stuck on nova create for a while now
<stgraber> tyhicks: btw, another adt retry for lxc just passed, so if that was the only blocker, apparmor will migrate very soon
<pitti> tyhicks: apparmor is held back by regressing systemd; that and the regressing udisks2 are because "scsi_debug" is missing, it seems that linux-image-extra does not get installed any more all of a sudden; investigating
<pitti> lxc seems happy again
<stgraber> pitti: looks like ppc64el adt for lxd also got unblocked, package just migrated now
<pitti> yeah, but that looks relatively stable (http://autopkgtest.ubuntu.com/packages/l/lxd/xenial/ppc64el/)
<stgraber> yeah, just not sure why it was seemingly stuck for over half an hour on nova create
<tyhicks> pitti: I also can't locally reproduce the systemd "storage" test failure that is preventing the apparmor migration: "modprobe: FATAL: Module scsi_debug not found in directory /lib/modules/4.4.0-18-generic"
<pitti> stgraber: pretty much everything has a timeout, I guess it timed out, and auto-retried
<pitti> tyhicks: yes, that's the thing I meant above 4 mins ago
 * pitti shakes fists at lcy01
<tyhicks> pitti: ah, I missed that message, sorry!
<pitti> tyhicks: I hinted apparmor for now to unblock this
<tyhicks> pitti: thank you!
<lordievader> Good morning.
<davmor2> jibel, cyphermox, slangasek, seb128: hmmm no image today?
<infinity> davmor2: Need a bit more verbosity.
<davmor2> infinity: no xenial images build today the page is missing from the cdimages http://cdimages.ubuntu.com/daily-live/20160409/
 * infinity raises his brow at the empty directories.
<davmor2> infinity: current image is based on the 8th
<rbasak> Launchpad was down briefly last night. Related?
<infinity> No.  Today's just exploded too.
<rbasak> I fixed the libgda5 FTBFS yesterday, but am not sure whether to upload: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811068
<davmor2> infinity: you understand my asking now right :)
<ubot5`> Debian bug 811068 in libgda5 "FTBFS: FAIL: check_vcnc: ../../test-driver: line 107: 77018 Aborted" [Serious,Open]
<rbasak> Old libgda5 was building against an older sqlite. Rebuilding it even with my patch may regress it.
<rbasak> The source would only be made better, but the binary may regress from the perspective of a user.
<jamespage> ^^ that swift upload should resolved the autopkgtest failure that's blocking 2.7.0 from the release pocket...
<rbasak> ^ will (should?) dep-wait without mysql-connector-c++
<rbasak> (he says to the mystery person accepting his stuff)
<rbasak> Oh, the mystery person being the unseeded auto-accept.
<teward> heheh, rbasak
<cyphermox> stgraber: since you cared about it before to review: ^
<cyphermox> this fixes the current autopkgtest failure, which was due to a changed default I didn't notice, because I was testing with my own existing connections.
<cyphermox> infinity: remember my cpc merge for ubuntu-cdimage?
<stgraber> cyphermox: looking
<Mirv> ^ you can reject ubuntu2, which only contains a partial fix to the emulator image building (or ubuntu-touch installation). ubuntu3 handles all upgrade situations. sorry for the hassle.
<Mirv> the gles packaging is in the middle of migrating to completely new system as mandated by CI Train changes, but I'm going to keep everything in sync now.
<xnox> infinity, cjwatson - why you hate UTF-8 on s390x? Looking at buildds, all arches are now on UTF-8, apart from s390x
<xnox> cause on s390x in addition to LANG=C.UTF-8, there is also LC_ALL=POSIX which trumps the UTF-9-ness
<xnox> cause on s390x in addition to LANG=C.UTF-8, there is also LC_ALL=POSIX which trumps the UTF-8-ness
<cjwatson> bluff
<cjwatson> sbuild-package:export LANG=C.UTF-8 LC_ALL=C.UTF-8 LANGUAGE=
<cjwatson> unless sbuild hates us lots, which is possible
<cjwatson>     $host_defaults->{'ENV'}->{'LC_ALL'} = 'POSIX';
<cjwatson> that line dates from 2010 though
<cjwatson> oh I don't know, please puzzle something out, I need to think about SSO stuff
<xnox> =)
<xnox> cjwatson, https://youtu.be/IXmF4GbA86E
<xnox> oh wait you said SSO, not SOS =) oh well.
<xnox> i guess POSIX is coming from the host itself, rather than the chroot, which is coming from debian, because our hosts got cross-graded _from_ debian rather than being ubuntu installs.
<xnox> infinity, could you ssh and fiddle with builders?
 * xnox is not going to fiddle with them via HMC console, because i shouldn't.
<cjwatson> can't be the host
<cjwatson> I mean except for xenial's sbuild
<cjwatson> and "grep -rs POSIX /etc" has nothing of interest
<cjwatson> I strongly suspect xenial's sbuild, just can't easily prove it right now
<xnox> ack.
<cpaelzer> Hi, we just realized that likely due to the reorg regarding build-dependencies we had a few packages falling out of main the last days
<cpaelzer> in particular all of dpdk and openvswitch-switch-dpdk
<cpaelzer> what would be the appropriate way to address that?
<infinity> cpaelzer: openvswitch-switch-dpdk was never in main...
<cpaelzer> infinity: I'll have to clarify that with jamespage tomorrow then
<cpaelzer> the changes made by doko back then wehn bug 1492186 was closed seem to be lost
<jamespage> cpaelzer, infinity: I'm still here
<ubot5`> bug 1492186 in dpdk (Ubuntu) "[MIR] dpdk" [High,Fix released] https://launchpad.net/bugs/1492186
<jamespage> and it was never in main - that's quite correct
<cpaelzer> but dpdk was, the bug even holds the "override component to main"
<cpaelzer> I wonder what was lost
<jamespage> cpaelzer, infinity: that said it is build from a main source package, so I can seed if if thats OK
<jamespage> that would pull the runtime dpdk bits back into main
<cpaelzer> jamespage: IIRC you intended bring in openvswitch-switch-dpdk anyway
<cpaelzer> yet I wonder why dpdk itself was "lost"
<jamespage> cpaelzer, its only a build-time depends atm
<infinity> Right, it's not a runtime dep of anything in main, nor is it seeded, so universe is correct.
<jamespage> it was pulled into main by the ovs source package, but only used by the -dpdk binary package
<infinity> jamespage: If the intent is to support ovs-dpdk, seeding that is your path of least resistance.
<cpaelzer> so was I right to assume that it was lost due to the changes to the archive regarding build dependencies?
<jamespage> infinity, that is the intent yes - I'll add it to the supported seed now
<cpaelzer> the intend was to support that
<cpaelzer> thank you jamespage
<cpaelzer> and thanks infinity for clarifying
<jamespage> cpaelzer, infinity: done
<cpaelzer> jamespage: thanks
<davmor2> infinity: did you figure out what was up with the images or is that a job for today?
<infinity> davmor2: cjwatson sorted it out, a fresh batch is being attempted right now.
<davmor2> infinity: nice one so hopefully in the morning we should have new images then?
<infinity> davmor2: Or right now.
<infinity> davmor2: I see 20160411.2
<davmor2> infinity: yeah but I finish now so I don't care till the morning ;)
<infinity> davmor2: Well, they'll still be there in the morning. :P
<davmor2> infinity: just happy to have images again \o/ good work everyone :)
<stgraber> final 2.0 release ^
<slangasek> so someone appears to have bulk-downgraded the packages that were in components-mismatches
<cjwatson> wat
<cjwatson> example?
<slangasek> doko: was this you?
<cjwatson> should be visible in publishinghistory
<slangasek> cjwatson: libiberty would be an example
<cjwatson> https://launchpad.net/ubuntu/+source/libiberty/+publishinghistory doesn't show a downgrade
<cjwatson> better example? :)
<slangasek> cjwatson: it doesn't?  main->universe?
<cjwatson> oh that sort of downgrade!
<cjwatson> I thought you meant version
<slangasek> ah no
<slangasek> sorry, 'demotion'
<slangasek> but it doesn't tell me who did it
<slangasek> and at least the discussion we had here concluded we wanted two sets of eyeballs to sanity check before demoting
<slangasek> and libiberty is one I know it *wasn't* sane to demote, because it only builds a static lib and needs to be in Built-Using
<slangasek> apw, infinity, RAOF, arges, Daviey, jdstrand, pitti, doko, stgraber, wgrant: did any of you mass-demote the packages that were listed on component-mismatches?
<stgraber> wasn't me
<stgraber> I did see the discussion last week and agree that we need to take a close look before demoting stuff :)
<slangasek> ok looks like it was pitti :)
<lamont> slangasek: I'm preparing to rage-upload for bugs 1569077 and 1528710, fyi...
<ubot5`> bug 1528710 in python-django (Ubuntu) "overly agressive URLField validation causes failures" [Medium,Confirmed] https://launchpad.net/bugs/1528710
<ubot5`> bug 1569077 in python-formencode (Ubuntu) "Incorrect regex for TLDs causes locally defined TLDs to be rejected" [Critical,New] https://launchpad.net/bugs/1569077
<mwhudson> just in case the archive team did not have enough to do
<slangasek> lamont: well I assume that's bugfix, or else you would have asked for an FFe
<lamont> slangasek: yes.  silly upstreams keep breaking my entire environment
<lamont> kindly, django already called it a regression and fixed it in 1.8.10, so I'm just backporting that fix to 1.8.7
<lamont> slangasek: the one I already discussed with infinity is the postfix 3.1.0-2 upload that I will do in a (today).  Upstream is far more pedantic than I, and everything in 3.1.0 (vs 3.0.4) is either a bugfix we'd want to backport, or a bugfix that we need to backport
<lamont> but I need to re-review the list before I so assert
#ubuntu-release 2016-04-12
<cyphermox> slangasek: ^
<cyphermox> seems to work correctly (as far as I could figure out for test cases) on ppc64el.
<cyphermox> (that was for ltrace, obviously)
<RAOF> Someone's having a joke with that package name :)
<slangasek> cyphermox: I see a lot of backported arm commits, but only power bugs linked in the changelog; were these requested somewhere, needed somehow as deps of the power commits you cherry-picked?
<cyphermox> they're required as deps of the POWER commits, sadly
<cyphermox> or we could spend time to untie it all
<slangasek> ok
<slangasek> cyphermox: and which archs did you test the result on?
<cyphermox> amd64, ppc64el, and briefly on armhf
<cyphermox> on armhf, AFAICT it was already broken, it still is.
<cyphermox> it's partly why I'm trying to set up my raspberry pi to have an environment in which I'm more certain of the starting state
<pitti> infinity: ^ I'd appreciate if you could review this soon, as there's some urgency wrt. the IBM fix
<pitti> (just three fixes and a couple of test improvements)
<infinity> pitti: Don't virtio eth devices suffer exactly the same issue as ibmveth?
<pitti> infinity: no, ifnames recognizes and names virtio devices, QEMU provides some kind of slot number
<pitti> "ens3"
<infinity> Hrm.  I would think openfirmware gives some faux physical address to veth as well.
<pitti> I looked through the udev dump and there was nothing except the MAC
<pitti> so I was quite happy that the IBM engineer helpfully pointed out that the number in DEVPATH is "hardware"-assigned
<pitti> (and that's what they want to use for naming them)
<infinity> pitti: Ahh, yes, that's the of I/O address.
<infinity> pitti: I didn't get that far in the comments yet. ;)
<pitti> heh yeah, took a bit of back and forth to get there
<infinity> And +1 for including it in the udeb.
<pitti> that's crucial, yes; otherwise the installer would generate a wrong /e/n/i
<infinity> Quite.
<infinity> Which is why I was looking for it. :P
<infinity> Cause I think we've been down that painful road before.
<pitti> during that I noticed that we forgot to include 73-idrac.rules in the initrd
<pitti> probably not that important, but presumably more important for ibmveth
<pitti> thanks
<pitti> tests will fail because of bug 1569204
<ubot5`> bug 1569204 in network-manager (Ubuntu Xenial) "xenial regression: does not start any more under upstart" [Critical,Triaged] https://launchpad.net/bugs/1569204
<pitti> I assume cyphermox is asleep now, so I'll get that fixed
<infinity> pitti: Speaking of initrds, did you test that that rule DTRT in a busybox environment?
<pitti> infinity: well, I tested that I get my eth0 device renamed to ibmveth2 in the initrd
<infinity> Same thing.
<pitti> I had to fudge the rule a bit to work with a qemu device, of course
<infinity> qemu does ibmveth.
<pitti> i. e. attach a fake ENV{XDEVPATH} and change teh rule to use XDEVPATH, but should be by and large the same
<infinity> Oh, unless you were testing on x86. ;)
<pitti> yeah, of course I was, I don't have that kind of access to ppc64el
<pitti> (can't attach them to scalingstack instances)
<infinity> qemu-system-ppc64 works on x86 too, mind you.
<infinity> Just not super speedy.
<pitti> oh, and that does ibmveth?
<infinity> Yeah.
<pitti> slick
<infinity> pitti: Bah.  I wish I could read.
<infinity> pitti: You have mismatched quotes in there.
<infinity> Which I didn't notice before I accepted...
<infinity> pitti: Also, a trivial command-line test doesn't seem to work.
<infinity> (base)adconrad@nosferatu:~$ export DEVPATH=/devices/vio/30000002/net/eth1(base)adconrad@nosferatu:~$ /bin/sh -ec 'D=${DEVPATH#*/vio/}; D=${D#3}; echo ${D%%%%/*} | sed s/^0*//'
<infinity> 2/net/eth1
<infinity> Pretty sure that should be '2'?
<pitti> did you replace %%%% with %% on the command line?
<pitti> %% == % in an udev rule (escaping)
<infinity> Oh.
<infinity> Yeah, that works better. ;)
<infinity> Still mismatched quotes, though, unless I can't read.
<pitti> I might have wedged this up after testing, I added the match on ACTION==, I think
<infinity> pitti: cmd="sh -ec 'cmd"
<infinity> pitti: You seem to be missing the closing ' after cmd.
<pitti> (and had to revert my testing changes)
 * infinity says abiguously, after using 'cmd' twice in his example.
<pitti> argh, yes
<Kamilion> many eyes...
<infinity> pitti: Also, not sure if 30000000 is a valid address (ie: ibmveth0), but if it is, your rule won't work for that either.
<pitti> infinity: ah, that would end up as "ibmveth" only, I suppose we want "ibmveth0"
<infinity> We would, yeah.
<pitti> infinity: thanks for the review, I'll fix both issues
<infinity> pitti: Extra fun, cutting the 3 based on the IBM engineer's "it's always 3" is BS.
<infinity> pitti: I have /sys/devices/vio/71000002/net/eth0 here. :P
<infinity> pitti: That appears to be a qemu/kvm default setup.
<pitti> infinity: so you get an ibmveth710002?
<pitti> ^ that puts back the upstart job (above bug), tested in VM with current NM
<infinity> 'D=${DEVPATH#*/vio/}; D=${D%%/*}; D=${D##*0}; echo ${D}' ... That solves the "start may not be 3" thing.  Doesn't deal with the possibility of 0.
<pitti> infinity: what's the problem with "cut off a leading 3 if it's there"?
<pitti> D=${D#3} is a no-op if it doesn't start with 3
<infinity> pitti: Because I have a leading 71? :P
<pitti> infinity: then that doesn't do anything
<infinity> pitti: Yes, but then your sed doesn't sed.
<pitti> right
<pitti> but then I also don't really want it to
<pitti> you might have a 3000001 and a 7000001
<infinity> I suppose I could have two virtual busses.  Maybe.
<pitti> unless there's some guarantee that this can't happen?
<infinity> I've never seen a setup like that.
<pitti> infinity: so in your rule you just cut out the inner 0's, making it "ibmveth712"? and "ibmveth32" for the original bug's example?
<pitti> ah no, you cut out the prefix entirely
<infinity> pitti: No, my rule ended up with the same result as yours, but... Yes.
<pitti> infinity: if that is safe, that WFM
<infinity> pitti: The only thing that's probably 100% safe is using the entire I/O address, but I can't see anyone liking that solution.
<infinity> pitti: But I've never seen a setup with multiple virtual busses.  3* and 7* seem most common.
<pitti> infinity: so adding a final echo ${D:-0} should solve the "300000" case as well
<infinity> pitti: I miss 70-persistent-net.rules :P
<pitti> I don't :)
<pitti> but anyway, nothing stops you from creating one again, with pretty names :)
<infinity> Indeed, 'D=${DEVPATH#*/vio/}; D=${D%%/*}; D=${D##*0}; echo ${D:-0}'
<infinity> And no more sed.
<infinity> Which was bugging me.
<pitti> yeah, it's sad that shell globs don't work for a thing like "any number of '0's"
<infinity> pitti: It's one of those "POSIX is old" things. :/
<pitti> infinity: ${D%%%%/*} is missing, or am I overlooking somethign?
<infinity> pitti: bash has awesomely powerful regexes, but no can use.
<infinity> pitti: It's there, I just didn't escape it.
<pitti> infinity: well, I know bash has =~, but that doesn't work in ${var..} substitutions?
<infinity> (Because I was testing on the CLI)
<pitti> oh, ${var/pattern/string}
<infinity> pitti: You can use #{haystack/needle/replacemen}
<infinity> Yeah.
<infinity> It's quite nice.
<infinity> But if no one has declared bash the One True Shell yet, I don't think it's ever going to happen.
<infinity> So, POSIX it is.
<infinity> Untill we ditch UNIX entirely and start over.
<Ukikie> I used  ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules  >_>
<infinity> pitti: As for the "you can write your own" argument, the nice thing about 70-persistent-net.rules being done automagically was that I had a template for how to write the rule. ;)
<infinity> pitti: And then would rewrite it based on which device I wanted named what.
<pitti> see /usr/share/doc/udev/README.Debian.gz
<infinity> Cause ain't no one got time to learn how to write udev rules just because they want their interfaces renamed.
<pitti> example rules how to name them by MAC, by USB ID, or PCI vendor/model
<infinity> pitti: Aha, danke.
<infinity> pitti: That MAC address is a lot shorter than the one that used to be written by 70-persistent.
<infinity> pitti: Was the rest just pointless fluff? :P
<infinity> Old:
<infinity> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="68:f7:28:77:e3:a8", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
<infinity> New:
<infinity> SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="11:22:aa:bb:cc:33", NAME="eth-dmz"
<pitti> infinity: that was because the generator supported different kinds of matches, of which MAC only was one
<pitti> (but I don't know why dev_id and type got matched, seems rather pointless)
<infinity> Kay, well, the shorter rule is almost something a human could learn.
<infinity> The long one was the reason I gave up trying.
<pitti> [    1.147326] virtio_net virtio0 ibmveth2: renamed from eth0
<pitti> and that happened in initramfs
<pitti> yay
<infinity> I can test this on a real ppc machine too, if you like.
<pitti> that'd be nice; let me toss you the final commit once I pushed it (typing commit log ATM)
 * infinity nods.
<pitti> http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=66e67d1
<pitti> ah, forgot to mention the 'handle device number 0' in the commit log
<infinity> You also kept the comment stating that it "usually starts with 3", but meh. :P
<pitti> http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=b83febe255
<infinity> (That's probably true on LPARs)
<pitti> infinity: ah, let me fix that too
<pitti> infinity: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=3dee9da
<infinity> pitti: Rebooting.
<infinity> 2: ibmveth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
<infinity> [    3.896825] ibmveth 71000002 ibmveth2: renamed from eth0
<pitti> LGTM
<infinity> Yep.
<pitti> infinity: ok, merging into Ubuntu, and reuploading; many thanks for your help!
<infinity> pitti: Ta.
<pitti> uploaded
<pitti> this also adjusts one tests for NM 1.2 not logging to syslog by default any more
<pitti> ... which seems like a bug, but it's not really systemd's concern
<infinity> pitti: Not your bug but wow, that assumption that system and user locales are the same is special. :P
<pitti> infinity: err, what?
<infinity> pitti: In the n-m upstart job.
<pitti> infinity: heh, yes
<pitti> I put back the file as it was, let's not introduce conffile changes now
<pitti> but apparently we got along with that for years
<infinity> pitti: Well, I assume it's a fundamental architectural defect in n-m (as if it doesn't have enough of those).
<infinity> pitti: Since one would expect a proper architecture would be for the daemon to pass C strings to the client, and have the client look them up based on *its* environment.
<infinity> (or similar)
<pitti> yeah, or error codes
<Mirv> hmm, are the non-languagepack translations on track to be updated this cycle? it's reported that at least ubiquity does not have up-to-date translations, and bzr log po or debian/real-po shows they'd be last updated in October 2014
<pitti> but dgettext()ing them on the client side sounds fine too
<pitti> (with NM's domain)
<knome> ubiquity-slideshow-ubuntu needs an upload too
<knome> Mirv, ^
<davmor2> infinity: so I have an image in current from yesterday but nothing for today, I assume that is down to a test failure or something right?
<Mirv> knome: yep, they're all listed at https://wiki.ubuntu.com/NonLanguagePackTranslationDeadline
<knome> :)
<Mirv> I'm just wondering since I remember there was reshuffling of responsibilities within Foundations team when colin stopped doing some of the things, and I wonder if this was assigned to someone
<infinity> davmor2: I see a fresh daily for today, no idea why it's not in current/ yet.  Ask your manager. :P
<knome> Mirv, mhm, indeed
<davmor2> infinity: my manager is currently flying to managers sprint :P
<infinity> davmor2: Anyhow, for QA people, I'd expect you to ignore the pending/current directories and just consume the most recent date.
<infinity> davmor2: Especially given how often the smoketest infra breaks.
<davmor2> infinity: nope always import from current/pending as they tend to be the images that work :)
<davmor2> infinity: pending will be the most recent iirc
<infinity> davmor2: pending should be the same as the most recent date, yes.
<infinity> davmor2: current is a crap shoot. ;)
<davmor2> infinity: indeed pending is 12th but
<pitti> FTR, one major reason (ssh startup failure) for failing tests got fixed a few days ago
<davmor2> infinity: I bet it is failing autopackage
<infinity> autpkgtests don't relate to this at all.
<infinity> Unless you mean something else.
<infinity> You could also just be impatient.  I don't know how to see into the guts of the ISO smoketests.
<infinity> pitti sounds like he might know.
<pitti> e. g. https://platform-qa-jenkins.ubuntu.com/job/ubuntu-xenial-desktop-i386-smoke-default/
<pitti> today's test is running
<pitti> https://platform-qa-jenkins.ubuntu.com/job/ubuntu-xenial-desktop-amd64-smoke-default/ too
<infinity> What a pretty graph...
<pitti> https://platform-qa-jenkins.ubuntu.com/view/desktop/ actually looks pleasantly green (aside from the upgrades)
<infinity> tar: Unexpected EOF in archive
<infinity> tar: Error is not recoverable: exiting now
<infinity> qemu: terminating on signal 15 from pid 8826
<infinity> That haunts us everywhere.
<rbasak> Is overlayfs involved?
<rbasak> There's a bug/interaction between tar and overlayfs that makes things break.
<pitti> rbasak: it uses an overlay, but the qemu-img one
<pitti> but I think this is some weird kind of hiccup with qemu's 9p file system
<pitti> so far I got a few reports from here and there, but I didn't get ssh access to a machine which exhibits this
<infinity> pitti: Ugh.  I didn't think that through.  It'll fail for LPARs with > 10 (or >16, not sure if that address is hex) interfaces.
<pitti> I got some more reports from trusty hosts, apparently wily's/xenial's qemu behaves a bit better there
<infinity> pitti: Might need to get sed back in the mix to actually write a real regex. :/
<pitti> infinity: oh, 3000102?
<infinity> pitti: Well, or just 30000010
<infinity> pitti: Cause it's a greedy match for *0, so 10 would end up as 0.
<pitti> ah, this certainly needs to be a non-greedy match, i. e. up to first 0 only
<pitti> ^ u-d-common is just a simple FTBFS fix, FTR
<infinity> pitti: I'm going to sleep before I break more things. :P
<pitti> infinity: I'll stare at this harder and make more experiments in a VM
<pitti> D=${D#*0}  ought to work already
<infinity> pitti: Cutting all the zeroes out of the middle when we don't know what the bus addresses might be is a bit of a pain.
<infinity> Since you could have something like 30100010, and you want the result to be 10.
<pitti> hmm, D=${D#*00} then?
<apw> is that two fields in there or something ?
<pitti> if we have some ugly-long names in utter corner cases it doesn't hurt
<pitti> apw: bus number slot number, yes
<infinity> pitti: Yeah, 00 gives us 100 interfaces, I think if they have more, sucks to be them.  That's an alright compromise.
<pitti> infinity: no, more should be fine, with non-greedy match and sed
<pitti> $ X=300001002
<pitti> $ echo ${X#*00} | sed 's/^0*//'
<pitti> 1002
<infinity> non-greedy would beak, say, 30020010
<infinity> I'm not sure how many digits are owned by the "bus" and how many by the "slot".
<infinity> If that terminology even applies.
<pitti> infinity: I think for 30020010 it sounds saver to name it ibmveth20010
<infinity> I think it might be just straight up I/O addresses.
<pitti> if you configure 5-digit slot IDs, you get to keep both halves, I think
<infinity> pitti: Kay.  I'm down with that.
<pitti> I don't know what a HMC is, but the IBM engineer said that you select the slot id there
<infinity> pitti: In the wild, it seems 3000xxxx (for LPARs) and 7100xxxx (for qemu) seem to be the two most common anyway.
<infinity> One can configure qemu to give you literally any address, but I think you get to keep the pieces if you do that.
<infinity> pitti: An HMC is an external machine that pools all your chassis' into one configuration group so you can spin up LPARs on any of them.
<infinity> pitti: Not really relevant to the discussion, except than it's the simple way to configure lots of LPARs.
<davmor2> infinity: go to sleep already :P
 * pitti yays at "sudo udevadm test /class/net/eth0" being such an useful tool
<infinity> pitti: Okay, the other scenario I know of (kimchi, a libvirt frontend) appears to pretend to be an LPAR, and configures qemu with 3000xxxx addresses, so that would work with your double-0 and non-greedy fix.
<infinity> Worst case, they'd get ibmveth1000, but meh.
<pitti> we could also drop the "veth" in between
<infinity> pitti: Though, that also lends some credence to those being 1234:1234 bus:slot.
<pitti> so that we get ibm0 or ibm1000, but not sure if there's other ibm-ish devices and that'd be confusing
<infinity> And maybe cutting the string in half before stripping leading zeroes would be sane.
<infinity> Or ibm71s10
<infinity> Which would match the way PCI is done, sort of.
<infinity> But also uglier.
<pitti> PROGRAM="/bin/sh -ec 'D=${XDEVPATH#*/vio/}; D=${D%%%%/*}; D=${D#*00}; D=`echo $D | sed s/^0*//`; echo ${D:-0}'"
<pitti> 3000000 â ibmveth0
<pitti> 3000002 â ibmveth2
<pitti> 3001002 â ibmveth1002
<pitti> don't like the sed, though
<pitti> it could be replaced with a while loop and chopping off 0's one by one
<pitti> which at least is pure sh
<pitti> (no bash in initramfs)
<infinity> That sed doesn't seem to be doing much there...
<pitti> it transforms ibmveth0002 to ibmveth2
<pitti> I'll see to making that D=`echo $D | sed...` a bit more elegant
<pitti> but I think from an "what's the effect" POV this seems to work fairly well now
<apw> can we not find out the format of that number ?
<apw> if that is an s390x thing, then i would expect it to be in 4 digit hex halves, as the channels are all 4 digit things
<infinity> apw: ppc.
<pitti> apw: we got it in the context of ppc64el, bug 1561096
<ubot5`> bug 1561096 in systemd (Ubuntu Xenial) "STC850:Brazos:Br16:Br16p05: Network ethernet port name changed under Ubuntu 16.04 with added adapters (ibmveth)" [High,Fix committed] https://launchpad.net/bugs/1561096
<pitti> for i in 1 2 3 4 5 6 7; do D=${D#0}; done
<pitti> poor man's sed
<pitti> and ugly as hell, but avoids calling sed and we know it can't be more than 6 0's
 * pitti isn't sure if `seq 8` spanws a shell, but I guess it does
<pitti> oh, wait, can do with while
<infinity> pitti: It's 8 chars, not 7.
<pitti> right, we have 8 chars, minus bus ID, minus the two 0's we cut off anyway
<pitti> so we should have at most 5 zeros
<pitti> hm, while [ "${D%?*}" = 0 ]; do D=${D#0}; done doesn't do what I want
<pitti> posix shell string manipulation sucks
<pitti> /bin/sh -ec 'D=${XDEVPATH#*/vio/}; D=${D%%/*}; D=${D#*00}; while [ "${D#0}" != "$D" ]; do D=${D#0}; done; echo ${D:-0}'
<pitti> that works
<xnox> is there any info on as to how Task-* things get published from seeds? there is "Ubuntu Desktop Usb" task which is published for s390x and that one really shouldn't, as there is no ubuntu-desktop metapackage....
<cjwatson> germinate doesn't care whether the metapackage exists
<cjwatson> xnox: I assume you actually only care about it being visible in tasksel?
<xnox> yes.
<xnox> or rather that it shouldn't be visible in tasksel on s390x... I would actually be quite happy with all them to exist, but hidden.
<xnox> i already got one support request "i've tried installing 'Ubuntu Desktop Usb'...."
<cjwatson> yeah, will fix.
<xnox> i'm strugling to find where the Task-* stanzas are processed at all and/or published =) and greping ArchiveAdmin wiki page didn't find things.
<xnox> thanks!
<cjwatson> lp:ubuntu-archive-publishing is the main bit
<cjwatson> but in this case it's more important how it's processed by tasksel itself
<cjwatson> xnox: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.xenial/revision/2451 should deal with it
<xnox> cool
<infinity> pitti: Assuming it is groups of 4, replacing D=${D#*00} with D=${D#????} makes the result a bit saner.  The whole thing is gross, though. :P
<xnox> cjwatson, also we might want to just kill the whole of usb seed, because we are not limited by CD size, and Ev is no longer testing broken, odly shapped, usb sticks from china. =)
<Kamilion> about as annoying as my dell machines calling their intel 10g nics p55p1 & p55p2...
<cjwatson> xnox: not my problem :)
<pitti> infinity: can do that as well, and it's a bit more predictable; I think I'll still keep the while loop to chop off '0's at the beginning, still better than calling sed IMHO
<Kamilion> http://paste.ubuntu.com/15782157/ nic renaming gives me such a headache.
<infinity> pitti: "better". :)
<infinity> I miss the good old days when, to get the names I wanted, I had to reorder the cards in my chassis.
<pitti> infinity: http://paste.ubuntu.com/15782387/ tested with all of the above scenarios again
<pitti> it's that or just put four copies of D=${D#0}
<infinity> pitti: I don't like it, but I've run out of better ideas. :P
<pitti> -ACTION=="add", SUBSYSTEM=="net", NAME=="", DRIVERS=="ibmveth", PROGRAM="/bin/sh -ec 'D=${DEVPATH#*/vio/}; D=${D%%%%/*}; D=${D#????}; while [ ${D#0} != $D ]; do D=${D#0}; done; echo ${D:-0}'", NAME="ibmveth$result"
<pitti> +ACTION=="add", SUBSYSTEM=="net", NAME=="", DRIVERS=="ibmveth", PROGRAM="/bin/sh -ec 'D=${DEVPATH#*/vio/}; D=${D%%%%/*}; D=${D#????}; D=${D#0}; D=${D#0}; D=${D#0}; D=${D#0}; echo ${D:-0}'", NAME="ibmveth$result"
<pitti> wow, this is even shorter by 3 chars, and avoids a potentially infinite loop
<infinity> pitti: Heh.  Yeah, loops in udev rules seem a bit wrong.
<infinity> pitti: Anyhow, I don't think we're going to make it much prettier without help from the kernel driver.
<pitti> infinity: so I guess four copies instead of while it is
<xnox> for s390x i just patched upstream systemd stock renaming rules.... =)
<xnox> (in C, rather than shell in udev rules)
<infinity> What names do we get on s390?
<pitti> but that's for ccw, not for ibmveth
<xnox> for a cccgroup-0.0.0100 -> which is a 00.0.0000-ff.f.ffff range we now get "enc100" that is "en" for ethernet, "c" for ccw bus, and full-id but with leading zeros stripped.
 * infinity has a 70-persistent-net.rules on all his s390x hosts, so no idea what the names would be.
<xnox> short, stable, determenistic, pretty enough.
<pitti> http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=8b023317 it is
<infinity> pitti: You may, indeed, want to suggest to IBM that if they care deeply about this, they commit something upstream, since they should understand their bus/id mapping better than we do.
<infinity> pitti: But I think our hack is "good enough".
<pitti> yeah
<pitti> infinity: not sure if we want yet another upload right away, but if  they want to test on a daily image ASAP, then I figure we do
<infinity> pitti: Yeah, upload away.
<infinity> Can never have too many.
<pitti> uploaded
<davmor2> sudo goto sleep infinity
<pitti> as soon as he reviews that upload :)
<davmor2> pitti: so it's your fault he is still awake shame on you ;)
<pitti> yeah, I'm afraid today it  is :(
<infinity> pitti: Why did a patch move in series...?
<pitti> infinity: it moved from "Debian patches" into "backported from upstream" as my upstream PR just landed
<pitti> infinity: this is both for bookkeeping, but also for correctly being able to build "daily upstream" packages
<infinity> Ahh.
<pitti> as it needs to ignore the backported patches but apply the distro ones
<pitti> http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=a65bb9
<infinity> pitti: Your ch; ch; ch; change is accepted.
<pitti> infinity: thanks; thanks; thanks!
<pitti> and now sleep well
<ogra_> can someone let ubuntu-core-meta in please
<doko> ogra_, done
 * ogra_ hugs doko ... thanks !
<Ukikie> owncloud?
<mvo> hi, if I could get review/approval for snapd, that would be awesome
<pitti> mvo: done
<pitti> doko: base-files> is that supposed to go in now, or next week and this was just for having the upload ready when we need it?
<doko> pitti, don't know. maybe wait for infinity
<pitti> yeah, I left it in the queue for now
 * mvo hugs pitti
<jdstrand> slangasek: re mass demote> I did not demote anything
<mhall119> infinity: slangasek Laney pitti I need somebody to look at https://bugs.launchpad.net/ubuntu/+source/muon/+bug/1562406 and tell the Kubuntu team if there's something more they need to do in order to get their package updated in xenial please
<ubot5`> Launchpad bug 1562406 in muon (Ubuntu) "[FFe] Update to latest upstream version" [Undecided,Confirmed]
<mhall119> the folks who usually help them get their packages in have not been available lately, so they need someone else to help them
<mgz> ha, was about to poke about juju-mongodb2.6 package and someone moved it forwards in the last hour. thanks!
<slangasek> hmm, so who did accept juju-mongodb2.6, which I had put comments into the bug log on? (LP: #1557852)
<ubot5`> Launchpad bug 1557852 in juju-mongodb (Ubuntu) "[needs-packaging] juju-mongodb3.2 in xenial, wily, and trusty" [Wishlist,Incomplete] https://launchpad.net/bugs/1557852
<pitti> not me, I thought you were handling that
<slangasek> I was, until somebody accepted it out from under me ;)
<doko> slangasek, me. based on infinity's approval to process NEW packages
<slangasek> ok
<slangasek> fair enough :)
<doko> this gcc-5 upload has for bug fixed, two wrong-code issues on armhf and ppc*, a libgomp update, and an unrelated sh4 change, everything else is patch noise
<mgz> slangasek: do you mean the 3.2 package or the 2.6 one?
<mgz> I don't see any comments in the juju-mongodb2.6 bug
<slangasek> mgz: where was the juju-mongodb2.6 bug?  I was commenting on the 3.2 bug because I thought that was the only bug
<slangasek> 1557830 maybe
<mgz> slangasek: yeah. they're all linked from the juju ffe bug
<mgz> slangasek: so, to clarify, 3.2 won't build on armhf
<mgz> 2.6 is fine.
<slangasek> ok
<slangasek> mgz: then we probably want it built consistently across those archs (including armhf and i386)
<mgz> er, I say "fine"... it builds but dies
<mgz> there was some debate about what we do over that given we don't care about running state servers on armhf
<mgz> see the bug
<mvo> snapd is like super simple, one line change only :)
<ogra_> the one line that makes everything explode :)
<kickinz1> o/
<kickinz1> I would like to get python-docker 1.8.0 into universe, it would be usefull for openstack magnum project.
<kickinz1> https://bugs.launchpad.net/ubuntu/+source/python-docker/+bug/1569424
<ubot5`> Launchpad bug 1569424 in python-docker (Ubuntu) "Please update python-docker to 1.8.0 from upstream" [Undecided,New]
<slangasek> mvo: you want *passing* tests?  crazy talk
<mvo> slangasek: :)
<slangasek> mvo: looks like there's a duplicate snapd upload though with the same version number
<mvo> slangasek: yes, its the same, sorry, I was confused by the lack of a mail from the archive
<mvo> slangasek: maybe my mailserver ate it
<mvo> slangasek: just reject that duplicated one, sorry again
<slangasek> mvo: done
<mvo> ta
<rbasak> ^ I think this (my) upload might be unnecessary.
<rbasak> It was to delete src:mysql-5.6, but of course as it's an alternative I think not needed? If not needed, please reject.
<rbasak> superm1: ^
<rbasak> infinity: around? Is this accurate please? ^^
<rbasak> I don't want to miss this and get stuck after FinalFreeze :-/
<tgm4883> rbasak: talking about the mythtv upload?
<rbasak> Yes
<tgm4883> rbasak: not sure if yours is necessary or not, but we need to do a new one later today
<rbasak> tgm4883: it shouldn't cause any harm for Xenial to do it, since the 5.6 packages are intended to disappear soon anyway. But superm1 mentioned backporting, and I can see that this change could get in your way for backporting a little, so if it's unnecessary to do in Xenial then no point in making you maintain it differently.
<rbasak> Now that I've thought about it I'm fairly sure it's unnecessary but I'd appreciate if an archive admin could confirm, since I don't want to end up stuck.
<superm1> it sounds to me that it's unnecessary at this point too
<rbasak> slangasek: could you advise please if you're around? ^^
<slangasek> rbasak: looking
<slangasek> rbasak: yes, the alternatives don't matter.  They make reverse-depends less clear as a tool for processing removals but that's a tooling issue
<slangasek> rbasak: you want me to reject?
<rbasak> slangasek: yes please. Thanks!
<slangasek> rbasak: done
<rbasak> superm1, tgm4883: so go ahead and ignore that and upload your own ubuntu4 without my change. Sorry for the noise.
<rbasak> nnnnnnnnnnnThanks again!
 * rbasak will hold his Alt key down harder next time.
<slangasek> if they wanted to include that change that would also be an option :)
<tgm4883> superm1: can you do an upload later?
<rbasak> Yes, but I don't think they do because they try to keep their backport delta small (presumably)
<superm1> yeah we use same packaging for backports, so keeping delta small is ideal
<tgm4883> I think there were questions whether I did it correctly last time. it was showing a bunch of changes?
<mdeslaur> important samba update to fix Badlock vulnerabilities ^
<xnox> mdeslaur, so it's real...
<mdeslaur> xnox: it's got a logo, it must be real! :)
<slangasek> as opposed to an urban legend? :)
<slangasek> mdeslaur: tested everywhere, same patches as in security pocket, etc?
<teward> heh
<slangasek> I guess you're taking the upstream release, so
<slangasek> I know where to yell at them if it breaks
<mdeslaur> slangasek: I've ran our usual QA scripts on it, and we're moving trusty and wily to that version also
<mdeslaur> since the fix is over 400 commits
<mdeslaur> yes, you've read that right
<teward> mdeslaur: *four hundred* commits? o.O
<mdeslaur> teward: yep
<rbasak> slangasek: how do you feel about for example: Build-Depends-Indep: mysql-server-core-5.6 | mysql-server-core
<rbasak> That would in theory work with src:mysql-5.6 removed.
<rbasak> But maybe better to rebuild against 5.7 now?
<rbasak> (this is amarok)
<slangasek> rbasak: "rebuild against" - I would assume that's only used for tests at build time or something?
<rbasak> I think so, yes.
<slangasek> but why would it be in Build-Depends-Indep instead of Build-Depends, hmm
<rbasak> However, if behaviour is different with 5.7, then the test using 5.6 wouldn't be valid.
<rbasak> slangasek: digikam is the same (question), except BD not BDI. I think that's all the seeded reverse deps.
<rbasak> (I will check again)
<rbasak> (and akonadi is in unapproved)
<lamont> http://paste.ubuntu.com/15799193/ <-- at some point, postfix had a blanket feature freeze exception for minor revs (which 3.0 -> 3.1 would qualify for)... is that still in effect? Nearly all of what I see in the current 3.1.0 release notes are things that I'd want to have (as an admin) in xenial, and upstream will unsupport 3.0 much sooner than 3.1, and ... who has better memory of things than me?
<infinity> lamont: I don't think you ever had a blanket FFe or SRU exception for *minor* releases, though probably for micro.
<infinity> lamont: That said, I think 3.1 is probably going to be safe enough anyway, and smart to get into xenial, so future updates are 3.1.x micros instead of 3.0.x micros.
<infinity> lamont: But gimme some time to go over it a bit.
<lamont> infinity: how about this... you review, ponder, scream at me as needed, and when you're happy, sync 3.1.0-2 from sid?
<infinity> lamont: Sounds fair.
<lamont> ta
<lamont> (and when do I come begging next?)
<infinity> lamont: In a few hours, probably, time's running out to be slack. :P
<lamont> infinity: I know exactly what you mean
<lamont> infinity: also, I assert that squid3 change above is (1) trivial, (2) benign, and (3) in something that's disabled anyway. :/
<lamont> infinity: and (4) perfectly fine for post-beta
<rbasak> infinity: some advice please? Do I need to remove mysql 5.6 build deps when an alternative (to the right) uses a non-version-specific one that 5.7 provides?
<rbasak> (scroll back ~90 minutes)
<infinity> rbasak: That's a no, for both deps and build-deps.  If this is causing you any issues, we should just remove mysql-5.6
<infinity> rbasak: It's entirely valid to have alternate deps that don't exist in xenial (for easy backporting or whatever).
<rbasak> infinity: OK, and to be clear, the order of alternatives doesn't matter?
<infinity> rbasak: Not one bit, *if* one of them doesn't exist.
<infinity> rbasak: Matter a lot when they both do.
<infinity> s/Matter/Matters/
<rbasak> OK, thanks.
<rbasak> I'd been focusing on the seeded rdeps first.
<rbasak> There are still universe deps on the old libmysqlclient18 binary, so I need to lose those next.
<rbasak> I presume I can't request removal of 5.6 until those are done.
<rbasak> (most are clear; just unrelated FTBFS left)
<infinity> rbasak: Yeah, no can remove until the transition is done.
#ubuntu-release 2016-04-13
<stgraber> oh, didn't expect an auto-accept, nice :)
<stgraber> cyphermox: ^ that upload is me fixing nm-openvpn to be a bit less busted as far as IPv6 as it was the only blocker for me to run on IPv6 only
<cyphermox> stgraber: ack. I'm looking at a ppp bug myself
<stgraber> cyphermox: that patch doesn't change default behavior and only allows passthrough of the tcp6 and udp6 protocols when the user is already specifying it. It's probably suitable for upstream though I'd expect they'd like to make it a bit more complete.
<cyphermox> ok
<cyphermox> I'm not sure yet, but I think my pptp tests were crashing my router.
<stgraber> specifcally, if you want to connect over IPv6, you must add the :udp6 or :tcp6 suffix with my patch, instead of having openvpn try ipv6 and fallback to ipv4 which would be preferred
<stgraber> I figured I'd keep things simple this late in the cycle :)
<cyphermox> mmkay
<stgraber> I could find a nice way to have OpenVPN do the IPv6 to IPv4 fallback... I think the right answer is to generate a second --remote config entry for the fallback protocol, but then the patch becomes significantly larger :)
<stgraber> my patch is still right, the right fix would just be added on top, so the change ever makes it upstream, we can cherry-pick it safely
 * stgraber is happy, Google fixed Hangout over IPv6 this morning and now NM is fixed too, those were the only two reasons why I was adding IPv4 connectivity back sometimes!
<cyphermox> yippee.
<cyphermox> stgraber: if Videotron could do a bit of work to get IPv6 to finally be available at large
<cyphermox> it's so close
<stgraber> haha, yeah, that's why I'm on teksavvy DSL here :)
<cyphermox> except so retarded with that weird Comcast DHCPv6 PD crap
<cyphermox> well, I'm surprised to see that teksavvy prices aren't that far from those of Videotron
<cyphermox> stgraber: if you have time to review stuff, ubiquity & its slideshow ;)
<cyphermox> heh, nevermind about the ubiquity upload, looks like that's TheMuso's, and I have some merging to do
<stgraber> I'm assuming we're keeping base-files in the queue until a bit before we start spinning rc images?
<infinity> stgraber: *shrug*
<stgraber> I don't mind personally but I've noticed that the queue has been emptied except for base-files a few times today :)
<infinity> stgraber: It's not like it says "we're released, tell your friends", it just doesn't say "development series" anymore.
<infinity> But yeah, traditionally, we seem to accept it right before the weekend respin.
<mwhudson> ^ we have the security fix already in ubuntu5 but uploading the release seems like it makes sense
<stgraber> mwhudson: good, so that means I don't have to re-upload lxd since it picked up the fix with ubuntu5 already
<mwhudson> stgraber: indeed
<mwhudson> although hm
<mwhudson> stgraber: looks like the fix is a bit more extensive than the patch i had, there's some ecdsa stuff to
<pitti> infinity: ^ this is quite a mouthful, please see bug 1553309
<ubot5`> bug 1553309 in openssl (Ubuntu) "[FFe]: Include FIPS 140-2 into openssl package" [Undecided,In progress] https://launchpad.net/bugs/1553309
<pitti> infinity: I did some rounds of patch reviews and discussions, and now sponsored the package as it's "good enough" and we desperaately need autopkgtests and field testing now
<pitti> there will be another upload with some patch cleanup
<pitti> infinity: want me to accept this myself, or do you want to revie?
<pitti> w
<pitti> infinity: ok, accepting this, and added a block-proposed tag, to get the test machinery going
<cpaelzer> Hi, please let me know if there are any questions about the dpdk upload that would have to be resolved to ack the upload
<caribou> same here regarding vsftpd : the previous upload failed on a DEP8 test
<infinity> caribou: I'd pay you big money to edit patches by hand when you're making a 1-line change instead of quilt refreshing. :P
<infinity> (Doubly-so, since this is a delta from Debian)
<infinity> caribou: Example:
<infinity> caribou: Yours: http://launchpadlibrarian.net/253581897/vsftpd_3.0.3-3ubuntu1_3.0.3-3ubuntu2.diff.gz
<infinity> caribou: Mine: http://paste.ubuntu.com/15808504/
<infinity> caribou: (And I uploaded that second one, you don't have to...)
<infinity> pitti: ^-- Review?
<caribou> infinity: for once I wanted to do it in a "clean" way :)
<infinity> caribou: Heh.  Well, to be fair, it's not your fault quilt refresh sucks so hard at this. :P
<infinity> caribou: Nor that, for some braindead reason, the initial format for dpkg --commit doesn't match the default format of quilt refresh.
<caribou> infinity: I got myself into a few problems previously by hacking directly at the patches
<infinity> caribou: But it drives me nuts to introduce extra delta, that's all.
<caribou> infinity: I didn't like the fact that it was touching other things either
<infinity> caribou: I probably hand-edit patches more often than I apply them with patch, so I'm also weird. :P
<caribou> infinity: even worse, running adt-run manually gave me FTBS errors that don't reproduce on the builders
<caribou> infinity: I still need to get the DM to accept to revert that change
<caribou> thanks for doing it yourself btw
<infinity> caribou: Yeah, I read through the bug report before accepting your upload.  You seem to be in the right on this one, IMO.
<caribou> infinity: well I researched a bit to find a reference to the fact that it should be starting (which xnox told me was the debian policy) and couldn't find it so I went ahead with xnox's suggestion
<infinity> caribou: I think the only time "unconfigured by default" is a valid setup for a daemon is when there's literally no sane default possible.  Which just isn't true for an ftpd.  Listening on all interfaces/protocols, password-only, is a totally sane default.
<caribou> infinity: well, it's been like that on debian/ubuntu for years, I couldn't figure out why they reverted it just because of the manpage
<caribou> luckily the DEP8 test caught it
<infinity> caribou: "Daemons must start by default if at all possible" might have been an Ubuntu policy decision, not Debian.  One of the many tweaks that made us more user-friendly.  I'd have to dig up references to be sure, though.
<xnox> caribou, que?
<infinity> Because it's just plain silly to install a thing and have it not working.
<caribou> infinity: I found a lot of forum/blog/stackexchange mentions that it was the default on debian, just couldn't find any reference of it in the policy manual
<xnox> oh that thing
<caribou> xnox: yep
<xnox> i think i ended up saying "we should listen on ipv6 and ipv4 by default"
<xnox> just like we did in the past.
<caribou> xnox: that's what listen_ipv6 does now
<xnox> well in the past we used to only do ipv4, but you know it's 2016 and ipv6 is a thing now.
<xnox> yeap.
<xnox> cool =)
<pitti> infinity: done
<cyphermox> good morning
<infinity> pitti: Ta.
<infinity> And now I go coffee and breakfasting while I wait for some archive churn.
<cpaelzer> infinity: reminder - you wanted to go shopping
<infinity> cpaelzer: Thanks. :P
<tyhicks> pitti: hi - I'm seeing that same failing lxc test is preventing the latest apparmor migration again
<tyhicks> pitti: could you hint it again?
<pitti> tyhicks: oh, is lxc failing regularly now?
<pitti> There is no download available for release=xenial, stream=daily, arch=amd64
<pitti> wut
<tyhicks> There is no download available for release=xenial, stream=daily, arch=amd64
<tyhicks> pitti: neither stgraber or I can reproduce it locally
<pitti> hinted
<pitti> tyhicks: ^
<pitti> but this is entirely new to me
<pitti> curiously it works fine on ppc
<ogra_> the architecture of the future
<tyhicks> pitti: it failed in the same way on monday
<tyhicks> pitti: retries can get it to eventually pass but I figured 3 retries was enough
<pitti> tyhicks: btw, nice to see linux' tests passing again since the new apparmor landed
<tyhicks> yes :)
<apw> i am glad ... we've been assuming it was the only issue ...
<cyphermox> breakfast time
<infinity> xnox: You didn't want to add statd to s390-tools' suggests?
<xnox> infinity, yes no maybe =)
<xnox> infinity, i should, shouldn't I ?
<infinity> xnox: *shrug*
<infinity> xnox: I think you've done that for the broken-out packages so far.
<infinity> xnox: OTOH, I suspect this isn't your last s390-tools upload. :P
<xnox> =)))))))
<xnox> unfortunately, i doubt it.
<infinity> xnox: So, catch it on the next upload, if you want.
<infinity> pitti: ^-- Based on a grep-dctrl, I decided just the virtual package was the right way to go, rather than s/16/12/
<infinity> Ahh, and thanks. :)
<pitti> infinity: yep, that's also what I tested in the schroot
<pitti> infinity: was auto-accepted :)
<infinity> Oh, of course.
<infinity> I'll retry smc when that publishes.
<pitti> was looking at that huge unity+stuff landing, but dinner time now
<infinity> Then we're down to one nbs?
<pitti> yeah, will look at the latex thingy tomorrow
<pitti> or rather, later tonight after basketball
<doko> hmm, why is this still "core"?
<infinity> pitti: gregoriotex was removed from testing over 1000 days ago.  Should probably just demote or remove it, unless there's an obvious and simple fix.
<infinity> platform.xenial/supported-development-common: * libstdc++-4.9-pic
<infinity> platform.xenial/supported-development-common: * gcj-4.9-jdk		
<infinity> ubuntu.xenial/development: * g++-4.9-multilib
<infinity> ubuntu.xenial/development: * gfortran-4.9-multilib
<infinity> ubuntu.xenial/development: * gcj-4.9-jdk
<infinity> ubuntu.xenial/development: * gcj-4.9-source
<infinity> ubuntu.xenial/development: * gcc-4.9-source
<infinity> ubuntu.xenial/development: * libstdc++-4.9-pic
<infinity> doko: ^
<doko> not anymore
<infinity> doko: Well, things could just be lagging a bit, then.  I wouldn't worry about it for now.
<infinity> pitti: I'm going to just remove gregoriotex.  I can't honestly see a single soul complaining.  "LuaTeX style for Gregorian chant scores".
<infinity> SUPER USEFUL.
<ogra_> the choirs will hunt you down !
<infinity> Let 'em.
<ogra_> yeah, until they show up under your bedroom window when you wanna sleep
<Skuggen> Noo, my chants
<cyphermox> infinity: why is that not seeded in minimal?
<ginggs> It is as if millions of Enigma fans suddenly cried out in terror, and were suddenly silenced.
<infinity> ginggs: Enigma has no fans.
<infinity> ginggs: Just a lot of people who regret their purchasing decisions in the 90s.
 * ogra_ knows a lot cryptographers that are enigma fans
<ogra_> oh, wait, thats the other enigma
<apw> they don't run things we make, not secure enough, they run hello-world they wrote in asm, and nothing else
<xnox> infinity, how dare you!
<xnox> pretty much everybody uses CTAN anyway, rather than distro packages for leave modules
<infinity> I was pretty sad to discover that gregorio had no rdeps.
<infinity> Was kinda hoping for some pocket of the archive dedicated to gregorian chant apps, maintained by debian-monks@lists.
<infinity> With any luck, they'd also make some stellar booze.
<infinity> But, sadly, no.
<xnox> omg i've never seen so many nice comments on youtube.
<xnox> on the enigma channel it's like "this is amazing" "i love it" "splendit"
<ogra_> about enigma ?
<xnox> aha
<ogra_> lol
<xnox> not a single diss at all
<infinity> Kids these days...
<ogra_> must be the music ... it lulls you into some weird state of mind
<ogra_> (dont play it backwards though)
<infinity> Enigma is a gateway drug that leads to Brian Eno.
<infinity> I guess parents just aren't doing their job anymore.
<pitti> infinity: gregoritex> sounds good
<infinity> pitti: Good, cause it's already gone. :P
<infinity> pitti: So, in a few publisher cycles, we should be at 0 NBS.
<ogra_> pitti, so you are one of these enigma fans then ?
<pitti> yay
<infinity> And then on to the next report to clean up.
<pitti> c-m? :-)
<infinity> c-m's in pretty good shape, just a few odds and ends.
<infinity> Ridding the world of mysql-5.6 looks to be the biggest thing left right now.
<infinity> doko: Have you noticed the irony that, just in time for powerpc scalingstack (well, almost there), the GCC testsuite doesn't kill my buildds anymore? :P
<doko> infinity, you told me ...
<infinity> doko: Oh, did I?  Well, I'm old and forgetful.  I'm sure you can relate to at least half of that statement.
<rbasak> infinity: can I have a pre-upload review of https://git.launchpad.net/~racb/ubuntu/+source/mysql-5.7/commit/?h=fixes&id=633deaa392959a658ff1b784e93eb0a7a3a73ac6 please, since it'll take a while to test and upload if you want it tweaking? It's a little extensive, but fixes a known issue. I've already quoted $rootpw properly and noted the LP bug reference in the changelog properly in a future commit.
<rbasak> The full set of changes I intend to upload are ubuntu/devel..fixes in https://git.launchpad.net/~racb/ubuntu/+source/mysql-5.7/log/?h=fixes
<stgraber> mwhudson: uploaded a new lxd now so you won't have to worry about having it rebuilt to get the rest of that golang fix :)
<pitti> stgraber: thanks for the fix :)
<stgraber> pitti: trivial enough :) looks like I thought of it for the stop case but not for start
<xnox> infinity, d-i passed smoke test and looks lovely
<xnox> however sysconfig-hardware is only half-Configured
<infinity> xnox: postinst broke?
<xnox> rmdir: failed to remove '/etc/sysconfig/scripts/common': No such file or directory^M
<xnox> yeap.
<xnox> looking.
<xnox> i shall fix that shortly
<xnox> i guess all ugprade logic is fine, but the fresh clean install was not =)
<infinity> xnox: Kay, but that sounds promising, if that's all that went wrong.
<xnox> anyway, all should be good now.
<xnox> it was a bit crap that i couldn't do versioned upgrade script. As there is no way to know if old d-i was used to do the installation =(
<lamont> thanks for the accept, whoever
<lamont> stupid broken test harness exposing broken things by accident like that
<xnox> infinity, if you approve sysconfig above, that would be nice.
 * xnox is afk
<Trevinho> Laney: hey, just noticed that https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1551986 had only the UIFe ACKed, not the FFe... Packages are in upload queue though :-/
<ubot5`> Launchpad bug 1551986 in unity (Ubuntu Xenial) "[FFe][UIFe] HUD hotkey assignment is suboptimal" [High,In progress]
<Trevinho> I've to go for a while now, but we can discuss that later... Anyway if someone from release team can give it a look. It's something design wanted to change at the last sight.
<Laney> Trevinho: erm
<Laney> you're changing the window controls now?
<Laney> this is insane
<Laney> argh
<infinity> Laney: On the one hand, "erk", (especially the continued confusion over semicolon versus super), on the other hand, I fully support remapping the braindead Alt-tap right up until release day (it's the one keybinding I *always* have to remap locally) :P
<Laney> Fixing the hud's shitty binding is one thing
<Laney> Making alt-space be hud is quite something else
<Laney> I'm going to block this stuff until we can sort it out
<infinity> Well, it needs to be a combo, at any rate.  The problem with it being a single key is long-proven to be just not workable.
<xnox> ship it
<infinity> Alt-space does feel odd, though.
<xnox> i think alt-space is the old gnome-do binding, and the old mac os x app which originally did that.
<Laney> Randomly taking over a bit of window manager functionality one week before release
<xnox> and alt-space does search on a mac os x too, no?
<Laney> nuts
<Laney> alt-space is *already* something in compiz
<xnox> i can't remember how one summons Cortana on windows, might be alt-space too
<xnox> Laney, what is it in compiz?
<Laney> press it
<infinity> Alt-space on Win32 and many/most UNIX window managers (including the one we use) is the window action menu.
<infinity> Min/Max/Move/etc.
<xnox> Laney, for me that did a drop down menu, randomly in a wrong position.
<apw> infinity, isn't alt-space already a keybinding
<xnox> i guess it doens't know how to display that menu in the righ tlocation with global menus in full screen size.
<infinity> apw: Yes, it's what I said above. :P
<infinity> The proposal seems to be to take over Alt-space and move the window menu to another keybinding, which is daft.
<infinity> I'd suggest Alt-Menu for the HUD and leave Alt-Space alone.
<apw> infinity, whats alt-menu ?  the right click key ?
<infinity> apw: Menu is the right-click key, yeah.
<apw> i don't even have one of those
<infinity> Me neither.
<xnox> infinity, i think that upload breaks accesibility and like TheMuso will complain loudly.
<infinity> It's the perfect place to bind the HUD! ;)
<apw> infinity, ahhh :)
<rbasak> ^^ amarok will dep-wait on mysql-5.7 5.7.11-0ubuntu6 above
<rbasak> I believe that should be all seeded packages switched to 5.7 after this, but I'll double check tomorrow after the archive has settled.
<apw> if alt-super works why are we not just putting hud on that
 * Laney just commented on the bug
<Laney> I'm going away though so others feel free to carry this on
<seb128> willcooke, you might want to read the backlog there
<seb128> Laney, the plan afaik was to move the menu combo to another binding, that should have been in the same landing?
<seb128> the email mentioned moving it to alt-super
<seb128> or
<seb128> https://launchpad.net/ubuntu/+source/compiz/1:0.9.12.2+16.04.20160412-0ubuntu1
<seb128>   * Show window actions menu on alt+semicolon. (LP: #1551986)
<ubot5`> Launchpad bug 1551986 in unity (Ubuntu Xenial) "[FFe][UIFe] HUD hotkey assignment is suboptimal" [High,In progress] https://launchpad.net/bugs/1551986
<seb128> that already landed it seems?
<xnox> seb128, semicolon is a very bad binding... because of keyboard layouts....
<seb128> xnox, I think it's a changelog thinko, see bug
<doko> infinity, can you accept openjdk-8, or do you plan to build images tomorrow?
<seb128> it's super-alt
<lamont> I suspect that https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820056 is worthy of an SRU, once it's fixed (migration should be possible, I expect, for many cases)  No way in hell it'll be in before the release
<ubot5`> Debian bug 820056 in bind9 "writeable file 'foo': already in use" [Important,Open]
<Trevinho> seb128, xnox: yeah changelog is broken... It's super+alt
<Trevinho> Laney: I know... I personally would have used super+space for HUD and keeping the Alt+space to what it used to be. But, design preferred this solution.
<Trevinho> Laney: also I thought you were aware of that request, sorry.
<infinity> Trevinho: It's fundamentally just greedy and gross to subvert a common keybinding for something new, and move the one we're all used to to somewhere else to compensate.
<infinity> Trevinho: I'd be much more supportive of just moving HUD to Super+Alt and leaving Alt+Space alone.
<infinity> (Or super+space, if you want, given that's just one key over from what design wanted)
<infinity> Trevinho: But "hey, let's move TWO key binding to make up for the bad placement of one of them" is daft.
<infinity> willcooke, seb128 ^
<seb128> +1 on that
<infinity> Trevinho: FWIW, I'm all for moving the HUD off Alt, that was a bad idea from day 1, it's just nutty to move it to another well-known binding.
<seb128> but the keys choice comes from design I think
<seb128> unsure how much they are open to the alternative
<infinity> seb128: Fine, design's not immune to me rejecting packages. :P
<seb128> willcooke, do you know?
<infinity> So, get some design people in here to argue.
<lamont> bind9_9.10.3.dfsg.P4-8 -- driver is "* Add support for native pkcs11.  LP: #1565392" which makes tjaalton's package usable again, by delivering separately built binaries for its use (see the bug for the crying)
<ubot5`> Launchpad bug 1565392 in bind9 (Ubuntu) "add support for native pkcs11" [Undecided,Confirmed] https://launchpad.net/bugs/1565392
<xnox> infinity, i can go into the office =) it will be funny.
<willcooke> infinity, seb128 - please comment on the bug and I will speak to Design
<seb128> willcooke, thanks
<infinity> willcooke: Added a quick comment.
<willcooke> thanks infinity
<Trevinho> infinity: yeah, I know... I already had all the concerns you mentioned here by my own. So It's nothing new to read. I would go with Super+Alt on HUD or Super+Space (better to me), but I understand that design point was "super is something we use for windows related actions, so alt+space is not good".
<cjwatson> Any reason why the seeds shouldn't be changed to replace ubuntu-snappy-cli with snapd?  ubuntu-snappy-cli is a transitional package now
<infinity> cjwatson: Yeahp, it should all be changed, I was just waiting for all to filter down.
<Trevinho> anyway my role is getting things done, then I did what it was designed.
<Trevinho> s/I/we/
<infinity> Trevinho: Yeah, I understand.  I'm happy to be the guy who has to say "no". :P
<infinity> s/happy to be/fine with being/
<infinity> cjwatson: You want I should do that, or are yo ualready committing?
<cjwatson> Go for it, I should go and do other evening things.
 * pitti retries smc, https://launchpad.net/ubuntu/+source/cegui-mk2/0.8.4+dfsg-4ubuntu1 is built now
<infinity> pitti: Ahh, I had been waiting on armhf to publish.
<infinity> pitti: (which it's still doing)
<pitti> infinity: hm, 42 mins not enough? well, if it still fails, we'll just retry again
<pitti> but at least we know if it works on the other arches then
<infinity> Yeah, I'll retry armhf again in a few minutes when the publisher gets there. :P
<infinity> I kinda want the publisher logtail in the lp.net web UI somewhere, so other people can pull the tricks I do by staring at it in progress.
<cjwatson> We might at least get it into an ELK instance with slightly wider view access at some point this year or so.
<infinity> cjwatson: Well, to be fair, watching the logtail is a workaround for the UI being suboptimal in other ways, but it's a workaround that works for people who know what the log is telling them. :P
<cjwatson> UI, publication process in general, ...
<pitti> infinity: *sob* https://launchpadlibrarian.net/253676097/buildlog_ubuntu-xenial-amd64.smc_1.9+git20121121-1.2build2_BUILDING.txt.gz
<infinity> cjwatson: If publishing records had an extra "publishing" state, we could set "publishing" where we currently set "published", and then flip to "published" at the dists switch.
<infinity> cjwatson: But that's effort.  Watching a log is easy.
<infinity> pitti: Hah.
<infinity> pitti: At least it's different!
<cjwatson> infinity: Which would confuse a different set of people who care about archive.u.c :-/
<infinity> cjwatson: Well, I don't think the LP UI can ever be accurate WRT mirrors.
<infinity> cjwatson: Those people clearly don't matter.
<infinity> (And it would be closer to right, at least)
<cjwatson> Sure, but the fact that a.u.c is a set of mirrors is an implementation detail.
<cjwatson> (I'm not arguing it's perfect as it stands BTW)
<infinity> Right.  My "solution" would make it "better" for the mirror situation, but still incorrect.
<infinity> Lots of "air quotes" around "here".
<pitti> anyway, that smc thing is a "tomorrow" thing, I reserve this nightshift for some quiet autopkgtest infra hacking
<tjaalton> was final freeze for universe too?
<infinity> cjwatson: To be fair, I think most people who assume "published" is meaningful are caring about up-to-the-minute ftpmaster status for build-deps and the like, not so much mirror lag, but YMMV.
<pitti> I just uploaded the three no-change rebuilds for the urdfdom lib transition (bug 1569626)
<ubot5`> bug 1569626 in urdfdom (Ubuntu) "[FFe] Sync urdfdom 0.4.1-1 (universe) from Debian unstable (main)" [Undecided,Fix committed] https://launchpad.net/bugs/1569626
<infinity> tjaalton: Yes and no.
<tjaalton> infinity: like, still able to get tested stuff out but will end up in the queue?
<infinity> tjaalton: We'll still have the auto-accept bot on until close to release time, but there's an honor system in play where you agree not to upload Stupid Things.
<tjaalton> right, of course
<infinity> tjaalton: Read a former Final Freeze announce from 6mo ago.
<tjaalton> ok
<infinity> tjaalton: Or wait a day for a new one. ;)
<pitti> infinity: debian bug 812096 does not sound very hopeful, though
<ubot5`> Debian bug 812096 in src:smc "smc: FTBFS: configure: error: Package requirements (CEGUI-OPENGL >= 0.7.2) were not met:" [Serious,Open] http://bugs.debian.org/812096
<tjaalton> well, looks like I can bump freeipa to 4.3.1, but that needs an update to bind9 which lamont is testing now, and also adding systemd support to opendnssec which I've tested already
<infinity> pitti: Fun.  Well, we have a week to decide what to do about it.
<tjaalton> it's really just a big bugfix release, finally allowing to install ipa replicas
<tjaalton> I guess apache systemd support might be pushing it too far :P
<pitti> infinity: "package the latest upstream version" at least sounds like a way out, only three reverse recommends
<infinity> pitti: If it's a trivial uupdate job that requires zero thought on our part, I'm game.
<lamont> tjaalton: it's actually sitting in the queue hoping for approval..
<lamont> bind9 that is
<tjaalton> lamont: ooh shiny
<infinity> pitti: We have more than enough work to do to be wasting real effort on it, though.
<tjaalton> thanks a lot!
<lamont> and since bind9 is on the cd images.... :/
<pitti> infinity: demote-to-proposed with ignoring the recommends on the three games-* metapackages would work too
<infinity> lamont: bind?  Isn't that old news?  I thought everyone used knot these days.
<pitti> (didn't realize that these are just metapackages)
<lamont> infinity: I refuse to rise to the bait. :p
<infinity> pitti: Yup.  But hey, we can sort it during the release sprint, it's not like affects media.
 * xnox has knot stickers on my laptop
 * lamont can tie knots
<cyphermox> tjaalton: any plans to backport the xenial X stack to trusty?
<pitti> actually, it is already in -proposed, so just remove from xenial-release, done
<pitti> infinity: yep0
 * pitti off irc, waves good night
<tjaalton> cyphermox: of course, once things have settled down a bit
<cyphermox> tjaalton: ok, I was just checking if you were going to do it or if it's somebody else
<tjaalton> cyphermox: no it's been me since mlankhorst jumped ship
<cyphermox> tjaalton: ack, thanks
<tjaalton> i'd hope to get mesa 11.2.1 in before release, but not sure about that
<tjaalton> sounds like it'll get released on friday
<cyphermox> ok
<mwhudson> stgraber: haha
<bdmurray> infinity / slangasek: I'm just going to make a generic EOLReleaseAnnouncement and put it in meta-release and on changelogs.ubuntu.com (when it comes back) to resolve bug 1569233. Sound good?
<ubot5`> bug 1569233 in ubuntu-release-upgrader (Ubuntu) "changelogs.ubuntu.com/EOLReleaseAnnouncement missing, causes distro upgrade failure on EOL systems" [Medium,Triaged] https://launchpad.net/bugs/1569233
<slangasek> bdmurray: "when it comes back"? where has it gone?
<slangasek> bdmurray: if the point here is that it doesn't require somebody to remember to create a per-series EOLReleaseAnnouncement file each time a release EOLs, reducing the number of things we have to touch sounds like a good idea to me
<bdmurray> slangasek: I think they are changing out hardware. My initial idea in comment 2 would require more touching like that, so going with a generic one on changelogs.
<cjwatson> it had a catastrophic disk failure (ironically, while adding more disk)
<cjwatson> aiui it's being recovered in one of the harder ways
<slangasek> heh
<slangasek> recovery procedure: replay 12 years of Ubuntu development in a pocket universe
<cjwatson> https://rt.admin.canonical.com/Ticket/Display.html?id=89921 if you want to follow along
<cjwatson> though I notice that extract-changelogs could usefully be fixed to use order_by_date=True ... I should have a poke at that
<slangasek> hmm that ticket number is older than I would expect for something that is taking meta-release offline
<bdmurray> meta-release is still accessible
<slangasek> ah
<bdmurray> its just I can't get to the server at the moment, and that bug isn't that important
<cjwatson> pitti: I just noticed r160 in ddeb-retriever, in which you seem to have missed the long comment I left immediately above the changed code explaining why any attempt to do what you did would introduce a subtle data-loss bug :-(
<cjwatson> pitti: can you have a look over that comment and we can discuss it when we're both around?
#ubuntu-release 2016-04-14
<slangasek> hmm. why is mksh in the core packageset?
<slangasek> historical, I guess
<Ukikie> Heh, and ubuntustudio-* isn't in ubuntustudio it seems, or so queuebot said.
<slangasek> https://bugs.launchpad.net/ubuntu/+source/mksh/+bug/1018162 is the reason, it's only a 4-year-old MIR, recent history how could I have forgotten
<ubot5`> Launchpad bug 1018162 in mksh (Ubuntu) "[MIR] mksh" [Undecided,Fix released]
<slangasek> zequence: are you building these ubuntustudio source packages on Debian instead of Ubuntu?  Because your .changes files are broken and will not autoclose bugs...
<infinity> slangasek: re: lua, srsly?
<slangasek> infinity: what about it?
<infinity> slangasek: The version-script thing.  This is just asking more questions than it answers for me. :P
<slangasek> infinity: you can read the bug, I opened you a task on glibc
<infinity> slangasek: Unless it's exporting symbols that clash with glibc or something hilarious?
 * infinity finds the bug.
<slangasek> infinity: glibc's stdio destructors get all pissy on powerpc if you use a version script on an executable that hides some special _is_stdio_in_use symbol
<slangasek> (paraphrased symbol name)
<slangasek> _IO_stdin_used
<slangasek> (and nevermind that it's stdout that causes the explosion)
<infinity> slangasek: Fascinating.  I'll forward that to IBM for extra WTFery.
<infinity> slangasek: While technically a regression, the response might be "don't do that, then", but we'll see when people dig deeper.
<slangasek> infinity: I would suspect the bug severity of being higher on account of shared libs also possibly using stdio and hiding the symbol, but I can't find that symbol in any shared lib on my system so I guess that's not how it works
<otto___> Hello! Current mariadb-10.0 in xenial pocket is buggy. I've been trying to upload a new one but have had multiple failures in the test suite due to specialities of Launchpad environment (these are all false positives).
<otto___> Now everything is should be fixed, both the actual bugs and test suite issues.
<otto___> Sync request filed as #1569922
<otto___> Since this is the last day before final release, I thought it is best to mention the urgent need to sync here in irc. Thanks for your help!
<pitti> cjwatson: oh, oops; I'm afraid I forgot the context of that (it happened a year ago); should I just revert this for now, and we just live with the longer runtime?
<mwhudson> infinity: so that dh-golang bug got fixed again and better in debian (by me again :-p), is it worth syncing or too much trouble at this stage?
<infinity> mwhudson: diff?
<mwhudson> infinity: http://paste.ubuntu.com/15824938/
<mwhudson> um no
<mwhudson> infinity: http://paste.ubuntu.com/15824944/
<infinity> mwhudson: Does that pick up the compiler itself, too?
<mwhudson> infinity: yes
<mwhudson> infinity: it doesn't pick up the golang-defaults version, but well
<mwhudson> it probably shouldn't
<infinity> mwhudson: If it seems to DTRT, it's certainly more conceptually correct than using build-deps.
<mwhudson> (no part of golang-defaults ends up in the binary after all)
<infinity> Yeah, golang-defaults shouldn't relate.
<mwhudson> infinity: i test-built lxd, and dropping golang-defaults was the only change to b-u
<infinity> mwhudson: Then I say sync it.  We want this all working correctly for xenial, IMO, and future attempts at proper security management.
<pitti> infinity: just uploaded apt to unapproved; I know, final freeze, and apt and so, but it got tested a full round, the patch is rather obvious, and it breaks upgrades fairly hard
<pitti> we should also SRU this, but apparently (during the tests) apt tends to get upgraded early enough
<pitti> or do-release-upgrade has some special provisions to take the new apt (IIRC it does that)
<infinity> pitti: Eek.
<pitti> but the bug is piling up duplicates rather quickly
<infinity> pitti: I don't even need to see it in action, the patch tells me exactly what the bug is.   Gross.
<pitti> infinity: the fun thing was that we've had this for 5 years and it managed to stay under the radar
<infinity> And we were so close to shipping a non-ubuntu-versioned apt, too. :P
<pitti> infinity: oh, wait
<infinity> Oh, wait?
<pitti> infinity: I can re-upload as 1.2.10+git1 if you want
<infinity> Hahaha.
<infinity> No. :P
<pitti> as that's what it really is
<pitti> I usually do that for some of my packages to keep them auto-syncable
<infinity> It'll get ubuntu revisions in SRUs soon enough anyway.
<infinity> And we'll sync over it in a week or two in 16.10.  No big deal.
<pitti> well, the fix hasn't been uploaded to Debian yet, otherwise I'd have taken that
<infinity> Why yes, I would love to "review" a 1.1MB command-not-found diff. :/
<pitti> btw, is the bot AWOL?
<pitti> I didn't see my apt upload, neither the ones I'm reviewing/accepting ATM
<infinity> He's not in the channel right now.
<infinity> Jerk bot.
<infinity> stgraber_: queuebot had a sad.
<pitti> o_O we have a package snap*d* which is a client CLI tool?
<pitti> what was wrong with snappy-cli, or at least snap-cli
<infinity> Dunno.  I don't name these things.
<pitti> yeah, I know, rhetorical questino
<pitti> at least because mvo isn't here
<infinity> I doubt mvo had any say either.
<pitti> the plotutils sync looks suspicious, debian changelog doesn't mention any of our ubuntu changes
<infinity> And "snap" is already in the archive as something entirely different.
<infinity> So why not pretend it's a daemon. :P
<pitti> ah, we raced on php7.0
<pitti> so you are doing command-not-found? looking at bind9 then
<pitti> infinity: just FAOD, we'll keep base-files until Monday or so, right?
<pitti> infinity: I can also accept it on Sunday along with the langpacks
<infinity> pitti: Weekend seems reasonable for base-files.
<infinity> pitti: The plotutils sync includes a dh(1) conversion and some mention of testsuite patches, so that covers all but the symbols delta.
<infinity> There is, indeed, no symbols file in the Debian version, though.
<infinity> So you could reject on that basis.
<pitti> ah, the kubuntu_test thing is obsolete? (didn't look at the diffs yet)
<pitti> bug 1565392 should be an FFE, hasn't been approved yet
<ubot5`> bug 1565392 in bind9 (Ubuntu) "add support for native pkcs11" [Undecided,Fix committed] https://launchpad.net/bugs/1565392
<infinity> Yeah, lamont mentioned that.  Kinda figured that we'd do FFe/queue review as a bundle and reject if we hated it. :P
<pitti> it's a bit of a mouthful
<pitti> I don't see anythign obviously wrong, but there's certainly enough change that anything could go wrong
<pitti> but oh well, I'd take it
<infinity> Yeah.  There are definitely changes we want from that upload, even if you decide the pkcs11 stuff is too risky, but we can make him cherry-pick those.
<infinity> (like the dep fixes)
<infinity> I was okay with the pkcs11 stuff conceptually, but wasn't braining well enough to read the diff yet.
<mwhudson> infinity: (master)mwhudson@aeglos:dh-golang$ syncpackage dh-golang
<mwhudson> syncpackage: Error: Debian version 1.14 has not been picked up by LP yet. Please try again later.
<mwhudson> heh too impatient
<pitti> rejected plotutils
<cjwatson> pitti: So there's definitely a way it can be changed to preserve at least some of the runtime wins while being more correct, but rather than just changing it, I wanted to make sure that I'd adequately communicated what the data-loss problem was (since it's quite subtle)
<pitti> cjwatson: so I understand it's because the objects returned by LP are not really lists, but volatile iterators, and they can change underneath you?
<cjwatson> pitti: sort of
<pitti> cjwatson: I guess I just ignored the comment back then, or we had some IRC conversation or whatnot
<cjwatson> pitti: lazr.restfulclient fetches a batch of 75 at a time; when it needs a new batch it's basically just like saying OFFSET 75 LIMIT 15
<cjwatson> er LIMIT 75
<cjwatson> so it depends what the database state looks like at the time when the next query comes in
<cjwatson> with just order_by_date, this is OK because the worst that can happen is that something gets pushed onto the front and shuffles everything else back, so you get duplicates
<cjwatson> with an extra status filter, what can happen is that a publication from the batch you were processing gets deleted which shuffles everything the other way, so publications can land in the gap between batches
<pitti> ah, that makes sense
<cjwatson> pitti: what I think we should do here, and I can implement it if you agree, is to move the status filter to a check inside the iteration (or possibly out in ddeb_retriever.py, but same deal)
<cjwatson> pitti: actually iterating over the collection elements is probably not too expensive here due to the batching; I bet the expense comes when you end up doing things that make additional per-element requests
<pitti> cjwatson: that makes sense; I faintly remember having to deal with ddebs which never got published, we must filter them out
<pitti> so beyond that functional issue, the main effect should be that the query/processing takes longer without the filter, but as we still have the date threshold that should not matter much
<cjwatson> right
<cjwatson> pitti: oh, we can probably also process packages in status "Pending"
<cjwatson> maybe?
<cjwatson> you might end up with ddebs running ahead of the primary archive a bit, but my thought was that it would increase the chance of ddebs being available when their deb partners are published
<cjwatson> though this only works if ddebs can cope with multiple versions of the same package/arch in a suite
<pitti> right, pending is fine, but we don't want "deleted"
<pitti> or superseded
<pitti> cjwatson: they should be able to, I think we fixed that to just publish multiple versions in the Packages
<cjwatson> pitti: OK, can you have a look at r168 and r169 and see if those look right?
<pitti> cjwatson: LGTM, thanks for fixing this
<pitti> cjwatson: rolled out
<cjwatson> thanks!
<zequence> slangase`: Really? Yes, I do build on Debian, but have not had that problem before.
<cjwatson> zequence: it's been this way since 2007; perhaps you simply haven't ever had automatic closing of Ubuntu bugs from the changelog working for you
<cjwatson> (or you manually edited Launchpad-Bugs-Fixed fields into the .changes, but that seems less likely)
<zequence> cjwatson: Pretty sure it has worked in the past, but I was using dpkg-buildpackage then. This time, bzr-buildpackage
<cjwatson> zequence: I'm pretty sure it can never have done using Debian's dpkg-dev.
<zequence> cjwatson: Bug 1565078
<ubot5`> bug 1565078 in ubuntustudio-sounds (Ubuntu) "Please remove ubuntustudio-sounds from Xenial" [Undecided,Confirmed] https://launchpad.net/bugs/1565078
<zequence> I'm thinking now it's because I've been not adding a space in the right place
<zequence> In this case, it's (LP: #1565078), but in other cases it has been (LP:#1570052)
<ubot5`> Launchpad bug 1565078 in ubuntustudio-sounds (Ubuntu) "Please remove ubuntustudio-sounds from Xenial" [Undecided,Confirmed] https://launchpad.net/bugs/1565078
<cjwatson> zequence: You must add a space there, yes - look in /usr/share/perl5/Dpkg/Vendor/Ubuntu.pm for the regex - but LP: annotations in the changelog are also only parsed if dpkg-dev thinks it's operating for the "ubuntu" vendor.
<cjwatson> zequence: LP:#1570052 will do nothing.
<cjwatson> zequence: LP: #1565078 is the usual form.
<ubot5`> Launchpad bug 1565078 in ubuntustudio-sounds (Ubuntu) "Please remove ubuntustudio-sounds from Xenial" [Undecided,Confirmed] https://launchpad.net/bugs/1565078
<zequence> cjwatson: Yep. Silly mistake.
<zequence> cjwatson: Are you saying the LP annotations end up somewhere else as well in the changes file, except for under "Changes:"? Seemingly, the bugs have been autoclosed in the past, if the regex was fine
<zequence> Just wondering from which part launchpad parses the LP annotations
<zequence> I will of course close any affected bugs of late.
<cjwatson> zequence: The way it works is that dpkg-genchanges is responsible for actually parsing the bug closures out of the changelog, and it adds a Launchpad-Bugs-Fixed field to the .changes file with the results of the parsing.  Launchpad itself only looks at the Launchpad-Bugs-Fixed field.
<cjwatson> zequence: (This is the exact same way that it works in Debian, only with a different field instead of Closes.)
<zequence> cjwatson: Perhaps launchpad is also checking the "Changes" field? I have built all packages in Debian for the past year, and it has worked so far (except for the last few times, when I forgot to use space)
<zequence> I wouldn't build a kernel like this, but these packages are just archives of files
<cjwatson> zequence: No, it doesn't.
<cjwatson> Really.
<cjwatson> zequence: Can you give me an example of a recent-ish package you uploaded built this way, and I'll go and check logs?
<cjwatson> zequence: (One that had the space in there.)
<apw> sometimes nice people parse it and fix bugs which were miss-specified
<cjwatson> Well, also, if it's a sync from some other archive (e.g. Debian's) I believe we parse the changelog directly
<zequence> This one was uploaded last, together with another package with the wrong regex. But, this one has the right one Bug 1565078
<ubot5`> bug 1565078 in ubuntustudio-sounds (Ubuntu) "Please remove ubuntustudio-sounds from Xenial" [Undecided,Confirmed] https://launchpad.net/bugs/1565078
<cjwatson> But direct changelog parsing is only used in the copy path.
<zequence> No, sorry. That was from the past week. But, recent, anyway
<cjwatson> Let's see if I can find out how that got there.
<cjwatson> Oh!  I see
<cjwatson> Of course, all packages end up going through the copy path nowadays, because of proposed-migration
<cjwatson> I forgot about that
<cjwatson> Hmph, OK, this is sort of not how it was meant to work, but I guess it's convenient in zequence's case
<cjwatson> Strictly, I think we should probably fix this, but need to work out how to do so without breaking use cases that are unambiguously desirable
<cjwatson> At least we should prefer Launchpad-Bugs-Fixed if it's there, but it's a bit tricky in the case of a copy with a difference of multiple versions
<cjwatson> zequence: OK, I apologise for having forgotten about the convolutions of modern upload handling
<LocutusOfBorg> question: a lot of stuff has been NMUed in debian for libpng1.6, my proposal is: for xenial+1 when the archive is not open, sync libpng1.6, MIR it, and then let the auto import fix ~100 packages
<LocutusOfBorg> is it possible?
<zequence> cjwatson: I'm sure there are other reasons why I'm doing it the wrong way. I used to use a virtual machine for Ubuntu development, and should probably start doing that again.
<cjwatson> LocutusOfBorg: Yes, I think we can remember to do that.  (We don't need to do the MIR before auto-sync, though; it will just block migration.)
<cjwatson> infinity: ^-
<LocutusOfBorg> <3
<LocutusOfBorg> also gdk-pixbuf needs a rebuild, to avoid having to retry and retry the gtk reverse-deps
<LocutusOfBorg> don't worry I'll bother you when xenial is out :p
<LocutusOfBorg> BTW I'm not a core-dev, so I'll probably need some help
<LocutusOfBorg> not sure how much of the reverse-deps are in main, I guess not too many
<cjwatson> libpng will at least have a fairly respectable number.
<LocutusOfBorg> well, with some help we can have a smooth transition, as we did in Debian
<doko> gave back all failed builds one last time
<pitti> yay, got libvigraimpex to build
<LocutusOfBorg> still #1562480 not fixed
<LocutusOfBorg> bad xenial on powerpc is bad
<LocutusOfBorg> 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
<pitti> libvigraimpex FTBFS fix in unapproved -- review SVP?
<coreycb> doko, just forwarded you an email about possible ways to fix sunpy autopkgtest failures
<ginggs> Hi, anyone from ubuntu-release able to look over two FFes please? LP: #1566326
<ubot5`> Launchpad bug 1566326 in papi (Ubuntu) "FFe: Sync papi 5.4.3-2 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1566326
<ginggs> and LP: #1565286
<ubot5`> Launchpad bug 1565286 in htop (Ubuntu) "[FFe] Please sync htop 2.0.1-1 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1565286
<cyphermox> good morning!
<LocutusOfBorg> hint also git git
<lamont> LocutusOfBorg: ~rc3 into an LTS?  that seems overly aggressive to me.
<LocutusOfBorg> lamont, it has nice features
<lamont> though at least it's not ~b1 or such
<LocutusOfBorg> BTW git 2.8.0 is out
<LocutusOfBorg> but I think it is the same as rc3
<LocutusOfBorg> if you grant an FFe I can prepare a packaging
<lamont> LocutusOfBorg: I'm sure it'll find its way into xenial-backports in the near future.  I'm not on the release team, but I'd be surprised if they'd grant the FFE at this stage.
<LocutusOfBorg> me too
<LocutusOfBorg> I asked it a while ago
<lamont> and that's coming from someone with a history of pushing the edges on FFe-sanity
<LocutusOfBorg> but too late indeed
<lamont> especially in this world of -backports and ppas
<LocutusOfBorg> parallel submodules fetching is something I really need to have, and I'll probably have in my ppa
<pitti> Laney: eww @ large gnome-software patch; reviewing this isn't realistic, can I have your word that this version is sane?
<pitti> barry: python-webob sync> large amount of changes, lots of rdepends, no FFE or other bug; do you have some details about that?
<barry> pitti: i meant to do an ffe, i'll do that now
<pitti> jamespage: same question about ceph -- no FFE, large changes, unreviewable -- how was this tested?
<jamespage> pitti, same way I did before - built in PPA, tested upgrades and deployment from .1
<jamespage> (referenced in the FFe linked in the changelog)
<pitti> jamespage: ok, thanks; so I take it you want that in xenial
<cyphermox> davmor2: don't tell me, I broke the "Install Ubuntu" option, it doesn't just get you ubiquity anymore :'(
<davmor2> cyphermox: haven't had time to try a new install will fire one up in a second
<cyphermox> it's some kind of ugly systemd unit start race
<cyphermox> I only just noticed, it was definitely working well when I tested here before uploading :/
<davmor2> cyphermox: so current is working which is last built on 14th, or at least the uefi version is getting to the let me try pending and also try non uefi
<davmor2> cyphermox: meh nevermind that was trusty wrong image D'oh
<jamespage> pitti, yup please
<Laney> pitti: haha
<rbasak> I want to drop the lxd seed from depends to recommends for server - just acked by kirkland. Will there be any issue with that?
<Laney> pitti: It's "more" sane IMO, but will definitely have more uploads to come
<Laney> depending on attente's brain to finger bandwidth that might be SRU though
<Laney> a lot of the delta will be because I moved the patches into the orig
<Laney> which is a one time cost
<willcooke> hi gang!  This:  https://bugs.launchpad.net/ubuntu/+source/muon/+bug/1562406
<ubot5`> Launchpad bug 1562406 in muon (Ubuntu) "[FFe] Update to latest upstream version" [Undecided,Confirmed]
<willcooke> There is a comment that it might not need a FFe, and a report of a missing dependency
<willcooke> Can anyone say if it doesn't need an FFe, or if it can or cannot be acked?
<willcooke> mhall119, ^
<mhall119> thanks wi
<willcooke> heh
<Laney> mhall119: I replied
<infinity> rbasak: The only person likely to complain is Mark.
<rbasak> infinity: OK, thanks. kirkland acked it so we're good.
<stgraber> infinity: it would still be pre-installed where Mark wants it pre-installed. I don't think he particularly cares about depends vs recommends.
<stgraber> anyway, I did the seed and meta change to move it to recommends earlier
<infinity> stgraber: Works for me.
<mhall119> thanks Laney
<mhall119> Laney: so what's the next step for this? Will someone in the release team take it from here or does Kubuntu need to do something else?
<doko> the give back in main produced one more build success in main, and 22 in universe
<doko> coreycb, I don't think I will push for a new numpy at this stage
<coreycb> doko, ok I understand that, it's not just bug fixes
<Laney> mhall119: They can upload it now
<mhall119> clivejo: ^^
<Laney> mhall119: I think they should get someone to replace Riddell on the release team too
<mhall119> Laney: what's the process for somebody to get on the release team?
<Laney> I think there's usually a quick email poll
<ogra_> proving experience ?
<infinity> mhall119: core-dev + agreed team trust.
<infinity> mhall119: (which involves experience, etc)
 * Laney is too formalist :P
<infinity> To be fair, most flavours don't have someone in ~ubuntu-release
<infinity> Losing ScottK and Riddell was more a loss to the project as a whole than just to kubuntu.
<Laney> It'd be good to have someone who might be more inclined to help flavours out
<Laney> I personally haven't given FFe/queue reviews as much time as I might have liked
<flexiondotorg> infinity, Laney Is the a role I can be mentored for?
<ogra_> flexiondotorg, needs core-dev
<flexiondotorg> ogra_, OK. A more long term goal then.
<ogra_> :)
<ogra_> though i guess the universe FFe stuff can be handed to someone not core-dev
<ogra_> that would probably drop some load from people like LAn
<ogra_> *Laney
<flexiondotorg> Well, I'm game.
 * flexiondotorg needs to go home now.
<Odd_Bloke> Could a core dev merge (and release) https://code.launchpad.net/~daniel-thewatkins/livecd-rootfs/interface-naming/+merge/291928, please?
<Odd_Bloke> smoser: ^ is relevant to your interests.
<smoser> Odd_Bloke, man..
<slangasek> smoser: does that mean you're taking it?
<smoser> Odd_Bloke, please set a commit message
<Odd_Bloke> smoser: Do I have to uncommit/commit to set the fixes data?
<smoser> no. just mention it at least
<smoser> you could bzr commit --fixes lp:
<smoser> and then it would say "do you want to commit with no changes"
<smoser> and you say "yes please"
<smoser> but i just wanted it linked someway to that bug
<Odd_Bloke> smoser: Done.
<smoser> Odd_Bloke, do i have to upload this ?
<smoser> versus just pushing to trunk
<Odd_Bloke> smoser: I would appreciate it if you would, because we're trying to build on top of released versions.
<smoser> yeah. ok.
<Odd_Bloke> smoser: Thanks. <3
<smoser> just uploaded.
<doko> cjwatson, slangasek: ^^^ pyjunitxml still remains in the core package set. is this expected?
<slangasek> doko: packagesets are not automatically cleaned up.  I suppose someone needs to go through and reconcile that, but I don't remember where either the tools or the reports are
<cjwatson> somebody in the DMB would need to do it
<doko> ok, I assume that would be colin. never managed package sets myself
<cjwatson> doko: Me?  No, I haven't been in the DMB for years
<infinity> Laney traditionally does the bulk updates.
<infinity> s/does/did/
<infinity> I think he needs to hand that off to someone else.
<doko> cyphermox?
<cjwatson> https://code.launchpad.net/~developer-membership-board has the code
<cyphermox> hello?
<infinity> Ah, I found the email from him detailing it.
<infinity> https://wiki.ubuntu.com/DeveloperMembershipBoard/KnowledgeBase#Automatically_managed_packagesets
 * infinity kicks off a run.
<infinity> cjwatson: Ahh, found one spot magicmirror misses splitting with by-hash.  $series/by-hash/* contains all the Contents files.
 * infinity says, while watching this very slow rsync.
<cjwatson> infinity: Mm, yeah, that's tricky for it to do.
<cjwatson> Not sure how to fix that.
<cjwatson> It can't just drop the by-hash files there that don't match current by-name files for supported arches, because that defeats the purpose of by-hash.
<cjwatson> And I don't really want to drop by-hash for Contents, since with modern apt-file, apt will actually try to download them and I think would even complain about mismatches.
<cyphermox>  doko: cjwatson: infinity: do you need me to do that packageset update? I'm still looking at grub-mkfont...
<infinity> cyphermox: It's already running here.
<cyphermox> ack
<infinity> cjwatson: Yeah, unsure.  I was going to suggest 'stat -c %h' and then realized the same thing, that we kinda want unreferenced files because, well, by-hash.
<cyphermox> cjwatson: btw this issue affects Debian as well, you might see that with the current freetype, there are missing glyphs at least in zh_CN
<cjwatson> cyphermox: No idea about that at the moment, sorry
<cyphermox> no, i wasn't expecting you to, just saying. I'm looking at the issue and I'll write a patch
<infinity> doko: ^-- That should be the final glibc upload.
<infinity> FYI.
<bdmurray> infinity: when are you planning on doing the freeze?
<sgclark> Hello folks, I have a pile of KDE bugfix release uploads, and I was hoping I could do this tonight, ( PST US time ) any objections?
<infinity> bdmurray: After I ingest a hamburger and write the email.
<infinity> sgclark: Bugfixes generally welcome, if reviewable and sane.  In about an hour, final freeze is upon us, and the general rule will be "if it would be acceptable for an SRU, go ahead and try, but we won't guarantee it gets in".
<infinity> sgclark: But if this all gets in quickly, you can ignore the second half of that sentence.
<sgclark> It is acceptable for SRU fixes, oh so I have an hour haha. Let me free up some time then. thanks.
<infinity> sgclark: An hour until the email is sent.  We can cut you some slack on the actual uploads.  Correct is better than hasty. :P
<sgclark> infinity: lol thanks!
<barry> infinity: can you reject the webob sync?  on further testing i don't want to deal with the potential dep8 failures
<infinity> barry: Someone rejected it 22m ago.
<infinity> barry: Service with a time machine.
<barry> thanks someone!
<infinity> barry: You should have had mail about it telling you who to blame.
<barry> infinity: not yet, which is why i pinged
<infinity> Weird.
<barry> yeah, that's mildly concerning
<cjwatson> There are a couple of ntfs-3g sync requests that somebody might want to take a look at.  They claim to be stability improvements, haven't really checked, just keep seeing people making increasingly urgent metadata changes to them.
<doko> infinity, not sure if I will finish the c-t-b packages before the final freeze
<infinity> doko: That's fine.
<mwhudson> infinity: i wanted to sync dh-golang but it seems to have got stuck on the debian side, do you know where i can look/poke to investigate that?
<mwhudson> oh
<doko> mwhudson, it needs some time to become visible for syncing. if you want to fetch it look at http://incoming.debian.org/debian-buildd/pool/
<mwhudson> doko: also somone filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821000
<ubot5`> Debian bug 821000 in dh-golang "dh-golang: matched no packages; no buildable Go source files" [Serious,Open]
<mwhudson> which is not the most helpful bug report ever
<infinity> Seems somewhat suboptimal.
<infinity> Both the bug and the report. :P
<mwhudson> yeah
<doko> does kubuntu have a freeze exception?
<infinity> They have a vaguely global MRE.
<infinity> Which doesn't extend beyond final freeze, but close enough.
<doko> ok to accept these?
<doko> glibc ftbfs on i386
<doko> timer issue, timer sig2 invoked too soon: 3.900357757 instead of expected 3.900607522
<infinity> Blaming qemu and retrying. :P
<infinity> And yeah, should be okay to accept the kde stuff with a cursory review to make sure nothing terribad happened in any of them.
<doko> many of these are just no-change releases
<infinity> slangasek: Hrm.  Would you expect in the new world order that packagesets use --no-follow-build-depends?
<infinity> slangasek: Cause without it, we're adding a ton of new stuff to core.
<infinity> (With it, I imagine we'll remove a huge mess of things...)
<slangasek> infinity: yes, I would think so
<infinity> Alright, need to grab germinate from git and retry this, then.
<slangasek> and if this causes things to drop out that make us go "wait, that package should not be a free-for-all", that's probably a candidate for seeding
<infinity> Check.
<infinity> I'll post the output delta before committing anything.
<infinity> cjwatson: Were you planning on a germinate upload before release, so xenial's vaguely self-hosting?
<cjwatson> infinity: Oh, a good point.
<cjwatson> Lemme shove that into Debian now and sync it tomorrow morning.
<cjwatson> (done)
<infinity> slangasek: http://lucifer.0c3.net/~adconrad/packageset-changes.txt
<infinity> slangasek: A fair bit to comb through.
<xnox> infinity, i still want to shove things in =)
<infinity> xnox: I'll file an HR complaint.
<xnox> infinity, i meant installer changes into xenial!
 * infinity lunches, finally.
<infinity> xnox: Yeah, I have installer fixes too.  Those get a free(ish) pass, as long as they're not crazy.
<xnox> infinity, multipath discovery by default on s390x.
<xnox> it works, and is expected by zfcp users....
<xnox> infinity, https://launchpadlibrarian.net/253795754/hw-detect_1.117ubuntu1_1.117ubuntu2.diff.gz ^
#ubuntu-release 2016-04-15
<slangasek> stgraber: ^^ perhaps open-vm-tools is something you'd like to give a second opinion on
<slangasek> infinity: aptdaemon, at-spi2-core: removed from 'core', and moved to a different packageset instead?
<slangasek> infinity: is there a good way to get boost-defaults included into the core packageset?
<slangasek> infinity: have seeded a few things; feel pretty good about what's left, modulo the boost-defaults question... and oh, maybe we want to make openjdk-8 stay in core. want to rerun that report against current seeds?
<slangasek> infinity, pitti: I've also taken care now of seeding the various static -dev packages that should get Built-Using'ed (with comment in the seed)
<slangasek> pitti: fwiw I don't see any reason to keep eperl in main, it seems to be just a specialized perl interpreter
<slangasek> doko, wgrant: why is nux on the FTBFS list if it only ftbfs on s390x and it's not built there? http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20160401-xenial.html
<wgrant> slangasek: "not built there"?
<wgrant> The rebuild test pages don't consider whether it built in the primary archive.
<wgrant> If it's in the arch list it'll build.
<slangasek> wgrant: ok.  makes it a bit harder to drive the list to 0 then
<slangasek> (i.e., less useful to drive it to 0 and harder to see which bits actually matter)
<infinity> slangasek: Don't recall the algorithm, but core happens when something is >> n packagesets (n might be 2).
<infinity> slangasek: So at-spi and aptdaemon probably fell out because they used to be in more due to build-deps.
<Kamilion> I just tried to create a new ext4 partition with gnome-disks and it segfaulted after creating the partition but before formatting it. Anyone else seen this behavior?
<infinity> slangasek: And are you cleaning up your c-m fallout from seed changes?  (I don't want to clash and hit the double-override bug)
<slangasek> infinity: yes I did clean up the c-m fallout, I think
<slangasek> infinity: ah, there's another round of it; I can do that now if you didn't already
<slangasek> infinity: right, those are cleaned up now; after the next c-m run everything should be Not Me
<pitti> slangasek: ah, cheers
 * pitti ughs at http://autopkgtest.ubuntu.com/running.shtml, glibc and a full round of KDE, that'll take ages
<pitti> I guesss we have to cut short the glibc tests
<slangasek> oh right, kde, that's why update_excuses jumped up by 120
<pitti> slangasek: nvidia-graphics-drivers-361-updates on c-m> that source can be removed, did you do that or demote?
<pitti> ah, /me should just check himself
<pitti> infinity removed it, perfect
<pitti> I guess I'll let some more glibc tests run, and once there's a sufficient amount of green and the reds get checked, I'll hint it in and flush the test queues
<slangasek> pitti: seems to me that there's no need to cut the queue short until that's actually a blocker for rolling images?
<slangasek> which according to infinity's mail isn't until "late Friday or early Saturday"
<pitti> slangasek: well, we basically can't land anything else right now
<pitti> and https://launchpad.net/ubuntu/xenial/+queue?queue_state=1 has some stuff which looks like it desperately wants to go in
<slangasek> hmm
<pitti> I estimate the current backlog to be ~ 2 days
<slangasek> how long does it take to complete a full glibc autopkgtest run?
<slangasek> ok
<pitti> KDE takes awfully long
<pitti> and of course glibc includes all those too, plus the rest of the archive
<slangasek> right, shouldn't be allowed to go too long then
<slangasek> how long is the backlog on the quickest arch? (which I think is s390x still?)
<slangasek> (can we at least get green for one arch before flushing?)
<pitti> s390x is insanely fast, I guess half a day or so
<pitti> yes, that's what I did last time
<slangasek> ok, cool
<pitti> i. e. I could remove glibc from the amd64/i386/armhf queues, keep s390x, and thus let KDE start on these arches
<pitti> then it should more or less settle by itself
<infinity> pitti: amd64/i386 share a scalingstack pool, I assume, yes?
<pitti> yes
<infinity> pitti: So, just kill i386 and leave amd64?
<pitti> works too, but i386 is much further ahead
<infinity> Or vice versa. :P
<pitti> 405 (i386) vs. 1050 (amd64)
<pitti> just because britney requests i386 before amd64
<pitti> infinity: yep, sounds good
<infinity> To be fair, nothing in that upload should regress on x86 anyway.
<infinity> But still nice to see *some* coverage.
<infinity> From a source perspective, that upload can't possibly break on armhf, so if there have been enough tests to qualify as a "yeah, not miscompiled crap" smoketest, you can whack armhf.
<pitti> infinity: yes, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#glibc has a hundred or so armhf: pass
<infinity> pitti: Righto, so flushing armhf glibc tests seems like it'd be fine.
<infinity> I mostly want good coverage on x86 because that's 99% of our userbase, and s390x because it actually had relevant and moderately scary commits.
<pitti> infinity: how about ppc64el?
<pitti> (couple hundred passes, only a few regressions which look unrelated)
<pitti> I mean in terms of arch specific change scariness
<pitti> "Fix HTM on powerpc/ppc64/ppc64el"
<infinity> slangasek: Oh, son of a.  I knew I was forgetting something.  We didn't address Till's lsb ld.so woes.  I'm thinking maybe just resurrecting lsb-core might be less crazy than adding the links to glibc this late.
<infinity> pitti: That was only relevant to 2.22
<infinity> pitti: (As in, it was a backport to 2.22 from 2.23, so we already had the commit)
<infinity> pitti: So, yeah, I don't think ppc64el needs more than smoketest coverage.
<pitti> ack, thanks; queues look more reasonable now (I slaughtered some other tests, I'll put them back once the queue settles down)
<pitti> infinity: wrt. unapproved review, how much do you want to do this yourself now?
<infinity> pitti: Always happy for help.
<pitti> infinity: I suppose today is still pretty much "if it looks sane, let it in", as we'll rebuild everything?
<infinity> pitti: I don't think we need to gate it down to a single tracking point/person until after langpacks are in, since no image can be "final" before that. :P
<infinity> pitti: And since you're the langpack man, you know exactly when that is.
<pitti> yes, that was my thought
<pitti> infinity: I asked wgrant to start an export now, and our BBQ is cancelled due to bad weather so I can do the package builds/review/upload tomorrow afternoon
<infinity> pitti: That sucks.  (The BBQ, not the langpacks)
<infinity> pitti: OOI, do we have any testing for langpacks, other than your spot-check?
<pitti> well, there's always the next weekend
<infinity> pitti: Seems like it would be trivial to write a generic autopkgtest that did a few useful things.
<pitti> infinity: not really, we just auto-upload everything to the devel series once a week and then have people complain
<pitti> which isn't very often, but we do see some issues every now and then
<pitti> like, evolution changes its domain every release, and templates need to be approved in LP, etc.
<infinity> Not that we can test for poor translations or anything, but we can test for functionality.
<pitti> but nothing substantial in terms of buliding them
<pitti> aside from the bug that sil2100 fixed last week
<Logan> the amount of spam on rcbugs is killing me
<pitti> ok, the rest is of the kind "why on earth are you uploading a 300 kB change after final freeze" kind
<infinity> setuptools was (barely) before freeze.
<infinity> And u-r-u has an obvious reason for the massive delta.
<pitti> right, currently reviewing that
<infinity> Though it might need a refresh after slangasek fiddled with the archive again. :P
<infinity> open-vm-tools, I dunno WTF that Steve guy is thinking.
 * infinity looks at LP: #1558198
<ubot5`> Launchpad bug 1558198 in open-vm-tools (Ubuntu) "[FFE] sync open-vm-tools from Debian for Xenial" [Undecided,Confirmed] https://launchpad.net/bugs/1558198
<pitti> u-r-u looks fine, accepted
<infinity> pitti: setuptools has an FFe filed, if you want to go have opinions about it.
<infinity> https://bugs.launchpad.net/ubuntu/+source/python-setuptools/+bug/1570587
<ubot5`> Launchpad bug 1570587 in python-setuptools (Ubuntu) "[FFe] Please update to bugfix release 20.7" [Undecided,New]
<pitti> I'll do this later on
<pitti> need to delve into the next upload of "scary openssl patches" again
<pitti> better sooner than later
<pitti> although that one should mostly be an effective no-op and just cleaning up patches
<pitti> slangasek: still some leftovers on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt, are you on this or should I move some stuff around?
<pitti> infinity: http://autopkgtest.ubuntu.com/packages/s/stress-ng/xenial/s390x/ regressed with a segfault in mmapfork
<pitti> infinity: not sure if that's a glitch (I'll retry), but so far this test has been fairly stable
<pitti> (no cking yet)
<pitti> could that be relevant?
<infinity> pitti: If it fails again, can you run that one on all arches?
<pitti> infinity: yes, will do; queue is almost done with setuptools and openssl, except on armhf
<infinity> pitti: Erk.  glibc just migrated...?
<pitti> meh, it did? I hoped I removed the override fast enough, after I saw that stress-ng thing
<infinity> Should wait for tests relating to glibc 2.23-0ubuntu3, but forced by pitti
<infinity> Valid candidate
<infinity> And it copied.  I have the email.
<pitti> ok, sorry about that the
<pitti> n
<infinity> Oh well.  We can investigate the stress-ng and I can upload a new one if it's an actual regression.
<pitti> spotted the stress-ng regression a few mins too late, the otehr regressions looked unrelated
<infinity> It's obviously not widespread if it is a regression.
<pitti> no, there are many hundred passes
<pitti> infinity: http://autopkgtest.ubuntu.com/packages/s/stress-ng/xenial/s390x/ retry worked, and pass on x86 too
<pitti> phew
 * LocutusOfBorg hopes that now fpc will be installable on powerpc with the new glibc
<Laney> Trevinho: Can you tell me what we should do for the 'minimal' hud & friends fix please?
<pitti> oh nice, the full langpack export is ready
<flexiondotorg> Laney, can you remind me of the correct syntax to request unblocks please?
<Laney> flexiondotorg: I don't think there's a block on atm
<Laney> you're just waiting for queue review
<pitti> langpack flood coming in, brace for impact
 * Laney ducks and covers
<pitti> argh again -- dput from britney takes awfully long, like last time; so this dput business will take some two hours, easy for buildds to keep up with
<Laney> s/britney/snakefruit/?
<pitti> yes, that
<pitti> (britney is my ssh alias)
<Laney> hmm
<Laney> did IS look into that?
<pitti> I didn't file an RT so far
<pitti> Laney: as I'll leave in about an hour, do you mind running this in the background:
<pitti> while queue -s xenial-proposed -Q unapproved -E accept language-pack-; do sleep 300; done
<Laney> pitti: okay
<Laney> doing
<pitti> Laney: cheers; it did the first batch
<Laney> nod
<LocutusOfBorg> doko, python-numpy merge?
<xnox> infinity, shiny, i see new kernel.
<flexiondotorg> Laney, what does "you're just waiting for queue review" mean?
<Laney> flexiondotorg: didn't you see this before?
<flexiondotorg> And how does that relate the infinity email from last night about Final Freeze being in place?
<Laney> https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=
<flexiondotorg> So I'm familiar with the new queue.
<flexiondotorg> Will seeded uploads make it to the release pocket automatically at the moment or will they require manual intervention.
<flexiondotorg> Laney, that ^^^ is what I'm not clear on.
<Laney> That's the unapproved queue, and uploads are held there. This freeze has been on for a few weeks already. People are proactively reviewing it.
<Laney> You only need "unblock" when there is a freeze at proposed-migration, which there is not currently
<flexiondotorg> Laney, Thanks for the clarification.
<ogra_> can some archive admin push https://launchpad.net/ubuntu/+source/linux-meta-snapdragon/4.4.0.1009.1 and https://launchpad.net/ubuntu/+source/linux-snapdragon/4.4.0-1009.9 from proposed to the archive ?
<xnox> ogra_, as per http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html no clever admin is needed.
<xnox> ogra_, all proposed->release are automatic
<xnox> Invalidated by dependency
<xnox> Not touching package as requested in bug 1567379 on Thu Apr 7 11:36:21 2016
<ubot5`> bug 1567379 in Kernel Development Workflow "linux-snapdragon: 4.4.0-1011.11 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1567379
<xnox> ogra_, so ping rtg to remove the block-proposed tag from that bug report, if all the testing and kernel upload procedure has been done correctly.
<ogra_> xnox, yep, will do, thanks
<Trevinho> Laney: well, if you agree with I can open a different bug (which I should have done anyway) about the fact that window actions aren't accessibile from HUD and we just merge HUD and BAMF... While we leave the keybinding stuff for some (even later?) decision
<Laney> Trevinho: Okay, so just taking those two is enough?
<Trevinho> Laney: yep... But I also removed from silo the offending MPs
<Trevinho> Laney: so silo could be kept with other unity and compiz fixes
<Laney> Trevinho: Then please rebuild and re-publish those two if they are fix only
<Trevinho> Laney: ok
<Laney> thanks!
<Laney> I'm going to reply
<Trevinho> Laney: well, there's even a dependency change in BAMF, but on libdbusmenu which is already well used around.
<Laney> if someone wants to force it through then we have a process for that
<rbasak> Incoming security update for MySQL 5.7. The microrelease update is available from upstream, though not the full announcement. Only the pre-announcement: http://www.oracle.com/technetwork/topics/security/cpuapr2016-2881694.html
<rbasak> We'll have a bug to track this in Ubuntu shortly.
<rbasak> I can upload the update now if that's desirable?
<rbasak> I also have a NEWS file to add (missed in previous upload) which I presume won't be an issue. No other packaging changes.
<rbasak> bug 1570808
<ubot5`> bug 1570808 in mysql-5.7 (Ubuntu) "Security fixes from the April 2016 CPU" [Undecided,New] https://launchpad.net/bugs/1570808
<barry> pitti: i definitely want to try to get dirtbike 0.3-2 and python-pip 8.1.1-2 into 16.04 but syncpackage has been saying they haven't been picked up by LP yet since yesterday afternoon
<cjwatson> barry: dak has been broken
<barry> cjwatson: gosh, again?
<cjwatson> I can only assume they have no tests for the pdiff code, because it apparently keeps breaking
<barry> cjwatson: yeah, at like the worst possible times for us ;)
<cjwatson> anyway, not an LP problem, we'd be importing stuff if it was published enough on the Debian side to import
<barry> cjwatson: is there any other acceptable work around?
<ogra_> there is rtg !
<rtg> ogra_, indeed
<ogra_> rtg, i was wondering about bug 1567379 ... there are hacks in livecd-rootfs that work around the missing -meta which i'd like to drop asap ... but that requires the meta to be in the archive
<ubot5`> bug 1567379 in Kernel Development Workflow "linux-snapdragon: 4.4.0-1011.11 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1567379
<rtg> ogra_, lemme see where that is. I thought it all should have been promoted by now.
<ogra_> rtg, we also still miss the firemware package i think
<ogra_> without it no WLAN (which is the only interface on that board)
<rtg> ogra_, yup
<cjwatson> barry: well, I'm still crossing fingers for dak to be fixed soon.  If it really has to be today then I guess a fakesync would be acceptable, though I normally deplore those where unnecessary
<zequence> Getting really close to release. Any chance to get our stuff merged into ubiquity and ubiquiti-slideshow-ubuntu? Very small changes, but important for us. Sorry we are so late with this.
<zequence> Bug 1569005
<ubot5`> bug 1569005 in ubiquity-slideshow-ubuntu (Ubuntu) "New ubiquity slideshow for Ubuntu Studio [UI Freeze Exception]" [Undecided,New] https://launchpad.net/bugs/1569005
<zequence> Bug 1568981
<ubot5`> bug 1568981 in ubiquity (Ubuntu) "new Ubuntu Studio wallpaper for ubiquity installer [UI FREEZE EXCEPTION]" [Undecided,New] https://launchpad.net/bugs/1568981
<LocutusOfBorg> pretty please virtualbox, with serious fixes for xorg 1.18
<LocutusOfBorg> on guest, as well as the guest-additions-iso package
<barry> cjwatson: thanks, i'll keep trying
<sil2100> Hello release team! livecd-rootfs doesn't seem to be seeded anywhere, where we need the new version to unblock ubuntu-touch xenial builds again (hash-mismatches)
<sil2100> Could someone poke it in from the unapproved queue?
<Laney> We're looking frequently, no need to ping :P
<sil2100> ACK ;)
<sil2100> Thanks!
<Laney> Trevinho: ^- that's for you
<Laney> thanks, queue accepter!
<Trevinho> Laney: thanks a lot
<Laney> Trevinho: I'm going to unblock bamf and hud now, let me know when unity and compiz are ready
<Laney> please
<Trevinho> Laney: silo is building instead
<Trevinho> Laney: oh, wait.. as I've triggered a rebuild for fixing changelog bigs
<Trevinho> bugs*
<Laney> oh for those too?
<Trevinho> yes
<Trevinho> as it's a different bug
<Laney> ok
<Laney> then I'm going to get lunch, let me know when published to xenial-proposed
<Trevinho> Laney: just waiting for hud to finish building in arm https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-059/+packages
<Trevinho> Laney: ok, it should be matter of minutes but take your time
<Laney> you can get sil2100 or someone to do that for you
<Trevinho> Laney: oh, actually it finished building it seems
<sil2100> What's up?
<Trevinho> sil2100: this needs love https://requests.ci-train.ubuntu.com/#/ticket/1251 :)
<sil2100> Trevinho: did you fix the changelog issues as per what the silo is reporting?
<Trevinho> sil2100: yes, I had to force rebuild. But it's fine I'm overriding that, since these have not been really released.
<Trevinho> sil2100: they were blocked in proposed, so we want those changelog entries not to be really there.
<sil2100> Oh, ok
<sil2100> Trevinho: so you would like to re-release the silo as it is right now, yes?
<Trevinho> sil2100: yep
<sil2100> Ok, on it
<sil2100> Trevinho: published
<flexiondotorg> I'm in search of a sponsor for this - https://bugs.launchpad.net/ubuntu/+source/mate-menu/+bug/1570554
<ubot5`> Launchpad bug 1570554 in mate-menu (Ubuntu) "Sync mate-menu 5.7.1-1 (universe) from Debian unstable (main)" [Undecided,New]
<flexiondotorg> Can anyone help with that?
<rbasak> flexiondotorg: are you sure bug 1568170 is suitable for a final freeze upload?
<ubot5`> bug 1568170 in ubuntu-mate "add software boutique to advanced mate menu" [Medium,Fix committed] https://launchpad.net/bugs/1568170
<bzoltan> hello folks, I have a package what I need in Xenial - https://requests.ci-train.ubuntu.com/#/ticket/1274 This does not bring new binaries and does not impact functionality. it is needed for the  application development as it provides the correct templates for the IDE. The LTS-Wily-Xenial SDK IDE is built from the xenial release of this package.
<flexiondotorg> rbasak, I am.
<flexiondotorg> rbasak, That feature was added in an earlier release but has a logic error.
<flexiondotorg> It was someone reporting the idea of adding it that alerted me to the fact it wasn't working.
<rbasak> OK. Well as it's you I'm happy to leave that between you and the release team.
<rbasak> I'm happy to sync but https://launchpad.net/debian/+source/mate-menu doesn't show it there yet.
 * rbasak wonders if he needs to wait or do some kind of fakesync or something.
<cjwatson> dak has been broken.  If it's today-urgent, do a fakesync
<flexiondotorg> I heard dinstall was broken yesterday.
<flexiondotorg> But I saw it turn up hear - https://packages.debian.org/source/sid/mate-menu
<flexiondotorg> So thought all was fine now.
<cjwatson> $ curl -Is http://ftp.debian.org/debian/dists/sid/InRelease | grep ^Last-Modified:
<cjwatson> Last-Modified: Fri, 15 Apr 2016 09:17:45 GMT
<cjwatson> might actually work in a few hours then
<rbasak> Better to wait or do a fakesync?
<barry> i'm going to wait until later in my day to sync the couple i need.  if it doesn't come back by near my eod, i plan on fake syncing them
<rbasak> flexiondotorg: btw, for next time, I don't believe "(LP:#1560332)" in debian/changelog works. You want a space there: "(LP: #1560332)" for automatic stuff to pick it up. Though you can just close the LP bugs manually once the fixes have landed.
<ubot5`> Launchpad bug 1560332 in ubuntu-mate "MATE Menu - Advanced menu, preferences regression 16.04 beta 1" [Medium,Fix committed] https://launchpad.net/bugs/1560332
<flexiondotorg> rbasak, That is the Debian Developer doing that when they upload.
<flexiondotorg> I'll feed that back.
<cjwatson> Uh.  https://packages.debian.org/source/sid/mate-menu matches https://launchpad.net/debian/+source/mate-menu
<cjwatson> Both show 5.7.0-1, not 5.7.1-1
<cjwatson> http://ftp.debian.org/debian/dists/sid/main/source/Sources.xz has 5.7.1-1, though
<flexiondotorg> http://incoming.debian.org/debian-buildd/pool/main/m/mate-menu/
<rbasak> https://tracker.debian.org/pkg/mate-menu seems to see 5.7.1-1 and I was able to dget from http://httpredir.debian.org/debian/pool/main/m/mate-menu/mate-menu_5.7.1-1.dsc
<rbasak> So perhaps just publication delay?
<rbasak> (and or pts/packages.d.o update delay)
<cjwatson> There'll have been a significant publication delay due to dak breakage.
<cjwatson> The next LP sync will be in a bit over two hours.
<cjwatson> So we'll see ...
<rbasak> flexiondotorg: ping me a bit later if I forget if you like?
<flexiondotorg> rbasak, Thanks.
<jamespage> infinity, pitti: some further information on https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1563714
<ubot5`> Launchpad bug 1563714 in ceph (Ubuntu) "[FFe] Ceph Jewel stable release" [Undecided,Confirmed]
<jamespage> discussed with sage  -  jewel release is likely to be wednesday, but I can't turnaround the packaging refresh and testing quick enough so I think a SRU when that's done is the best way forward...
<flexiondotorg> The X2Go team ask me to file an FFe for X2Go client.
<flexiondotorg> Can I get a release team ack?
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/x2goclient/+bug/1569310
<ubot5`> Launchpad bug 1569310 in x2goclient (Ubuntu) "FFe: Sync x2goclient 4.0.5.1-1 (universe) from Debian unstable (main)" [Undecided,New]
<cjwatson> infinity: so, the libnss change; I have a feeling that we'll need to cherry-pick Aurelien's changes to d-i to use mklibs-copy everywhere and to drop libc* from build/pkg-lists/exclude.  What do you think?
<cjwatson> infinity: (and your change to d-i to drop those udebs of course)
<LocutusOfBorg> pretty please can anybody accept virtualbox?
<cjwatson> infinity: I've uploaded fixes for everything else using libnss-*-udeb, modulo waiting for openssh to be syncable from unstable
<LocutusOfBorg> infinity, please can you accept virtualbox?
<LocutusOfBorg> we really need this one, to comply with xorg rootless on guests
<LocutusOfBorg> I hoped on a new release before the freeze, but I can only have a patch for now
<cjwatson> dak must be working again now, because Debian imports are; they're up to libg<something> now.
<cjwatson> rbasak: ^-
<cjwatson> Ah, you wanted mate-menu didn't you.
 * cjwatson taps fingers
<flexiondotorg> cjwatson, Thanks for checking. I just looked.
<Odd_Bloke> infinity: FYI, we're hoping to get open-vm-tools in to the archive before we start spinning images; upstream have committed to supporting 10.0.7 (the version in -proposed) but not 10.0.0.
<Odd_Bloke> infinity: (Where the "we" spinning images is all of us, because it's in the server ISOs as well as cloud images :)
<cjwatson> rbasak,flexiondotorg: mate-menu 5.7.1-1 is there now
<rbasak> cjwatson: thanks!
<flexiondotorg> cjwatson, rbasak Thanks!
<Odd_Bloke> infinity: Oh, I see you've seen that; rcj is doing some extra validation this morning (he's validated it once, but then Steve showed us how to do a better merge and he's re-testing the new version).
<rbasak> flexiondotorg: ^^ synced
<infinity> cjwatson: Yes, I was intending to take the mklibs-copy change.  Dependency changes shouldn't be necessary, I'd have thought, since libc-udeb provides nss-udeb*
<cjwatson> infinity: Oh, so it does, I swear it didn't when I looked.  Still, they won't hurt.
<cjwatson> infinity: The pkg-lists changes may be necessary to stop d-i FTBFSing after NBS cleanup (or maybe not, not certain).
<infinity> cjwatson: The pkg-lists changes shouldn't be necessary either, but I'll do them to be more correct.
<cjwatson> barry: ^- in case you didn't notice, Debian imports are back
<flexiondotorg> rbasak, Thanks for taking care of that. I really appreciate it.
<stokachu> hmm i uploaded juju-core-1_1.15.5 last night but i never got a email and i dont see it in the queue
<stokachu> 1.25.5*
<stokachu> is there any record of that version being uploaded and if it was rejected?
<stokachu> was uploaded the same time as juju 2.0 beta4
<marco-parillo> Odd_Bloke: Would that include open-vm-tools-desktop also?
<rbasak> flexiondotorg: np, but note that the release team still need to review it since it's seeded
<rbasak> flexiondotorg: https://launchpad.net/ubuntu/xenial/+queue?queue_state=1
<Odd_Bloke> marco-parillo: That would also include -desktop, yes.
<flexiondotorg> rbasak, Noted.
<ogra_`> stokachu, https://launchpad.net/ubuntu/xenial/+queue?queue_state=4&queue_text=juju (no idea why it is in rejected)
<stokachu> hmm 1.25.5 is not there
<stokachu> odd i didnt get any error emails or anything
<stokachu> https://www.irccloud.com/pastebin/Ivr79tLk/
<cjwatson> stokachu: one moment
<stokachu> thanks
<flexiondotorg> infinity, Can I request that mate-menu get a review please?
<cjwatson> 2016-04-15 00:12:31 INFO    Failed to parse changes file '/srv/launchpad.net/ubuntu-queue/incoming/upload-ftp-20160415-001123-006217/ubuntu/juju-core-1_1.25.5-0ubuntu1_source.changes': GPG verification of /srv/launchpad.net/ubuntu-queue/incoming/upload-ftp-20160415-001123-006217/ubuntu/juju-core-1_1.25.5-0ubuntu1_source.changes failed: Verification failed 3 times: ["(7, 9, u'No public key')", "(7,
<cjwatson>  9, u'No public key')", "(7, 9, u'No ...
<cjwatson> ... public key')"]
<cjwatson> stokachu: ^- must have been a keyserver failure of some kind, please try reuploading
<stokachu> cjwatson: ok thanks ill try now
<cjwatson> unsatisfying failure, that, since that usually means "unsigned" but you've shown evidence that that wasn't the case
<cjwatson> but I have no more telemetry on it
<stokachu> it looks like it went through this time
<infinity> cjwatson: Bah, again?
<infinity> cjwatson: How many times (and with what interval) does it retry the keyserver?
<infinity> cjwatson: This seems to have gotten decidedly more unreliable recently (or, it's just happening to whinier people recently, like me)
<rbasak> infinity: opinion on bug 1570808 please? Worth getting into the release pocket?
<ubot5`> bug 1570808 in mysql-5.7 (Ubuntu) "Security fixes from the April 2016 CPU" [Undecided,New] https://launchpad.net/bugs/1570808
<infinity> rbasak: Probably valuable to at least evaluate getting .12 in, can you put it together and shove a diff somewhere?
<rbasak> infinity: ack
<infinity> rbasak: If it's too daunting to consider sanely QAing it before release, you can shunt it to the security team for a post-release security update.
<cjwatson> infinity: three times, but zero interval.  I'm not sure whether the reliability has changed particularly, I've always been a bit suspicious of this
<infinity> cjwatson: It's entirely possible it's always been this reliable and it's just happening to more vocal people lately.  Randomness is random.
<rbasak> infinity: QA for MySQL (upstream code, not packaging) consists of build tests and dep8. I'm confident in upstream and the test coverage. We have yet to find a regression in that.
<rbasak> infinity: would you be happy with that?
<infinity> rbasak: Probably, but I'd like to see the diff anyway.
<rbasak> OK
<infinity> cjwatson: Is there a proxy or something masking the difference between "no key found to match your query" and "keyserver is busted", or is that process just blatantly ignoring the difference?
<infinity> cjwatson: (Or is our keyserver actually failing in such a subtle way that it's returning "no key" when it's actually sad?)
<infinity> cjwatson: I suppose on the roadmap for "make launchpad stop assuming all networks and services are 100% reliable", one could also argue that working off local keyring exports wouldn't be stupid (though introduces an unfortunate delay between making changes and seeing them).
<cjwatson> infinity: I'm not sure what the problem is.  The first step would have to be more verbose logging.
<infinity> cjwatson: Righto.  Well, I'm sure you have tons more important things to tackle, but some day this would be nice to understand.
<cjwatson> infinity: Yep, so my current project is auto-uploading snaps to the store, then after that Mark asked for github bug linking a while back and we probably ought to keep him happy :-), but after that things are looking promising for being able to tackle some of the chunkier bits of backlog.
<rbasak> cjwatson: github bug linking> ah, the server team were going to ask you for that. I guess we don't need to then? :)
<rbasak> (there is a bug on it I believe)
<infinity> cjwatson: Bug linking in Malone, or URLification of some github: #123 string?
<cjwatson> rbasak: Indeed
<cjwatson> infinity: the former
<cjwatson> like debbugs references and such
<rbasak> bug 848666 is it
<ubot5`> bug 848666 in Launchpad itself "Support GitHub issues as external bugtracker" [Low,Triaged] https://launchpad.net/bugs/848666
<cjwatson> yes, I know
<rbasak> jgrimm: ^^
<rbasak> Cool, thanks :)
<infinity> cjwatson: Aww, kay.  If it was the latter, I was going to ask for proper support for genchanges bug parsing in the URLification code so we can link Debian bugs in changelogs. :P
<jgrimm> rbasak, nice
<infinity> But since you're not mucking around in that code, nevermind.
<cjwatson> infinity: yes, I see you filed https://bugs.launchpad.net/launchpad/+bug/1481471 on that
<ubot5`> Launchpad bug 1481471 in Launchpad itself "Please linkify Debian bug closures on parsed changelogs" [Low,Triaged]
<cjwatson> infinity: remind me at the release sprint
<rbasak> infinity: got a fix for apache2 that we think is fine for a 0-day. Do you want it in the queue or should I wait before uploading next week?
<infinity> rbasak: In the queue.
<infinity> doko: What's with the change to debian/control.powerpc.in ?
<doko> infinity, unused file
<infinity> doko: Okay, so biarch bits aren't being dropped from powerpc-cross?
<doko> no
<infinity> doko: Excellent.  Thanks.
<doko> infinity, btw, I'm building a gccgo-6 6.0.1 in my ppa, release candidate 1. no go/libgo or libgcc changes. will wait for the test results before asking for FFe ...
 * infinity goes to see if Tim Horton's produces a coffee with the approximate volume of a small child.
<Odd_Bloke> #JustCanadianThings
<cyphermox> infinity: there used to be the SuperTim, for the barrel-sized coffees, but I'm not sure they still do that
<cyphermox> I still have a container for it ;)
<wxl> infinity: hey with the delay of the rc, we're still planning on a normal final release date, correct?
<rcj> Odd_Bloke, infinity: open-vm-tools in -proposed looks good.  Test results in bug #1558198.  Hoping to get this out of -proposed before image builds start as Odd_Bloke was saying earlier.
<ubot5`> bug 1558198 in open-vm-tools (Ubuntu) "[FFE] sync open-vm-tools from Debian for Xenial" [Undecided,Confirmed] https://launchpad.net/bugs/1558198
<infinity> wxl: What delay?
<infinity> wxl: This is exactly how it's gone for several cycles.
<wxl> infinity: well, RC was supposed to be released yesterday?
<infinity> wxl: release candidates start "after final freeze", but it's never been immediately after.
<wxl> infinity: k, thx
<infinity> wxl: None of that should stop people from testing dailies, though.  Find bugs now and we can fix them before release.  Don't test until something is an "RC", and well, it's not much of an RC.
<nacc> infinity: i think it's a confusion due to the releaseschedule page -- i've seen a few similar queries in #ubuntu since yesterday
<nacc> https://wiki.ubuntu.com/XenialXerus/ReleaseSchedule indicates April 14th is "the" ("a"?) ReleaseCandidate
<infinity> nacc: Clicking the link helps.
<infinity> nacc: We don't release "a release candidate".
<wxl> nacc: it's confusing because none of the rc's for other milestones are put on the schedule
<nacc> infinity: yes, but why put something on the schedule that doesn't exist?
<wxl> and it does exist
<wxl> it's just not released in the same way as the actual milestones
<infinity> I could rename it "release week", I suppose.
 * infinity shrugs.
<nacc> yeah, i guess it's a varied difference of "it" :)
<wxl> i like that, infinity
<wxl> because i've had this argument with several people over time
<nacc> infinity: it may not matter, i was just trying to figure out if there was a good answer to give ... will just point to the text there
<wxl> i thought at some point we DID stop calling it an RC but i guess not
<wxl> i mean by that notion every daily image is an rc
<wxl> release week implies a sustained effort towards getting all the last minute showstoppers taken care of immediately
<wxl> and implies an impending deadline
<cjwatson> every daily image isn't an rc because there isn't generally a possibility that we might stop and call it done at that point
<cjwatson> but during release week there is such a possibility, getting less theoretical as the week goes on
<wxl> that's entirely logical
<wxl> but i think at least some folks seem to think rc is a milestone
<cjwatson> the reason we don't release a separate RC as such any more is that we used to have a thing that was actually labelled "Release Candidate" on the image itself, which could therefore never be an actual candidate for release since we were always going to have to at minimum rebuild it to get rid of the "candidate" label
<wxl> maybe this is because some other projects consider rc a release
<wxl> ?
<wxl> i don't think the idea of "release week" necessarily violates what the intention of the rc is, right, cjwatson ?
<cjwatson> people think all sorts of things, I don't think we necessarily need to worry about some of them being wrong; especially since people treating "RC" as a milestone is basically a good thing, better than them aiming for release
<infinity> Could we bikeshed about this when we're not all busy doing the actual work involved in release week? :P
<cjwatson> I'm not going to obsess about correcting everyone who gets it wrong
<wxl> yuuup :)
<infinity> Laney: What's with the uploader path leakage in gnome-software/data/featured.ini?
<infinity> Laney: Kinda gross, kinda noisy, and curious if it also affects the built binaries?
<infinity> Laney: (for example)
<infinity> -background=url('/home/laney/jhbuild/install/share/gnome-software/featured-polari.svg') 70% 80% / 120% auto no-repeat, #43a570
<infinity> +background=url('/home/william/Code/jhbuild/install/share/gnome-software/featured-polari.svg') 70% 80% / 120% auto no-repeat, #43a570
<infinity>  stroke=#4e9a06
<Odd_Bloke> infinity: Sorry to keep bugging you about open-vm-tools, but we aren't sure who else to bug (^_^); what needs to happen for us to unblock it in to the archive?
<Odd_Bloke> infinity: (I tried bugging slangasek which worked yesterday, but he's OOO today :p)
<infinity> Odd_Bloke: Nothing.  It'll migrate in the next run.
<Odd_Bloke> infinity: <3
<cyphermox> infinity: freetype ^ will still need a no-change rebuild of grub2, and then grub2-signed of course
<infinity> pitti: Two langpacks seem to have gone AWOL?
<infinity> pitti: gnome-bs-base and gnome-sk didn't get updated with gnome-bs and gnome-sk-base, looks like.
<flexiondotorg> Can someone review mate-menu please.
<infinity> flexiondotorg: We'll get there.
<flexiondotorg> Roger.
<infinity> jdstrand: appnames can start with [a-z0-9] but use upper case from the second char on?
<infinity> jdstrand: Why the restriction on the first char?
<infinity> jdstrand: Or is that a bug in your patch (and test)?
<jdstrand> infinity: it's a cheap test, but after discovering bug #1571048, why don't you hold off on that. it will have a super small patch too and I can refine the appname test
<ubot5`> bug 1571048 in ubuntu-core-launcher (Ubuntu) "ubuntu-core-launcher querying udev for wrong name" [High,In progress] https://launchpad.net/bugs/1571048
<infinity> jdstrand: The test (network-manager.NetworkManager) sort of implies that UpperCase is only allowed after the first '.', which the regex doesn't enforce.  If it's allowed before the first '.', I'm not sure why it wouldn't be allowed in the first char.
<infinity> jdstrand: Perhaps a comment block above the regex that desribes the spec it's meant to be implementing wouldn't go amiss. ;)
<jdstrand> sure
<jdstrand> feel free to reject that one since I'll have another in a few minutes
<infinity> jdstrand: Just did.
<infinity> jdstrand: If this is Java-style vendor namespaces, I'd assume the regex should perhaps express uppercase is allowed after the *last* period, or in the entire name in the absense of periods.
<jdstrand> it isn't that
<jdstrand> I'll document it
<infinity> jdstrand: ie: net.company.MyCoolApp or company.MyCoolApp but not Company.MyCoolApp
<infinity> jdstrand: Okay.  Document away. :)
<jdstrand> it is sorta that, but anyhoo, I'll document
<infinity> (In the above example, I'd assume a bare 'MyCoolApp' without namespace would also be okay)
<seb128> infinity, seems like the gnome-software issue is something to look at but it's nothing due to the update so shouldn't block it imho
<seb128> if you want somebody to look at it now better to ping attente though, it's friday evening for Laney
<infinity> seb128: No, indeed, it's exposing a (potential) existing bug, not adding one.
<infinity> seb128: It's not blocking the review, was just a "WTF" I noticed in passing.
<seb128> k, since you didn't accept the update I was unsure if that made you skip it waiting for a reply
<slangasek> infinity: yes, I prefer resurrecting lsb-core to touching glibc again.
<infinity> slangasek: Oh, fresh packageset run after your fiddling: http://lucifer.0c3.net/~adconrad/packageset-changes-new.txt
<slangasek> infinity: also, if you're sorting lsb-core, do you want to trade that to Till for fixing his outstanding MIR?  (Do we really need two separate braille renderers being pulled in by default from cups?)
<slangasek> infinity: cool. anything on there that bothers you?
<slangasek> I'd suggest it should go out to ubuntu-devel for review
<infinity> slangasek: Hard to say, given the unreadable mess of the format.  Haven't had a chance to read it all yet.
<slangasek> k
<infinity> slangasek: As for Till's MIR, you mean https://bugs.launchpad.net/ubuntu/+source/liblouisutdml/+bug/1564058 ?
<ubot5`> Launchpad bug 1564058 in liblouisutdml (Ubuntu) "[MIR] liblouisutdml" [Undecided,Incomplete]
<slangasek> infinity: yes
<LocutusOfBorg> still no accepted virtualbox :'(
<infinity> LocutusOfBorg: Oh, I was waiting for you to pop up.
<infinity> LocutusOfBorg: Any meaningful reason (the control tweak doesn't seem to matter) to take your -3build1 upload rather than just syncing -3?
<infinity> LocutusOfBorg: -3build1 is a lie anyway, since it contains a change from Debian. :P
<Ukikie> IIRC, at the time it was in incoming/
<LocutusOfBorg> infinity, broken dak
<LocutusOfBorg> was the reason
<LocutusOfBorg> if you reject I can sync from experimental
<LocutusOfBorg> and I don't know how much time I have for it
<LocutusOfBorg> ok sync request done
<LocutusOfBorg> <3
<LocutusOfBorg> I still hope to have a 5.0.18 in time for xenial
<LocutusOfBorg> this version is something in the middle
<mgz_> I have an autopkgtest problem. the ubuntu run fails, but my local version does not. is there a way to rerun the tests with more debug stuff without actually making a new package and uploading it just to do that?
<infinity> No, but you can run it locally the same way it's being run remotely...
<mgz_> I did, as far as I was able
<mgz_> I guess I can try and get a big enough machine for the qemu virt server instead
<infinity> 2016-04-15 07:59:47 ERROR cmd supercommand.go:448 Get https://10.0.8.1:8443/1.0/profiles: Forbidden
<infinity> That seems like something that shouldn't be too hard to reproduce...
<mgz_> yup. passes on a canonistack vm, works in manual testing.
<mgz_> didn't get any good ideas from the lxd team.
<mgz_> it's almost certainly something small and dumb, but I have no idea what.
<flexiondotorg> infinity, Thanks!
<flexiondotorg> infinity, The X2Go team asked me to file this FFe on their behalf. Any chance of an ack?
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/x2goclient/+bug/1569310
<ubot5`> Launchpad bug 1569310 in x2goclient (Ubuntu) "FFe: Sync x2goclient 4.0.5.1-1 (universe) from Debian unstable (main)" [Undecided,New]
<flexiondotorg> It is not need to the images, but they'd like it in the official archive because translations are fixed.
<mgz_> infinity: if I have a test packaging change that might help but I'm not certain, will you accept the package?
<infinity> flexiondotorg: ^
<infinity> mgz_: Maybe?
<flexiondotorg> infinity, Thanks.
<infinity> mgz_: Would be nicer if you knew it fixed it. :P
<seb128> ^ the theme update there has small calendar app/widget fixes and one changeset that updates some suru icon which is touch specific (so should be fine/not impact on any desktop env)
<flexiondotorg> infinity, And if I'm not being too cheeky (which I know I am) this is the last from me.
<flexiondotorg> https://bugs.launchpad.net/bugs/1570874
<ubot5`> Launchpad bug 1570874 in engrampa (Ubuntu) "Sync engrampa 1.12.0-2 (universe) from Debian unstable (main)" [Undecided,New]
<flexiondotorg> Bug fix for working with p7zip.
<flexiondotorg> I'll let the X2Go guys know, they'll be very pleased :-)
<mgz_> infinity: well, I need to find someone to upload it too, so I guess getting anything done is just maybe
 * infinity lunches.
<flocculant> infinity: ummm
<flocculant> just triple checked
<flocculant> built a usb with 'disks' went straight to desktop - no try/choose window - no idea if accessibility is working or an option at that point
<Kamilion> oh, awesome, thanks for getting x2go sorted, flexiondotorg
#ubuntu-release 2016-04-16
<doko> slangasek, pitti: eperl wants to demote.  which package should have a Built-Using: eperl? or should it be just seeded?
<ianorlin> flocculant, infinity I had something similar in booting a kvm virtual machine multiple times as well
<ianorlin> with lubuntu
<slangasek> doko: I'm not sure that we want either for eperl, it seems to me it should just be demoted.  I'm not sure why pitti thought that one should come back into main
<zequence>  Any kind soul who could squeeze these in for us, at this late hour?
<zequence> Bug 1568981
<ubot5`> bug 1568981 in ubiquity (Ubuntu) "new Ubuntu Studio wallpaper for ubiquity installer [UI FREEZE EXCEPTION]" [Undecided,New] https://launchpad.net/bugs/1568981
<zequence> Bug 1569005
<ubot5`> bug 1569005 in ubiquity-slideshow-ubuntu (Ubuntu) "New ubiquity slideshow for Ubuntu Studio [UI Freeze Exception]" [Undecided,New] https://launchpad.net/bugs/1569005
<slangasek> ^^ this pulls a fix from Debian that was uploaded shortly after 2.02.133-1 was merged (I maybe should've called this 2.02.133-2ubuntu1) that resolves a problem with lvm snapshotting being slow and dmeventd failing to monitor
<slangasek> (so if you use schroot with lvm snapshots, this is why they're slow to setup/teardown, and why you get noise on stderr... which also breaks adt-virt-schroot)
<Laney> infinity: It's regenerated at build time anyway - it's an AC_CONFIG_FILE
<Laney> Just shouldn't be put into the release tarballs
<infinity> Laney: Do the paths actually come out sane at build time? :P
<Laney> Yeah
<Laney> check the file on your system
<Laney> https://git.gnome.org/browse/gnome-software/commit/?h=wip/iainl/ubuntu-xenial&id=1f5bc7571c4647ce3d47640f49f428ef0a89b66f anyways
<bzoltan> folks, is here anybody who could pubish a landing silo what stuck after a late QA approval? I could use the time to integrate this release to the IDE.
<bzoltan> https://requests.ci-train.ubuntu.com/#/ticket/1266
<clivejo> does anyone here understand whats changed with mysql?
<clivejo> I have a Kubuntu system with apps that require MySQL to work.  Ever since the update to MySQL a few days ago they have all stopped working
<doko> https://bugs.launchpad.net/ubuntu/+source/gccgo-6/+bug/1571182 ^^^
<ubot5`> Launchpad bug 1571182 in gccgo-6 (Ubuntu) "FFe: update gccgo-6 to the GCC 6.1 release candidate 1" [Undecided,New]
<apw> clivejo, i would recommend asking on #ubuntu-server based on the previous uploaders for that ...
<clivejo> apw: hi, do you know was there a FFE for MySQL?
<apw> clivejo, what version worked, and which not?
<clivejo> the one previous to the version releases in the last week or so worked fine
<apw> (there are more than one base release in xenial)
<clivejo> its only since an update a few days ago
<clivejo> on the 14th my system upgraded to mysql 5.7 libmysqlclient20
<clivejo> but the problem upgrade was on the 7th I believe when I went from 5.6 to 5.7
<apw> clivejo, so it depends what version you had before, but that might well have been ubuntu3 which had an FFE LP: #1528583
<ubot5`> Launchpad bug 1528583 in mysql-5.7 (Ubuntu) "[FFe] Please update to MySQL 5.7 series" [Wishlist,In progress] https://launchpad.net/bugs/1528583
<clivejo> ubuntu3 was when I started seeing problems
<clivejo> that was installed on the 7th
<clivejo> which was then upgraded to ubuntu6 on the 14th
<clivejo> but from the 14th my problems have got worse
<apw> that all was uploaded by rbasak so i'd ask on #ubuntu-server ...
<Skuggen> clivejo: What's the issue?
<clivejo> I dont actually know!
<Skuggen> What happens, then? :)
<clivejo> apps that use it wont work
<Skuggen> Which apps, specifically?
<clivejo> GREPME MySQLe query failed! (2000) mysql_embedded: Shutdown complete
<clivejo> amarok and kontact that I know of
<Skuggen> amarok was very recently fixed to build with MySQL 5.7, at least
<Skuggen> Which MySQL 5.7 package version are you using now?
<clivejo> ubuntu6 I believe
<Skuggen> And amarok?
<clivejo> 2:2.8.0-0ubuntu8
<clivejo> rebuilt - -- Robie Basak <robie.basak@ubuntu.com>  Wed, 13 Apr 2016 11:32:21 +0000
<Skuggen> Both newest, then. I'd have to look closer at amarok and see how it uses MySQL
<clivejo> the component that uses mysql in kontact is called akonadi
<clivejo> http://packages.ubuntu.com/xenial/akonadi-backend-mysql
<clivejo> again rebuilt -- Robie Basak <robie.basak@ubuntu.com>  Tue, 12 Apr 2016 14:33:29 +0000
<Skuggen> Akonadi was updated for 5.7 in 4:15.12.1-0ubuntu4, yes
<clivejo> akonadi is a complicated beast
<clivejo> but its the heart of the Kubuntu PIM
<clivejo> my whole groupware is dead in the water
<Skuggen> The main differences from the 5.6 packages to 5.7 is that 5.7 is more strict by default and that it's stricter on letting you have a root account without a password
<Skuggen> Is there anything in /var/log/mysql/error.log?
<Skuggen> Would probably need to look closer at how akonadi is using MySQL
<clivejo> nothing I think is relevant
<clivejo> I think these apps startup their own instances
<Skuggen> Ah, I saw a similar bug report for amarok that was because of config problems
<Skuggen> Can you run mysqld --verbose --help 2>&1 > /dev/null  and see if it says anything?
<clivejo> few warnings, few notes and an error - [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
<clivejo> and mysqld: Can't change dir to '/var/lib/mysql/' (Errcode: 13 - Permission denied)
<Skuggen> Ah, the permission denied is just because you didn't sudo, but that's fine.
<Skuggen> mysql_upgrade should have been run when 5.7 was installed/upgraded, though.
<Skuggen> But if it hasn't then the server won't work properly, so try running sudo mysql_upgrade -uroot -p
<clivejo> Error: Failed while fetching Server version! Could be due to unauthorized access.
<clivejo> FATAL ERROR: Upgrade failed
<Skuggen> What does mysql_upgrade --version say?
<clivejo> same message
<Skuggen> Not really sure what would cause that error. my_print_defaults mysqld | grep port?
<Skuggen> And mysql --version and mysqld --version
<clivejo> sorry, I been purging mysql packages
<clivejo> when I install mysql-server Im getting errors
<clivejo> mysql_upgrade: [ERROR] 1146: Table 'mysql.innodb_table_stats' doesn't exist
<clivejo> Setting up mysql-server-5.7 (5.7.11-0ubuntu6) ...
<clivejo> http://paste.ubuntu.com/15873389/
<Skuggen> I think I've seen that before in a bug report. Hang on
 * clivejo hangs
<Skuggen> There was a bug in mysql_upgrade if the server was started without innodb, but it was fixed before the 5.7 GA
<Skuggen> https://bugs.mysql.com/bug.php?id=70152
<clivejo> so its my data dir?
<Skuggen> Yeah. You can test if everything works as it should by backing it up to somewhere else and trying to reinstall
<clivejo> nothing in the main dir
<clivejo> Ill just rm it
<Skuggen> There's nothing, or just nothing you need to keep? Maybe akonadi stores it somewhere else
<clivejo> so basically the 5.7 failed?
<clivejo> akonadi starts an instance and stores it in my home directory
<clivejo> ok installed that time :)
<clivejo> I need to reboot
<Skuggen> Ah, of course. The mysql installation probably doesn't handle data in non-standard locations too well
<Skuggen> So if /var/lib/mysql was there, but empty, it would assume the database exists and not create it, then run mysql_upgrade.
<Skuggen> That at least is a bug we can probably fix
<clivejo> nope, apps still not working
<Skuggen> Does mysql_upgrade still give the same error as before?
<clivejo> no, mysql-server installed without error
<Skuggen> If you run it manually as well?
<Skuggen> When it's run as part of the 5.7 install it will  upgrade the database in /var/lib/mysql
<clivejo> well --version is now giving an output - mysql_upgrade  Ver 2.0 Distrib 5.7.11, for Linux (x86_64)
<Skuggen> My guess is the apps aren't working because the database is stored somewhere else, and hasn't been upgraded
<Skuggen> Maybe akonadi specifies a config to use instead of changing the normal ones
<clivejo> yes, the flat files are stored in my home directory
<clivejo> --datadir=~/.local/share/akonadi/db_data/
<Skuggen> Can you do mysqld --verbose --help | grep datadir?
<clivejo> /var/lib/mysql/
<Skuggen> Check your process list for mysqld and see if it specifies anything in particular on the command line?
<clivejo> akonadi starts its own instance though
<clivejo> in my home directory
<clivejo> there is an error log here
<clivejo> stderr: "mysqld: [ERROR] Could not open required defaults file: /home/~/.local/share/akonadi/mysql.conf\nmysqld: [ERROR] Fatal error in defaults handling. Program aborted!\n"
<Skuggen> Is that file there?
<clivejo> mysql.conf is
<clivejo> what does \nmysqld mean?
<Skuggen> Looking for a mysqld section in the file, I guess
<clivejo> \n means newline?
<Skuggen> What's in the mysql.conf file?
<clivejo> LOL settings
<clivejo> http://paste.ubuntu.com/15873829/
<Skuggen> Looks like it's actually looking for the full string including \nmysqld, though
<Skuggen> Oh wait, maybe not. Hang on, let me try just using that
<flexiondotorg> infinity, slangasek cyphermox Ubiquity is not behaving as it should in the April 16th daily image.
<flexiondotorg> It is boot directly to desktop.
<Skuggen> clivejo: Config file seems to work ok to me. So does indeed look like it's trying to use the full string, for some reason
<Skuggen> clivejo: See if you can find out where the path to that config file is set in akonadi?
<clivejo> from what I understand it starts up agents when I log in
<clivejo> these agents connect to my mail resources and grab my new email which are cached in akonadi
<clivejo> its basically black magic to me
<clivejo> I just dont understand how an upgrade of this kind can be made so close to release date
<clivejo> it worked fine in 5.6
<clivejo> The only thing I have done is to upgrade my system
<apw> clivejo, rememeber whatever is in the release has to be supported for 5 years, so the latest upstream version is desirable
<Skuggen> clivejo: So it works if you remove 5.7 and install 5.6?
<flexiondotorg> infinity, slangasek cyphermox This is still an issue too - https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1552539
<ubot5`> Launchpad bug 1552539 in ubiquity (Ubuntu) "Ubiquity Erase Disk and Install Fails to create Swap Space" [Critical,Triaged]
<clivejo> Skuggen: I dont know, Robie changed the dependancies in the latest package - Depend on mysql-{server,client}-core-5.7, not 5.6, for the switch to
<clivejo>     MySQL 5.7.
<rbasak> o/
<clivejo> I guess I could force install 5.6 and see if it works :/
<rbasak> Skuggen: I wonder if it's because of the binaries missing from -core?
<rbasak> clivejo: do you have the mysql-server-5.7 package installed also? Or just mysql-server-core-5.7?
<Skuggen> rbasak: But the error message he's getting seems to just be about not finding the config file. Unless that's a distraction
<Skuggen> If so, then it might just be that you need to upgrade the database to 5.7
<rbasak> Skuggen: ah, then that sounds more likely. I was just thinking of reasons akonadi might have problems with no regard to the specific symptoms.
<ogra_> note that akonadi got a new upstream version this morning ...
<ogra_> (EU morning :) )
<Skuggen> 5.6 core package didn't have those plugin binaries either
<clivejo> ogra_: it did and it didnt
<ogra_> ?
<ogra_> https://launchpad.net/ubuntu/+source/akonadi/4:15.12.3-0ubuntu1
<ogra_> regard the diff
<rbasak> Does akonadi need to be running mysql_upgrade in its postinst?
<ogra_> -         mysql-client-core-5.7 | virtual-mysql-client-core,
<ogra_> -         mysql-server-core-5.7 | virtual-mysql-server-core,
<ogra_> +         mysql-client-core-5.6 | virtual-mysql-client-core,
<ogra_> +         mysql-server-core-5.6 | virtual-mysql-server-core,
<clivejo> its a package thats been ready to go for a long time but we (Kubuntu) are bit short staffed at the moment
<ogra_> (not sure that was desired)
<ogra_> there is aalso a patch to the mysql-global.conf defaults
<clivejo> its been working all along on 5.6
<clivejo> its only since this forced upgrade to 5.7 that its fallen on its face
<rbasak> There isn't that much different in 5.7 AIUI. I'm sure we can figure this out.
<ogra_> the mysql-global.conf change looks like it is needed for 5.7
<clivejo> rbasak: are you robie in the changelog?
<rbasak> clivejo: yes.
<clivejo> ah o/
<ogra_> http://launchpadlibrarian.net/253864624/akonadi_4%3A15.12.1-0ubuntu4_4%3A15.12.3-0ubuntu1.diff.gz looks very much like rbasak and sgclark clashed there
<ogra_> (see the top most changelog entry)
<Skuggen> mysql_upgrade --socket=/tmp/akonadi_usersomething I think
<ogra_> which might explain the breakage
<Skuggen> ogra_: I don't actually think that will break, since virtual-mysql-client/server-core will be there
<Skuggen> clivejo: Assuming it isn't actually failing to find the config file (which wouldn't be different between 5.6 and 5.7), then upgrading the database should fix it, but that's a one-way street, so should probably back it up first
<ogra_> Skuggen, rbasak added the 5.7 dep ... people that had his package have upgraded to 5.7 ... then sgclark added a fix for the mysql default config but downgraded the dep ... so the fix wont land since 5.6 is gone
<Skuggen> Ah
<ogra_> at least thats how i read that diff above
<rbasak> Both 5.6 and 5.7 provide virtual-mysql-server though
<ogra_> sure
<ogra_> but there are 5.7 specific config changes in the second upload
<clivejo> Skuggen: I dont know what to do, its just strange close to release and at least two apps in Kubuntu are dead :(
<clivejo> scary
<ogra_> clivejo, it will be fixed one way or the other ... and it is definitely better to have a bug for the first few days around the release than having to maintain an unsupported mysql version for 5 years :)
<ogra_> that is what you get for not waiting to the .1 release ;)
<ogra_> (the privilege of reporting bugs :) )
<clivejo> I dont get why we been bumped though
<clivejo> surely the decision to move from 5.6 to 5.7 is with us?
<ogra_> again, because 5.6 wont be supported for 5 years by upstream
<clivejo> ie Debian/Kubuntu KDE teams
<Skuggen> clivejo: Can you first take a backup of the .local/share/akonadi/db_data directory?
<rbasak> We share the archive.
<rbasak> MySQL isn't exclusive to KDE.
<clivejo> *holds hands up*  Im new to all this, so please go easy on me!
<Skuggen> Then run mysql_upgrade -uroot -p --socket=/tmp/akonadi-youruser-something/mysql.socket
<rbasak> clivejo: np, just explaining. I appreciate your patience.
<clivejo> we sync with Debian - http://anonscm.debian.org/cgit/pkg-kde/applications/akonadi.git/
<Skuggen> Not sure about the -uroot -p, since I'm not sure what credentials akonadi sets up :)
<Skuggen> And the youruser-something is randomly generated
<rbasak> clivejo: if I thought it would be a major deal, I would have checked with your team first. I could yet turn out to be wrong, but I suspect it'll be a one line (or similar) fix.
<rbasak> Skuggen: thank you for being on top of this. Shall I leave you to drive? I'm around, let me know if I can help.
<Skuggen> Sure
<clivejo> I dont really have the time to look into it properly
<ogra_> someone really needs to clearify with sgclark if the rollback of the dependency was wanted though .. the new upstream definitely also modifies the SQL tables
<rbasak> I'm also preparing the update to 5.7.12 though the release team hasn't acked that yet.
<clivejo> I would like to know if this is a problem for new installs, or is it just upgrades
<ogra_> (according with claiming a config change for 5.7 while the dep was downgraded to 5.6)
<rbasak> ogra_: given that the upload chopped off my changelog message, I think it's safe to assume that the reversion was inadvertent.
<ogra_> right
 * ogra_ would just re-upload with the dependency fixed again ... 
<clivejo> I cant actually see that package of sgclark's yet
<ogra_> https://launchpad.net/ubuntu/+source/akonadi ... was released to universe 5h ago
<clivejo> I know
<rbasak> Oh
<clivejo> but it hasnt made it to my system yet
<Skuggen> clivejo: The config file you pasted has the change
<rbasak> p/sb end
<rbasak> clivejo: what version of akonadi do you have installed?
<clivejo> nothing at the minute
<rbasak> What version did you have installed?
<clivejo> I purged mysql and akonadi
<rbasak> /var/log/apt/history.log should be able to tell you
<clivejo> I had the rbasak modified
<Skuggen> But you put the contents of your mysql.conf file at http://paste.ubuntu.com/15873829/
<clivejo> previous to that I had the one sgclark uploaded from a staging/testing PPA
<Skuggen> Ah
<Skuggen> # Deprecated in MySQL >= 5.6.3, removed in 5.7 (works in MariaDB)
<rbasak> Yeah
<rbasak> That's what I'm thinking
<clivejo> ok so now it wants to install 5.6
<ogra_> Skuggen, that was what i was referring to 30min ago ;)
<rbasak> clivejo: I suggest you force it onto 5.7.
<Skuggen> clivejo: If you install 5.7 first, then akonadi
<rbasak> clivejo: ask apt-get for mysql-server-core-5.7 specifically, along with akonadi
<ogra_> Skuggen, it also has a dbupdate.xml file that it likely processes to convert the tables
<clivejo> I want to get to a point where its working
<clivejo> and see what breaks it
<clivejo> this only started about a wek ago
<Skuggen> As it is now I don't think upgrading akonadi from 5.6 to 5.7 will work, because you need to run mysql_upgrade
<Skuggen> But would be very nice to test if it works with a fresh install with 5.7
<ogra_> doesnt it do that from a postinst ?
<Skuggen> ogra_: Akonadi stores the database somewhere else
<Skuggen> And uses its own config file
<Skuggen> So the mysql-5.7 postinst will upgrade whatever database is in /var/lib/mysql, but that won't help akonadi
<ogra_> no, i mean the dbupdate.xml file and the mysql-global.conf change from akinadi itself
<clivejo> amarok is having problems too
<clivejo> brb
<ogra_> i would expect some postinst to process them
<PaulW2U> flexiondotorg: I'm also seeing that the install option boots to a desktop. Xubuntu too although a little more graceful than MATE :)
<clivejo> ok its working now
<Skuggen> clivejo: Can you also try a completely fresh install with 5.7?
<clivejo> mysql  Ver 14.14 Distrib 5.6.28, for debian-linux-gnu (x86_64) using  EditLine wrapper
<clivejo> so purge all mysql packages?
<Skuggen> And akonadi
<clivejo> but akonadi will want to use 5.6
<Skuggen> Purge mysql and akonadi, then install mysql 5.7, then akonadi
<Skuggen> Akonadi wants 5.6 or virtual, and they both provide virtual
<clivejo> I have to go soon
<clivejo> It'll have to wait until later
<Skuggen> amarok uses removed config values
<clivejo> ok purged mysql, installed 5.7 and then installed akonadi
<clivejo> it seems to be working
<clivejo> Skuggen: ping if you are still here
<Skuggen> clivejo: I'm actually surprised, because looking at the source it seems akonadi uses outdated mysql_install_db options :D
<clivejo> it seems to have picked up my old database
<Skuggen> Also, amarok has an option in the config file it generates that just needs renaming, and it seemed to work
<clivejo> everything is there
<Skuggen> Ah, right. Yeah, this would only affect new databases.
<clivejo> Skuggen: are you on the release team?
<Skuggen> I work for MySQL :)
<clivejo> ah
<clivejo> an expert :)
<Skuggen> Only worked here for about a year, but I'm working with rbasak on the Ubuntu packaging
<clivejo> is rbasakabout?
<clivejo> rbasak: ping
<Skuggen> clivejo: For amarok, I think there's a .local/share/amarok/my.cnf or something like that, with a myisam-recover=FORCE, that should be myisam-recover-options=FORCE
<clivejo> Skuggen: would you might coming to #kubuntu-devel?
<Skuggen> On freenode?
<clivejo> yes
<infinity> sgclark: Your changelog format is broken (missing a newline between entries)
<infinity> sgclark: Also, the "debsign broken" thing can be solved by asking specifically for the right key.  "debsign -k 'Lappy2.0'" or specify the key like so:
<infinity> (base)adconrad@nosferatu:~$ cat .devscripts
<infinity> DEBSIGN_KEYID=B1CDE58F
<clivejo> infinity: are you on the release team?
<infinity> clivejo: Last I checked.
<clivejo> :)
<clivejo> we have a Package Manager in Kubuntu called Muon which is currently broken to install
<infinity> sgclark: You also got Robie's entries in the wrong spot (which might account for the newline issue)
<clivejo> kinda need some help with it
<infinity> clivejo: Gimme a sec.  One thing at a time.
<sgclark> infinity: ok thanks, will fix, sorry.
<infinity> sgclark: If I fix it up, can you just commit the diff to pkg-kde (I don't think I have access).
<sgclark> infinity: suree I can do that. We are moving back to launchpad next release.
<infinity> sgclark: wget http://lucifer.0c3.net/~adconrad/akonadi.patch && patch -p1 < akonadi.patch && rm akonadi.patch && git commit -a -m 'Fix changelog' && git tag ubuntu/4%15.12.3-0ubuntu4 && git push -a
<infinity> sgclark: Uploading that now.
<infinity> sgclark: (And yes, the diff looks awful, but it looks sane against -0ubuntu1 :P)
<sgclark> infinity: you are awesome, thank you so much.
<infinity> sgclark: This is how it comes out as a diff against -0ubuntu1, much prettier: http://launchpadlibrarian.net/254141356/akonadi_4%3A15.12.3-0ubuntu1_4%3A15.12.3-0ubuntu4.diff.gz
<sgclark> infinity: :)
<clivejo> how did it get from ubuntu1 to ubuntu4 ?
<infinity> clivejo: Magic.
<clivejo> fairies then
<infinity> clivejo: (I would have called it ubuntu2, but sgclark had already tagged 2 and 3 in git, and deleting tags is generally bad)
<clivejo> ah, not I see
<clivejo> now
<infinity> sgclark: You didn't apply my patch. :P
<infinity> sgclark: The changelog in git is still broken, just with an extra entry now.
<infinity> Well, three extra entries.
<infinity> Aww, dang, I don't have write access.  Didn't think I would.
<sgclark> hmm but I did. let me look, I am in too many places.
<infinity> Not the patch I linked from lucifer.
<infinity> clivejo: Okay.  muon.  You have half an hour before I run off to an airport.  What's up.
<infinity> clivejo: Laney ACKed your FFe two days ago.
<doko> slangasek, pitti: eperl demoted
<cyphermox> flexiondotorg: both known issues I want to fix on Monday
<cyphermox> btw, I found this very funny bug: https://bugs.launchpad.net/ubuntu/+source/gnome-bluetooth/+bug/1571262
<ubot5`> Launchpad bug 1571262 in gnome-bluetooth (Ubuntu) "my computer's name is not "Bastien's computer"" [Undecided,New]
<flexiondotorg> cyphermox, Yeah. I was sent the bugs by Xubuntu. I've +1 them.
<cyphermox> cool
<flexiondotorg> cyphermox, Hah!
<cyphermox> I'm not sticking around to hack at the bugs tonight though, I have a school project to work on
<flexiondotorg> Sure.
<flexiondotorg> Time for sleeping here.
<flexiondotorg> Night.
<cyphermox> nght
<infinity> doko: Ahh, I was testing a numpy merge in my PPA, you beat me to the archive upload. :)
<infinity> clivejo: This muon upload is a bit concerning to me.
<clivejo> infinity: how so?
<infinity> clivejo: You drop a bunch of packages (I'm guessing everything is in muon now?), but I see no Breaks/Replaces/Conflicts/etc.
<infinity> clivejo: How is this meant to upgrade for people who have muon-notifier, muon-common, etc installed?
<clivejo> they have moved to a brand new package plasma-discover
<infinity> clivejo: And libmuon?  And muon-common?
<infinity> That's all in plasma-discover too?
<clivejo> muon-common is now plasma-discover-common I believe
<clivejo> packaged here - http://packages.ubuntu.com/xenial/plasma-discover
<infinity> Kay, seeing the libmuon->libdiscover, *-common and *-discover relationships.
<infinity> notifier and updates don't seem to be mentioned anywhere.
<clivejo> libmuon doesnt exist any more
<infinity> Ahh plasma-discover-updater is updater.
<clivejo> plasma-discover-updater
<clivejo> all part of plasma now
<infinity> It's both.
<infinity> Kay.
<clivejo> basically it was all moved bar the Package Manager
<infinity> The one thing I'd ask is that all those relationships that are currently Breaks/Replaces turn into Conflicts/Replaces, which apt takes as a hint to completely remove the old one for the new one.
<clivejo> we werent going to package it, but a lot of users have said they still use it
<infinity> Each of the dropped packages has a B/R in a plasma equiv.
<clivejo> infinity: as you probably can tell Im very new to this
<infinity> libmuon -> libdiscovercommon, plasma-discover-updater -> muon-notifier/muon-updater, plasma-discover -> muon-discover
<infinity> I tihnk I missed one.
<clivejo> the kubuntu team are under pressure and I took this on to try and learn
<infinity> Oh, and plasma-discover-common -> muon-common
<clivejo> trying to install muon currently in Xenial leads to an apt failure on libmuon
<infinity> I guess I can upload to fix that all up.
<infinity> I don't board for 8 minutes. :P
<clivejo> have you a laptop?
<infinity> Yeah. :)
<infinity> Oh.
<infinity> There are transitional packages in plasma-discover.  I didn't get far enough down the control file.
<infinity> Accepted.  Please test upgrades from wily with all the muon stuff installed.
<clivejo> thanks
<clivejo> any feedback?
<clivejo> does/dont's ?
<infinity> Other than whining about upgrade paths, not really.  So, do test that it all actually works.
<infinity> A full review is a bit hard, given the massive diff. :P
<clivejo> I know it works in Xenial
<infinity> Aaaand, boarding time.
<clivejo> been using it myself for about 3 weeks
<clivejo> have a good flight!
<infinity> Back in 10 hours from the other side of the world.
<clivejo> and thankyou!
<clivejo> LOL im going to bed!
#ubuntu-release 2016-04-17
<darkxst> infinity, bdmurray slangasek we really need to the casper fix in bug 1561302, before our final images spin, can one of you look at that this week?
<ubot5`> bug 1561302 in casper (Ubuntu) "gdm won't allow passwordless login" [Critical,Triaged] https://launchpad.net/bugs/1561302
<infinity> darkxst: Have you tested that does reasonable and sane thing?
<infinity> s
<darkxst> infinity, i tested it, by dumping it in place on the live images
<darkxst> infinity, the flag does not get set because casper adds the user before accountsService starts
<infinity> darkxst: I assume this works due to some PAM module kicking in when you run passwd -d?
<darkxst> infinity, not sure its a PAM module, but accountsservice picks up the passwd -d call
<infinity> I wonder if it has an inotify watch on /etc/passwd or something equally disgusting. :P
<infinity> Anyhow, looking.
<darkxst> infinity, likely, everything seems disgusting at this point in the hacks
<darkxst> including the pam code that detects if a user has no passwd
<infinity> darkxst: Mind if I move it to the "if [ -d /root/etc/gdm3 ]" block, so you're the only one that suffers if it proves slightly wonky? :P
<darkxst> infinity, sure if you want, its  a generic bug though, doesnt only affect us (maybe others just havent seen side-effects yet)
<infinity> darkxst: Well, it's a subtle change (changing from a blank password to no password), and I'm not positive what the fallout there might be in other bits.
<darkxst> infinity, ok
<infinity> wq
<infinity> darkxst: http://paste.ubuntu.com/15891954/ <-- Okay having your name on this version?
<darkxst> infinity, ack
<infinity> darkxst: TBF, accountservice is gloriously buggy if it needs to be running to process passwd *changes* to set flags.
<infinity> darkxst: But what could be happening is that it only sets "it's null, yo" on accounts where the password is actually ::
<infinity> darkxst: And we set the password to the crypt() equivalent of "blank".
<infinity> darkxst: Which is quite different.
<infinity> darkxst: Might be a simple patch in accountservice somewhere to mangle its startup parser to look for the crypted version of blank as well.
<infinity> darkxst: Anyhow, casper hack is in for now.
<darkxst> infinity, k thanks, I am glouriously buggy also retreating to bed in attempt to sleep off flu
<infinity> darkxst: Ick.  No good.  Get better!
<infinity> sgclark: http://launchpadlibrarian.net/254213242/kcachegrind_4%3A15.12.3-0ubuntu1_4%3A15.12.3-0ubuntu2.diff.gz
<infinity> sgclark: Another diff for you to pull into git.
<sgclark> infinity: yeah just heard, recently woke up, trying to injest some coffee
<sgclark> thats what happens when folks ignore VCS entries...
<infinity> sgclark: Heh.  Well, there it is all bundled up for you, I already uploaded. :P
<sgclark> thanks
<infinity> sgclark: To be fair, ignoring VCS entries is entirely the right thing for us to do when we can't commit to the VCS in question.
<sgclark> fair enough. but we need to be informed
 * infinity mutters something about "always debdiff before you upload".
<sgclark> anyway, we are moving back to launchpad, next release
 * sgclark mutters huh?
<sgclark> infinity: pushed. thanks bunches.
<bluesabre> Please approve the above xubuntu-default-settings.  It sets our default Libreoffice theme, which is very much a part of our desktop experience. :)
 * stgraber looks
<stgraber> bluesabre: translation update intentional?
<stgraber> it's not listed in the changelog
<bluesabre> ah
<bluesabre> meant to list that as well
<stgraber> ok, that's fine then
<stgraber> just wanted to make sure that those aren't broken/bad translations you had around on your machine :)
<bluesabre> I've only uploaded bad translation once, and swore to never do it again :)
<bluesabre> +s
<stgraber> :)
<bluesabre> thanks stgraber
<flocculant> stgraber: I'll add some thanks too :)
<doko> any idea why ktp-kded-integration-module doesn't migrate?
<infinity> trying: ktp-kded-integration-module
<infinity> skipped: ktp-kded-integration-module (3 <- 3)
<infinity>     got: 139+0: a-41:a-15:a-16:i-15:p-19:p-18:s-15
<infinity>     * amd64: kde-telepathy-integration-module-dbg
<infinity> Looks like the dbg just needs to be removed.  I'll do that.
<doko> ok
<doko> this one might be good to fix, used as a b-d for a bunch of other packages: https://launchpadlibrarian.net/253777080/buildlog_ubuntu-xenial-amd64.pkg-info-el_0.6-1_BUILDING.txt.gz
<infinity> doko: Any idea what's up with the pip vs virtualenv autopkgtests?
<infinity> Or does that need barry?
<doko> infinity, no, however there's a rc issue for unstable today
<infinity> Oh, statsmodels and pandas are in a build-dep loop.  Can probably bootstrap that on s390x.  After I've beered with stgraber.
<doko> pandas just migrated
<infinity> Yeah, but without s390x.
<infinity> Just aiming for more coverage.
<infinity> There's also the libsemanage that no one ever bothered to see through.
<infinity> Probably too late to care now.
<doko> infinity, according to mdeslaur they don't want to look at updating the policy packages
<doko> so what we need to do is to build libsemange in -proposed after release to get the ruby2.3 module
<infinity> doko: No need to do it after release.  I can do it in a PPA, delete libsemanage from proposed, copy PPA version in, let it migrate, then copy the old one back.
<doko> works for me
<infinity> doko: I'll put that on the post-beer TODO.
<flexiondotorg> infinity, You online? I have an release critical issue with a potential fix. I need someone to sanity check the fix.
<mparillo> Hi, I just downloaded the Kubuntu ISO,  burned it, and it did not start plasma. However, this ISO did boot. I can get a login prompt and type kubuntu <enter> <enter> and sudo poweroff just fine. It is just that plasma did not load. Is there some larger issue that is already known?
<infinity> mparillo: No idea, perhaps ask yofel?
<infinity> flexiondotorg: Point me at the issue/fix?
<mparillo> infinity: TY. I already asked in kubuntu-devel. I guess he is not on. I will try again with tomorrow's image.
<stgraber> infinity: qatracker stuff all done
<infinity> stgraber: Guess I should uncron.
 * infinity does that.
<stgraber> infinity: yeah, then update debian-cd and trigger a first spin so folks can do some smoketesting on "rc" images
<infinity> stgraber: yep.
<flexiondotorg> infinity, https://bugs.launchpad.net/ubuntu-mate/+bug/1571242
<ubot5`> Launchpad bug 1571242 in ubuntu-mate "Ubutnu MATE 16.04 Grub Install Fails in UEFI Mode" [Undecided,New]
<flexiondotorg> The work around is to uninstall grub-pc from the live session before starting the installer.
<infinity> flexiondotorg: That seems incorrect.  It's in all the live tasks.  If it's only failing for you, something weird is going on.
<flexiondotorg> I've checked the other seeds, all flavours unclusing Ubuntu proper, and none have grub-pc in ship-live but Ubuntu MATE does.
<flexiondotorg> *including
<infinity> (base)adconrad@nosferatu:~$ apt-cache show grub-pc | grep ^Task
<infinity> Task: ubuntu-live, kubuntu-live, edubuntu-live, xubuntu-live, mythbuntu-live, lubuntu-live, ubuntustudio-live, ubuntustudio-dvd-live, ubuntu-gnome-live, ubuntukylin-live, ubuntu-mate-live
<flexiondotorg> infinity, What puts grub-pc in the live task?
<flexiondotorg> Because in Ubuntu MATE live seed it is expressly included.
<flexiondotorg> But not in the others.
<infinity> grub2?
<infinity> And a recommends of ubiquity.
<infinity> So, you don't follow recommends, right?
<infinity> Having it in your live task would be correct to fix that.
<flexiondotorg> Correct, but nither does Lubuntu.
<infinity> But not in ship-live.
<infinity> lubuntu might be broken differently from you. :P
<flexiondotorg> infinity, If I remember correctly it was added to live by cjwatson sometime back to fix a similar EFI issue.
<flexiondotorg> OK, so removing from ship-live is OK?
<flexiondotorg> But not actually going to fix anything?
<infinity> Oh, no.  lubuntu/live does follow recommends.
<flexiondotorg> OK, but as far as I can tell Ubuntu MATE should too?
<infinity> Should what?
<flexiondotorg> Because I don't have anything in the seeds to say no-recommends for live.
<infinity> Yes you do.
<infinity>  * Feature: no-follow-recommends
<flexiondotorg> Shit
<flexiondotorg> OK. Sec...
<flexiondotorg> OK, that is the issue then.
<infinity> Nah.
<infinity> Shouldn't be.
<infinity> That's why you include it explicitly, though.
<flexiondotorg> I should follow recommends in live.
<infinity> But you can drop it from ship-live.
<flexiondotorg> OK.
<infinity> If dropping it from ship-live magically fixes the bug, yay.  But if not, we can investigate WTF is going wrong for you.
<flexiondotorg> So the issue, if I'm reading it right is EFI install fails on EFI machine when the HD is zeroed.
<infinity> Yeah.  Easy enough to test.
<flexiondotorg> But, if the HD has an existing legacy install on it, the install works.
<flexiondotorg> I don't have a suitable machine.
<flexiondotorg> But I know a man who does.
<flexiondotorg> I'll get more details from them.
<flexiondotorg> But, by comparision Ubuntu and Lubuntu are said to work under those condidtions.
<flexiondotorg> And I do need to not follow recommends in the live seed, other I get most of Unity along for the ride.
<zequence> Could someone please help us get a couple of changes in for ubiquity and ubiquity-slideshow-ubuntu. They are outdated for us, completely, and both merge requests were from before Final Freeze. Unfortunately we could be done sooner with the changes, since they were the last in a series of others.
<zequence> Bug
<zequence> 1569005
<zequence> Ahh, Bug 1569005
<ubot5`> bug 1569005 in ubiquity-slideshow-ubuntu (Ubuntu) "New ubiquity slideshow for Ubuntu Studio [UI Freeze Exception]" [Undecided,New] https://launchpad.net/bugs/1569005
<zequence> Bug 1568981
<ubot5`> bug 1568981 in ubiquity (Ubuntu) "new Ubuntu Studio wallpaper for ubiquity installer [UI FREEZE EXCEPTION]" [Undecided,New] https://launchpad.net/bugs/1568981
<flexiondotorg> infinity, OK, here is a to the point description of the problem.
<flexiondotorg> infinity, "So, installing ubuntu MATE in UEFI mode kicks off an error at the end of the install because the grub-efi-amd64-signed package is not installed on the install image. And to install that grub-pc must be removed. The problem seems to only be appearing on ubuntu mate. Lubuntu and Ubuntu are fine."
<infinity> flexiondotorg: Okay, well your manifest for installed packages matches ubuntu.
<infinity> flexiondotorg: manifest-remove doesn't match, which is curious in itself.
<flexiondotorg> infinity, Is this my weird no-recommends making a mess of things?
<infinity> Ah-ha.
<infinity> Yes.
<stgraber> queuebot and I will be offline for a few minutes, relocating to a new server
<infinity> flexiondotorg: You're not pulling bootloaders recommended by linux-image-$(uname -r) ... We can hardcode those somewhere probably.
<infinity> Maybe.
<infinity> Kinda gross, though.
 * infinity ponders.
<flexiondotorg> infinity, Is this something I should add to the seed or something the build system can do?
<infinity> flexiondotorg: In this case, it's not the seed, but the APT_OPTIONS="--yes --no-install-recommends" in livecd-rootfs, I think.
<flexiondotorg> OK
<infinity> Though, lubuntu should have this issue.
 * infinity looks.
<infinity> Yeah, lubuntu has the same manifest-remove issue.
<flexiondotorg> Why do they not has the same bug?
<infinity> flexiondotorg: I think I might need a full syslog from that failed install to unravel what's actually happening.  English descriptions of what people *think* is happening aren't ideal.
<flexiondotorg> What logs would you like?
<flexiondotorg> Just syslog or anything else?
<infinity> flexiondotorg: syslog should do.
<flexiondotorg> Just for Ubuntu MATE?
<infinity> For MATE and lubuntu.  I see no reason they should differ.
<flexiondotorg> infinity, For UBuntu MATE, you want the syslog upto the point the error occurs right?
<flexiondotorg> You do not want to have grub-pc remove before hand, right?
<infinity> flexiondotorg: The whole /var/log/syslog from the system, copied after the failure.
<flexiondotorg> OK
<flexiondotorg> infinity, Instructions dispatched to the man with the computer.
<flexiondotorg> I'll got and try to fix a laptop and see if I can prepare some logs too.
<flexiondotorg> I have a busted EFI laptop.
<flexiondotorg> infinity, This is the Recommends in linux-image- you're referring to right?
<flexiondotorg> Recommends: grub-pc | grub-efi-amd64 | grub-efi-ia32 | grub | lilo
<flexiondotorg> infinity, I added APT_OPTIONS="--yes --no-install-recommends" in livecd-rootfs to also prevent pulling in Recommends.
<flexiondotorg> Is APT_OPTIONS needed?
<zequence> infinity: Any chance I could bother you with the ubiquity merges?
<zequence> Just a change of artwork, really. But, it's from 14.04, so..
<zequence> I mean, the current artwork is from 14.04
<zequence> Would be nice to not have to release our ISO with that (though I know we are very, very late, and I have to ask people for favors)
 * zequence hates asking people for favors, and can't spell today
<clivejo> infinity: ping
<doko> clivejo, don't ping, just write
<clivejo> Have another problem, with plasma-discover
<clivejo> basically, it was fixed and in our staging PPA - https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/staging-plasma/
<clivejo> plasma-discover (5.5.5-0ubuntu1~ubuntu16.04~ppa2)
<clivejo> yofel cherrypicked two upstream patches which fix a problem with the updater
<clivejo> but somewhere along the line, those patches didnt make it into the archive
<clivejo> The patches in question are 0001-Fix-refresh-on-the-notifier-plasmoid-for-QApt-backen.patch and 0002-Improve-how-we-react-to-failed-parses.patch
<clivejo> The one publsihed to the archive seems to be misisng them - https://launchpad.net/ubuntu/+source/plasma-discover/5.5.5-0ubuntu1
<clivejo> published on the 14th
<infinity> flexiondotorg: I'd rather not take shots in the dark, let's wait until we have a syslog to stare at.
<infinity> cyphermox: You around to maybe help zequence with his merges?
<infinity> clivejo: So get someone to upload a fixed -0ubuntu2 with the midding patches?
<infinity> s/midding/missing/
<clivejo> infinity: If I knew someone with uploading permission I would love to
<clivejo> sgclark is currently trying to get some rest
<infinity> clivejo: Ahh.  I'll try to look in a sec.
<clivejo> we are all a bit stressed, Im new to this all so I cant be must help on that front.  But I know that version in the PPA works and has worked and been tested
<clivejo> I cant explain or even understand how it was ommited, but the patches arent in the main archive for some reason
<flexiondotorg> infinity, Understood. Test are being conducted.
<infinity> clivejo: Uploaded in yofel's name.
<clivejo> infinity: thanks, do you know how or why the patches got dropped?
<infinity> clivejo: No idea, I didn't do the previous upload.
<clivejo> do you know who uploaded?
<clivejo> LP says it was Phil himself
<doko> clivejo, does the package come from the kubuntu staging ppa's?
<infinity> clivejo: Phil's name in the changelog, Scarlet's sig.
<doko> they tend to override changes which go directly into the ubuntu archive
<clivejo> we follow a process, uploaded to staging, then landing, then to archive usually
<infinity> clivejo: anyhow, this should fix it: https://launchpad.net/ubuntu/+source/plasma-discover/5.5.5-0ubuntu2
<clivejo> but its gone from landing
<clivejo> infinity: thanks
<flexiondotorg> infinity, syslogs attached - https://bugs.launchpad.net/ubuntu-mate/+bug/1571242
<ubot5`> Launchpad bug 1571242 in ubuntu-mate "Ubutnu MATE 16.04 Grub Install Fails in UEFI Mode" [Undecided,New]
<infinity> flexiondotorg: Okay, you can see that both of them remove grub-pc before trying to install grub-efi-amd64-signed, so that's a red herring.
<flexiondotorg> Yep.
<flexiondotorg> Just looking now.
<infinity> flexiondotorg: Figuring out why the grub-efi-amd64-signed install doesn't want to shouldn't be too tough.
<flexiondotorg> infinity, I'm looking too.
<flexiondotorg> Perhaps  grub-efi-amd64 should be listed in ship-live?
<flexiondotorg> I mean, grub-efi-amd64-bin
<infinity> It's there.
<infinity> See http://cdimage.ubuntu.com/ubuntu-mate/daily-live/20160417/xenial-desktop-amd64.list
<infinity> Oh.
<infinity> That could have just been a version mismatch.
<infinity> Can he reproduce with a newer image? :P
<infinity> Betting grub-signed and grub were just out of sync on that image build.
<infinity> And we're chasing shadows.
<flexiondotorg> Ha!
<flexiondotorg> I'll check.
<flexiondotorg> However, the original report is from the 15th and the tests were done this morning by Mike.
<flexiondotorg> So maybe not that.
<flexiondotorg> infinity, Running tests again for Ubuntu MATE using the current daily.
<infinity> flexiondotorg: Can confirm that grub in /pool/ and livefs were out of sync for 20160416, they look fine for 20160417
<infinity> flexiondotorg: So that's probably what it was.
<flexiondotorg> infinity, I really hope so :-)
<flocculant> infinity: not sure what's fixed what here but I did a rebuild for another reason here and bug 1570901 not apparent now
<ubot5`> bug 1570901 in ubiquity (Ubuntu) "Cd menu not booting to ubiquity try/install menu but always to live session" [Undecided,Confirmed] https://launchpad.net/bugs/1570901
<infinity> flocculant: Spooky.
<flocculant> yup
<flocculant> just thought I'd mention something positive ;)
 * infinity rebuilds the world.
<infinity> (Don't worry, there's no way these are "final", don't sweat if your last minute stuff isn't in, this is just to get more testing)
 * flocculant doesn't panic 5 days before :)
<infinity> 4.
<infinity> 3, if you consider that we like to be ready by Wed night.
<flocculant> :)
<infinity> But no pressure. :P
<flocculant> ha ha ha
<flocculant> infinity: mmm so spookier - if I choose install from the first menu you could get to - I do land at the live desktop
<infinity> That sounds delighfully broken.
<flocculant> :)
<infinity> Might be a cyphermox bug.  I think he was rooting around in gfxboot menus last week.
<flocculant> :)
<flexiondotorg> infinity, Two different computers test in EFI. All Good! No issue! :-)
<flexiondotorg> infinity, As always, thanks for your time helping investigate.
<flexiondotorg> So the images from April 17th are not affected.
<infinity> flexiondotorg: Righto.  Final images obviously can't have this bug, as we take great care to keep the archive consistent while building during release week.
<infinity> flexiondotorg: So go ahead and close the bug.
 * flexiondotorg is closing the bugs now.
<bluesabre> Please approve the above xubuntu-artwork package, fixes an issue where our wireless icons become very difficult to see in the network indicator
<bluesabre> also, hi everyone :)
<flexiondotorg> infinity, Am I right in saying we should only see release critical bugs being added to the archive from now on?
<infinity> flexiondotorg: Ideally removed, not added.
 * infinity is going to have a short jetlag nap.
<doko> pkg-info-el built with fixed emacs24
<slangasek> cyphermox: I just got the UEFI secureboot debconf prompt on an upgrade within xenial (not at the time I upgraded to xenial).  Will get more info and file a ug
<slangasek> or a bug
<apw> slangasek, fyi the mok secure boot disable does not appear to be working, i am looking at it
<slangasek> apw: ok
<clivejo> rbasak: ping
<doko> I'm not happy about the state of dbus in xenial. you see test related dbus failures in many packages: libnih, libsecret, nux, are the ones I touched today
<xnox> infinity, shall we have unity on s390x in xenial? doko wants it to run openjdk tests, and IBM java team do too (so far directed them to use xfce, but doko is resisting)
<xnox> https://launchpadlibrarian.net/254258618/nux.debdiff
<doko> heh
<doko> build stuff if we can ...
<xnox> infinity, a noopt build guest nux going on s390x, i shall test unity build with that one in a ppa.
<doko> also looking at lz4 on s390x
<doko> which works with noopt again
<xnox> doko, well if we have unity & nux, we may as well publish ubuntu-desktop.
<doko> looks like toolchain issues
<xnox> lz4 did build on s390x in february -> https://launchpad.net/ubuntu/+source/lz4/0.0~r131-2/+build/9029716
<doko> how did the cantor autopkg tests get fixed?
<doko> still don't know what to do about the wine mess ...
#ubuntu-release 2017-04-10
<cyphermox> imho, it's pretty late for rebuilding main packages just for PIE, perhaps if there are other bugfixes alongside..
<Ukikie> It depends on if its pumpkin pie....
<mwhudson> any release team people about?
-queuebot:#ubuntu-release- Unapproved: golang-1.6 (xenial-proposed/main) [1.6.2-0ubuntu5~16.04 => 1.6.2-0ubuntu5~16.04.1] (kubuntu, ubuntu-desktop)
<cyphermox> mwhudson: it's either too late or too early I think; otherwise too weekend? ;D
-queuebot:#ubuntu-release- Unapproved: ubiquity (zesty-proposed/main) [17.04.8 => 17.04.9] (core)
-queuebot:#ubuntu-release- Unapproved: ubiquity-slideshow-ubuntu (zesty-proposed/main) [123 => 124] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: golang-1.6 (yakkety-proposed/main) [1.6.3-1ubuntu1 => 1.6.3-1ubuntu1.1] (kubuntu, ubuntu-desktop)
<mwhudson> cyphermox: yeah too weekend
<estan> good morning folks. any release team member who could kindly have a look at qtbase-opensource-src 5.5.1+dfsg-16ubuntu7.4 in the xenial upload queue? it fixes a quite annoying bug i reported, so i'm eager to have it tested in proposed (https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1598173).
<ubot5> Ubuntu bug 1598173 in qtbase-opensource-src (Ubuntu Xenial) "Please consider SRU of "xcb: Compress mouse motion and touch update events"" [Undecided,New]
-queuebot:#ubuntu-release- Unapproved: rejected ubiquity-slideshow-ubuntu [source] (zesty-proposed) [124]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (zesty-proposed) [2:10.0.0-0ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (zesty-proposed) [17.04.9]
-queuebot:#ubuntu-release- Unapproved: gnss-sdr (zesty-proposed/universe) [0.0.9-1 => 0.0.9-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnss-sdr [sync] (zesty-proposed) [0.0.9-2]
-queuebot:#ubuntu-release- Unapproved: r-bioc-genomeinfodb (zesty-proposed/universe) [1.10.2-1 => 1.10.3-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-genomeinfodb [sync] (zesty-proposed) [1.10.3-1]
<infinity> rbalint: I suspect your science is a bit off if glibc is in that list, given that dpkg and gcc didn't change since the last glibc upload.  But also, waaaay too late to be asking to rebuild a bunch of stuff in main.  It can wait for Anonymous Antelope.
<ginggs> rbalint: yw, and thanks for the upload.  i've sync'd r-bioc-genomeinfodb and will trigger the necessary tests
<infinity> ginggs: Still hoping to get that whole R mess migrated under the wire?
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-weather (zesty-proposed/universe) [0~20160325.gitb5415ec-2ubuntu2 => 0~20170402.git34506a6-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-weather [sync] (zesty-proposed) [0~20170402.git34506a6-1]
<ginggs> infinity: i think a big chunk of them will migrate now - but there are still a couple with bad tests
 * apw yawns at the world
<infinity> ginggs: Yeah, I briefly looked at the mess when I was on the warpath to make glibc's rdeps all green.  I got everything EXCEPT for r-* because I had better things to do.
<infinity> apw: Did the world yawn back?
<apw> seems not, seems i am not very interesting
<jbicha> hi, what should we do to fix chrome-gnome-shell 8-2ubuntu4~ubuntu16.10.1 not actually being published for 16.10?
<jbicha> http://archive.ubuntu.com/ubuntu/pool/universe/c/chrome-gnome-shell/
<jbicha> https://github.com/nE0sIghT/chrome-gnome-shell-mirror/issues/44
<LocutusOfBorg> hello infinity thanks for curl hint
-queuebot:#ubuntu-release- Unapproved: system-config-printer (zesty-proposed/main) [1.5.7+20160812-0ubuntu8 => 1.5.7+20160812-0ubuntu9] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: dnscrypt-proxy (zesty-proposed/universe) [1.9.4-1 => 1.9.4-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ubuntu-gnome-meta (zesty-proposed/universe) [0.77 => 0.78] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: accepted dnscrypt-proxy [source] (zesty-proposed) [1.9.4-1build1]
-queuebot:#ubuntu-release- Unapproved: dnstap-ldns (zesty-proposed/universe) [0.2.0-2 => 0.2.0-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: freeipa (zesty-proposed/universe) [4.4.3-3ubuntu1 => 4.4.3-3ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted freeipa [source] (zesty-proposed) [4.4.3-3ubuntu2]
-queuebot:#ubuntu-release- Unapproved: opendnssec (zesty-proposed/universe) [1:2.0.3+-1ubuntu1 => 1:2.0.3+-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted dnstap-ldns [source] (zesty-proposed) [0.2.0-2build1]
-queuebot:#ubuntu-release- Unapproved: libzonemaster-perl (zesty-proposed/universe) [1.0.16-1 => 1.0.16-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: strongswan (zesty-proposed/main) [5.5.1-1ubuntu2 => 5.5.1-1ubuntu3] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: libnet-ldns-perl (zesty-proposed/universe) [0.75-1 => 0.75-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pathspider (zesty-proposed/universe) [1.0.1-1 => 1.0.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted libzonemaster-perl [source] (zesty-proposed) [1.0.16-1build1]
-queuebot:#ubuntu-release- Unapproved: python-libtrace (zesty-proposed/universe) [1.6+git20161027-1 => 1.6+git20161027-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pathspider [source] (zesty-proposed) [1.0.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted libnet-ldns-perl [source] (zesty-proposed) [0.75-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted opendnssec [source] (zesty-proposed) [1:2.0.3+-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted python-libtrace [source] (zesty-proposed) [1.6+git20161027-1build1]
<infinity> LocutusOfBorg: Dude.  A library transition three days before release? :(
<infinity> LocutusOfBorg: One that involves seeded packages, no less?
-queuebot:#ubuntu-release- Unapproved: cluster-glue (zesty-proposed/main) [1.0.12-5ubuntu1 => 1.0.12-5ubuntu2] (ubuntu-desktop, ubuntu-server)
<LocutusOfBorg> infinity, erm... not my fault, trying to fix other people mistakes
<LocutusOfBorg> trying to fix the mess :/
<mapreri> only strongswan is seeded, right?
<infinity> LocutusOfBorg: It wasn't a mess until you just now uploaded.
<infinity> LocutusOfBorg: One library stuck in proposed is not a "mess".
<infinity> LocutusOfBorg: Now it's one library and a bunch of stuff that depends on it.
-queuebot:#ubuntu-release- Unapproved: tigervnc (zesty-proposed/universe) [1.7.0+dfsg-6ubuntu1 => 1.7.0+dfsg-7ubuntu1] (edubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted system-config-printer [source] (zesty-proposed) [1.5.7+20160812-0ubuntu9]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-gnome-meta [source] (zesty-proposed) [0.78]
-queuebot:#ubuntu-release- Unapproved: accepted tigervnc [source] (zesty-proposed) [1.7.0+dfsg-7ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted strongswan [source] (zesty-proposed) [5.5.1-1ubuntu3]
<infinity> ginggs: Did you need to do something with gearhead for that last minute fpc upload of yours?
<LocutusOfBorg> ta for tigervnc strongswan
<LocutusOfBorg> will make it smooth
<ginggs> infinity: i don't think we need any rebuild for fpc, everything is statically linked. did you pick up a problem?
<infinity> ginggs: NBS picked up a problem.  gearhead build-deps on an fpc-source version you're about to remove.
<ginggs> infinity: thanks, i'll look into that
<mapreri> infinity: fyi, the top of britney has a "Trying easy from adconrad.... Version mismatch ... Not using hint"
-queuebot:#ubuntu-release- Unapproved: ubuntu-gnome-default-settings (zesty-proposed/universe) [17.04.2 => 17.04.3] (ubuntugnome)
<infinity> mapreri: Yeah, that's harmless.  It's an old hint I haven't deleted.
-queuebot:#ubuntu-release- Unapproved: gearhead (zesty-proposed/universe) [1.302-3 => 1.302-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gearhead [source] (zesty-proposed) [1.302-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: dpkg (xenial-proposed/main) [1.18.4ubuntu1.1 => 1.18.4ubuntu1.2] (core)
-queuebot:#ubuntu-release- Unapproved: dpkg (zesty-proposed/main) [1.18.10ubuntu1 => 1.18.10ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: dpkg (yakkety-proposed/main) [1.18.10ubuntu1 => 1.18.10ubuntu1.1] (core)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [amd64] (xenial-proposed) [4.10.0-19.21~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted dpkg [source] (zesty-proposed) [1.18.10ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted cluster-glue [source] (zesty-proposed) [1.0.12-5ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-gnome-default-settings [source] (zesty-proposed) [17.04.3]
-queuebot:#ubuntu-release- Unapproved: accepted dpkg [source] (xenial-proposed) [1.18.4ubuntu1.2]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-117.164]
-queuebot:#ubuntu-release- Unapproved: accepted dpkg [source] (yakkety-proposed) [1.18.10ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-settings (zesty-proposed/universe) [17.04.6 => 17.04.7] (ubuntu-mate)
<ginggs> infinity: is forcing bad-test an option for r-bioc-annotationhub/2.6.4-1 ?  this is holding up many of the R packages.  i believe the current failure is also due to NCBI's FTP site reorganization, we already fixed debian bug #859864, but this looks like another.  i'm pretty sure  r-bioc-annotationhub/2.4.2-2 in zesty is affected too, so it's not a regression
<ubot5> Debian bug 859864 in src:r-bioc-genomeinfodb "r-bioc-genomeinfodb: Reorganization of ftp://ftp.ncbi.nlm.nih.gov/genomes/all" [Grave,Open] http://bugs.debian.org/859864
<ginggs> rbalint ^
-queuebot:#ubuntu-release- Unapproved: base-files (zesty-proposed/main) [9.6ubuntu12 => 9.6ubuntu13] (core)
<infinity> ginggs: Can the test not be fixed?
<infinity> (Or the code the test is calling)
<ginggs> infinity: i'll keep looking, but I don't know R from P or Q
<jbicha> please unblock ubuntu-gnome-meta, thanks
<infinity> ginggs: Well, the bug you referenced is fixed in a new upload...
-queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (xenial-proposed) [2:8.1.1-0ubuntu3]
<infinity> jbicha: Will unblock when I redo all the metas after lunch.
<ginggs> infinity: yup, and i've sync'd that and re-run the tests, but there is still a failure (that appeared on the same date)
<infinity> Fun.
<infinity> ginggs: If you're positive it's not a regression from 2.4.2-2, yeah, we can badtest it for now.
<ginggs> infinity: how can i make 100% sure?
<infinity> Run the same tests with the same triggers, except for the r-bioc-annotationhub versions, and compare?
<ginggs> do you mean on the ubuntu autopkgtest infra, or locally?
<ginggs> infinity: i think http://autopkgtest.ubuntu.com/packages/r/r-bioc-annotationhub/zesty/amd64 confirms it - autopkgtests haven't passed since 2017-01-16
<infinity> ginggs: Except while I see 404s in the old tests, I see something very different in new tests?
<infinity> ginggs: And, indeed, the new failure seems specific to the migration being attempted.
<ginggs> infinity: yes, the 404 is gone, but it is the same test that still fails - FAILURE in test_tidyGRanges: Error in checkIdentical(setNames(rep(c(FALSE, TRUE), c(4, 1)), chr), GenomeInfoDb::isCircular(gr1)) :
<infinity> Or maybe the underlying library just doesn't bubble up the 404s anymore.
<infinity> Which would be annoying.
<infinity> Meh.  I'm going to run 2.4.2-2 with a self-trigger to be sure.
<ginggs> infinity: ok, thanks
<xnox> infinity, https://code.launchpad.net/~xnox/unity/no-more-upstart-dep/+merge/322283
-queuebot:#ubuntu-release- Unapproved: apport (zesty-proposed/main) [2.20.4-0ubuntu3 => 2.20.4-0ubuntu4] (core)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-settings [source] (zesty-proposed) [17.04.7]
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (zesty-proposed) [2.20.4-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (zesty-proposed) [9.6ubuntu13]
<jbicha> I'm rebuilding the GNOME iso's to verify the ubiquity theme fix
-queuebot:#ubuntu-release- Unapproved: libphysfs (zesty-proposed/universe) [2.0.3-4 => 2.0.3-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libphysfs [sync] (zesty-proposed) [2.0.3-5]
<infinity> jbicha: Kay.  There will be a mass rebuild later today, but that's fine.
<jbicha> right, I just wanted to make sure that if there was a problem, I didn't wait until the last moment!
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Zesty Final] has been updated (20170410)
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Zesty Final] has been updated (20170410)
<infinity> jbicha: A noble goal.
-queuebot:#ubuntu-release- Unapproved: command-not-found (zesty-proposed/main) [0.3ubuntu17.04.1 => 0.3ubuntu17.04.2] (core)
-queuebot:#ubuntu-release- Unapproved: mate-panel (zesty-proposed/universe) [1.18.1-0ubuntu1 => 1.18.1-0ubuntu2] (ubuntu-mate, ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: labplot (zesty-proposed/universe) [2.3.0-2ubuntu1 => 2.3.0-2ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: twisted (zesty-proposed/main) [16.6.0-2 => 16.6.0-2ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: txzmq (zesty-proposed/universe) [0.7.4-1 => 0.7.4-1ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted txzmq [sync] (zesty-proposed) [0.7.4-1ubuntu1]
<infinity> jbicha: FYI, that chrome-gnome-shell oops looks fixed now.
-queuebot:#ubuntu-release- Unapproved: libmatekbd (zesty-proposed/universe) [1.18.1-0ubuntu1 => 1.18.2-0ubuntu1] (ubuntu-mate, ubuntukylin)
<infinity> rbasak: Does anyone care that the ppc64el server ISO is 5MB over CD size?
<rbasak> powersj: ^
<infinity> rbasak: He usually submits MPs to change the limit, I was asking if you wanted to change seeds to trim the size. :P
<rbasak> I don't know. powersj may know better if we care :)
<infinity> Fair enough.
<rbasak> Or jgrimm may also know if we care ^
-queuebot:#ubuntu-release- Unapproved: gnome-logs (zesty-proposed/universe) [3.24.0-0ubuntu1 => 3.24.1-0ubuntu1] (ubuntugnome)
 * rbasak knows little about the ppc64el install process
<jgrimm> infinity, rbasak yeah i was just starting to type
<jgrimm> TL;DR we don't care
<infinity> rbasak: Well, the "process" is the same as most places.  In that real sysadmins use netboot of some sort, but they *can* boot optical media too.
<infinity> We could fix this if IBM fixed their machines to love compressed kernels.
<infinity> (The giant kernels are why it's always larger than x86)
<infinity> jgrimm: Not caring works for me.
<jgrimm> we'll still 'monitor' for crazy growth that indicates something wildly has gone wrong, but no longer the specific size tied to CD media
<infinity> jgrimm: Mmkay.
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-meta (zesty-proposed/universe) [1.189 => 1.190] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (zesty-proposed/main) [1.378 => 1.379] (core)
-queuebot:#ubuntu-release- Unapproved: xubuntu-meta (zesty-proposed/universe) [2.212 => 2.213] (xubuntu)
-queuebot:#ubuntu-release- Unapproved: ubuntustudio-meta (zesty-proposed/universe) [0.167 => 0.168] (ubuntustudio)
<infinity> seb128: Langpacks?
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-meta [source] (zesty-proposed) [1.190]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (zesty-proposed) [1.379]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntustudio-meta [source] (zesty-proposed) [0.168]
-queuebot:#ubuntu-release- Unapproved: rejected twisted [sync] (zesty-proposed) [16.6.0-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted xubuntu-meta [source] (zesty-proposed) [2.213]
<apw> infinity, you want that command-not-found "reviewed" ?
<infinity> apw: Please.
-queuebot:#ubuntu-release- Unapproved: accepted mate-panel [source] (zesty-proposed) [1.18.1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: twisted (zesty-proposed/main) [16.6.0-2 => 16.6.0-2ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server)
<Laney> Review each line explicitly please
-queuebot:#ubuntu-release- Unapproved: accepted gnome-logs [source] (zesty-proposed) [3.24.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libmatekbd [source] (zesty-proposed) [1.18.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted labplot [source] (zesty-proposed) [2.3.0-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted twisted [source] (zesty-proposed) [16.6.0-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted command-not-found [source] (zesty-proposed) [0.3ubuntu17.04.2]
<infinity> apw: Did you read every line of that diff?
<infinity> apw: I have my doubts.
<apw> infinity, i grepped out the -powerpc, the ripped the 'same lines' diff from movement, and eyeballed the rest
<apw> it seemed sane
<apw> some movement to univere, some commands dropped and some added in line with waht i expected
<apw> (plus i started before i offered :))
<apw> but, i may have not read every line as well as Laney would have
<infinity> apw: We're just messing with you. :P
<apw> infinity, :)
<apw> infinity,
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Zesty Final] (20101020ubuntu504) has been added
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Zesty Final] (20101020ubuntu504) has been added
-queuebot:#ubuntu-release- Builds: Netboot armhf [Zesty Final] (20101020ubuntu504) has been added
-queuebot:#ubuntu-release- Builds: Netboot i386 [Zesty Final] (20101020ubuntu504) has been added
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Zesty Final] (20101020ubuntu504) has been added
-queuebot:#ubuntu-release- Builds: Netboot s390x [Zesty Final] (20101020ubuntu504) has been added
-queuebot:#ubuntu-release- Unapproved: ubiquity-slideshow-ubuntu (zesty-proposed/main) [123 => 124] (kubuntu, ubuntu-desktop)
<infinity> cyphermox: Did the s/Muon Discover/Discover/ change not suffer the same msgid invalidation problem?
<cyphermox> am I not Derpy McDerpface?
<infinity> You might be.  Are you?
<cyphermox> looks that way
<cyphermox> derpty derp .
<infinity> Shall I reject?
<cyphermox> yeah, I'll go touch it again
<cyphermox> right after the DMB meeting
-queuebot:#ubuntu-release- Unapproved: rejected ubiquity-slideshow-ubuntu [source] (zesty-proposed) [124]
-queuebot:#ubuntu-release- Unapproved: ubiquity-slideshow-ubuntu (zesty-proposed/main) [123 => 124] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity-slideshow-ubuntu [source] (zesty-proposed) [124]
-queuebot:#ubuntu-release- Unapproved: wxpython3.0 (zesty-proposed/universe) [3.0.2.0+dfsg-3 => 3.0.2.0+dfsg-3ubuntu1] (edubuntu)
<apw> ^ that really ought to have a bug# so it can be an SRU
-queuebot:#ubuntu-release- Unapproved: accepted wxpython3.0 [source] (zesty-proposed) [3.0.2.0+dfsg-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: poedit (zesty-proposed/universe) [2.0-1~exp1 => 2.0.1-1~exp1~build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted poedit [source] (zesty-proposed) [2.0.1-1~exp1~build1]
-queuebot:#ubuntu-release- Unapproved: gui-ufw (zesty-proposed/universe) [17.04.1-1 => 17.04.1-1ubuntu1] (ubuntu-mate)
<LocutusOfBorg> apw, you right :) unfortunately this has been an omygodkitten issue, so I did it quick
<LocutusOfBorg> anyhow, a bug report is on Debian BTS now https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860043
<ubot5> Debian bug 860043 in src:wxpython3.0 "" [Important,Open]
<LocutusOfBorg> (I read irclogs when possible, don't rely on it :) )
 * LocutusOfBorg leaves, he is on train
-queuebot:#ubuntu-release- Unapproved: content-hub (zesty-proposed/main) [0.3+17.04.20170317.1-0ubuntu1 => 0.3+17.04.20170403-0ubuntu1] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: tomcat8 (xenial-proposed/main) [8.0.32-1ubuntu1.3 => 8.0.32-1ubuntu1.4] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: tomcat8 (zesty-proposed/main) [8.0.38-2ubuntu1 => 8.0.38-2ubuntu2] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: epiphany-browser (zesty-proposed/universe) [3.24.0-0ubuntu2 => 3.24.1-0ubuntu1] (desktop-extra)
-queuebot:#ubuntu-release- Unapproved: tomcat8 (yakkety-proposed/main) [8.0.37-1ubuntu0.1 => 8.0.37-1ubuntu0.2] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cockpit (zesty-proposed/universe) [137-3 => 138-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [sync] (zesty-proposed) [138-1]
<xnox> my laptop did something really weird
<xnox> ext4 started to detect journal errors and filesystem got remounted readonly
<xnox> and from that point onwards I am enable to run df or gain root via sudo
<xnox> all results in input/output errors
<xnox> rebooting now.....
<xnox> however, this is quite old kernel, not 4.10 =/
<Bashing-om> xnox: Off topic for this channel . Suggest ya seek support in your OS channel .
 * ogra_ lols
-queuebot:#ubuntu-release- New sync: ms-gsl (zesty-proposed/primary) [0~git20170403.ebab8ca-1]
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-dashtodock (zesty-proposed/universe) [57-1 => 57-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-dashtodock [source] (zesty-proposed) [57-1ubuntu1]
<slangasek> infinity, seb128: based on conversation with cyphermox, I understand that at least part of why we get so many bug reports on shim-signed related to debconf prompts not happening is that the gnome frontend is still broken by default due to missing libgtk2-perl.  This is not an opportune time to discover this vs. release, but the problem affects older releases also and will need SRUed. opinions on
<slangasek> seeding libgtk2-perl onto ubuntu-desktop for 17.04?
<slangasek> infinity, seb128: this makes a difference in the UX of installing dkms packages (nvidia) from the liveCD, so seems worth pushing in
<cyphermox> assuming we get another respin, seems like a relatively easy and safe fix?
<slangasek> I'm not asking about including it opportunistically, I'm asking about committing to a respin for this issue
<seb128> slangasek, no objection in principle from me, did anyone check if that would pull in other things as well? (we still have gtk2 on the iso so that's ok)
<slangasek> Depends: libatk1.0-0 (>= 1.12.4), libc6 (>= 2.14), libcairo2 (>= 1.2.4), libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.24.0), libgtk2.0-0 (>= 2.24.0), libpango-1.0-0 (>= 1.18.0), libpangocairo-1.0-0 (>= 1.14.0), perl (>= 5.22.2-1), perlapi-5.22.2, libcairo-perl, libglib-perl (>= 3:1.280), libpango-perl, shared-mime-info
<cyphermox> slangasek: I understand that, what I'm saying is it's a moot point if we already are going to respin. my opinion in this case isn't gospel, but I'd respin
<seb128> so basically that gtk-perl bindings stack, which is probably small enough
<seb128> I don't have data to know if that's worth a respin though, so letting that decision to others
<seb128> installing nvidia drivers in a live session doesn't seem an important usecase to me at least
<slangasek> isn't the common case that if you're going to install nvidia drivers, you do it during the install?
<slangasek> thinking further, maybe this should be a dep of ubuntu-software instead of directly seeded
<dmj_s76> When upgrading from 16.10 to 17.04 the nvidia dkms modules don't get rebuilt.
<slangasek> that impacts ubuntukylin (and would impact edubuntu)
<slangasek> dmj_s76: have you filed a bug report with upgrade logs?
<dmj_s76> slangasek: Not yet, we just identified this now.
<slangasek> ok
<seb128> I don't have nvidia hardware so I don't know how the installer is dealing with those, I know you can enable them from software-properties on an installed system though
<dmj_s76> The end result is that there are dkms modules for 4.8 but not 4.10 installed.
<seb128> cyphermox, ^ do you know what the installer is doing?
<cyphermox> seb128: afaik it's running ubuntu-drivers uninteractively, to get the list of packages to install towards the end of the install process
<cyphermox> (when you click "Install third-party drivers"
<seb128> so what wouldn't work without libgtk2-perl?
<slangasek> seb128: installing nvidia drivers through the gui on a machine that has SecureBoot enabled will blow up
<cyphermox> but the installer is "special" in that if you can fallback to Dialog if necessary (given that you have a shell window under the slideshow) and possibly a bit more is done to go uninteractively.
<slangasek> falling back to Dialog is horrendous
<seb128> slangasek, k, that seems worth a respin indeed
<cyphermox> (and furthermore, the default if secure boot is detected is to try to convince the user to set a password for mokutil)
<slangasek> if it falls back to dialog, it won't crash on install
<cyphermox> slangasek: I have never seen an install fallback to anything
<seb128> so that issue is in the LTS and nobody investigated until now?
<cyphermox> I think in that case it runs uninteractive
<jackpot51> cyphermox: We are talking about `update-manager`, not the installer
<dmj_s76> slangasek: Are you guys talking about a separate nvidia issue here?
<slangasek> seb128: it's a new consequence of the changes to enforce kernel module signing in the secureboot policy
-queuebot:#ubuntu-release- Unapproved: gnome-software (zesty-proposed/main) [3.22.7-0ubuntu2 => 3.22.7-0ubuntu3] (ubuntu-desktop)
<jackpot51> cyphermox: `nvidia-375` is installed, then `update-manager -d`, then after reboot the nvidia driver does not load
<seb128> slangasek, ok, thanks for the details, so yeah +1 from me to respin with libgtk2-perl
<slangasek> cyphermox, seb128: ok, I forgot that this is integrated in ubiquity itself, which means the installer doesn't depend on the debconf gnome frontend for prompting... so now it seems to me maybe we /don't/ need it in 17.04 images
<cyphermox> jackpot51: seb128 asked with the words "installer"
<slangasek> jackpot51, dmj_s76: you've joined a conversation already in progress that has nothing to do with the upgrade bug you're talking about
<jackpot51> ok
<dmj_s76> ah, okay...now that makes sense
<cyphermox> slangasek: why? isn't it still needed that drivers recommends libgtk2-perl or something?
<slangasek> cyphermox: why is that not SRUable?
<Bashing-om> seb128: Ya need a ginny pig ? I do have a 17.04 install on a nVidia GT710 card running the nouveau driver . I could reboot and see what results in installing the proprietary driver .
<cyphermox> slangasek: oh, it most definitely is; it's just going to be ugly for the installs without network that can't get updates
<slangasek> cyphermox: if that debconf prompt is not used in the installer path, even for 'install third-party drivers', it seems a post-release update is fine
<cyphermox> I don't think there are very many network drivers depending on dkms
<seb128> Bashing-om, thanks, unsure if that's needed, seems people have a good understanding of the problem and when it's an issue
<slangasek> cyphermox: right, I think the practical impact of that is nil
<cyphermox> slangasek: I think we'll get in a state where the system is installable for most cases; but maybe not all that usable
<cyphermox> yes, it's a very small portion of users
<cyphermox> only r8168-dkms comes to mind, assuming that's still relevant.
<Bashing-om> seb128: K; I do little enough to help .. So I help where I can :)
<cyphermox> slangasek: that *might* impact willcooke, if I remember well; could be worth asking him how he does his installs.
<cyphermox> (so we know if we're completely forgetting something important)
<slangasek> cyphermox: ah - I assumed the set of dkms network drivers in the archive was zero.  If it's not, I think that's sufficient justification for a respin
<cyphermox> it's definitely non-zero
<cyphermox> I see rtl8812au-dkms too which I don't particularly care about, but I have hardware that requires it
<cyphermox> it's some wireless dongle
<cyphermox> oh, and broadcom-sta-dkms
<cyphermox> I think it will need to be there; STA used to be required for quite a bunch of people.
<slangasek> so, if I fix this properly, it's a new Recommends: on gnome-software; that impacts lubuntu, ubuntustudio, ubuntukylin, ubuntu-budgie, xubuntu in addition to ubuntu
<cyphermox> on gnome-software?
<slangasek> yes
<cyphermox> seems odd; but ok
<slangasek> ubuntu-software is just a thin layer around gnome-software, it's gnome-software that has the dep on aptdaemon
<jbicha> slangasek: gnome-software isn't the right place, maybe software-properties-common?
<cyphermox> I don't think we're talking about the same thing
<jbicha> I don't believe gnome-software supports debconf
<slangasek> jbicha: gnome-software depends on aptdaemon without providing it a frontend
<cyphermox> it shouldn't have to
<slangasek> jbicha: this isn't an aptdaemon bug, because aptdaemon doesn't know /which/ gui toolkit frontend you want; that's a property of whatever depends on aptdaemon
<jbicha> software-properties-gtk also depends on aptdaemon
<slangasek> yes, and that package should *also* Recommends: libgtk2-perl
<cyphermox> jbicha: gnome-software still probably ought to pull the package in, because you *might* install some dkms package from there.
<jbicha> because I'm pretty sure that you can't install NVIDIA drivers using gnome-software/zesty but you can with software-properties-gtk
<slangasek> this problem is not limited to software-properties-gtk
<slangasek> jbicha: LP: #1679435
<ubot5> Launchpad bug 1679435 in gnome-software (Ubuntu) "installing dkms package from software-center, no debconf frontend: package shim-signed 1.27~16.10.1+0.9+1474479173.6c180c6-1ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Critical,Triaged] https://launchpad.net/bugs/1679435
<slangasek> should fix the title though, since it's not actually "software center" being used :P
<cyphermox> slangasek: what of things that use packagekit instead? do we care?
<cyphermox> uh-oh, frozen
<slangasek> cyphermox: which are those?
<jbicha> I think we're miscommunicating there; I don't think anything available in gnome-software uses dkms and I don't believe gnome-software supports debconf at all
<cyphermox> slangasek: I'm not sure, I thought there was
-queuebot:#ubuntu-release- Unapproved: rejected gnome-software [source] (zesty-proposed) [3.22.7-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: gnome-software (zesty-proposed/main) [3.22.7-0ubuntu2 => 3.22.7-0ubuntu3] (ubuntu-desktop)
<cyphermox> slangasek: jbicha seems to have a point; it doesn't look like you can pick a dkms package to install via Software.
<cyphermox> maybe I'm doing this wrong though; but quick searches when it does work don't turn up anything useful; I tried "dkms", "broadcom", "driver"...
<slangasek> cyphermox, jbicha: virtualbox. QED
<slangasek> as detailed in the bug I linked
<cyphermox> oh, of course.
<jbicha> ok, but my second concern is whether gnome-software supports debconf
<cyphermox> jbicha: it doesn't have to
<slangasek> I don't know what you think that means
<slangasek> it is inexcusable for a frontend for installing Debian packages to NOT support debconf
<jbicha> please file a bug then
<infinity> "suporting debconf" is probably just a question of having libgtk-perl installed.
<slangasek> to be clear, you're right that gnome-software doesn't install drivers and therefore it's not release-critical to fix gnome-software for 17.04.  But if we're respinning anyway we could as well fix both
<infinity> Maybe.
<jbicha> I had this problem when working on the steam/zesty package where I had to drop the mandatory debconf question
<slangasek> jbicha: like the one I linked to above already?
<slangasek> infinity: yes, that's basically how I'm solving it (one package in queue, another in progress now)
<infinity> slangasek: Mmkay.
<slangasek> infinity: so you had respins planned anyway? cool
<infinity> slangasek: Yeah.  Was waiting for all the unblocks in the stack to wind through, final langpacks seb gave us earlier today, etc.
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (zesty-proposed) [3.22.7-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted gui-ufw [source] (zesty-proposed) [17.04.1-1ubuntu1]
<slangasek> infinity: software-properties also uploaded
-queuebot:#ubuntu-release- Unapproved: software-properties (zesty-proposed/main) [0.96.24.11 => 0.96.24.12] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted content-hub [sync] (zesty-proposed) [0.3+17.04.20170403-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted epiphany-browser [source] (zesty-proposed) [3.24.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (zesty-proposed) [0.96.24.12]
<cyphermox> slangasek: the gnome-software change makes sense, but did it work for you?
<cyphermox> because http://imgur.com/a/6qqkP
<cyphermox> disregard the "Secure Boot not enabled" message, I hacked the script to run anyway -- this is because my desktop does EFI but not Secure Boot.
<jbicha> yes, that's similar to what I saw with steam
<slangasek> well
<slangasek> yeah, perhaps there are other problems here
<cyphermox> (but that's a bug in gnome-software anyway)
<slangasek> and no, I didn't actually test it
<slangasek> how is it a bug in gnome-software?
<cyphermox> not properly setting a frontend?
<cyphermox> (or running non-interactively here)
<jbicha> to me, it's unclear whether gnome-software not supporting debconf is a design decision or a bug
<infinity> Design decisions can also be bugs.
<infinity> Anyhow, I'm going to let you guys sort this out for a bit, I'll be back in 1.5 hours or so to see the state of proposed and start respins once I massage it to how I like before bed.
<cyphermox> probably more an oversight, because most developers working on Software are probably more used to RPM distros, I suppose.
<infinity> slangasek: Feel free to self-accept followups, so long as you get a positive review from someone sane.
<cyphermox> but I'm just guessing, I have no idea
<Laney> I think you can call setDebconfFrontend or something on aptdaemon transactions
<jbicha> is it mandatory to show debconf prompts? or is the bug in the package that won't install completely without answering a debconf question?
<Laney> FYI
<slangasek> infinity: check.  if we miss the 1.5 window, feel free to throw the respin list to me
<slangasek> Laney: any chance you can point me to an example?
<cyphermox> jbicha: any software may ask debconf questions; for things it needs to know to properly install -- for instance MAAS will ask you for some details about your setup
<slangasek> Laney: n/m, I should obviously be looking at update-manager
<slangasek> Laney: thanks
<slangasek>         yield trans.set_debconf_frontend("gnome")
<jbicha> cyphermox: right, but does it cause problems if it doesn't get an answer?
<Laney> NFI if that makes aptdaemon magically work or not though
<jbicha> I tried looking through Debian Policy earlier about this issue, but I couldn't find a clear guideline
<slangasek> cyphermox, Laney: software-properties reuploaded, setting the debconf frontend; anyone have a good way to test this?
-queuebot:#ubuntu-release- Unapproved: software-properties (zesty-proposed/main) [0.96.24.12 => 0.96.24.13] (desktop-core, ubuntu-server)
<cyphermox> jbicha: you might get exactly what you saw before with update-secureboot-policy, crash or other kind of failure because it's non-interactive, or it might work because of sensible defaults, priority, etc.
<cyphermox> slangasek: nvidia?
<cyphermox> I'm not sure I still have hardware to test that
<slangasek> cyphermox: yes, I don't either; only nvidia box here is non-UEFI, that's why I was talking earlier about putting together a test case
<jbicha> slangasek: isn't installing VBox the test case on a clean UEFI install?
<cyphermox> yeah, I figured
<cyphermox> jbicha: that won't allow you to test software-properties, it only knows about modaliases
<slangasek> jbicha: for gnome-software, but not for software-properties - check
<jbicha> ok
<slangasek> so I'm going to work up a test ppa for all of this
<cyphermox> slangasek: short of uploading a fake driver that does dkms, that could be recognized by software-properties, I can't think of a way
<slangasek> in the meantime, if someone could test that software-properties still DTRT on a *non* UEFI box, that would be good
<cyphermox> fortunately, that fake driver part is not too hard
<slangasek> because I made that code change totally blind
<cyphermox> yeah
<slangasek> cyphermox: do you have anything you can test on for the non-SB case?
<cyphermox> maybe, need to go upstairs look at my wife's machine
<tsimonq2> infinity: When we have the new codename, I call dibs on creating all the new wiki pages (like I've done for the past 3 or 4 releases :P).
<slangasek> dmj_s76, jackpot51: is there a bug w/ logs yet for the nvidia dkms upgrade issue?
<jackpot51> Yep, come to #ubuntu-devel to see
<slangasek> ok; if another dev is working it now, I don't need to get in the middle :)
<jackpot51> https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1681566
<ubot5> Ubuntu bug 1681566 in ubuntu-release-upgrader (Ubuntu) "nvidia-375 DKMS module not recompiled on upgrade to 17.04" [Undecided,Confirmed]
<jackpot51> Still, we could use more help
<jackpot51> bdmurray is helping out
<bdmurray> yeah, cause I'm not to sure what is up
<bdmurray> slangasek: or because I'm reviewing cloud-init. ;-)
<slangasek> yeah, but I'm head-down on a bugfix we're trying to land in the 17.04 image, which takes precedence over an upgrade issue
<bdmurray> okay
<dmj_s76> infinity: any ideas?
<tsimonq2> Release team: any chance the Lubuntu team could get some help with bug 1681178? Is it just adding something to the seed, or is it more complex?
<ubot5> bug 1681178 in lubuntu-meta (Ubuntu) "The alternate installer does not install man" [Undecided,New] https://launchpad.net/bugs/1681178
<rbalint>  ginggs: i wrote a simple python script for generating autopkgtest rerun links: http://pastebin.ubuntu.com/24356986/
<rbalint> ginggs: this is current output: http://pastebin.ubuntu.com/24357014/
<rbalint> ginggs: could you please trigger those?
<cyphermox> slangasek: yeah, I have a system that can probably test this
<tsimonq2> cyphermox: Do you think we should be concerned about this? https://pad.lv/1667453
<ubot5> Launchpad bug 1667453 in ubiquity (Ubuntu) "Lubuntu Zesty ubiquity welcome dialog not shown" [Undecided,New]
-queuebot:#ubuntu-release- Unapproved: gnome-terminal (zesty-proposed/main) [3.20.2-1ubuntu7 => 3.20.2-1ubuntu8] (ubuntu-desktop)
<cyphermox> tsimonq2: I don't know from that bug
<cyphermox> I'll sync the world to my system and test this after dinner
<bdmurray> cyphermox: which "this"?
<cyphermox> bdmurray: tsimonq2's
<tsimonq2> cyphermox: Thank you. :)
<bdmurray> smoser: Is the change in bug 1665773 necessary if bug 1665694 is fixed?
<ubot5> bug 1665773 in cloud-init (Ubuntu Xenial) "wrong configuration example for cc_set_passwords module" [Medium,Confirmed] https://launchpad.net/bugs/1665773
<ubot5> bug 1665694 in cloud-init (Ubuntu Yakkety) "cc_set_passwords fails to change passwords specified as chpasswd['list'] in cloud-config" [Medium,Confirmed] https://launchpad.net/bugs/1665694
<bdmurray> As I understand it either a list (the way it was supposed to be) or a string will work now and the docs are switching from string to list, while list was the original intent. So it seems strange to me to "fix" the docs.
<bdmurray> Given that the documentation isn't wrong I'll let it in.
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (yakkety-proposed) [0.7.9-90-g61eb03fe-0ubuntu1~16.10.1]
<tsimonq2> bdmurray: Re: bug 1674796, what do you think the fix might be?
<ubot5> bug 1674796 in lubuntu-default-settings (Ubuntu) "After alternate install two network applets show up" [Undecided,Confirmed] https://launchpad.net/bugs/1674796
<tsimonq2> bdmurray: Any clue what the problem is internally?
<bdmurray> tsimonq2: I don't know, sorry
 * cyphermox -> dinner, bbl
<fossfreedom> tsimonq2: in lubuntu do you run both a X11 system tray and an appindicator  in the panel ?
<slangasek> ok what am I doing wrong here?
<slangasek> db_fget "$question" seen
<slangasek> if [ "$RET" = false ]; then
<slangasek> [...]
<slangasek> because I am certainly seeing the question immediately before this
<slangasek> n/m, still not sure why it didn't work but found a workaround
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [0.7.9-90-g61eb03fe-0ubuntu1~16.04.1]
<tsimonq2> fossfreedom: I'm not 100% sure...
<fossfreedom> tsimonq2: the reason for the question is that on Ubuntu Budgie we saw the same thing - sometime double network icons - the network-manager applet gets confused between appindicators and the system tray and shows two icons
<fossfreedom> in the end I just coded around it - hid the network-manager appindicator version in our appindicator applet implementation
<fossfreedom> anyway - may not be your issue - but just putting that bit of info out there.
<tsimonq2> Ah ok :)
-queuebot:#ubuntu-release- Unapproved: dovecot (zesty-proposed/main) [1:2.2.27-2ubuntu1 => 1:2.2.27-2ubuntu2] (ubuntu-server)
<slangasek> hmm, well, I have an affirmative test of a debconf prompt through software-properties now (so, accepting); but my negative test passes even when libgtk2-perl is not installed
-queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (zesty-proposed) [0.96.24.13]
<slangasek> because debconf says "sure, I'm going to display that question, trust me"
<infinity> tsimonq2: That "doesn't install man" bug is because your ISO's preseed doesn't include standard.
<infinity> tsimonq2: I can fix that, but you'll also get recommends, which you hate :P
<infinity> (Which might be why it wasn't done?)
<tsimonq2> infinity: Didn't we talk about this a while back but somebody was supposed to do something? Rings a bell but isn't clear...
<infinity> tsimonq2: It's hardly a new bug, though.
<tsimonq2> infinity: Why does including the standard task bring in everything?
<tsimonq2> infinity: And weren't we supposed to follow up the other week re: opening floodgates by bringing in all recommends?
<infinity> tsimonq2: It's doesn't bring in "everything", it brings in all of the standard task.
<infinity> tsimonq2: Which, if you look at "ubuntu-standard" is half recommends.
<infinity> Oh.
<tsimonq2> Oh?
<infinity> But your livefses already install the whole task.
<infinity> Not the package minus recommends.
<infinity> So, meh.
<tsimonq2> But we're talking Alternate, here, I think.
<infinity> Yes.
<infinity> I'm comparing behaviour.
 * cyphermox -> back
<tsimonq2> cyphermox: \o/
<tsimonq2> cyphermox: Welcome back. :)
<cyphermox> hey, I'm in a good mood, I have a Mille-feuille to boot :)
<tsimonq2> infinity: Like I said, I think we had this discussion at one point and afaicr it led into "let's get alternate out of here" sooo :P
<tsimonq2> cyphermox: :D
<infinity> tsimonq2: Well, committed a fix anyway.
<tsimonq2> infinity: Got a link? "fix" is kinda generic...
<tsimonq2> infinity: Also, does this need a respin?
<infinity> tsimonq2: The world is respinning shortly anyway.
<wxl> oh noes
<infinity> tsimonq2: And the link will be in the bug when the branch is mirror to the public copy.
<infinity> wxl: "Oh noes"?  It's Monday. :P
<tsimonq2> infinity: Oh, more last-minute low-level kernel thingies? :P
<infinity> tsimonq2: No.
<infinity> slangasek: How did your battle go?
<tsimonq2> infinity: I was joking, but ok. :)
#ubuntu-release 2017-04-11
<tsimonq2> infinity: Alright, well thanks for helping with this. :)
<slangasek> infinity: validated software-properties against ppa:vorlon/debconf-tests; accepted and unblocked; working through the component overrides now
<slangasek> (to repromote libgtk2-perl and friends)
<infinity> slangasek: But my precious component-mismatches was empty!
<infinity> Well, I guess it still is, cause this is all in proposed. ;)
<slangasek> ;)
<infinity> (Seriously, though, EMPTY.  Did you see that?)
<infinity> I might have been excessively proud of that.  It hasn't been empty for cycles.
<slangasek> yes, it's very confusing
<slangasek> :)
<slangasek> but not as confusing as the -proposed one telling me conntrack-tools-dbg needs demoted only in -proposed
<infinity> Weird fallout from the php transition it's attempting in proposed?
<slangasek> btw, that svg at the bottom takes 95M to render in chromium
<slangasek> conntrack tied to php? not that I could tell
 * infinity shrugs.
<infinity> Fix your stuff, check the non-proposed report, ignore proposed, win.
<slangasek> yep, done
<infinity> Or conntrack-tools-dbg might be NBS in proposed.
<slangasek> oh, quite
<infinity> Oh.
<infinity> It's not NBS in proposed, but it will become NBS when proposed migrates.
<infinity> So, mystery solved.
<slangasek> technically, it is also Not Built from Source in -proposed
<slangasek> it's just also not present in -proposed ;)
<infinity> Well, yes.  But not what we mean by NBS, which is "cruft that's NBS".
<infinity> Otherwise, the NBS set is infinite.
<infinity> SO MANY THINGS NOT BUILT FROM SOURCE.
<slangasek> this cow? NBS.
<infinity> Okay, I'm sick of these snapd tests and their flappiness.
<infinity> Dpkg is getting a hint.
<wgrant> I'm glad LP didn't ever end up tracking NBS. Our DB servers aren't that big.
<infinity> wgrant: Hey now.  Don't sell them short.  They're pretty big.
<infinity> wgrant: Besides, who doesn't want to file an RT for "infinite disk, and infinite/10 RAM for hot caches"?
<wgrant> Heh
<slangasek> I was going to suggest lazy expansion as a solution, then I realized someone would be bound to write a query for it
<slangasek> infinity: software-properties accepted into zesty
<infinity> slangasek: So, gnome-software was a failed experiment?
<slangasek> infinity: gnome-software is a partial fix; the recommends is still valid to add but does no good without code changes to tell aptd to actually use the gnome frontend
<slangasek> and that piece isn't installer-critical since it's not related to drivers, so we'll deal with it in SRU
<infinity> "code changes" like just pushing DEBIAN_FRONTEND to gnome-software's env?
<infinity> Or is it foiling that plan by forking aptdaemon in a clean env?
<slangasek> infinity: aptd is dbus-activated
<infinity> Oh.
<infinity> Derp.
<infinity> But, wait.  update-manager uses aptd, doesn't it?  And it debconfs.
<infinity> Maybe I'm living in the past.
 * infinity shrugs.
<slangasek> so there's an api to tell it which frontend to use, which you have to call, and since gnome-software is !python I have to look up the deets and this is not something for you to block the respin on
<slangasek> infinity: yes, u-m calls the api to set the frontend, that's where I stole the one-liner to do it for software-properties
<infinity> Ah.
<infinity> Check.
<infinity> Alright.
<infinity> Well, let your half fix in, please.
<infinity> If you didn't already.
<infinity> And I'll go twiddle some thumbs while I wait on these langpacks and your stuff and my stuff to all converge in one spot.
<slangasek> infinity: k, gnome-software unblocked
-queuebot:#ubuntu-release- Unapproved: sysprof (zesty-proposed/universe) [3.24.0-0ubuntu1 => 3.24.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted sysprof [source] (zesty-proposed) [3.24.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: bijiben (zesty-proposed/universe) [3.20.2-1build2 => 3.20.2-1.1] (desktop-extra) (sync)
<jbicha> ^ bijiben is unseeded, let me know if you'd rather I did an Ubuntu-specific upload instead https://tracker.debian.org/news/843188
-queuebot:#ubuntu-release- Unapproved: gnome-builder (zesty-proposed/universe) [3.24.0-0ubuntu1 => 3.24.1-0ubuntu1] (desktop-extra)
-queuebot:#ubuntu-release- Unapproved: polari (zesty-proposed/universe) [3.24.0-0ubuntu1 => 3.24.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted polari [source] (zesty-proposed) [3.24.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted bijiben [sync] (zesty-proposed) [3.20.2-1.1]
-queuebot:#ubuntu-release- Unapproved: accepted dovecot [source] (zesty-proposed) [1:2.2.27-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-terminal [source] (zesty-proposed) [3.20.2-1ubuntu8]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-builder [source] (zesty-proposed) [3.24.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted tomcat8 [source] (zesty-proposed) [8.0.38-2ubuntu2]
<mwhudson> slangasek, infinity: around?
-queuebot:#ubuntu-release- Unapproved: golang-1.8 (zesty-proposed/universe) [1.8-1ubuntu1 => 1.8.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted golang-1.8 [source] (zesty-proposed) [1.8.1-1ubuntu1]
<cyphermox> mwhudson: anything I can help with?
<mwhudson> cyphermox: wondering whether to upload the fix for https://bugs.launchpad.net/ubuntu/+source/golang-1.7/+bug/1681294 to zesty
<ubot5> Ubuntu bug 1681294 in golang-1.6 (Ubuntu Yakkety) "ugly "pthread_create failed: Resource temporarily unavailable" running snaps" [Undecided,In progress]
<mwhudson> i guess i can stick it in the queue and let the release team decide
<mwhudson> ... after checking that it won
<mwhudson> 't result in a transition
<mwhudson> (it really shouldn't)
<cyphermox> ah
<slangasek> mwhudson: hi
<mwhudson> well what the heck, it does cause a transition
<slangasek> mwhudson: libgolang-1.7-std1 is seeded on cloud-image and server, so this impacts release; it's fine to upload it, but I think we should punt this to SRU (and doubly so given the transition) <-- infinity
<mwhudson> i really need to look into making the go shared library abis more stable
<mwhudson> slangasek: fair enough
<mwhudson> argl bargl, the transition is because the change adds a new file to runtime/cgo
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Zesty Final] has been updated (20170411)
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Zesty Final] has been updated (20170411)
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Zesty Final] has been updated (20170411)
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Zesty Final] has been updated (20170411)
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Zesty Final] has been updated (20170411)
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Zesty Final] has been updated (20170411)
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Zesty Final] has been updated (20170411)
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Zesty Final] has been updated (20170411)
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Zesty Final] has been updated (20170411)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Zesty Final] has been updated (20170411)
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Zesty Final] has been updated (20170411)
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Zesty Final] has been updated (20170411)
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Zesty Final] has been updated (20170411)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Zesty Final] has been updated (20170411)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Zesty Final] has been updated (20170411)
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Zesty Final] has been updated (20170411)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Zesty Final] has been updated (20170411)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Zesty Final] has been updated (20170411)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Zesty Final] has been updated (20170411)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Zesty Final] has been updated (20170411)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Zesty Final] has been updated (20170411)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Zesty Final] has been updated (20170411)
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Zesty Final] has been updated (20170411)
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Zesty Final] has been updated (20170411)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Zesty Final] has been updated (20170411)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Zesty Final] has been updated (20170411)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Zesty Final] has been updated (20170411)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Zesty Final] has been updated (20170411)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Zesty Final] has been updated (20170411)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Zesty Final] has been updated (20170411)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Zesty Final] has been updated (20170411)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Zesty Final] has been updated (20170411)
-queuebot:#ubuntu-release- Unapproved: wxwidgets3.0 (zesty-proposed/universe) [3.0.2+dfsg-3 => 3.0.2+dfsg-4~build1] (edubuntu)
-queuebot:#ubuntu-release- Unapproved: poedit (zesty-proposed/universe) [2.0.1-1~exp1~build1 => 2.0.1-1~exp1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted poedit [sync] (zesty-proposed) [2.0.1-1~exp1]
<slangasek> infinity, jbicha: yeah, so the set_debconf_frontend() bits are implemented entirely in python (python3-aptdaemon + python3-debconf), that's going to take a bit of work to implement for gnome-software (but still should be done)
<slangasek> n/m there is no python3-debconf, just a debconf.py in python3-aptdaemon
<rbalint> Laney: lp:autopkgtest-cloud don't seem to be accessible fore mere mortals
<Laney> uh?
<rbalint> Laney: https://code.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud
<Laney> https://code.launchpad.net/autopkgtest-cloud ?
<Laney> we just changed it recently
<Laney> if you find a reference to that old one please fix it
<rbalint> Laney: thanks
<rbalint> Laney: i found it on launchpad search
<rbalint> Laney: not sure if i can fix that easily :-)
<rbalint> Laney: https://launchpad.net/+search?field.text=autopkgtest-cloud
<Laney> maybe I could push a readme.txt there
<Laney> can't hurt eh
<LocutusOfBorg> hello release team, can you please unblock wxwidgets3.0? a rationale is explained on debian bug #860074
<ubot5> Debian bug 860074 in release.debian.org "unblock: wxpython3.0/3.0.2.0+dfsg-4 wxwidgets3.0/3.0.2+dfsg-4" [Normal,Open] http://bugs.debian.org/860074
<LocutusOfBorg> I did upload wxpy3.0, but the patch was touching a wxwidgets embedded code copy (sigh)
<LocutusOfBorg> so, the real fix is to upload wxwidgets3.0, not wxpython
<LocutusOfBorg> I will sync them later today, making the ubuntu delta useless and disappear
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (yakkety-proposed) [231-9ubuntu4]
<rbalint> Laney: botch's autopkgtest result shows OOM and I'd like to set it to use m1.large instance
<rbalint> Laney: should i somehow verify that it fixes the OOM before filing a merge for autopkgtest-cloud?
<rbalint> Laney: it may fail on my small VM-s, too
<rbalint> rbalint: Laney i'll give it a try, but i'm interested in understanding the general process
<Laney> sure, try it
<LocutusOfBorg> apw, can you please unblock wxwidgets3.0? http://bugs.debian.org/860074 the fix on wxpython3.0 was touching embedded code copy of wx, not the real one :(
<ubot5> Debian bug 860074 in release.debian.org "unblock: wxpython3.0/3.0.2.0+dfsg-4 wxwidgets3.0/3.0.2+dfsg-4" [Normal,Open]
<LocutusOfBorg> I got two unblocks from release team in Debian
<LocutusOfBorg> (and I'll sync them from here by today)
<Laney> there's a --ram argument to autopkgtest-virt-qemu
<Laney> is it 'expected' to use that much? would be good to know
<LocutusOfBorg> can anybody please give me his opinion to a llvm-toolchain-4.0 sync?
<LocutusOfBorg> I'm worried about:   * change the min version of the libclang1 symbols to 1:4.0-3~
<LocutusOfBorg> this is because finally we are getting versioned symbols, but I dont' understand if a transition is needed or not
-queuebot:#ubuntu-release- Unapproved: mate-themes (zesty-proposed/universe) [3.22.8-0ubuntu1 => 3.22.10-0ubuntu1] (ubuntu-mate)
<Laney> flexiondotorg: you want to respin for that?
<flexiondotorg> Laney, no thanks. Just being there for an update on day 1 is fine.
<Laney> ok, then please put a bug number in the changelog :-)
<flexiondotorg> There are no Ubuntu bugs, it is general fixes from upstream.
-queuebot:#ubuntu-release- Unapproved: rejected mate-themes [source] (zesty-proposed) [3.22.10-0ubuntu1]
<Laney> right, but if it is to become an SRU it needs a bug
<apw> LocutusOfBorg, what is the impact of that wxwidgets thing, it looks like we respan after the previous attempt
<flexiondotorg> Laney OK, then can I respin? :-)
<Laney> filing a bug is that hard?
<infinity> wx* will cause a studio respin.
<infinity> LocutusOfBorg: We release in two days.  If you have any questions about an upload, the answer should be "no", and you shouldn't ask the question.
<infinity> LocutusOfBorg: As for wx*, it will cause a studio respin, which has no testing currently, so that's probably okay.  But if you were implying you wanted to sync them both at different times, uhm, do them both now? :P
<infinity> LocutusOfBorg: The llvm one should be a hard "no", unless it's actively buggy and causing issues right now.
<LocutusOfBorg> infinity, I just uploaded them in unstable
<LocutusOfBorg> just let lp catch them :)
<LocutusOfBorg> infinity, for llvm-4.0 the answer is no also on my side, but I wanted to understand if a transition is required when symbols versions are bumped
<infinity> If it is, symbols aren't versioned very well. :P
<LocutusOfBorg> infinity, the problem is that various llvm-* implementations are using the same symbols, so people complains about crashes when different llvm are used at runtime
<LocutusOfBorg> something like that
-queuebot:#ubuntu-release- Unapproved: accepted golang-1.6 [source] (yakkety-proposed) [1.6.3-1ubuntu1.1]
<LocutusOfBorg> anyway, I'll sync wx* in some hours, hopefully after britney run
<infinity> I'll probably fakesync it now, if you really want it.
<LocutusOfBorg> yes please if you can
<infinity> At this point in the release, waiitng is not an option.
<LocutusOfBorg> it is an important assert fix, various crashes because of that mutex issue
<LocutusOfBorg> accepted by upstream and cherry-picked on stable branch 3.0
<LocutusOfBorg> I really trust poedit upstream developer and his work
<Ukikie> infinity: I don't suppose you'd accept ms-gsl? :P
<LocutusOfBorg> I would accept it, leaf package and hurray for new telegram-desktop not crashing anymore!
-queuebot:#ubuntu-release- Unapproved: wxpython3.0 (zesty-proposed/universe) [3.0.2.0+dfsg-3ubuntu1 => 3.0.2.0+dfsg-4] (edubuntu)
-queuebot:#ubuntu-release- Unapproved: wxwidgets3.0 (zesty-proposed/universe) [3.0.2+dfsg-3 => 3.0.2+dfsg-4] (edubuntu)
-queuebot:#ubuntu-release- New: accepted ms-gsl [sync] (zesty-proposed) [0~git20170403.ebab8ca-1]
-queuebot:#ubuntu-release- Unapproved: rejected wxwidgets3.0 [source] (zesty-proposed) [3.0.2+dfsg-4~build1]
<infinity> Ukikie: /win 77
<Ukikie> OK, you win.
-queuebot:#ubuntu-release- Unapproved: accepted wxpython3.0 [source] (zesty-proposed) [3.0.2.0+dfsg-4]
-queuebot:#ubuntu-release- Unapproved: accepted wxwidgets3.0 [source] (zesty-proposed) [3.0.2+dfsg-4]
-queuebot:#ubuntu-release- New binary: ms-gsl [amd64] (zesty-proposed/universe) [0~git20170403.ebab8ca-1] (no packageset)
<rbalint> infinity: i have added botch to big packages: lp:~rbalint/autopkgtest-cloud
<rbalint> infinity: could you please merge?
<rbalint> infinity: hm, it seems i have to add it to multiple lists, please hold on
<apw> rbalint, yeah there are 3 or 4
-queuebot:#ubuntu-release- Unapproved: r-cran-fields (zesty-proposed/universe) [8.10-1 => 8.10-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-fields [source] (zesty-proposed) [8.10-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: stress-ng (zesty-proposed/universe) [0.07.28-1 => 0.07.28-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted stress-ng [source] (zesty-proposed) [0.07.28-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted ms-gsl [amd64] (zesty-proposed) [0~git20170403.ebab8ca-1]
-queuebot:#ubuntu-release- Unapproved: telegram-desktop (zesty-proposed/universe) [1.0.14-1ubuntu1 => 1.0.29-1] (no packageset) (sync)
<infinity> flexiondotorg: I'll take care of that respin for you when the archive is in the correct state.
-queuebot:#ubuntu-release- Unapproved: accepted telegram-desktop [sync] (zesty-proposed) [1.0.29-1]
<davmor2> infinity, cyphermox: so other than the old issue that I added a work around for in the bug (be good to get it in the release notes) most of the installs are going without a hitch
<infinity> davmor2: The old issue being the lack of "remove CD and press enter" prompt?
<infinity> We've only fixed that about 17 times.
<infinity> It's a horrible hack.
<davmor2> infinity: yeap it's a pain cause cyphermox can't reproduce it but it happens here on multiple machines but it's only a case of hitting the power button
<apw> davmor2, it doesn't respond to return even so ?
<davmor2> apw: it does for some but not for all
<davmor2> apw: on the dell xps13 the cursor just moves down a line but you can't type anything into it
<apw> such dodgy code, we should make a ramfs with the shutdown code in it, and chroot there really
<infinity> apw: Yes, I was thinking the same thing, but I didn't want to say it out loud, because then Lennart wins.
<apw> infinity, he has to be right now and again even if it is luck
<infinity> apw: But I don't have to be happy about it.
<davmor2> swing the bat often enough at some point you'll hit the pinata
<infinity> davmor2: And the moral of this story is "CANDY!!"?
<davmor2> infinity: always candy
-queuebot:#ubuntu-release- Unapproved: r-cran-adegraphics (zesty-proposed/universe) [1.0-6-1 => 1.0-6-1ubuntu1] (no packageset)
<smb> Am I thinking correctly that the empty download for "Ubuntu Server armhf+raspi2" should be http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/current/zesty-preinstalled-server-armhf+raspi2.img.xz
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-adegraphics [source] (zesty-proposed) [1.0-6-1ubuntu1]
<smb> ^ that is in the tracker
<Laney> smb: Yeah I added it, thx for noticing
<smb> Laney, cool, then I also grabbed the right one
-queuebot:#ubuntu-release- Unapproved: tome (zesty-proposed/multiverse) [2.4~0.git.2015.12.29-1.1ubuntu1 => 2.4~0.git.2015.12.29-1.1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted tome [source] (zesty-proposed) [2.4~0.git.2015.12.29-1.1ubuntu2]
<flexiondotorg> Laney Sorry, I was in meetings and my bouncer crashed so I've missed some scrollback.
<Laney> No worries hombre
<Laney> it's gone in now
<flexiondotorg> Ah, well thanks :-)
<infinity> flexiondotorg: I'll be respinning for you shortly.
<infinity> flexiondotorg: Waiting on some archive settle.
<flexiondotorg> infinity Thanks.
<flexiondotorg> infinity Are you in London now?
<infinity> flexiondotorg: Ate.
<infinity> flexiondotorg: Also aye.
<Laney> Ale
-queuebot:#ubuntu-release- Unapproved: r-cran-sp (zesty-proposed/universe) [1:1.2-4-1 => 1:1.2-4-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-sp [source] (zesty-proposed) [1:1.2-4-1ubuntu1]
<flexiondotorg> Laney infinity I'll be in the office on Thursday. Beers on me.
-queuebot:#ubuntu-release- Unapproved: pbh5tools (zesty-proposed/universe) [0.8.0+dfsg-5 => 0.8.0+dfsg-5build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pbh5tools [source] (zesty-proposed) [0.8.0+dfsg-5build1]
-queuebot:#ubuntu-release- Unapproved: garmin-plugin (zesty-proposed/universe) [0.3.23-4 => 0.3.23-4ubuntu1] (no packageset)
<apw> infinity, want that reviewed ?
-queuebot:#ubuntu-release- Unapproved: accepted garmin-plugin [source] (zesty-proposed) [0.3.23-4ubuntu1]
<infinity> apw: It reviewed itself.
<apw> oh heh, so it did, back in my box
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Zesty Final] has been updated (20170411.1)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Zesty Final] has been updated (20170411.1)
-queuebot:#ubuntu-release- Unapproved: ubuntu-location-provider-here (zesty-proposed/universe) [0.1+15.10.20150601.3-0ubuntu1 => 0.1+15.10.20150601.3-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-location-provider-here [source] (zesty-proposed) [0.1+15.10.20150601.3-0ubuntu2]
<davmor2> infinity: there isn't gonna be another respin for ubuntu is there?  AMD64 is done moving onto I386
<infinity> davmor2: It's only Tuesday, so dunno.
<infinity> davmor2: But I have no respins planned.
 * davmor2 hugs infinity just leave like that ;)
<apw> infinity, we have some kernels pending in stables for publishing to proposed, are you happy for those to hit with the associated pu
<apw> pu
<apw> publisher gummage ?
<infinity> apw: Better now than later.
<apw> infinity, ack
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.23.6 => 2.24] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.23.6+16.10 => 2.24+16.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (zesty-proposed/main) [2.23.6+17.04.1 => 2.24+17.04] (desktop-core, ubuntu-server)
<cyphermox> davmor2: I managed to reproduce it after all, but I still have no idea why it works on the live session and breaks otherwise
<cyphermox> well, I have an idea why, but still not sure how.
<davmor2> cyphermox: works on manual keep home too :)
<cyphermox> I'm talking about the shutdown promot.
<cyphermox> *prompt.
<davmor2> cyphermox: yeap
<cyphermox> hrm
<davmor2> cyphermox: do a manual install and then do a manual install keeping home over that and the popup appears too
<apw> infinity, i'll look at those snapd uploads
<davmor2> cyphermox: so litterally just fresh install nothing kept
<cyphermox> ok, so in only-ubiquity you do an install with keeping home and that works?
-queuebot:#ubuntu-release- Unapproved: r-cran-xml2 (zesty-proposed/universe) [1.1.0-1 => 1.1.0-1ubuntu1] (no packageset)
<cyphermox> the only thing that could be is systemd blocking waiting for stuff to be unmounted
<cyphermox> I'll keep looking then, that might be easy to fix.
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-xml2 [source] (zesty-proposed) [1.1.0-1ubuntu1]
<davmor2> cyphermox: so everything oem-mode, fresh install, overwrite install, auto-resize and manual install (normal) all had no prompt, manual reuse home and install from desktop both did
<infinity> davmor2: How much RAM does your VM have?
<infinity> I *think* the common thread in those successes is that both probably had swap active.
<infinity> Maybe.
<davmor2> infinity: hardware 4gig
<infinity> 4G should be more than enough for our stupid caching tricks, though. :P
<davmor2> infinity: and hardware 8gig
<cyphermox> yep, it should
<davmor2> infinity: the 8GB on the xps13 should be more than enough
<cyphermox> I'd be surprised if you need much more than 100Mb.
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.23.1~14.04 => 2.24~14.04] (no packageset)
<davmor2> infinity: I get a crash on unity date-time indicator on i386 I'll try another install and see if it happens again and double check my iso versions
<davmor2> infinity: it's still a revision behind D'oh only looked at the amd64 this morning as that was where I was starting updating now and I'll try again
<infinity> davmor2: The indicator hasn't changed, so I assume the segv also hasn't. :P
<davmor2> infinity: I'll find out in a minute
<infinity> davmor2: Is there a bug for that?  I don't see anything on the tracker.
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Zesty Final] has been updated (20170411.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Zesty Final] has been updated (20170411.1)
<davmor2> infinity: I sent the crash file but after checking my md5sum I noticed the numbers didn't match so stopped looking at it then.  If I get it on this install too I'll be sure it is filed and added to the tracker
-queuebot:#ubuntu-release- Unapproved: gcc-6-cross (zesty-proposed/main) [19ubuntu1 => 21ubuntu1] (ubuntu-desktop)
<smoser> bdmurray, it would not be strictly necessary, but it went in first. and then the user contributed a fix to support either.
-queuebot:#ubuntu-release- Unapproved: gcc-6-cross-ports (zesty-proposed/main) [17ubuntu1 => 19ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-6-cross-ports [source] (zesty-proposed) [19ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-6-cross [source] (zesty-proposed) [21ubuntu1]
<davmor3> infinity: still crashing https://errors.ubuntu.com/oops/280c3984-1ec0-11e7-990e-fa163ed44aae trying to figure out why it isn't reporting a bug and only sending to errors
<Laney> davmor has incremented
-queuebot:#ubuntu-release- Unapproved: libhmsbeagle (zesty-proposed/universe) [2.1.2+20160831-5 => 2.1.2+20160831-5ubuntu1] (no packageset)
<Laney> apport bug reporting gets disabled for the release
-queuebot:#ubuntu-release- Unapproved: accepted libhmsbeagle [source] (zesty-proposed) [2.1.2+20160831-5ubuntu1]
<davmor3> Laney: nope it looks to be enabled but it isn't when I manually trigger ubuntu-bug either
<rbalint> could someone please review LP: #1680577 ?
<ubot5> Launchpad bug 1680577 in autopkgtest (Ubuntu) "Autopkgtest fails on s390x due to long PATH in test config" [Undecided,In progress] https://launchpad.net/bugs/1680577
<Laney> rbalint: Please file it in Debian and get it fixed there
<Laney> I hope that other one bit of delta forwarded too
<Laney> was
<Laney> english good
<rbalint> Laney: i hoped to get it fixed here first to let tests pass before the release, but ok
<infinity> davmor3: Is that only on i386?
<davmor3> infinity: yeap
<infinity> Failed to retrace.  Helpful.
<infinity> doko: Your gcc-5-cross has been FTBFS for a month too.
<infinity> doko: Or gcc-5-cross-ports, I guess.
-queuebot:#ubuntu-release- Unapproved: kamoso (zesty-proposed/universe) [3.0.0-0ubuntu1 => 3.2.1-1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted kamoso [sync] (zesty-proposed) [3.2.1-1]
<doko> infinity: I'll have a look tomorrow, or today
-queuebot:#ubuntu-release- Unapproved: cinder (zesty-proposed/main) [2:10.0.0-0ubuntu2 => 2:10.0.1-0ubuntu1] (openstack, ubuntu-server)
<bdmurray> davmor2: Do you still have the .crash file? I could manually retrace it.
<davmor2> infinity, bdmurray: see pm  desktop is currently having the popup I can hit the button to report it if you want
-queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (zesty-proposed) [2:10.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: youker-assistant (zesty-proposed/universe) [2.2.7-0ubuntu1 => 2.2.7-0ubuntu2] (ubuntukylin)
<davmor2> infinity, bdmurray, Laney: https://bugs.launchpad.net/ubuntu/+source/indicator-datetime/+bug/1681870
<ubot5> Error: ubuntu bug 1681870 not found
-queuebot:#ubuntu-release- Unapproved: accepted youker-assistant [source] (zesty-proposed) [2.2.7-0ubuntu2]
<davmor2> infinity, bdmurray, Laney: https://bugs.launchpad.net/ubuntu/+source/indicator-datetime/+bug/1681870
<Laney> thx
<davmor2> should be public now
<davmor2> advantage of a machine here have ssh access :D
-queuebot:#ubuntu-release- Unapproved: gnome-music (zesty-proposed/universe) [3.24.0-0ubuntu1 => 3.24.1.1-0ubuntu1] (desktop-extra, ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: phyml (zesty-proposed/universe) [3:3.2.0+dfsg-7 => 3:3.2.0+dfsg-7ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted phyml [source] (zesty-proposed) [3:3.2.0+dfsg-7ubuntu1]
<bdmurray> I was able to manually retrace the indicator-datetime crash if the LP retracers fail
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (zesty-proposed/partner) [1:20170314.1-0ubuntu1 => 1:20170411.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: r-cran-rcppgsl (zesty-proposed/universe) [0.3.1-1 => 0.3.2-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-rcppgsl [sync] (zesty-proposed) [0.3.2-2]
<bdmurray> Great, why did it fail to retrace.
<davmor2> bdmurray: it hates me
<bdmurray> I'm sure the hate for me is stronger.
<infinity> jbicha: gnome-music is on your images.  Did you want to accept that and respin for it?
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (zesty-proposed) [1:20170411.1-0ubuntu1]
<jbicha> infinity: is it ok if you accepted it into proposed for 0-day SRU and we can promote it if there's a need for respin?
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (precise-proposed/partner) [1:20170314.1-0ubuntu0.12.04.1 => 1:20170411.1-0ubuntu0.12.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20170314.1-0ubuntu0.16.04.1 => 1:20170411.1-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (trusty-proposed/partner) [1:20170314.1-0ubuntu0.14.04.1 => 1:20170411.1-0ubuntu0.14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (yakkety-proposed/partner) [1:20170314.1-0ubuntu0.16.10.1 => 1:20170411.1-0ubuntu0.16.10.1] (no packageset)
<infinity> jbicha: Sure.
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (yakkety-proposed) [1:20170411.1-0ubuntu0.16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-music [source] (zesty-proposed) [3.24.1.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (trusty-proposed) [1:20170411.1-0ubuntu0.14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20170411.1-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (precise-proposed) [1:20170411.1-0ubuntu0.12.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (zesty-proposed) [2.24+17.04]
<bdmurray> Okay, bug 1681870 has been retraced
<ubot5> bug 1681870 in indicator-datetime (Ubuntu) "indicator-datetime-service crashed with SIGABRT in __malloc_assert()" [Medium,New] https://launchpad.net/bugs/1681870
<davmor2> woohoo
<bdmurray> infinity: I noticed u-r-u has been uploaded in months. I think I should do another upload to get new mirrors / promotions & demotions.
<infinity> bdmurray: That'll trigger a world respin.  But yeah, perhaps you should lob it at the queue, and we'll pull it in if we have a critical mass of things that seem worth respinning for.
<bdmurray> infinity: it'd be fine to do it as a 0-day SRU
<infinity> bdmurray: Yeah, but upload early, and we can make the call.
<bdmurray> infinity: okay, working on it
-queuebot:#ubuntu-release- Unapproved: r-cran-rcppgsl (zesty-proposed/universe) [0.3.2-2 => 0.3.2-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-rcppgsl [source] (zesty-proposed) [0.3.2-2ubuntu1]
<davmor2> bdmurray: I can drop the link to the machine now then right?
<bdmurray> davmor2: let me double check one thing
<bdmurray> davmor2: yes, thanks again
<davmor2> bdmurray: no worries
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-73.94~14.04.1] (kernel)
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (zesty-proposed/main) [1:17.04.6 => 1:17.04.7] (core)
<Laney> 'k, we know how to fix that and we'll upload
<davmor2> Laney: woohoo that'll need a respin for i386 right infinity
<Laney> davmor2: 64 too, to keep it in sync
<Laney> & kylin
<Laney> & Adam's talking about maybe doing one for snapd which will be everything, but not sure yet
<davmor2> woohoo retesting the world
<Laney> moar testing is moar fun
<infinity> It's only Tuesday, if we weren't respinning, it would feel weird.
<davmor2> infinity: no really
<cyphermox> don't worry
<cyphermox> I'm testing ppc64el server right now and I can't complete the install.
<cyphermox> just making sure with mini; but it looks like something grub-installer :(
<cyphermox> only on multipath?
-queuebot:#ubuntu-release- Unapproved: qtcreator (zesty-proposed/universe) [4.1.0-3ubuntu1~2 => 4.1.0-3ubuntu1] (qt5)
<tsimonq2> infinity: How does one even start to debug this? https://lists.ubuntu.com/archives/kubuntu-devel/2017-April/011186.html
<tsimonq2> CC cyphermox ^
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (zesty-proposed) [1:17.04.7]
-queuebot:#ubuntu-release- Unapproved: accepted qtcreator [source] (zesty-proposed) [4.1.0-3ubuntu1]
<cyphermox> strace?
<infinity> tsimonq2: Fun.  I use wine daily, and have no such issues.
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-73.94~14.04.1]
<tsimonq2> infinity: Wwweeeiiirrrddd.
-queuebot:#ubuntu-release- Unapproved: ostree (zesty-proposed/universe) [2016.15-3ubuntu2 => 2016.15-3ubuntu3] (ubuntugnome)
<tsimonq2> cyphermox: It was kind of rhetorical, but ok. :P
<cyphermox> you don't have much option but to take the big guns to debug this
<tsimonq2> valorie: Can you reproduce this? Is it even worth looking in to?
-queuebot:#ubuntu-release- Unapproved: accepted ostree [source] (zesty-proposed) [2016.15-3ubuntu3]
-queuebot:#ubuntu-release- Unapproved: content-hub (zesty-proposed/main) [0.3+17.04.20170403-0ubuntu1 => 0.3+17.04.20170403-0ubuntu2] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: indicator-transfer (zesty-proposed/main) [0.2+17.04.20170215-0ubuntu1 => 0.2+17.04.20170215-0ubuntu2] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: pay-service (zesty-proposed/universe) [15.10+17.04.20170211-0ubuntu1 => 15.10+17.04.20170211-0ubuntu2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: qtmir (zesty-proposed/main) [0.5.1+17.04.20170404-0ubuntu1 => 0.5.1+17.04.20170404-0ubuntu2] (ubuntu-desktop, ubuntu-qt-packages) (sync)
-queuebot:#ubuntu-release- Unapproved: indicator-datetime (zesty-proposed/main) [15.10+17.04.20170322-0ubuntu1 => 15.10+17.04.20170322-0ubuntu2] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: qtmir-gles (zesty-proposed/universe) [0.5.1+17.04.20170404-0ubuntu1 => 0.5.1+17.04.20170404-0ubuntu2] (ubuntu-qt-packages) (sync)
-queuebot:#ubuntu-release- Unapproved: libertine-scope (zesty-proposed/universe) [1.3.2+17.04.20170228-0ubuntu1 => 1.3.2+17.04.20170228-0ubuntu2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-app-launch (zesty-proposed/main) [0.12+17.04.20170404.2-0ubuntu1 => 0.12+17.04.20170404.2-0ubuntu2] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-system-settings-online-accounts (zesty-proposed/main) [0.7+17.04.20170308.2-0ubuntu2 => 0.7+17.04.20170308.2-0ubuntu3] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: url-dispatcher (zesty-proposed/main) [0.1+17.04.20170328-0ubuntu1 => 0.1+17.04.20170328-0ubuntu2] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-push (zesty-proposed/universe) [0.68+17.04.20170211-0ubuntu1 => 0.68+17.04.20170211-0ubuntu2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: unity8 (zesty-proposed/main) [8.15+17.04.20170404.7-0ubuntu2 => 8.15+17.04.20170404.7-0ubuntu3] (ubuntu-desktop, ubuntu-qt-packages) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libertine-scope [sync] (zesty-proposed) [1.3.2+17.04.20170228-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-push [sync] (zesty-proposed) [0.68+17.04.20170211-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted pay-service [sync] (zesty-proposed) [15.10+17.04.20170211-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted content-hub [sync] (zesty-proposed) [0.3+17.04.20170403-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted indicator-transfer [sync] (zesty-proposed) [0.2+17.04.20170215-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted qtmir [sync] (zesty-proposed) [0.5.1+17.04.20170404-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-system-settings-online-accounts [sync] (zesty-proposed) [0.7+17.04.20170308.2-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted url-dispatcher [sync] (zesty-proposed) [0.1+17.04.20170328-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted indicator-datetime [sync] (zesty-proposed) [15.10+17.04.20170322-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-app-launch [sync] (zesty-proposed) [0.12+17.04.20170404.2-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted qtmir-gles [sync] (zesty-proposed) [0.5.1+17.04.20170404-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted unity8 [sync] (zesty-proposed) [8.15+17.04.20170404.7-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: flashplugin-nonfree (zesty-proposed/multiverse) [25.0.0.127ubuntu1 => 25.0.0.148ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted flashplugin-nonfree [source] (zesty-proposed) [25.0.0.148ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-caffeine (zesty-proposed/universe) [0~git20161228-1ubuntu1 => 0~git20161228-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gnome-user-docs (zesty-proposed/universe) [3.22.0-1 => 3.24.0-0ubuntu1] (ubuntu-desktop)
<jbicha> fossfreedom: do you have an opinion on LP: #1681896 ?
<ubot5> Launchpad bug 1681896 in gnome-user-docs (Ubuntu) "Update gnome-user-docs to 3.24.0" [Low,In progress] https://launchpad.net/bugs/1681896
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-caffeine [source] (zesty-proposed) [0~git20161228-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: eog-plugins (zesty-proposed/universe) [3.16.5-1 => 3.16.6-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted eog-plugins [source] (zesty-proposed) [3.16.6-0ubuntu1]
<fossfreedom> jbicha: not really important enough to respin imho
<jbicha> fossfreedom: I get the feeling they are respinning anyway, are you ok with that update landing in 17.04?
<fossfreedom> sure.  why the respin?  this mornings respin is working well.
<cyphermox> jbicha: including a new version of docs?
<jbicha> cyphermox: yes, do you disagree with that?
<cyphermox> my personal opinion is that it's quite late for that, but I'm not in the release team, and this doesn't break translations if it's indeed directly translated in the package
<cyphermox> ie. not my decision.
<jbicha> well it does break its own translations which I don't like but I'm not sure the existing pkg is that much better
<cyphermox> I'm just expressing doubt while I try to fix things
<jbicha> I'm fine with the Release Team deciding either way
<jbicha> I think GNOME's so desperate for docs contributors that they don't want to discourage them with inconveniences like string freezes
<cyphermox> jbicha: we have those "inconveniences" for a reason though
<jbicha> of course, and someone should encourage GNOME to have a docs string freeze too
<cyphermox> well, it doesn't need to be up to GNOME necessarily, you don't need to be precisely in sync with every new release
<jbicha> yes, I am ok with the Release Team saying no on this update
<cyphermox> I got you; I'm not saying one way or another. if it was up to me; I'd say okay, but let's try to avoid very late uploads
<cyphermox> jbicha: back when I was in desktop; we used http://people.canonical.com/~platform/desktop/versions.html to track things, not all was up to date with the latest gnome
<cyphermox> jbicha: aren't you a release manager for ubuntu-gnome?
<jbicha> yes
<cyphermox> AIUI part of it comes up to you, if you think this is worth respinning and re-testing.
<slashd> For SRU, LP #1317491 has landed in -proposed on "2017-02-22" and has been tag "verification done" the following day "2017-02-23", and the package is languishing in -proposed since then "libvirt | 1.2.2-0ubuntu13.1.20 | trusty-proposed". Could someone please have a look this bug and let tinoco and I (slashd) know the outcome ?
<ubot5> Launchpad bug 1317491 in libvirt (Ubuntu Trusty) "virsh blockcommit hangs at 100%" [Medium,Fix committed] https://launchpad.net/bugs/1317491
<nacc> slashd: http://people.canonical.com/~ubuntu-archive/pending-sru.html shows non-green bugs
<nacc> slashd: meaning some are not marked v-d
<nacc> tinoco: --^
<tinoco> nacc: mine is green
<tinoco> the other is won't fix
<nacc> tinoco: there are three bugs listed
<tinoco> nacc: 2 wont fix and mine, green
<nacc> ah that might need a special sru reminder, i'm not sure
<nacc> rbasak: --^ ?
<rbasak> Yeah if pending-sru doesn't show all green, ~ubuntu-sru will generally ignore it and will need a special prod.
 * rbasak looks
<nacc> won't fix seems like it should be struck-through or something on the pending-sru page (or there shouldn't be a task for trusty at all)
<nacc> it seems odd
<rbasak> Yeah
<rbasak> The report could do with that fixing.
<rbasak> Launchpad-Bugs-Fixed: 1317491
<rbasak> So I'm not sure why the other bugs appear anyway
<nacc> i see it's a jump of several versions, is it possible that one of the older versions fixes them (18 or 19)?
-queuebot:#ubuntu-release- Unapproved: gajim-omemo (zesty-proposed/universe) [1.0.0-1 => 1.0.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gajim-omemo [sync] (zesty-proposed) [1.0.0-2]
<slashd> rbsak, 1483071 used to have a libvirt pkg in -proposed, and then has been tag to won't fix, maybe this is the reason ?
<slashd> rbasak ^
<slashd> but a year ago
<slashd> https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1483071/comments/37
<ubot5> Ubuntu bug 1483071 in libvirt (Ubuntu) "Error creating new VM with OVMF" [High,Fix released]
<slashd> https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1483071/comments/39
<rbasak> I'm not sure where the report gets the bug references from. I thought it was from the corresponding changes file only.
-queuebot:#ubuntu-release- Unapproved: fgrun (zesty-proposed/universe) [3.4.0.final-3 => 2016.4.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted fgrun [sync] (zesty-proposed) [2016.4.0-1]
<rbasak> slashd, tinoco: released to trusty-updates. I see there's a separate libvirt SRU that may be ready in yakkety-proposed. I'll look at that tomorrow (it's my SRU day tomorrow).
<tinoco> rbasak: tku very much Robie.
<slashd> rbasak thank you very much, I appreciate it
<tinoco> rbasak: this shall me fast for you (its a small one)
<tinoco> analysis was way bigger then the fix itself
-queuebot:#ubuntu-release- Unapproved: sleekxmpp (zesty-proposed/universe) [1.3.1-5 => 1.3.1-6] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted sleekxmpp [sync] (zesty-proposed) [1.3.1-6]
-queuebot:#ubuntu-release- Unapproved: grub-installer (zesty-proposed/main) [1.128ubuntu7 => 1.128ubuntu8] (core)
<cyphermox> infinity: grub-installer fix for ppc64el multipath installs ^^
<cyphermox> jbicha: so; now that this is in the queue, I'm going to have another look at the bugs in iso.qa.u.c, and I'll spend a bit of time to check out gdm3/shell again
<cyphermox> is there something in particular you'd want me to try?
<cyphermox> I would possibly make a new install with the daily too.
<jbicha> at least for the GNOME release notes, it would be interesting to know if Radeon broke with gdm3 from 16.10 to 17.04
<cyphermox> mine is not radeon
<cyphermox> well
<cyphermox> not *only&
<cyphermox> I have two systems affected, one of which is intel graphics.
<cyphermox> the other is indeed radeon, but I'd rather not reinstall that now
<cyphermox> I need to keep at least one untouched system to do work :)
<jbicha> oh, Intel only is broken for you? when was the last time you tried gdm with it?
<cyphermox> not only for me; I think Beret also has the same issue
<cyphermox> Beret: can you comment on the last time you tried gdm, was that today and/or the most recent version in zesty?
<cyphermox> jbicha: I'll do the test here *now*
<jbicha> I'm sadly not a graphics guy, so the most I'll probably be able to do is ask you to file a bug and work with GNOME or Ubuntu's driver maintainers about the issues
-queuebot:#ubuntu-release- Unapproved: apparmor (zesty-proposed/main) [2.11.0-2ubuntu3 => 2.11.0-2ubuntu4] (core)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-user-docs [source] (zesty-proposed) [3.24.0-0ubuntu1]
<cyphermox> jbicha: yeah, I fear it's a graphics driver issue, but the fact that it works in unity and not gnome looks suspect
<cyphermox> (I know, it's not quite the same bits)
-queuebot:#ubuntu-release- Unapproved: accepted apparmor [source] (zesty-proposed) [2.11.0-2ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted grub-installer [source] (zesty-proposed) [1.128ubuntu8]
<cyphermox> possible slideshow update coming up from xubuntu...
<tsimonq2> barry: I'm literally having the exact same problem with systemd-resolved as I did before.
<tsimonq2> barry: I can't tell if this is a regression or an error on my part...
<cyphermox> tsimonq2: REFUSED responses?
<cyphermox> err, I mean, fails to resolve some things, and succeeds at others?
<tsimonq2> mmm let me reboot quick, I needed to access email etc. so I just overwrote my /etc/resolv.conf quick, rebooting restores it
<tsimonq2> Be back on my phone in a min or so
<cyphermox> tsimonq2: or point me to a bug so I can look tonight
<cyphermox> I need to quickly go take a shower so when my wife gets home I don't look like I'm some homeless person squatting the house :)
<flocculant> lmao
<tsimonq2> lol
<tsimonq2> cyphermox: Yep, can't ping Google but I can ping 8.8.8.8
 * tsimonq2 pokes around a bit
<tsimonq2> Yep, got nothing.
 * tsimonq2 finds a bug report
<tsimonq2> cyphermox: bug 1647031
<ubot5> bug 1647031 in systemd "systemd-resolvedâs 127.0.0.53 server does not follow CNAME records" [Unknown,New] https://launchpad.net/bugs/1647031
<tsimonq2> cyphermox: And I *do* have libnss-resolve installed.
<Beret> cyphermox, today
<tsimonq2> cyphermox: FWIW I have systemd 232-21ubuntu2 on my system.
<cyphermox> ok
<cyphermox> tsimonq2: let's move debugging this to #ubuntu-devel
<cyphermox> jbicha: ^^
<cyphermox> (I mean, Beret's tried gdm3 today, fails in a similar way than my system)
-queuebot:#ubuntu-release- Unapproved: update-manager (yakkety-proposed/main) [1:16.10.9 => 1:16.10.10] (core)
<tjaalton> arges: hi, I'm not able to build a vlc for yakkety which does not have that silly ffmpeg "diff". pull-lp-source pulls two ffmpeg tarballs as you can see, but for some reason extracting 0.16.10.1 doesn't extract the newer ffmpeg, but creating a new version does include it in .dsc..
<tjaalton> hm no
<tjaalton> where did that come from..
<tjaalton> extracting a pkg from a remote path copies the tarballs.. weird
<tjaalton> ok, problem solved then :)
<tjaalton> caused by having the tarballs for zesty in the same path when I originally created these..
-queuebot:#ubuntu-release- Unapproved: vlc (yakkety-proposed/universe) [2.2.4-4ubuntu0.16.10.1 => 2.2.4-4ubuntu0.16.10.2] (mozilla, mythbuntu)
-queuebot:#ubuntu-release- Unapproved: python-pbcore (zesty-proposed/universe) [1.2.11+dfsg-1 => 1.2.11+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-pbcore [source] (zesty-proposed) [1.2.11+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ubiquity-slideshow-ubuntu (zesty-proposed/main) [124 => 125] (kubuntu, ubuntu-desktop)
#ubuntu-release 2017-04-12
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity-slideshow-ubuntu [source] (zesty-proposed) [125]
-queuebot:#ubuntu-release- Unapproved: golang-1.6 (xenial-proposed/main) [1.6.2-0ubuntu5~16.04 => 1.6.2-0ubuntu5~16.04.2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: golang-1.6 (yakkety-proposed/main) [1.6.3-1ubuntu1.1 => 1.6.3-1ubuntu1.2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Zesty Final] has been updated (20170412)
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Zesty Final] has been updated (20170412)
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Zesty Final] has been updated (20170412)
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Zesty Final] has been updated (20170412)
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Zesty Final] has been updated (20170412)
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Zesty Final] has been updated (20170412)
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Zesty Final] has been updated (20170412)
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Zesty Final] has been updated (20170412)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Zesty Final] has been updated (20170412)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Zesty Final] has been updated (20170412)
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Zesty Final] has been updated (20170412)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Zesty Final] has been updated (20170412)
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Zesty Final] has been updated (20170412)
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Zesty Final] has been updated (20170412)
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Zesty Final] has been updated (20170412)
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Zesty Final] has been updated (20170412)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Zesty Final] has been updated (20170412)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Zesty Final] has been updated (20170412)
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Zesty Final] has been updated (20170412)
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Zesty Final] has been updated (20170412)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Zesty Final] has been updated (20170412)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Zesty Final] has been updated (20170412)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Zesty Final] has been updated (20170412)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Zesty Final] has been updated (20170412)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Zesty Final] has been updated (20170412)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Zesty Final] has been updated (20170412)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Zesty Final] has been updated (20170412)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Zesty Final] has been updated (20170412)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Zesty Final] has been updated (20170412)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Zesty Final] has been updated (20170412)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Zesty Final] has been updated (20170412)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Zesty Final] has been updated (20170412)
-queuebot:#ubuntu-release- Unapproved: gnss-sdr (zesty-proposed/universe) [0.0.9-3 => 0.0.9-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnss-sdr [sync] (zesty-proposed) [0.0.9-4]
<ginggs> morning! would someone please 'force-badtest roary/all/armhf roary/all/s390x'  ?  it depends on bedtools, which is no longer built on those architectures
<ginggs> also 'force-badtest pbgenomicconsensus/all/i386' - it depends on python-pbcore, which in turn depends on python-pysam which is no longer built there
<rbalint> can i do something to lp:~rbalint/autopkgtest-cloud to get it merged? it unblocks mathicgb and botch to get in zesty
<apw> rbalint, looking
<apw> rbalint, have you proposed it for merging ?
<apw> rbalint, and if so could you send me the url for the merge-request
<rbalint> apw: thanks, i proposed now https://code.launchpad.net/~rbalint/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/322430
<davmor2> Morning guys
<sil2100> Morning
<davmor2> sil2100, infinity: did everything that needed to land land and everything respin?
<sil2100> davmor2: I think yes, Adam's not around here yet - he might now more in case he encountered something after work hours
<infinity> davmor2: Barring install/boot critical bugs, I'm considering the current set final.
<infinity> davmor2: So, find those critical bugs. :P
<infinity> (Or, alternately, find that we don't have any?)
<sil2100> I opt for not finding any
<davmor2> sil2100: man it's me you know I'm gonna break it ;)
<sil2100> Test with you eyes closed!
<rbasak> [SRU] could someone glance at bug 1506427 please? I'm not sure how it ended up in trusty-proposed. I see no message about it (plus it doesn't appear to have been verified in trusty, but that's a separate matter)
<ubot5> bug 1506427 in ido (Ubuntu Yakkety) "Using calendar with keys might cause Indicator-datetime to crash unity-panel-service" [Medium,Fix released] https://launchpad.net/bugs/1506427
<davmor2> sil2100: I do how else do you expect me to test screenreader
<davmor2> infinity: I'll start with one test of each today rather than concentrating on one I think
<infinity> rbasak: sru-review/sru-accept won't comment if there's no bug task, and the trusty task was nominated but never accepted.
 * infinity fixes that.
<rbasak> Hmm
<rbasak> I thought it would sort out the bug task automatically. Thanks.
<davmor2> infinity, Laney: can one of you fire up i386 ab320064e2a11bbec19000c122886641 *zesty-desktop-i386.iso in live session I still have the crashed date-time indicator
<sil2100> davmor2: on the final images? Could you check what version of indicator-datetime you have?
<davmor2> sil2100: indicator-datetime 15.10+17.04.20170322-0ubuntu1
<sil2100> davmor2: uh, that looks old
<sil2100> davmor2: you should have 15.10+17.04.20170322-0ubuntu2
<sil2100> davmor2: are you sure it's the latest image?
<sil2100> Let me check the manifest
<sil2100> davmor2: ok, so I see in the manifest that the latest image has indicator-datetime ubuntu2, so the correct one - you have to be using an older image
<davmor2> sil2100: check the md5sum above mine locally matches it and it matches the image on the servers under current
<sil2100> davmor2: no, it doesn't
<sil2100> davmor2: ah, ok, you shouldn't use current
<davmor2> http://cdimages.ubuntu.com/daily-live/current/MD5SUMS
<sil2100> davmor2: you need to use 'pending'
<sil2100> http://cdimage.ubuntu.com/ubuntu/daily-live/pending/
<davmor2> sil2100: no we test from current
<sil2100> This is the latest
<davmor2> sil2100: it is what all the iso tracker tests point to ;)
<davmor2> brb errand
<sil2100> davmor2: that's what I see from the isotracker ;p http://iso.qa.ubuntu.com/qatracker/milestones/375/builds/145751/downloads
<sil2100> Anyway, get the latest iso and check :)
<infinity> davmor2: You're both wrong.  We don't test from current or pending, we test from the date directories that the tracker explicitly links to. :P
<sil2100> I guess infinity's right, I also generally check the date directory but that's when I browse cdimage directly ;p Mostly because I always mixed up what current and pending mean
<xnox> Laney, infinity: i've navigated to https://platform-qa-jenkins.ubuntu.com/job/ubuntu-zesty-desktop-i386-iso-download/ and I am logged in and I clicked "Build with Parameters" to trigger a brand new top level run, hopefully that should fetch the brand new ISO and trigger the rest of the jobs
<xnox> i am logged in, and I think back in the day they gave me "rights"
<xnox> but i may have powers
<Laney> I want powers
-queuebot:#ubuntu-release- Unapproved: cppformat (zesty-proposed/universe) [3.0.1+ds-1 => 3.0.1+ds-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cppformat [source] (zesty-proposed) [3.0.1+ds-1ubuntu1]
<davmor2> sil2100: thanks dude
<sil2100> davmor2: xnox was looking into why the images didn't move by themselves to current
<sil2100> He's running the jobs manually it seems
 * davmor2 slaps Laney hand and tells him he is not a ranger
<xnox> sil2100, right.
 * xnox only (re)-trigger download job and thus downstream test jobs.
<xnox> imho this was just waiting for the timer trigger.
<xnox> sil2100, davmor2: i386 desktop did move to current now; and i've only just retriggered amd64 tests
<flexiondotorg> Laney infinity Morning.
<flexiondotorg> Interesting bug has surfaces in the 17.04 testing which might affect all flavours.
<flexiondotorg> dnsmasq is not seeded, therefore connection sharing in Network Manager doesn't work.
<flexiondotorg> https://bugs.launchpad.net/ubuntu-mate/+bug/1681912
<ubot5> Ubuntu bug 1681912 in network-manager (Ubuntu) "[Zesty] missing dnsmasq package breaks NetworkManager connection sharing feature" [Undecided,New]
<flexiondotorg> Wondering how best to address this? Should flavours seed dnsmasq or should network-manager Recommends dnsmasq?
<infinity> flexiondotorg: s/dnsmasq/dnsmasq-base/
<infinity> flexiondotorg: But also it was dropped in favour of systemd-resolved.
<flexiondotorg> Right, dnsmasq-base. But is this something each flavour should resolve in their seeds?
-queuebot:#ubuntu-release- Unapproved: mtx (xenial-proposed/main) [1.3.12-9 => 1.3.12-9ubuntu0.16.04.1] (ubuntu-server)
<infinity> flexiondotorg: No, I don't think seeding it is correct.
-queuebot:#ubuntu-release- Unapproved: mtx (yakkety-proposed/main) [1.3.12-9 => 1.3.12-9ubuntu0.16.10.1] (ubuntu-server)
<infinity> flexiondotorg: But this might need a larger discussion with, say, cyphermox.
<davmor2> Yay no crash
<infinity> flexiondotorg: Where does one find this sharing option?  Does it require a static interface?
<infinity> flexiondotorg: Anyhow, we're also at a point where I'm not accepting anything that isn't install/boot-critical, so we can discuss today, but fixes would be in SRUs, IMO.
<flexiondotorg> infinity I'll request the reporter provides more details...
<infinity> You might also want to tell the reporter to remove dnsmasq, and just use -base.
<infinity> The former wreaks havoc with other things like VPNs.
<flexiondotorg> ack
-queuebot:#ubuntu-release- Unapproved: libsbml (zesty-proposed/universe) [5.13.0+dfsg-1 => 5.13.0+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Zesty Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Zesty Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Zesty Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Zesty Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Zesty Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Zesty Final] has been marked as ready
-queuebot:#ubuntu-release- Unapproved: accepted libsbml [source] (zesty-proposed) [5.13.0+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: pywavelets (zesty-proposed/universe) [0.5.1-1ubuntu1 => 0.5.1-1.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pywavelets [sync] (zesty-proposed) [0.5.1-1.1]
<davmor2> Laney, sil2100, infinity: so looking good on i386 now testing amd64 to make sure it didn't regress there
<sil2100> davmor2: thanks!
<davmor2> cyphermox, infinity: did you guys do something to the press enter to continue cause it is showing up now on i386 and amd64 \o/
<flocculant> davmor2: I've always found that to be one of those sometimes you see it bugs ...
<davmor2> flocculant: no I was hitting it always but now I'm not and cyphermox said he had an idea and might squeeze it in so I don't know if that happened
<flocculant> :)
<davmor2> sil2100: Laney infinity looking good on amd64 too
<sil2100> Ship it!
<davmor2> sil2100: hold your horses lots of other tests yet those were the basic ones :P
<davmor2> D'oh ofcourse the enter dialogue appeared I was in livecd mode D'oh
-queuebot:#ubuntu-release- Unapproved: freeciv (zesty-proposed/universe) [2.5.6-2 => 2.5.6-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted freeciv [source] (zesty-proposed) [2.5.6-2ubuntu1]
<davmor2> Yeah so my no enter key bug is still valid :D
<davmor2> Just my head not on completely straight for some reason
<infinity> davmor2: Yeah, doubt that one's getting fixed this cycle.
<davmor2> infinity: yeah thought it was fixed forgot I ran the live session to see if it was fixed in both live and installed
<jbicha> I am installing Ubuntu GNOME zesty/amd64 and I clicked the box to install third-party software and it looks like the install is stuck at installing adobe-flashplugin, see also LP: #1682031
<ubot5> Launchpad bug 1682031 in adobe-flashplugin (Ubuntu) "adobe flashplugin could not be installed in lubuntu 17.04" [Undecided,New] https://launchpad.net/bugs/1682031
<jbicha> chrisccoulson: ^
<infinity> jbicha: Have an installer log that could shed some light?
<jbicha> oh wait, it eventually did complete, it just took a long time
<jbicha> it looks like it took 15 minutes to download updates including Flash LP: #1682107
<ubot5> Launchpad bug 1682107 in ubiquity (Ubuntu) "Install seemed to get stuck installing adobe-flashplugin" [Undecided,New] https://launchpad.net/bugs/1682107
<jbicha> maybe I just need a better Internet connection?
<infinity> There's a firefox in there, probably.
<infinity> But 15m is pretty ick.
<jbicha> it worked fine with i386, it might just have been my network being congested (I *was* zsyncing i386 in the background)
-queuebot:#ubuntu-release- Unapproved: rejected munin [source] (trusty-proposed) [2.0.19-3ubuntu0.4]
<jbicha> ok, I retried amd64 and it is *very* slowly downloading adobe-flashplugin
<jbicha> Fetched 30.4MB in 5 min (101 kB/s)
<infinity> Ouch.
<ginggs> infinity: thanks for the previous force-badtests - htsjdk looks like uinstallable tests as well, but i can't see what
-queuebot:#ubuntu-release- Unapproved: astroquery (zesty-proposed/universe) [0.3.4+dfsg-2 => 0.3.4+dfsg-2ubuntu1] (no packageset)
<cyphermox> good morning
<infinity> cyphermox: EVERYTHING IN THE INSTALLER IS BROKEN AND IT'S ALL YOUR FAULT.
<cyphermox> is it?
<infinity> No.
-queuebot:#ubuntu-release- Unapproved: accepted astroquery [source] (zesty-proposed) [0.3.4+dfsg-2ubuntu1]
<cyphermox> I knew it, only some things in the installer are broken and it's sometimes my fault
<infinity> Yes, that.
<wgrant> The slow Flash download is probably because we're being rather heavily hit by the update overnight.
<wgrant> This is why we have mirrors for everything else :/
<infinity> archive.c.c could certainly do with a mirror.
<infinity> Or just a fatter link and a lot of RAM, since the entire mirror contents can probably be hot all the time.
<infinity> s/mirror/archive/
<jbicha> or is there a way that update could be better phased so we don't have everyone trying to get the file at the same time?
<infinity> Could be.  But it's too late for this one.
<infinity> Err, maybe could be.  If partner actually pays attention to extra overrides.
<infinity> wgrant: ^-- Does NMAF do the right thing if we actually tried to phase partner?
<wgrant> I'm not sure who many downloads are flashplugin-installer vs adobe-flashplugin
<wgrant> infinity: It should.
<infinity> Also that too.
<infinity> The way we distribute flash is a cluster.
<wgrant> (flashplugin-installer is multiverse, but pulls adobe-flashplugin from partner, for those unfamiliar with this particular specialness)
<wgrant> infinity: Half of that sentence is redundant.
<apw> heh
<apw> interestingly i suspect that applied to both sentences equally
<wgrant> Hah, indeed
-queuebot:#ubuntu-release- Unapproved: profanity (zesty-proposed/universe) [0.5.0-0.1 => 0.5.0-0.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted profanity [source] (zesty-proposed) [0.5.0-0.1ubuntu1]
<infinity> ginggs: It's because libngs-java only exists on x86.
<ginggs> infinity: ah, thanks - will you force-badtest that too?
<infinity> Yeah.
<ginggs> infinity: thanks!
-queuebot:#ubuntu-release- Unapproved: gnome-settings-daemon (zesty-proposed/main) [3.24.0-0ubuntu2 => 3.24.1-0ubuntu1] (ubuntu-desktop)
<jbicha> what's the guideline for 0-day SRUs?
<infinity> jbicha: Same as any other SRU.  But if it meets the combination of urgent and very obviously correct, we can push it out faster (again, like a regular SRU).
<infinity> jbicha: So, basically, if it's the sort of SRU where you'd be comfy saying "Hey, Adam, can we push this out ASAP, it's urgent and super obvious to fix, and super easy to test that it's not broken", then yay 0-day.
<jbicha> ok, I'm doing some 3.24.1 uploads that aren't needed in the release images
<ginggs> rbalint: i triggered botch and mathicgb autopkgtests
<rbalint> ginggs: thanks, i have just asked sil2100, too, to do that :-)
<rbalint> ginggs: for the next release i have ambitious plan to keep the update_excuses list low :-)
<infinity> rbalint: We all share that ambition.  It fades in time.
<cjwatson> don't discourage them :)
<infinity> Heh.
<infinity> rbalint: Also, your pywavelets upload FTBFS on armhf.
<infinity> rbalint: (alignment bug)
<rbalint> infinity: maybe i'll buy some candys myself or others every day when the queue is short enough :-)
 * rbalint checking pywavelets
<infinity> rbalint: test_multidim.test_byte_offset ... Bus error (core dumped)
<infinity> rbalint: Not at ALL suspicious that one would find an alignment bug in something called test_byte_offset.
-queuebot:#ubuntu-release- Unapproved: gnome-control-center (zesty-proposed/universe) [1:3.24.0-0ubuntu1 => 1:3.24.1-0ubuntu1] (edubuntu, ubuntugnome)
<rbalint> infinity: yes, it looks like alignment
<rbalint> infinity: i suspect buildds use /proc/cpu/alignment=4  LP: #1516331 and Debian uses /proc/cpu/alignment setting of 2 (fixup) on armhf
<ubot5> Launchpad bug 1516331 in launchpad-buildd "please set /proc/cpu/alignment=4 on Launchpad ARM buildd kernels" [Undecided,New] https://launchpad.net/bugs/1516331
<infinity> rbalint: We definitely don't do fixups, yes.  I believe we discovered that arm64 kernels can't do it (we don't build on armv7 anymore)
<rbalint> infinity: this is why we don't see FTBFS on Debian buildds, except for sparc64 which is picky: https://buildd.debian.org/status/package.php?p=pywavelets&suite=unstable
<rbalint> infinity: looks like there are some unaligned issues to fix till tomorrow then :-)
-queuebot:#ubuntu-release- Unapproved: gnome-photos (zesty-proposed/universe) [3.24.0-0ubuntu1 => 3.24.1-0ubuntu1] (desktop-extra, ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: rejected bluez [source] (xenial-proposed) [5.37-0ubuntu6]
-queuebot:#ubuntu-release- Unapproved: bison (zesty-proposed/main) [2:3.0.4.dfsg-1 => 2:3.0.4.dfsg-1build1] (core)
-queuebot:#ubuntu-release- Unapproved: dctrl-tools (zesty-proposed/main) [2.24-2 => 2.24-2build1] (core)
-queuebot:#ubuntu-release- Unapproved: dh-exec (zesty-proposed/main) [0.23 => 0.23build1] (core)
-queuebot:#ubuntu-release- Unapproved: gfxboot (zesty-proposed/main) [4.5.2-1.1-5 => 4.5.2-1.1-5build1] (core)
-queuebot:#ubuntu-release- Unapproved: gobi-loader (zesty-proposed/main) [0.7-0ubuntu2 => 0.7-0ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: hfsutils (zesty-proposed/main) [3.2.6-13ubuntu1 => 3.2.6-13ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: hello (zesty-proposed/main) [2.10-1 => 2.10-1build1] (core)
-queuebot:#ubuntu-release- Unapproved: ibmasm-utils (zesty-proposed/main) [3.0-1ubuntu11 => 3.0-1ubuntu12] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ibus-sunpinyin (zesty-proposed/main) [2.0.3-5build2 => 2.0.3-5build3] (input-methods, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: irda-utils (zesty-proposed/main) [0.9.18-14ubuntu1 => 0.9.18-14ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: joyent-mdata-client (zesty-proposed/main) [0.0.1-0ubuntu2 => 0.0.1-0ubuntu3] (ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ipvsadm (zesty-proposed/main) [1:1.28-3 => 1:1.28-3build1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: john (zesty-proposed/main) [1.8.0-2 => 1.8.0-2build1] (core)
-queuebot:#ubuntu-release- Unapproved: lockfile-progs (zesty-proposed/main) [0.1.17 => 0.1.17build1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lupin (zesty-proposed/main) [0.57 => 0.57build1] (core)
-queuebot:#ubuntu-release- Unapproved: lsscsi (zesty-proposed/main) [0.27-3 => 0.27-3build1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: m2300w (zesty-proposed/main) [0.51-12 => 0.51-12build1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: maas-enlist (zesty-proposed/main) [0.4+bzr38-0ubuntu2 => 0.4+bzr38-0ubuntu3] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: nicstat (zesty-proposed/main) [1.95-1 => 1.95-1build1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: powertop (zesty-proposed/main) [2.8-1build1 => 2.8-1build2] (core)
-queuebot:#ubuntu-release- Unapproved: mouseemu (zesty-proposed/main) [0.16-0ubuntu9 => 0.16-0ubuntu10] (core)
-queuebot:#ubuntu-release- Unapproved: opensp (zesty-proposed/main) [1.5.2-13ubuntu1 => 1.5.2-13ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: quota (zesty-proposed/main) [4.03-2 => 4.03-2build1] (core)
-queuebot:#ubuntu-release- Unapproved: tmispell-voikko (zesty-proposed/main) [0.7.1-4 => 0.7.1-4build1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: tinycdb (zesty-proposed/main) [0.78 => 0.78build1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: uucp (zesty-proposed/main) [1.07-23 => 1.07-23build1] (core)
-queuebot:#ubuntu-release- Unapproved: python-tx-tftp (zesty-proposed/main) [0.1~bzr42-0ubuntu2 => 0.1~bzr47-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: apt-xapian-index (zesty-proposed/universe) [0.47ubuntu12 => 0.47ubuntu13] (kubuntu)
<slashd> For SRU, There is a patch for sssd pkg via LP#1566508 in trusty upload queue [https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=sssd] uploaded on 2017-03-29. We were wondering if one of you could please have a look at it in order to review/build it into -proposed if this pass all the necessary validation of course. I currently don't see any sssd pkg already in -proposed that could possibly block the
<slashd> process.
<nacc> slashd: does it just need sponsoring?
<nacc> oh wait, it's sponsored but not reviewed, i see
<slashd> nacc exactly
<nacc> slashd: i think rbasak was on sru today, his time
<nacc> slashd: but not sure
<bdmurray> Is anybody looking at bug 1681566?
<ubot5> bug 1681566 in ubuntu-release-upgrader (Ubuntu) "nvidia-375 DKMS module not recompiled on upgrade to 17.04" [Undecided,Confirmed] https://launchpad.net/bugs/1681566
<nacc> bdmurray: is the underlying issue that the dkms trigger isn't seeing the new kernel for some reason?
<bdmurray> nacc: maybe?
<nacc> bdmurray: i'm grabbing the logs to see
<bdmurray> slashd: Why did the patch names change from .patch to .diff?
<slashd> bdmurray, looking
<nacc> bdmurray: confusing from the original log -- i see nvidia-375.39-0ubuntu5 get installed and it says "REmoving all DKMS modules" .. then i see linux-image-generic-4.10.0-19-generic get installed and the dkms trigger runs ... and runs again with linux-headers-4.10.0-19-generic, linux-image-extra..., then a new dkms get installed, then the nvidia-375 driver installs, and seems to only run for the
<nacc> running kernel
<nacc> i wonder if the hook is wrong in the new driver?
<slashd> bdmuarray, seems like there is a mixed of both in d/p (.diff and .patch), which probably confuse the creator of the patch (note that I haven't look the patch nor sponsor it myself).
<slashd> bdmurray^
<bdmurray> slashd: it also introduces a bunch of noise into the diff for us to review.
<slashd> vtapia, can you answer bdmurray since you are the patch submitter ^^
<vtapia> hey, I used diff
<vtapia> after discussing this with tjaalton, to keep track of the patches in pkg-sssd
<slashd> bdmurray ^
<bdmurray> But why were the existing patches renamed from .patch to .diff?
<vtapia> let me check, please
-queuebot:#ubuntu-release- Unapproved: gbrowse (zesty-proposed/universe) [2.56+dfsg-2 => 2.56+dfsg-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gbrowse [source] (zesty-proposed) [2.56+dfsg-2ubuntu1]
<rbasak> I did glance at sssd but it looked very confusing so I skipped past in order to make progress.
<nacc> rbasak: :)
<bdmurray> rbasak: because of the patch renaming right?
<rbasak> Previous changelog entries edited IIRC etc
<bdmurray> We should just reject it then.
<bdmurray> If two of us have skipped it.
<vtapia> hmmm
<vtapia> so those changes are already in -updates
<rbasak> That and some verifications already done but the Trusty upload pending, so it seemed a bit involved to untangle it
<rbasak> sssd appears in pending-sru
<bdmurray> rbasak: that's for xenial
<nacc> for non-trusty
<bdmurray> vtapia: in -updates for what?
<rbasak> Sure, but that's what I meant by confusing. I'd want to unravel all of that in my head to make sure everything's straight before touching anything
<vtapia> the patch renaming bdmurray
<bdmurray> vtapia: Where does the patch renaming exist in -updates?
<rbasak> And if I'm going to reject, I prefer to make it really clear what needs to be done to make progress instead, and that was going to take longer to figure out, so I moved on to some easier ones
<rbasak> Anyway I'm pretty much EOD now, so shall I leave this to bdmurray?
<bdmurray> Sure
<rbasak> If it's still outstanding tomorrow, ping me and I'd be happy to go through it in realtime if somebody has the patience.
<rbasak> bdmurray: thanks!
<vtapia> sorry bdmurray, I'm completely mistaken
<bdmurray> Part of my point is this is taking a lot of time / patience because the diff is wacky.
<rbalint> infinity: i think the problem with pywavelets is actually in numpy:
<rbalint> infinity: import numpy as np; np.dtype([('ddata', 'float32'),('pad', 'byte')]).alignment
<rbalint> infinity: 1
<bdmurray> vtapia: To be absolutely clear this is what makes no sense to me. http://pastebin.ubuntu.com/24368576/ lines 16,17 and lines 25,26
<vtapia> I see what I did, please reject the SRUs
-queuebot:#ubuntu-release- Unapproved: accepted bison [source] (zesty-proposed) [2:3.0.4.dfsg-1build1]
-queuebot:#ubuntu-release- Unapproved: rejected sssd [source] (trusty-proposed) [1.11.8-0ubuntu0.6]
<bdmurray> vtapia: Done, if you need something sponsored feel free to ping me.
<vtapia> thanks a lot bdmurray, and sorry for this
<slashd> rbasak, bdmurray, tks for your quickly jumping on it
-queuebot:#ubuntu-release- Unapproved: rejected dctrl-tools [source] (zesty-proposed) [2.24-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted dh-exec [source] (zesty-proposed) [0.23build1]
-queuebot:#ubuntu-release- Unapproved: python-tx-tftp (zesty-proposed/main) [0.1~bzr42-0ubuntu2 => 0.1~bzr47-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected gfxboot [source] (zesty-proposed) [4.5.2-1.1-5build1]
<bdmurray> infinity/slangasek: I think bug 1681566 is a problem with dkms in general.
<ubot5> bug 1681566 in virtualbox (Ubuntu) "nvidia-375 DKMS module not recompiled on upgrade to 17.04" [Undecided,Confirmed] https://launchpad.net/bugs/1681566
<nacc> bdmurray: agreed based upon your last comment, someting seems wrong with the hook
<bdmurray> I'm not familiar with that package though.
-queuebot:#ubuntu-release- Unapproved: accepted gobi-loader [source] (zesty-proposed) [0.7-0ubuntu3]
<jbicha> buffer 2
<infinity> bdmurray: Not fixing it on images (which is fine, cause upgrades tend to be from the network), but I can have a look tomorrow if no one else has.
<bdmurray> infinity: What should I look at in the package?
<infinity> bdmurray: I'd start with seeing if xenial->yakkety had the same upgrade issue.  If not, then diff yakkety->zesty versions and poke around.
<nacc> bdmurray: if you want me to, i can import dkms so you have a git tree to look at for seeing the changes
<infinity> bdmurray: So, uhm.  I dunno.  I didn't have a killer "look at this bit" in mind, I've just played with it a lot in the ast.
<infinity> s/ast/past/
<nacc> bdmurray: when you're in that broken state (where dkms hasn't built the module for the 17.04 kernel), i wonder if you can try to run dkms manually with various optoins to see if you can get it to build
-queuebot:#ubuntu-release- Unapproved: accepted hello [source] (zesty-proposed) [2.10-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted hfsutils [source] (zesty-proposed) [3.2.6-13ubuntu2]
<nacc> bdmurray: sorry, lappy hung up when i reconnected to my monitor -- let me know if you did want an import or if i can help at all
<bdmurray> "an import"?
<slashd> bdmurray, FYI vtapia changed the "v-d" tag to "v-f" for the 2 bugs related to sssd (LP#1566508 & LP#1669712) for releases where the existing patch has been mistakenly renamed. He will correct and re-submit later. I just want to make sure you are aware.
<nacc> bdmurray: the server team's git importer
<nacc> bdmurray: will import the published history for dkms into a git tree, so you can git {blame, log}, etc files to see what was changed when
-queuebot:#ubuntu-release- Unapproved: accepted ibmasm-utils [source] (zesty-proposed) [3.0-1ubuntu12]
<nacc> bdmurray: given you only are looking at what's in zesty, you may not need it to figure out the issue :)
-queuebot:#ubuntu-release- Unapproved: multipath-tools (zesty-proposed/main) [0.6.4-3ubuntu3 => 0.6.4-3ubuntu4] (core)
-queuebot:#ubuntu-release- Unapproved: accepted ibus-sunpinyin [source] (zesty-proposed) [2.0.3-5build3]
-queuebot:#ubuntu-release- Unapproved: rejected ipvsadm [source] (zesty-proposed) [1:1.28-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted irda-utils [source] (zesty-proposed) [0.9.18-14ubuntu2]
-queuebot:#ubuntu-release- Unapproved: rejected lsscsi [source] (zesty-proposed) [0.27-3build1]
-queuebot:#ubuntu-release- Unapproved: rejected lockfile-progs [source] (zesty-proposed) [0.1.17build1]
-queuebot:#ubuntu-release- Unapproved: rejected lupin [source] (zesty-proposed) [0.57build1]
-queuebot:#ubuntu-release- Unapproved: accepted john [source] (zesty-proposed) [1.8.0-2build1]
-queuebot:#ubuntu-release- Unapproved: rejected maas-enlist [source] (zesty-proposed) [0.4+bzr38-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: rejected mouseemu [source] (zesty-proposed) [0.16-0ubuntu10]
-queuebot:#ubuntu-release- Unapproved: rejected quota [source] (zesty-proposed) [4.03-2build1]
-queuebot:#ubuntu-release- Unapproved: rejected uucp [source] (zesty-proposed) [1.07-23build1]
-queuebot:#ubuntu-release- Unapproved: rejected joyent-mdata-client [source] (zesty-proposed) [0.0.1-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: ampliconnoise (zesty-proposed/universe) [1.29-6 => 1.29-6ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ampliconnoise [source] (zesty-proposed) [1.29-6ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted m2300w [source] (zesty-proposed) [0.51-12build1]
-queuebot:#ubuntu-release- Unapproved: accepted nicstat [source] (zesty-proposed) [1.95-1build1]
-queuebot:#ubuntu-release- Unapproved: rejected tinycdb [source] (zesty-proposed) [0.78build1]
-queuebot:#ubuntu-release- Unapproved: accepted opensp [source] (zesty-proposed) [1.5.2-13ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted powertop [source] (zesty-proposed) [2.8-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted tmispell-voikko [source] (zesty-proposed) [0.7.1-4build1]
-queuebot:#ubuntu-release- Unapproved: rejected python-tx-tftp [source] (zesty-proposed) [0.1~bzr47-0ubuntu1]
<slangasek> cyphermox: multipath-tools upload in queue, are you expecting this in the final images?
<slangasek> also, er, somehow this bug is marked fix-released in zesty
<cyphermox> wat
<cyphermox> no, I'm expecting this as a SRU
<cyphermox> if we can sneak it in, all good, but I don't think it's that critical
<slangasek> ok
<slangasek> cyphermox: want to put an SRU template on the bug then? :)
<cyphermox> yes, getting to it
<cyphermox> I'm in a one on one right now
<bdmurray> priorities
<cyphermox> bdmurray: I know, but slangasek already has a dedicated priority queue.
<slangasek> infinity: why bump z3c.rml / schooltool to -proposed now, vs. leaving python-pypdf around for a bit?
<cyphermox> slangasek: can you please reject the multipath-tools upload? seems like it's pointing to the wrong bug anyway
<slangasek> cyphermox: ack
<slangasek> done
-queuebot:#ubuntu-release- Unapproved: rejected multipath-tools [source] (zesty-proposed) [0.6.4-3ubuntu4]
<cyphermox> infinity: same as yesterday but for today; any issue came up in iso testing (but isn't on iso.qa.u.c) that I should look at in priority?
<cyphermox> I had a quick look at UbuntuKylin bugs, but they pretty much all seem to be in ukui-control-center or something
-queuebot:#ubuntu-release- Unapproved: multipath-tools (zesty-proposed/main) [0.6.4-3ubuntu3 => 0.6.4-3ubuntu4] (core)
<slangasek> infinity: sorry, ignore question re: z3c.rml / schooltool, this was clearly my fault for removing python-pypdf back in Feb while it still had revdeps
<jackpot51> Is today's daily ISO the release?
<slangasek> not until it's been released
<jackpot51> Does it feel like it will?
-queuebot:#ubuntu-release- Unapproved: zimlib (zesty-proposed/universe) [1.4-2 => 1.4-2ubuntu1] (no packageset)
<cyphermox> jackpot51: if you have time, you can help testing: http://iso.qa.ubuntu.com/qatracker/milestones/375/builds
<jackpot51> Definitely do
<slangasek> g++ -shared [...] -o libvp
<slangasek> x.so.4.1.0
<slangasek> [...]
-queuebot:#ubuntu-release- Unapproved: accepted zimlib [source] (zesty-proposed) [1.4-2ubuntu1]
<slangasek> /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/Scrt1.o: In function `_start':
<slangasek> (.text+0x20): undefined reference to `main'
<slangasek> good job
<cyphermox> o.O?
<slangasek> no idea :)
<cyphermox> hehe
<slangasek> jbicha: I see you synced zeroinstall-injector, which FTBFS because of wrong link order (Ubuntu's default of -Wl,--as-needed, which is not used in Debian - https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-Wl.2C--as-needed).  Is that something you'd want to follow up on with Debian?
<jackpot51> cyphermox: Which test cases do you need?
<slangasek> jackpot51: https://iso.qa.ubuntu.com
<cyphermox> jackpot51: take your pick, priority to those that aren't fully tested (not 5/5 or whatever)
-queuebot:#ubuntu-release- Unapproved: zeroinstall-injector (zesty-proposed/universe) [2.12-3 => 2.12-4] (no packageset) (sync)
<jbicha> slangasek: let's try this version ^ (all I did last month was sync a newer version on top of the already existing autosynced ftbfs)
-queuebot:#ubuntu-release- Unapproved: accepted zeroinstall-injector [sync] (zesty-proposed) [2.12-4]
<slangasek> jbicha: any reason to expect that one to work better, given that it's an Ubuntu-specific build failure?
-queuebot:#ubuntu-release- Unapproved: gjs (zesty-proposed/universe) [1.48.0-0ubuntu1 => 1.48.1-0ubuntu1] (desktop-extra, mozilla, ubuntugnome)
<cyphermox> jackpot51: it's getting increasingly late to fix things, but you might want to have a good look at OEM-mode installs, I know you care about those :)
<jackpot51> I will
<jackpot51> Thanks cyphermox! I will fill out the OEM install test then
<jbicha> slangasek: it worked https://launchpad.net/ubuntu/+source/zeroinstall-injector/2.12-4
<slangasek> jbicha: ok then :)
<jbicha> the maintainer was subscribed to Ubuntu bugs for his package which is always nice :)
-queuebot:#ubuntu-release- Unapproved: gnome-desktop3 (zesty-proposed/main) [3.24.0-0ubuntu1 => 3.24.1-0ubuntu1] (ubuntu-desktop)
<ginggs> rbalint: around?
<rbalint> ginggs: yes :-)
<ginggs> kodi-visualization-spectrum should build if you change DEB_BUILD_MAINT_OPTIONS = hardening=+all -> +all,-pie
<ginggs> rbalint: yes it does, just built in my PPA
<ginggs> shall I upload?
<jackpot51> http://iso.qa.ubuntu.com/qatracker/milestones/375/builds/145748/testcases/1305/results
<jackpot51> Tested it, OEM config looks great on Ubuntu
<jackpot51> I still can crash the installer with WPA 2 enterprise cyphermox :P
<cyphermox> yes
<jbicha> jackpot51: stop crashing the installer! ;)
<rbalint> ginggs: thanks!
<jackpot51> Sorry!
<rbalint> ginggs: yes, please upload this should be ok
<ginggs> rbalint: done
-queuebot:#ubuntu-release- Unapproved: kodi-visualization-spectrum (zesty-proposed/universe) [1.1.1-1 => 1.1.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted kodi-visualization-spectrum [source] (zesty-proposed) [1.1.1-1ubuntu1]
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Zesty Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Zesty Final] has been marked as ready
-queuebot:#ubuntu-release- Unapproved: gnome-shell (zesty-proposed/universe) [3.24.0-0ubuntu2 => 3.24.1-0ubuntu1] (desktop-extra, edubuntu, mozilla, ubuntugnome)
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Zesty Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Zesty Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Zesty Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Zesty Final] has been marked as ready
<jackpot51> Where is my Ubuntu Desktop amd64 [Zesty Final] ?
<jackpot51> Make it happen! :)
-queuebot:#ubuntu-release- Unapproved: mutter (zesty-proposed/universe) [3.24.0-0ubuntu1 => 3.24.1-0ubuntu1] (desktop-extra, edubuntu, ubuntugnome)
<bdmurray> infinity: laney has a potential fix attached to bug 1681566
<ubot5> bug 1681566 in virtualbox (Ubuntu) "nvidia-375 DKMS module not recompiled on upgrade to 17.04" [Undecided,Confirmed] https://launchpad.net/bugs/1681566
<infinity> jackpot51: It's not Thursday.
<jackpot51> It is in some places ;-)
<infinity> bdmurray: Seems potentially reasonable.  I can look with fresher eyes in the morning.
<infinity> jackpot51: It's not sufficiently Thursday for people to be bugging us about the release.
<infinity> jackpot51: (You may think it's cute and funny until you realize that we have millions of users, thousands of whom know how email and IRC work, and hundreds of whom think that's a fun thing to use it for)
<cyphermox> bdmurray: looks elegant
<jackpot51> Oy vey. infinity: I've been in this too, just ask cyphermox. I'm helping where I can
<jackpot51> Going home, will be back in to bug in 18 hours
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Zesty Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Zesty Final] has been marked as ready
<tsimonq2> infinity: Will there be another global respin, or are we done?
<infinity> tsimonq2: We look pretty done, but I make no promises until it ships.
<flexiondotorg> See you later this morning infinity :-)
<tsimonq2> infinity: That's fair to say (I get that last minute things sometimes happen), I just wanted to make sure that nobody was sitting on $something-important until now.
<tsimonq2> infinity: Thanks for letting me know.
<cyphermox> tsimonq2: the big bad bugs should be showing up on the iso.qa dashboard
<cyphermox> there are some bugs open showing up there, but there has been for every release (AFAIK) and it doesn't look like any translates to "omg the world is on fire"
<cyphermox> that said, not everything is fully tested either, can you help on some of those?
<tsimonq2> cyphermox: Have anything in mind, or just "Go Do"?
<cyphermox> I have weird results trying to test the OEM-config mode for Kubuntu, maybe you can try that, let me know if it works well for you
<cyphermox> I keep hitting a blank screen, not sure whether it's my system or the image.
<tsimonq2> cyphermox: Any specific steps you want me to take besides what's on the tracker?
<cyphermox> nope, that should be the steps
<wxl> cyphermox: i've had that problem before. and other times, not.
<cyphermox> could just be that I'm giving the VM too little memory, I suppose
<tsimonq2> cyphermox: OK, getting the ISO now.
<wxl> yeah i only had it in vms
<wxl> and admittedly i tend to kind of strangle my vms for resources :)
<tsimonq2> wxl: I'd be testing with a spare hard drive on this 16 GB, 6-core machine, I shouldn't have any resource restrictions here. :P
<tsimonq2> (and if I do, welllll that's a problem :P)
<cyphermox> I just let virt-manager do its thing there, I didn't bother using my scripts for vms for this one
<wxl> i've seen this https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1561745
<ubot5> Ubuntu bug 1561745 in ubiquity (Ubuntu) "OEM config fails to remove itself" [Medium,New]
<cyphermox> that should translate to 1G
<cyphermox> ugh, seriously?
<wxl> but this is the main one we were using for tracking https://bugs.launchpad.net/ubuntu/+source/oem-config/+bug/1638473
<ubot5> Ubuntu bug 1638473 in oem-config (Ubuntu) "Blank screen after running oem-config" [Undecided,Triaged]
<tsimonq2> cyphermox: Before I reboot, anything bad on Lubuntu?
<tsimonq2> Or are we Clear For Launch there?
<cyphermox> I don't know
<cyphermox> Lubuntu looks decent, but I don't make the go/no-go decisions
<cyphermox> think of me like a I'm testing monkey; I just test the things and occasionally eat bugs.
<tsimonq2> cyphermox: Then I'm asking with your testing monkey hat on. :P
<tsimonq2> (because I'm the guy who makes the go/no-go decisions for Lubuntu now)
<cyphermox> judging from the dashboard, lubuntu is tested, and marked ready already.
<tsimonq2> Because I did that. :P
 * tsimonq2 goes with "cyphermox> Lubuntu looks decent..."
<cyphermox> tsimonq2: to be clear, I did *not* personally run a Lubuntu image today; I can only make a general observation based on the bugs showing on the dashboard.
<tsimonq2> Apologies for the confusion here, I don't think I've been clear, what my real question is is this: Are there any low-level overarching issues or anything in Lubuntu that you've found that I should be concerned about?
<cyphermox> I don't think so, but like I said, i didn't test lubuntu at all for this image.
<tsimonq2> Ok, thank you. Sorry again, I wasn't clear with what I was asking. :)
<tsimonq2> cyphermox: If you could, I would absolutely appreciate it (as a just-in-case thing). I can pay in beer if I ever see you at a conference. ;)
<wxl> you'd have to be old enough XD
<valorie> totally not possible for you to legally buy cyphermox beer!
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (zesty-proposed/main) [2.440 => 2.441] (desktop-core)
<wxl> hahhahahah
<wxl> jinx :)
<valorie> but I'll cover it.....
<cyphermox> slangasek: ^
<cyphermox> re: livecd-rootfs.
<slangasek> cyphermox: thanks; hands full right now but I'll look in a bit
<cyphermox> no problem
<cyphermox> tsimonq2: ok, coming up
<tsimonq2> wxl: My point in that being, the chances of me seeing cyphermox are low enough that I probably won't see him until I'm 21+ ;)
<tsimonq2> (if at all, as much as I love y'all, I won't see *everyone* at a conference...)
<tsimonq2> cyphermox: Thank you. :)
<cyphermox> seems like I broke keyboard-detection
<cyphermox> broke as in "manage to trick it into thinking of the wrong keyboard"
 * tsimonq2 goes AFK for 10-20 mins to do some room cleaning, by the time I'm back, ISO should be done...
<tsimonq2> s/ISO/ISO downloading/
<cyphermox> oh, it's because I can't read.
<tsimonq2> cyphermox: PEBKAC is exactly why I sometimes spit internal brain logs verbosely into a channel (can't think of a better way to word that, and that sounds pretty cool :P)
<slangasek> that's fine; keyboard-detection is for writing, not for reading
<cyphermox> is that why everything always starts with qwerty?
<cyphermox> or .,somethingsomethign for yu.
<tsimonq2> Dvorak <3 - I'd use it if I had the motor skills to learn it :P
#ubuntu-release 2017-04-13
<cyphermox> I want a Lorem keyboard.
<tsimonq2> Hah.
<tsimonq2> +1
<cyphermox> tsimonq2: lubuntu-desktop-amd64 looks good to me, but I did just see https://bugs.launchpad.net/ubuntu/+source/gnome-system-tools/+bug/1617468
<ubot5> Ubuntu bug 1617468 in gnome-system-tools (Ubuntu) "Package contains files in /usr/@DATADIRNAME@/locale" [Undecided,Confirmed]
<cyphermox> alternate is still running, and that's super slow, fortunately there is an easy fix to that I think
<cyphermox> it's just not something we can do for this release though
<tsimonq2> cyphermox: Ok, I'll take a look.
<cyphermox> I don't think the reason for alternate is the slightly lower download size, so using a livefs rather than a pool of packages might help there, at a slight download cost.
<tsimonq2> cyphermox: What about Lubuntu Alternate? We're thinking of axing that pretty soon, so if it's a simple fix, JFDI please.
<cyphermox> axing alternate is another way to fix it being slow, of course.
<tsimonq2> cyphermox: (will be up for discussion soon, fwiw)
<tsimonq2> lol
<tsimonq2> yep
<wxl> the other reason for alternate is lower resource usage
<wxl> esp. RAM
<cyphermox> wxl: yeah, that's what I figured, download size isn't (the ~150M difference doesn't seem worth it)
<tsimonq2> wxl: I don't want to go on about this today, but we have mini.iso?
<wxl> i mean it exists, yes
<wxl> not like anyone ever tests it :)
<wxl> referred to as netboot, btw
<tsimonq2> ^ yep
 * tsimonq2 goes back to cleaning room and waitng for ISO
<tsimonq2> cyphermox: Ok, rebooting now.
<lyn||ian> well should there be an install using mini.iso using netboot testcase?
<cyphermox> lyn||ian: those exist already
<cyphermox> Product (Netboot)
<cyphermox> speaking of which, if you happen to have armhf, those aren't tested yet.
<lyn||ian> ah yeah I forgot about that off the top of it
<cyphermox> tsimonq2: alternate looks fine too.
<tsimonq2> cyphermox: Thanks
<rbalint> i am testing a fix in python-numpy for the alignment issue in pywavelets it my PPA https://launchpad.net/~rbalint/+archive/ubuntu/scratch/+packages
<rbalint> numpy has many reverse deps which I'm rebuilding to look for regressions but if the fix turns out to be good there won't be enough time to run autopkgtest for each package before zesty's release :-(
<slangasek> rbalint1: it parallelizes fairly well; try it and see?
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (zesty-proposed) [2.441]
<slangasek> cyphermox: ^^
<slangasek> cyphermox: and https://api.launchpad.net/devel/~ubuntu-cdimage/+livefs/ubuntu/zesty/ubuntu-server-live
-queuebot:#ubuntu-release- Unapproved: sleuthkit (zesty-proposed/universe) [4.4.0-2 => 4.4.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted sleuthkit [source] (zesty-proposed) [4.4.0-2ubuntu1]
<cyphermox> slangasek: ta; will fix ubuntu-cdimage now.
<slangasek> cyphermox: eta?  I'm timing out here; if there are no other fixes beyond my previous review feedback I could just do that in-line with the merge?
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Zesty Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Zesty Final] has been marked as ready
<cyphermox> slangasek: debian-cd
<cyphermox> slangasek: ubuntu-cdimage is updated.
<slangasek> cyphermox: hmm run-tests fails for me
<slangasek> (which I noticed only after merging, because I'm Bad)
<cyphermox> oh of course, that change would do that yes
<cyphermox> fixed
<slangasek> cyphermox: should that not be SUBPROJECT=live?
<cyphermox> that's not what I wrote?
<cyphermox> 29 6 * * *      for-project ubuntu-server cron.daily --live; for-project ubuntu-server cron.daily-preinstalled --live; SUBPROJECT=live for-project ubuntu-server cron.daily-live --live
<slangasek> cyphermox: I see you rewrote both instances of ubuntu-server-live to ubuntu-server; I was suggesting self.config["SUBPROJECT"] = "live" in the test, in which case the test url would be http://kapok.buildd/~buildd/LiveCD/xenial/ubuntu-server-live/[...]
<slangasek> seems to me that would be a more true test
<cyphermox> yes
<slangasek> cyphermox: I'll fix that locally
<cyphermox> yeah just going through the motions and running the test
<cyphermox> which fails.
<cyphermox> ah, changed one too much
<slangasek> yeah. fixed here, committing & pushing
<slangasek> cyphermox: I see you replied to my debian-cd review comment; am I waiting for you to make that change, then?
<cyphermox> slangasek: do you feel strongly about the change? seems to me like we shouldn't carry only-ubiquity just for kicks.
<cyphermox> ie. things as they are in this branch will work and not have cruft.
<cyphermox> well; not any more than the other bits have cruft, anyway
<slangasek> cyphermox: the cruft you mean is the only-ubiquity boot option?
<cyphermox> yes
<slangasek> hmm
<slangasek> trying to decide which bothers me more, cruft in the code or cruft on the boot line
<slangasek> :)
<cyphermox> liveparams would carry that otherwise
<cyphermox> it *all* needs refactoring
<cyphermox> I'd be happy to do it once we're not scrambling to release stuff
<slangasek> yeah, merging as-is
<cyphermox> we're basically in friday-pm mode by now
<slangasek> merged
<slangasek> needs livecd-rootfs to publish
<slangasek> hmm, failing
<slangasek> o rite, that's the private branch nonsense that shouldn't be on the private branch ;)
<cyphermox> I thought you had fixed that already?
<slangasek> nah
<slangasek> ok there we are, test build running now w/ PROPOSED=1
<wxl> hey is there any chance that the published sums for kubuntu's i386 image is wrong?
<wxl> i zsync'd mine and every sum is totally wrong, but zsync should check it, right?
<apw> wxl, got a link to the image, i can compare
<slangasek> wxl: it's surely possible. You're talking the current candidate image?
<wxl> apw: http://cdimage.ubuntu.com/kubuntu/daily-live/20170412/zesty-desktop-i386.iso
<wxl> yep slangasek see above
<wxl> the thing that got me looking was weird issues that don't seem to exist on any other reports https://share.riseup.net/#kpC2GLxkE0o0mMjdlyClpg
<slangasek> wxl: I just recalculated and the image on the master server has the checksum which matches the SHA256SUMS file
<wxl> ok lemme see if i can regrab this
<cyphermox> slangasek: are these faileds due to a mistake on my part, or is something else off? I can't even get logs.
<slangasek> cyphermox: those were because of the private branch not properly dispatching to lp
<cyphermox> ok
<slangasek> (that's the bit that I don't think should be on the private branch)
<cyphermox> aren't you also missing something for pointing to LP?
<cyphermox> ubuntu-server-live-amd64 on kapok.buildd starting at 2017-04-13 04:43:40
<cyphermox> oh wait
<cyphermox> No valid suites to build for
<wxl> weird. now zsync is updating.
<slangasek> cyphermox: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/zesty/ubuntu-server-live/+build/94534 https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/zesty/ubuntu-server-live/+build/94535
<slangasek> have not yet diagnosed
<cyphermox> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/zesty/daily-live-20170413.2.log
<slangasek> that's old
<slangasek> keep up ;)
<cyphermox> ah
<slangasek> but, I see no logs for the failed livefs
<cyphermox> I see three logs on cd-build-logs, only two builds (one per arch) on LP; something is clearly off
<slangasek> cyphermox: cd-build-logs just hasn't synced the .3 log yet, which is the one that triggered the above livefs attempts, but I don't know why they failed
<cyphermox> what does .3 say? nothing at all?
<wxl> ok now i got the right value
<wxl> disaster averted
<slangasek> cyphermox: it says that no livefs builds succeeded
<cyphermox> so specific.
<slangasek> cyphermox: nusakan has no more information about it than the livefs links themselves do. consistency
<slangasek> rbalint1: livecd-rootfs autopkgtest fails ;)
<cyphermox> can you spin up a livefs build outside ubuntu-cdimage to test?
<cyphermox> http://paste.ubuntu.com/24372349/
<cyphermox> that uses Release, not Proposed, but it won't matter now
<cyphermox> and it's "$script ubuntu-cdimage zesty ubuntu-server-live amd64"
<cyphermox> it's almost more verbose in its error now
<slangasek> ah?
<cyphermox> *almost*
<cyphermox> I have no idea why it's not happy; maybe still livecd-rootfs?
<slangasek> yeah, I really don't know
<slangasek> has this particular livecd-rootfs code been tested before upload?
<slangasek> cyphermox: an ubuntu-server build still does something useful: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/zesty/ubuntu-server/+build/94540
<slangasek> cyphermox: but a build of ubuntu-server-live in my own ppa did nothing different
<cyphermox> wat
<cyphermox> it was working here.
<slangasek> were you feeding any additional json when you were building?
<slangasek> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/zesty/ubuntu-server-live/+build/94542
<slangasek> after setting project=ubuntu-server in the metadata
<slangasek> that's evidently not passed by ubuntu-cdimage
<slangasek> and maybe I should also be setting subproject there
<cyphermox> https://launchpad.net/~cyphermox/+livefs/ubuntu/zesty/subiquity/+build/94541
<cyphermox> the most we'd be missing is subproject; but then it should still be building an ubuntu-server image
<cyphermox> what's different in your last build?
<cyphermox> I can't read, it's too late
<cyphermox> I thought you knew how to create livefses! ;)
<slangasek> ... I do, I was following your script which populated it with empty json
<slangasek> assumed you had tested that ;)
<cyphermox> the script just does the creation
<cyphermox> we'll still be missing subproject.
<slangasek> yes, with empty json, you could specify non-empty at creation time :)
<cyphermox> I didn't think of it
<slangasek> anyway, subproject set, maybe that'll be more useful
<cyphermox> I could get it to do the json metadata with a user-provided json file
<slangasek> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/zesty/ubuntu-server-live/+build/94543 log looks more promising
<cyphermox> yep
<cyphermox> oops.
<slangasek> ?
<cyphermox> I never removed set -x and some echoes.
<slangasek> ah
<slangasek> 'sudo [...] snap download'?  why sudo?
<cyphermox> muscle memory, I suppose.
<cyphermox> it shouldn't be necessary.
<slangasek> cyphermox: alright, the api-triggered build succeeded, and I've triggered a build from nusakan as well, and now I'm dropping off
<cyphermox> ok
 * cyphermox -> sleep
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Zesty Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Zesty Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Zesty Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Zesty Final] has been marked as ready
<davmor2> sil2100, infinity: Moving onto mini.iso
<rbalint> slangasek: surprising to see livecd-rootfs passing only on ppc64el :-)
<sil2100> davmor2: \o/
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Zesty Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Zesty Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Zesty Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Zesty Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Zesty Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Zesty Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Zesty Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Zesty Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Zesty Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Zesty Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Zesty Final] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Zesty Final] has been marked as ready
<davmor2> infinity: hmm I'm not hitting the hang that the guy on the tracker is seeing on hardware or vm so not sure what is going on there mini.iso for amd64 and i386 are now completed
<sil2100> davmor2: woot, thanks!
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-74.95~14.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-74.95] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (yakkety-proposed/main) [4.8.0-48.51] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.8.0-48.51~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-74.95~14.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-74.95]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.8.0-48.51~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (yakkety-proposed) [4.8.0-48.51]
-queuebot:#ubuntu-release- Unapproved: ovito (zesty-proposed/universe) [2.8.1+dfsg2-5 => 2.8.1+dfsg2-5ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ovito [source] (zesty-proposed) [2.8.1+dfsg2-5ubuntu1]
<ogra_> hmm, archive.canonical.com is unusably slow ...
<ogra_> (dont hit people that when they test with "install additional software" enabled ? adonbe-flashpulgin is downloading since 10+ minutes)
<ogra_> *adobe
<jbicha> ogra_: yes, I mentioned that yesterday, I think one problem is that there was a new Flash update for everyone published on Tuesday LP: #1682107
<ubot5> Launchpad bug 1682107 in ubiquity (Ubuntu) "[ubiquity] adobe-flashplugin download is slow" [Undecided,Invalid] https://launchpad.net/bugs/1682107
<ogra_> jbicha, right, but there is no reason for that server to be slow, archive.u.c isnt slow either ...
 * ogra_ me too's the bug
<jbicha> too many people trying to download the same file, with no mirrors
<ogra_> well, thats the same as security.u.c ... :)
<jbicha> I don't know if me-too-ing will help much for a closed bug :|
<ogra_> oh, i missed that
<wgrant> archive.c.c should be quick again now. There was just a few minutes of heavy traffic.
<wgrant> security.u.c doesn't have the same problem, since security updates are published to -updates too
<wgrant> So most hosts get security updates from mirrors
<wgrant> (but security.u.c is sometimes problematic too)
<fossfreedom_> hmm - just reading on omgubuntu - people seem to have the ability to login to gnome-shell as well as unity and unity8 on the normal ubuntu ISO
<jbicha> fossfreedom_: gnome-shell is not included by default in 17.04: http://releases.ubuntu.com/17.04/ubuntu-17.04-desktop-amd64.manifest
<fossfreedom_> odd that two different people reported the issue
<jbicha> I think that's user error, the other article has step 16: Install gnome-shell
<fossfreedom_> ah - makes sense now.
* Laney changed the topic of #ubuntu-release to: Released: Xenial 16.04.2, Zesty | Archive: closed | ? 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
<tsimonq2> infinity: You're up early!
<tsimonq2> :D
<infinity> tsimonq2: It's 2:14pm.
<tsimonq2> infinity: Oh. :P
<davmor2> infinity: well that was nice and smooth
<Laney> no you
<cyphermox> morning
<LocutusOfBorg> infinity, can we start asking when the AA will open? :p
<LocutusOfBorg> seriously, nice release!
-queuebot:#ubuntu-release- Builds: 38 entries have been added, updated or disabled
<tsimonq2> It was a super quick cycle imho
<infinity> LocutusOfBorg: No.
<LocutusOfBorg> (it was a joke :) )
 * LocutusOfBorg goes to upvote the release topic on slashdot https://slashdot.org/recent
<bdmurray> Laney: So you think your patch is worth testing?
<bdmurray> infinity: Should we hold off on modifying metarelease until bug 1681566 is sorted?
<ubot5> bug 1681566 in virtualbox (Ubuntu) "nvidia-375 DKMS module not recompiled on upgrade to 17.04" [Undecided,Confirmed] https://launchpad.net/bugs/1681566
<infinity> bdmurray: Yes.
<bdmurray> Laney, infinity: I did an upgrade test (it worked) and updated the bug.
<Laney> bdmurray: Ta.
-queuebot:#ubuntu-release- Unapproved: dkms (zesty-proposed/main) [2.3-3 => 2.3-3ubuntu1] (core)
<bdmurray> Laney: For good measure I installed zesty dkms on yakkety and upgraded the kernel and that worked too.
<Laney> bdmurray: It's in the queue now
<Laney> Did someone SRUify the bug?
 * Laney refuses to open it to find out :P
<bdmurray> Laney: No.
-queuebot:#ubuntu-release- Unapproved: rejected golang-1.6 [source] (xenial-proposed) [1.6.2-0ubuntu5~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted dkms [source] (zesty-proposed) [2.3-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted golang-1.6 [source] (yakkety-proposed) [1.6.3-1ubuntu1.2]
<ogra_> AAAAAAAAAAAAAAAAAAAAAAAAA
<ogra_> !
<Pici> AAAA
 * Ursinha hugs ogra_
<Ursinha> I don't know why you are screaming, but just in case
 * nacc assumes aa-series naming
 * ogra_ hugs Ursinha (meant to do that anyway :) )
<Ursinha> :)
<ogra_> Ursinha, that was a praise for infinity's nicely crafted mail ;)
<Ursinha> aah :)
<davmor2> I thought he was going for an ascii  christmas tree
<ogra_> only the right half though
<rbasak> "Actually"
<rbasak> Not sure if that was meant to be ironic or not!
<bdmurray> sil2100: Did I hear you are verifying bug 1681566?
<ubot5> bug 1681566 in dkms (Ubuntu Zesty) "nvidia-375 DKMS module not recompiled on upgrade to 17.04" [Undecided,Fix committed] https://launchpad.net/bugs/1681566
<bdmurray> You'll need to manually install dkms as -proposed will get disabled on upgrade.
<sil2100> bdmurray: yeah, prepping up a yakkety env as we speak
<bdmurray> sil2100: ^^
<infinity> bdmurray: Yo, speaking of things enabled/disabled.  On security-only systems, security is used for the upgrade too, right?
<infinity> bdmurray: (I was planning to copy this to security, due to the high impact nature of the oops)
<bdmurray> infinity: As far as I know, yes.
<bdmurray> I could test that now.
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (zesty-proposed/main) [2.441 => 2.441.1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted golang-1.6 [source] (xenial-proposed) [1.6.2-0ubuntu5~16.04.2]
<bdmurray> infinity: I upgraded from X to Y with -security and apt 1.3.3 is installed at the end of that.
<sil2100> Fix looks good so far, I already saw when the upgrade was happening that the module was rebuilt
<cyphermox> slangasek: ^ can I haz review for livecd-rootfs please?
<bdmurray> sil2100: for both kernels?
<sil2100> I think so, but I will know now after I has rebooted
<sil2100> I can has a working system then to check
<sil2100> bdmurray: yep, for both kernels
<sil2100> Putting details in the bug
<sil2100> I guess it's goodish, I suppose?
<sil2100> Is there anything specific expected?
<bdmurray> Looking, does dkms status list modules for both kernels?
<sil2100> Yes
<sil2100> As per output pasted to the bug
<bdmurray> and "grep 'Building for' in /var/log/dist-upgrade/apt.log"?
<slangasek> cyphermox: it occurs to me that you could just do ubuntu-server:|ubuntu-base:*[...]) and not add the extra case
<slangasek> cyphermox: would that be more or less clear?
<cyphermox> I don't mind either way; seems more explicit the way I uploaded it; but you can see it differently
<cyphermox> either way seems pretty clear.
<sil2100> bdmurray: hm, strangely not much useful info there
<clivejo> will this dkms fix mean a respin of the release ISO?
<bdmurray> sil2100: Did you use do-release-upgade?
<sil2100> Yes, as per bug
<sil2100> do-release-upgrade -d
<bdmurray> clivejo: no, its only an issue for multiple kernels
<nacc> clivejo: i don't believe so, as it won't affect new installs
<sil2100> bdmurray: http://paste.ubuntu.com/24374912/ is my apt.log
<bdmurray> sil2100: sorry, apt-term.log
<sil2100> hmm
 * cyphermox -> pea soup, brb
<sil2100> Building for 4.8.0-45-generic
<sil2100> Building for 4.8.0-45-generic
<sil2100> Building for architecture x86_64
<sil2100> Argh
<sil2100> Darn it, re-trying
<sil2100> bdmurray: scratch this result, wait 10 minutes
<slangasek> cyphermox: on balance I think your existing patch is clearer, ubuntu-server:| makes it hard to see the missing *
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (zesty-proposed) [2.441.1]
<bdmurray> slanagasek: Could you have a look at my apt-xapian-index Zesty upload?
<slangasek> bdmurray: sure!
<bladernr`> out of curiosity, how long until do-release-upgrade will work for zesty GA?  I noticed that do-release-upgrade -d still seems to load zesty, but -p or simply do-release-upgrade still says there is nothig available.
<bladernr`> maas seems to be deploying GA now though.
<slangasek> bladernr`: we have at least one SRU that's critical to land first because of dkms impact
<bladernr`> ahhh ok.  Thanks.  I have a few systems to upgrade adn run tests on, so I'll wait for that
<bdmurray> shouldn't be much longer though
<bladernr`> thanks slangasek bdmurray
<bdmurray> bladernr`: nothing changes between -p and not -p
-queuebot:#ubuntu-release- Unapproved: accepted apt-xapian-index [source] (zesty-proposed) [0.47ubuntu13]
<bdmurray> bladernr`: well aside of the dkms fix
<bdmurray> sil2100: I'm running another upgrade too fwiw
<sil2100> It's almost donnish here
<bdmurray> bladernr`: Other than the dkms change why would you wait for the metarelease file (which affects the need to use -p) to change? I feel like there is a misconception that something magical happens when you don't have to use -p.
<bladernr`> I just wanted to be sure that what I was installing was GA level, that's all.
<tsimonq2> infinity: I applaud your humor in that email :P
<bladernr`> so yeah, in my mind -d means non-ga Dev release stuff, -p means ready to go, and no - is GA.  But FWIW, when I use -p I get the same "No release available' message anyway.
<bladernr`> ubuntu@s1lp9g003:~$ sudo do-release-upgrade -p
<bladernr`> Checking for a new Ubuntu release
<bladernr`> No new release found
<bdmurray> bladernr`: sorry, I meant -d
<bladernr`> ahhh, ok.  So yeah, as I said, my perception of -d is "this is dev and will change and could be broken" while -p and no opts is "this is release or release worthy for normal use"
<tsimonq2> cyphermox: Mmmm pea soup
<bdmurray> bladernr`: that perception regarding -d is true until the devel release is released.
<bdmurray> bladernr`: so right now it'll be the same thing as when I flip the metarelease file
<bladernr`> bdmurray, ack.  upgrades underway.  Thanks for clarifying that.
<sil2100> bdmurray: ok, much better now
<sil2100> Building for 4.8.0-45-generic 4.10.0-19-generic
<sil2100> Building for 4.8.0-45-generic 4.10.0-19-generic
<sil2100> Building for architecture x86_64
<xnox_> infinity, that's the TEST-12 failing https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1672542
<ubot5> Ubuntu bug 1672542 in systemd (Ubuntu Zesty) "systemd 232-18ubuntu1 ADT test failure with linux 4.10.0-13.15" [Undecided,New]
<sil2100> bdmurray: sorry about the wasted time, I was an idiot and tested the wrong thing
<ogra_> but good that this gets some testing too
<ogra_> :)
<sil2100> bdmurray: so building for two now as per your test results
<bdmurray> sil2100: okay, I think its good to go then.
<sil2100> Noted in the bug, setting verification-done
<sil2100> bdmurray, Laney: done
<bdmurray> sil2100: I think infinity is the one who needs notifying
<sil2100> He's here, he knows
<bdmurray> Okay
<Laney> sil2100: good job done well
<Laney> well good job done?
<slangasek> Ford: Quality is Job 1
<slangasek> Fnord: Quality is Well Jobbed
<xnox_> slangasek, breaks often! fixed quickly!
<slangasek> Ford, 2017: systemd is pid 1?
<bdmurray> Laney: I don't think the dkms change needs SRUing.
<infinity> bdmurray: Wat?
<infinity> bdmurray: It's released now.  But also, wat?
<infinity> bdmurray: PS: Wat?
<bdmurray> infinity: I mean SRUing to things other than Z!
<tsimonq2> infinity: systemd-resolved Likes Breaking Everything.
<infinity> bdmurray: Oh.  Indeed.  Yes, it's only needed in Z.
<tsimonq2> infinity: https://ubuntuforums.org/showthread.php?t=2356828
<slangasek> just noticed from the release announcement that the kernel versioning has caught up with Ubuntu's
<slangasek> can I claim to be running zesty with a warty kernel?
<apw> slangasek, we should do that, codename the kernel by the nearest ubuntu release by version
<tsimonq2> infinity: I had this problem last night while doing QA and didn't think anything of it, but ubiquity didn't think I was connected to the internet. This might be why.
<tsimonq2> infinity: When cyphermox comes back from his pea soup, he has more details. I sent him my logs, so he knows the terminology behind the broken bits.
<bdmurray> "ukuu"?
<infinity> tsimonq2: That forum post is not a remotely actionably bug report.
<tsimonq2> infinity: Then let me get you a real one. bug 1647031 is pretty spot on.
<ubot5> bug 1647031 in systemd "systemd-resolvedâs 127.0.0.53 server does not follow CNAME records" [Unknown,New] https://launchpad.net/bugs/1647031
<infinity> tsimonq2: That was fixed.
<apw> yeah i remember that change going by
<tsimonq2> infinity: Maybe. But it accurately describes the problems I'm seeing.
<bdmurray> infinity: but it's "(VERY BAD !)"
<infinity> bdmurray: Indeed.
<slangasek> lp:~ubuntu-sru/britney/hints-ubuntu-zesty/ created fwiw
<tsimonq2> All I know is that something regressed, infinity.
<infinity> slangasek: Iz branch from dev?
<slangasek> infinity: yes
<infinity> \o/
<slangasek> we ought to find a spot for that on the checklist, if we're ever to start using p-m directly for SRU releases
<infinity> bdmurray: So, yes.  dkms is released, I'd recommend giving a couple of hours for downstream mirrors to pick it up before flipping meta-release.
<infinity> slangasek: Probably belongs right at the end of ReleaseProcess.
<bdmurray> infinity: roger
<flocculant> thanks for the work release peeps - have a good break :)
<slangasek> infinity: agreed and done
<cyphermox> tsimonq2: tbf, your issue may or may not have anything to do with that forum port or the comments about DNSSEC
<cyphermox> you should file a new bug; and test if disabling DNSSEC helps; but as I recall your issue was timeouts and that's probably not dnssec.
<wxl> yeah tsimonq2 the fix on the forum is manually setting nameservers
<infinity> bdmurray: Make that "wait at least 4 hours", as we only trigger tertiary mirrors every 4h.
<infinity> bdmurray: So, meh.  If it gets late, change it in the morning.  Your call.
<bdmurray> infinity: 4h is still mid-afternoon for me
<infinity> bdmurray: Kay.  I say do it around your EODish, then.
<tsimonq2> If I want to work on merges from Debian in universe, can I assume developers are checking bug reports with patches for the packages they upload?
<tsimonq2> I mean, before uploading, do people check the sponsorship queue?
<tsimonq2> ack wxl cyphermox
<tsimonq2> Reason being, I anticipate being antisocial this weekend and making a dent in merges.ubuntu.com and I don't want to dup work
<tsimonq2> :P
-queuebot:#ubuntu-release- Unapproved: xapian-bindings (zesty-proposed/main) [1.4.3-1 => 1.4.3-1ubuntu1] (ubuntu-server)
<wxl> if this networking problem is somehow related to systemd-resolv, then shouldn't EVERYONE be having a problem?
<slangasek> the network is dark and full of terrors, and there could be any number of latent bugs in systemd-resolved that are only reproducible in select environments
<wxl> alright, well, do we actually have a bug tracking all this?
<slangasek> that's up to the person who's seeing the bug to file it
<wxl> yeah. and i'm not. and so far haven't found one that is :/
<slangasek> the dnssec problem is understood, and xnox is working on that
<slangasek> but it's not at all clear that tsimonq2 is seeing a dnssec-related problem
<slangasek> ("understood" in the sense of "we know resolved isn't doing dnssec right")
<wxl> is that bug 1647031 ?
<ubot5> bug 1647031 in systemd "systemd-resolvedâs 127.0.0.53 server does not follow CNAME records" [Unknown,New] https://launchpad.net/bugs/1647031
<slangasek> no
<slangasek> also, why is that bug open again?
<wxl> nextcloud
<slangasek> oh a different task, right
<wxl> for systemd, nm it's fixed
<wxl> if you find one, let me know. meanwhile, brb
<cyphermox> tsimonq2: it's maybe a bit early for that seeing as AA isn't open; but it's customary to ask people who last uploaded/merged something before taking it, and that tends to reduce work duplication.
<Ukikie> cyphermox: ...Aren't you supposed to be outside? ;)
<cyphermox> I was outside for a moment to get a propane tank and food
<tsimonq2> cyphermox: But but but... Adam said in his email we could get a head start if we wanted :D
<tsimonq2> cyphermox: But yes, I always do that in the bug report anyways.
<cyphermox> tsimonq2: you sure can, I'm just saying it can't be uploaded until the archive is open, by then, things may change.
<cyphermox> I'm going to go back outside soonish, but there's work to be done still
<tsimonq2> cyphermox: Ok :)
<bdmurray> infinity: meta-release is done
#ubuntu-release 2017-04-14
-queuebot:#ubuntu-release- Unapproved: rejected account-plugins [sync] (xenial-proposed) [0.13+16.04.20161212-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected gnome-control-center-signon [sync] (xenial-proposed) [0.1.9+16.04.20161212-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted logrotate [sync] (yakkety-proposed) [3.8.7-2ubuntu2.16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted logrotate [sync] (xenial-proposed) [3.8.7-2ubuntu2.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted logrotate [sync] (trusty-proposed) [3.8.7-1ubuntu1.1]
<nacc> hrm, odd situation in #ubuntu -- someone upgraded to 17.04, which no longer ships software-center, but in 16.10, gnome-software opens software-center. On upgrade it still does. Shouldn't we do something so that software-center gets autoremoved?
<nacc> hrm, nevermind
<nacc> misunderstanding on my part
-queuebot:#ubuntu-release- Unapproved: uvtool (trusty-proposed/universe) [0~bzr92-0ubuntu1 => 0~bzr92-0ubuntu1.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted uvtool [source] (trusty-proposed) [0~bzr92-0ubuntu1.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-trusty [amd64] (precise-proposed) [3.13.0-117.164~precise1]
<wxl> um
<wxl> lubuntu alternates for 17.04 appear to go nowhere https://d18fwbn370j49e.cloudfront.net/lubuntu-17.04-alternate-amd64.iso
<Bashing-om> ^ confirmed " This XML file does not appear to have any style information associated with it. The document tree is shown below." .
<bdmurray> wxl: Somebody is working on it.
<tsimonq2> infinity, slangasek: People have been piggybacking on bug 1647031 with relevant updates.
<ubot5> bug 1647031 in systemd "systemd-resolvedâs 127.0.0.53 server does not follow CNAME records" [Unknown,New] https://launchpad.net/bugs/1647031
<slangasek> tsimonq2: ITYM irrelevant updates, since that bug is fixed
<tsimonq2> slangasek: :P
<slangasek> tsimonq2: people really need to open fresh bug reports instead of dogpiling on already-fixed bugs with vaguely related symptoms
<tsimonq2> slangasek: Updates relevant to me, not relevant to the bug report :P
#ubuntu-release 2017-04-15
<estan_> how long does it normally take for someone to have a look at a package in the upload queue? (in my case qtbase-opensource-src 5.5.1+dfsg-16ubuntu7.4 , which has a fix for a bug i reported)?
<estan_> it's now been there for more than three weeks. i can't remember it taking anywhere near this long last time i did an SRU request, but maybe i was just lucky then :p
<estan_> i completely understand if people are swamped, and thank you for all the tireless work. i just like to know if it's normal that things linger in the queue for that long.
<jbicha> estan_: it's a holiday weekend now so if you don't get a reply, I'd ask again next week (not Monday)
<estan_> jbicha: ah yes, i'll do that.
-queuebot:#ubuntu-release- Unapproved: mozjs38 (zesty-proposed/universe) [38.2.1~rc0-0ubuntu5 => 38.2.1~rc0-0ubuntu6] (ubuntugnome)
#ubuntu-release 2017-04-16
<nacc> estan_: is it just me or did 7.3 not get published outside the ppa?
<nacc> estan_: oh i see, there are two syncs in the queu
<estan_> nacc: ah yes, and the uploader is hoping that whoever gets around to approving them will just approve the latest one (7.4), since it includes the 7.3 changes as well (see dmitry's comment here https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1598173/comments/12)
<ubot5> Ubuntu bug 1598173 in qtbase-opensource-src (Ubuntu Xenial) "Please consider SRU of "xcb: Compress mouse motion and touch update events"" [Undecided,New]
<estan_> (that's from the bug i was talking about btw, https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1598173)
<ubot5> Ubuntu bug 1598173 in qtbase-opensource-src (Ubuntu Xenial) "Please consider SRU of "xcb: Compress mouse motion and touch update events"" [Undecided,New]
<nacc> estan_: yeah, i wonder if the sru team will ask they just get folded together then (as otherwise we're unnecessarily burning a version between) -- but i'm not an sru team member
<nacc> estan_: also, i imagine that desktop-affecting changes maybe are harder to figure out and approve :)
<estan_> aha. alright, yes i guess there's a risk of that, i don't know how it'll work. i got the feeling that dmitry was experienced and thought this was OK, but i may be wrong :)
<nacc> estan_: yeah, i'm not sure myself, i think jbicha's advice is probably good, i doubt any sru folks are around right now :)
<estan_> right, i can understand that. last time i requested an SRU it was for Octave, so i understand that it was quicker then.
<estan_> yup, i'll stick around.
<estan_> not doing anything really for easter myself this year, so catching up with FOSS stuff. problem is, everyone's gone, heh.
<nacc> estan_: :)
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-autohidetopbar (zesty-proposed/universe) [20161203-1 => 20161203-1ubuntu1] (no packageset)
#ubuntu-release 2018-04-09
-queuebot:#ubuntu-release- Unapproved: gnucash (bionic-proposed/universe) [1:2.6.18-1 => 1:2.6.19-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gnome-tweaks (bionic-proposed/universe) [3.28.0-1 => 3.28.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-tweaks [sync] (bionic-proposed) [3.28.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted gnucash [sync] (bionic-proposed) [1:2.6.19-1]
-queuebot:#ubuntu-release- Unapproved: bubblewrap (bionic-proposed/universe) [0.2.0-4 => 0.2.1-1] (ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: network-manager-pptp (bionic-proposed/main) [1.2.4-5build1 => 1.2.6-1] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-autohidetopbar (bionic-proposed/universe) [20171126-1 => 20171126-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ruby-gnome2 (bionic-proposed/universe) [3.2.3-1 => 3.2.3-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-autohidetopbar [sync] (bionic-proposed) [20171126-2]
-queuebot:#ubuntu-release- Unapproved: spectre-meltdown-checker (bionic-proposed/universe) [0.35-1 => 0.36-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ruby-gnome2 [sync] (bionic-proposed) [3.2.3-2]
-queuebot:#ubuntu-release- Unapproved: devhelp (bionic-proposed/main) [3.28.0-1 => 3.28.1-1] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted spectre-meltdown-checker [sync] (bionic-proposed) [0.36-1]
<tsimonq2> infinity, slangasek: https://lists.ubuntu.com/archives/ubuntu-release/2018-April/004387.html <-- my proposal regarding getting rid of milestones, resulting from the discussion we had a few weeks ago.
-queuebot:#ubuntu-release- Unapproved: ukui-panel (bionic-proposed/universe) [1.1.2-0ubuntu1 => 1.1.3-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: libbpp-popgen (bionic-proposed/universe) [2.4.0-1 => 2.4.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libbpp-popgen [sync] (bionic-proposed) [2.4.0-2]
-queuebot:#ubuntu-release- Unapproved: libbpp-phyl-omics (bionic-proposed/universe) [2.4.0-1 => 2.4.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libbpp-raa (bionic-proposed/universe) [2.3.2-1 => 2.4.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libbpp-phyl-omics [sync] (bionic-proposed) [2.4.0-2]
-queuebot:#ubuntu-release- Unapproved: accepted libbpp-raa [sync] (bionic-proposed) [2.4.0-2]
-queuebot:#ubuntu-release- New binary: libbpp-popgen [s390x] (bionic-proposed/universe) [2.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-popgen [amd64] (bionic-proposed/universe) [2.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-raa [amd64] (bionic-proposed/universe) [2.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-raa [s390x] (bionic-proposed/universe) [2.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-popgen [ppc64el] (bionic-proposed/universe) [2.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-raa [ppc64el] (bionic-proposed/universe) [2.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-popgen [i386] (bionic-proposed/universe) [2.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-raa [i386] (bionic-proposed/universe) [2.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-raa [armhf] (bionic-proposed/universe) [2.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-popgen [arm64] (bionic-proposed/universe) [2.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-raa [arm64] (bionic-proposed/universe) [2.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-popgen [armhf] (bionic-proposed/universe) [2.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-seq-omics [s390x] (bionic-proposed/universe) [2.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-seq-omics [ppc64el] (bionic-proposed/universe) [2.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-seq-omics [i386] (bionic-proposed/universe) [2.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-seq-omics [amd64] (bionic-proposed/universe) [2.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-seq-omics [arm64] (bionic-proposed/universe) [2.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-seq-omics [armhf] (bionic-proposed/universe) [2.4.0-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: oslo-sphinx (bionic-proposed/universe) [4.18.0-0ubuntu1 => 4.18.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted oslo-sphinx [sync] (bionic-proposed) [4.18.0-2]
-queuebot:#ubuntu-release- Unapproved: ubuntukylin-theme (bionic-proposed/universe) [1.7.5 => 1.7.6] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: ukui-settings-daemon (bionic-proposed/universe) [1.1.5-0ubuntu1 => 1.1.6-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ukwm (bionic-proposed/universe) [1.1.7-0ubuntu1 => 1.1.8-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ukui-media (bionic-proposed/universe) [1.1.1-0ubuntu1 => 1.1.2-0ubuntu1] (no packageset)
<flocculant> !team | thoughts on https://lists.ubuntu.com/archives/ubuntu-release/2018-April/004387.html
<tsimonq2> \o/
<flocculant> wrong channel
<flocculant> I'm not awake
<tsimonq2> hehe
<tsimonq2> Â¯\_(ã)_/Â¯
<Bashing-om> flocculant: Whatever you big boys decide to do .. I will do what I can to help .
<valorie> big boys!
 * valorie is not a boy in any sense of the word
<Bashing-om> hehe - It's the role - that I play such a small boy part of :)
-queuebot:#ubuntu-release- Unapproved: libtickit (bionic-proposed/universe) [0.2-2 => 0.2-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted libtickit [source] (bionic-proposed) [0.2-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: pam-wrapper (bionic-proposed/universe) [1.0.2-1 => 1.0.6-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pam-wrapper [sync] (bionic-proposed) [1.0.6-1]
<cpaelzer> Hi, anybody of the release team around that could consider FFE-ack'ing bug 1762315 ?
<ubot5`> bug 1762315 in qemu (Ubuntu) "slirp: Add domainname option to slirp's DHCP server" [Undecided,New] https://launchpad.net/bugs/1762315
<cpaelzer> Another bug that would be great to have FFE exception soon would be bug 1761899
<ubot5`> bug 1761899 in nginx (Ubuntu) "[FFe] Please merge with 1.13.10-1 from Debian unstable" [Undecided,New] https://launchpad.net/bugs/1761899
<cpaelzer> good morning sil2100
<cpaelzer> seeing you join, might I hijack you for an FFE-view on 1761899 and 1762315 ?
<sil2100> Morning!
-queuebot:#ubuntu-release- Unapproved: pocl (bionic-proposed/universe) [1.0-2ubuntu1 => 1.1-4] (no packageset) (sync)
<sil2100> cpaelzer: let me take a look in 5 minutes
<cpaelzer> thanks, in case of questions let me know
-queuebot:#ubuntu-release- Unapproved: accepted pocl [sync] (bionic-proposed) [1.1-4]
<cpaelzer> sil2100: I'm dropping my daughter at kindergarden now, but really if there is anything while reviewing those bugs for FFE I'll be here with you again shortly
<sil2100> cpaelzer: did you do a test build of the new version?
<sil2100> cpaelzer: of nginx
<cpaelzer> sil2100: we did on the MP
<cpaelzer> sil2100: let me get you a linkg
<cpaelzer> sil2100: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3228/+packages
<cpaelzer> sil2100: from my MP review https://code.launchpad.net/~nacc/ubuntu/+source/nginx/+git/nginx/+merge/342762/comments/895908
<sil2100> cpaelzer: thanks!
<sil2100> Yeah, didn't look at the MP, maybe I should have ;)
-queuebot:#ubuntu-release- Unapproved: libtickit (bionic-proposed/universe) [0.2-2ubuntu1 => 0.2-2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted libtickit [source] (bionic-proposed) [0.2-2ubuntu2]
<jamespage> doko: next cycle
-queuebot:#ubuntu-release- New binary: libtickit [amd64] (bionic-proposed/universe) [0.2-2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: libtickit [s390x] (bionic-proposed/universe) [0.2-2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: libtickit [ppc64el] (bionic-proposed/universe) [0.2-2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: libtickit [i386] (bionic-proposed/universe) [0.2-2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: libtickit [arm64] (bionic-proposed/universe) [0.2-2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New sync: starjava-topcat (bionic-proposed/primary) [4.5.1-1]
-queuebot:#ubuntu-release- New binary: libtickit [armhf] (bionic-proposed/universe) [0.2-2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New: accepted libtickit [amd64] (bionic-proposed) [0.2-2ubuntu2]
-queuebot:#ubuntu-release- New: accepted libtickit [armhf] (bionic-proposed) [0.2-2ubuntu2]
-queuebot:#ubuntu-release- New: accepted libtickit [ppc64el] (bionic-proposed) [0.2-2ubuntu2]
-queuebot:#ubuntu-release- New: rejected starjava-topcat [sync] (bionic-proposed) [4.5.1-1]
-queuebot:#ubuntu-release- New: accepted libtickit [arm64] (bionic-proposed) [0.2-2ubuntu2]
-queuebot:#ubuntu-release- New: accepted libtickit [s390x] (bionic-proposed) [0.2-2ubuntu2]
-queuebot:#ubuntu-release- New: accepted libtickit [i386] (bionic-proposed) [0.2-2ubuntu2]
-queuebot:#ubuntu-release- New: accepted libbpp-seq-omics [amd64] (bionic-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- New: accepted libbpp-seq-omics [arm64] (bionic-proposed) [2.4.0-2]
-queuebot:#ubuntu-release- New: accepted libbpp-seq-omics [i386] (bionic-proposed) [2.4.0-2]
-queuebot:#ubuntu-release- New: accepted libbpp-seq-omics [amd64] (bionic-proposed) [2.4.0-2]
-queuebot:#ubuntu-release- New: accepted libbpp-seq-omics [ppc64el] (bionic-proposed) [2.4.0-2]
-queuebot:#ubuntu-release- New: accepted libbpp-seq-omics [armhf] (bionic-proposed) [2.4.0-2]
-queuebot:#ubuntu-release- New: accepted libbpp-popgen [amd64] (bionic-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- New: accepted libbpp-popgen [armhf] (bionic-proposed) [2.4.0-2]
-queuebot:#ubuntu-release- New: accepted libbpp-popgen [ppc64el] (bionic-proposed) [2.4.0-2]
-queuebot:#ubuntu-release- New: accepted libbpp-popgen [amd64] (bionic-proposed) [2.4.0-2]
-queuebot:#ubuntu-release- New: accepted libbpp-popgen [s390x] (bionic-proposed) [2.4.0-2]
-queuebot:#ubuntu-release- New: accepted libbpp-popgen [i386] (bionic-proposed) [2.4.0-2]
-queuebot:#ubuntu-release- New: accepted libbpp-popgen [arm64] (bionic-proposed) [2.4.0-2]
-queuebot:#ubuntu-release- New: accepted libbpp-raa [arm64] (bionic-proposed) [2.4.0-2]
-queuebot:#ubuntu-release- New: accepted libbpp-raa [i386] (bionic-proposed) [2.4.0-2]
-queuebot:#ubuntu-release- New: accepted libbpp-raa [s390x] (bionic-proposed) [2.4.0-2]
-queuebot:#ubuntu-release- New: accepted libbpp-seq-omics [s390x] (bionic-proposed) [2.4.0-2]
-queuebot:#ubuntu-release- New: accepted libbpp-raa [amd64] (bionic-proposed) [2.4.0-2]
-queuebot:#ubuntu-release- New: accepted libbpp-raa [ppc64el] (bionic-proposed) [2.4.0-2]
-queuebot:#ubuntu-release- New: accepted libbpp-raa [armhf] (bionic-proposed) [2.4.0-2]
-queuebot:#ubuntu-release- New: accepted libbpp-seq-omics [arm64] (bionic-proposed) [2.4.0-1]
<sil2100> cpaelzer: ok, both approved
-queuebot:#ubuntu-release- Unapproved: httping (bionic-proposed/universe) [2.5-1build1 => 2.5-1.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted httping [sync] (bionic-proposed) [2.5-1.1]
<cpaelzer> thank you so much sil2100
-queuebot:#ubuntu-release- New source: buildbot (bionic-proposed/primary) [1.1.1-1]
-queuebot:#ubuntu-release- Unapproved: gcc-8 (bionic-proposed/main) [8-20180406-0ubuntu1 => 8-20180408-0ubuntu1] (core) (sync)
<slangasek> andyrock: hi, thanks for the branch on software-properties.  Are you confident that moving the deps is not going to leave any runtime failures on systems that have software-properties-common / python3-software-properties installed but not software-properties-gtk?
-queuebot:#ubuntu-release- New: accepted buildbot [source] (bionic-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-8 [sync] (bionic-proposed) [8-20180408-0ubuntu1]
-queuebot:#ubuntu-release- New binary: buildbot [amd64] (bionic-proposed/none) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted matplotlib [source] (bionic-proposed) [2.1.1-2ubuntu3]
-queuebot:#ubuntu-release- New: accepted buildbot [amd64] (bionic-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- Unapproved: libgoogle-gson-java (bionic-proposed/universe) [2.4-2 => 2.8.2-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libgoogle-gson-java [sync] (bionic-proposed) [2.8.2-1]
-queuebot:#ubuntu-release- Unapproved: bppphyview (bionic-proposed/universe) [0.5.1-1 => 0.5.1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libbpp-phyl (bionic-proposed/universe) [2.3.2-2 => 2.3.2-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: bppsuite (bionic-proposed/universe) [2.3.2-1 => 2.3.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libbpp-qt (bionic-proposed/universe) [2.3.2-1 => 2.3.2-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted bppphyview [source] (bionic-proposed) [0.5.1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted libbpp-phyl [source] (bionic-proposed) [2.3.2-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted bppsuite [source] (bionic-proposed) [2.3.2-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted libbpp-qt [source] (bionic-proposed) [2.3.2-1build1]
<Laney> slangasek: don't know, sorry, I didn't chase it down
-queuebot:#ubuntu-release- Unapproved: maffilter (bionic-proposed/universe) [1.2.1+dfsg-1build1 => 1.2.1+dfsg-1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: physamp (bionic-proposed/universe) [1.0.3-1 => 1.0.3-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: maven-javadoc-plugin (bionic-proposed/universe) [3.0.0-3 => 3.0.0-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted maven-javadoc-plugin [source] (bionic-proposed) [3.0.0-3]
-queuebot:#ubuntu-release- Unapproved: accepted physamp [source] (bionic-proposed) [1.0.3-1build1]
<Laney> oh, you found it, ok
-queuebot:#ubuntu-release- Unapproved: accepted maffilter [source] (bionic-proposed) [1.2.1+dfsg-1build2]
<Laney> slangasek: ah, cdimage, no I guess mid-air collision
<Laney> slangasek: I checked http://releases.ubuntu.com/artful/ before updating and it said .1 already
<slangasek> ah, well then :)
<Laney> oh, you're here, hi
 * Laney expected replies in many hours :P
<slangasek> :)
<Laney> 67 emails @ubuntu.com
<Laney> guess IS haven't deleted that stuck instance yet ...
-queuebot:#ubuntu-release- Unapproved: maven-javadoc-plugin (bionic-proposed/universe) [3.0.0-3 => 3.0.0-4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted maven-javadoc-plugin [source] (bionic-proposed) [3.0.0-4]
<jbicha> slangasek: you're probably better off uploading the remaining bpp packages from the Debian git repos to get the 2.4 versions
<slangasek> jbicha: that sounds like work.  I was just attempting no-change rebuilds because I saw the transition was started (why?)
-queuebot:#ubuntu-release- Unapproved: vala (bionic-proposed/universe) [0.40.2-1 => 0.40.3-1] (ubuntu-desktop) (sync)
<jbicha> the whole bpp thing is a mess, hopefully it's getting a bit better, Debian bug 890400
<ubot5`> Debian bug 890400 in libbpp-core3 "libbpp-core3: ABI change without soname chenge" [Serious,Fixed] http://bugs.debian.org/890400
<slangasek> hmm but you synced the new upstream version rather than merging just a fix to debian/control?
<jbicha> I think the fix was the new upstream series
<jbicha> libbpp-core 2.3.2-1 was already stuck in bionic-proposed before I synced the 2.4 series
<slangasek> ok
<slangasek> otoh wasn't it stuck because the autopkgtests were broken, because the revdeps needed a rebuild?
-queuebot:#ubuntu-release- Unapproved: golang-go-dbus (bionic-proposed/universe) [1~bzr20150203-0ubuntu1 => 1~bzr20150203-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted golang-go-dbus [source] (bionic-proposed) [1~bzr20150203-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: moonshot-trust-router (bionic-proposed/universe) [1.4.1-1build1 => 1.4.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted moonshot-trust-router [source] (bionic-proposed) [1.4.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: globus-gridftp-server (bionic-proposed/universe) [12.4-1build1 => 12.5-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted globus-gridftp-server [sync] (bionic-proposed) [12.5-1]
<doko> slangasek: what is the regression in http://autopkgtest.ubuntu.com/packages/r/ruby-fakeweb/bionic/armhf ?
-queuebot:#ubuntu-release- Unapproved: nginx (bionic-proposed/main) [1.13.6-2ubuntu2 => 1.13.10-1ubuntu1] (ubuntu-server)
<slangasek> doko: 1.3.0+git20131202.48208f9+dfsg-3 is badtested; if it's the same failure we should probably update the hint version?
<doko> slangasek: asking because the only passing test doesn''t have a log
<slangasek> doko: ah. that's because wrong links are generated from logs of tests that were run during a previous release
<doko> old run: 88 runs, 207 assertions, 20 failures, 54 errors, 0 skips
<doko> new run: 192 tests, 296 assertions, 11 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications
<slangasek> yeah, the new package is much closer to passing. I'll hint it.
<acheronuk> slangasek: I'm just seeing what changes I can pull from kio-extras in debian, given that they are behind us in version. then I will test build what I get
<doko> slangasek: mvo claims a strange systemd setup to be the cause of the snapd autopkg test failure (on #snappy)
-queuebot:#ubuntu-release- Unapproved: kio-extras (bionic-proposed/universe) [4:17.12.3-0ubuntu1 => 4:17.12.3-0ubuntu2] (kubuntu)
<sil2100> doko: could you point me to the snapd failure if you have it handy?
<doko> sil2100: http://autopkgtest.ubuntu.com/packages/s/snapd/bionic/i386
<doko> <mvo> doko: I doubt its a real issue, this works fine in our GCE environment, we see close to 100% success there (sometimes network related failures). I will check with Laney.
<doko> <mvo> doko, Laney an interessting observation is that they all (the recent ones) die in "+ journalctl --sync\n\n<kill-timeout reached>". makes me wonder if something is wrong with the systemd setup on these instance
-queuebot:#ubuntu-release- Unapproved: mosquitto (bionic-proposed/universe) [1.4.15-1 => 1.4.15-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mosquitto [sync] (bionic-proposed) [1.4.15-2]
-queuebot:#ubuntu-release- Unapproved: gdb (bionic-proposed/main) [8.1-0ubuntu2 => 8.1-0ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: accepted gdb [source] (bionic-proposed) [8.1-0ubuntu3]
<Laney> anyone have any particular opinion on https://bugs.launchpad.net/ubuntu/+source/libzip/+bug/1674057 ?
<ubot5`> Ubuntu bug 1674057 in libzip (Ubuntu) "[FFe] upgrade libzip to version 1.5.0" [Wishlist,New]
-queuebot:#ubuntu-release- Unapproved: binutils (bionic-proposed/main) [2.30-14ubuntu2 => 2.30-15ubuntu1] (core)
<doko> Laney: given that we have a two year old version in the archive ... why not?
<Laney> because the new version might have bugs, it's late in the cycle, and it's a transition
<darkxst> Laney, it also switches to proven SSL code
<darkxst> upstream have been very responsive in my dealings with them
-queuebot:#ubuntu-release- Unapproved: accepted binutils [source] (bionic-proposed) [2.30-15ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted synfig [source] (bionic-proposed) [1.2.1-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted nginx [source] (bionic-proposed) [1.13.10-1ubuntu1]
<Laney> darkxst: yes I know, I'm asking what people thing, not judging
<Laney> think
<Laney> doko asked "why not?" and I answered that question
<darkxst> ok
<acheronuk> Laney: would be nice for better zip support in ark, but I we have been building using libarchive for a few releases now and have had no real screams of anguish from users
<acheronuk> *but we
<LocutusOfBorg> tjaalton, jbicha did you break somewhere virtualbox on guest for bionic? https://www.virtualbox.org/ticket/17623
<LocutusOfBorg> I see "Apr  7 09:00:35 bionic org.gnome.Shell.desktop[1214]: /usr/bin/gnome-shell: symbol lookup error: /usr/lib/x86_64-linux-gnu/libmutter-2.so.0: undefined symbol: glFramebufferTexture2D"
<darkxst> LocutusOfBorg, I think there is an upstream bug for that somewhere
<Laney> darkxst: probably grabbing a silo and uploading everything into that would be good
<tjaalton> LocutusOfBorg: I admit nothing :)
<LocutusOfBorg> I hope somebody will fix that soon, at least before release :/
-queuebot:#ubuntu-release- Unapproved: sssd (bionic-proposed/main) [1.16.0-5ubuntu2 => 1.16.1-1ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server)
<darkxst> Laney, sure, will do, what was the link to the CI-train again?
<darkxst> not used it in a while ;)
-queuebot:#ubuntu-release- Unapproved: vagrant-lxc (bionic-proposed/universe) [1.2.1-3ubuntu1 => 1.4.0-1] (ubuntu-cloud) (sync)
<apw> Laney, as it is removing a non-standard crypto implentation that sounds like a fair plus to me
<apw> darkxst, did i suggest you asked rat-liff about this?  did that happen?  this was on the assumption they might be strongly +1 on that basis
<Laney> darkxst: bileto.u.c
-queuebot:#ubuntu-release- Unapproved: accepted language-selector [source] (bionic-proposed) [0.187]
<darkxst> apw, I think you might have mentioned it and i didnt follow up on that
<darkxst> ratliff, can you take a look at bug 1674057
<ubot5`> bug 1674057 in libzip (Ubuntu) "[FFe] upgrade libzip to version 1.5.0" [Wishlist,New] https://launchpad.net/bugs/1674057
<Laney> it's not actually in main tho
-queuebot:#ubuntu-release- Unapproved: base-files (bionic-proposed/main) [10ubuntu1 => 10.1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: yard (bionic-proposed/universe) [0.9.12-1ubuntu3 => 0.9.12-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted yard [sync] (bionic-proposed) [0.9.12-2]
-queuebot:#ubuntu-release- Unapproved: accepted vagrant-lxc [sync] (bionic-proposed) [1.4.0-1]
-queuebot:#ubuntu-release- Unapproved: update-notifier (bionic-proposed/main) [3.189 => 3.190] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted pam [source] (artful-proposed) [1.1.8-3.2ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: accepted pam [source] (xenial-proposed) [1.1.8-3.2ubuntu2.1]
<jbicha> LocutusOfBorg: I use VirtualBox all the time, bionic guest on bionic host still works fine here
-queuebot:#ubuntu-release- Unapproved: usb-creator (bionic-proposed/main) [0.3.4 => 0.3.5] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rejected ibus [source] (xenial-proposed) [1.5.11-1ubuntu3~xenial1]
-queuebot:#ubuntu-release- Unapproved: ibus (xenial-proposed/main) [1.5.11-1ubuntu2 => 1.5.11-1ubuntu2.1] (input-methods, kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: ubuntu-system-service (bionic-proposed/main) [0.3 => 0.3.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-system-service [source] (bionic-proposed) [0.3.1]
-queuebot:#ubuntu-release- Unapproved: accepted usb-creator [source] (bionic-proposed) [0.3.5]
-queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (bionic-proposed) [3.190]
-queuebot:#ubuntu-release- Unapproved: accepted ibus [source] (xenial-proposed) [1.5.11-1ubuntu2.1]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [4.15.0-1004.4] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [4.15.0-1004.4]
-queuebot:#ubuntu-release- Unapproved: buildbot (bionic-proposed/universe) [1.1.1-1 => 1.1.1-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted buildbot [source] (bionic-proposed) [1.1.1-2]
<LocutusOfBorg> thanks jbicha, maybe some not so common configuration
<jbicha> maybe different version of virtualbox or guest drivers?
<LocutusOfBorg> https://answers.launchpad.net/ubuntu/+source/virtualbox/+question/665636
<LocutusOfBorg> this refers to something old
<LocutusOfBorg> but quoting vbox-dev irc channel "Hi, if I enable 3D in ubuntu 18.04 guest (on macos 10.13 host), I get the following error on bootup so that the login screen doesn't appear, just a black screen."
-queuebot:#ubuntu-release- Unapproved: libtemplate-perl (bionic-proposed/main) [2.24-1.2build5 => 2.27-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: qemu (bionic-proposed/main) [1:2.11+dfsg-1ubuntu5 => 1:2.11+dfsg-1ubuntu6] (ubuntu-server, virt)
<cpaelzer> Hi Release Team - for quite a few days I was collecting and testing qemu fixes.
<cpaelzer> It is now in Bionic unapproved and I wanted to ask to accept this soon if that would not crash with the image building
<cpaelzer> See https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=qemu
<cpaelzer> The reason I poll more than the usual "waitin until you get to it" is that one of the fixes should really not be a day-0 SRU but in-release pocket
<cpaelzer> therefore and since murphy is an idiot surely hitting something on dep8 test or so I'd ask to check and accept it soon
<cpaelzer> I'll poll later again if no one found the time
<cpaelzer> thanks in advance
<cpaelzer> TL;DR - @release team - please accept new qemu into bionic-proposed
-queuebot:#ubuntu-release- Unapproved: rejected qemu [source] (xenial-proposed) [1:2.5+dfsg-5ubuntu10.25]
<cpaelzer> thank for x-proposed as well, but I assume that was the SRU Team
-queuebot:#ubuntu-release- Unapproved: accepted dtv-scan-tables [sync] (bionic-proposed) [0+git20171226.07b18ec-1]
<cpaelzer> so should I ask for x-proposed to get b- ? :-)
<Laney> the queue's not that big; I should think qemu will get progressed quite soon
-queuebot:#ubuntu-release- Unapproved: accepted partman-lvm [sync] (bionic-proposed) [123]
<cpaelzer> sil2100: I think your reject only send me the first line
<cpaelzer> sil2100: but that means the essential part is missing
<cpaelzer> even in the mail I only got "What is the reason that the previous security update"
<cpaelzer> I assume something followed that half sentence that I could address, but ?
-queuebot:#ubuntu-release- Unapproved: accepted yorick [sync] (bionic-proposed) [2.2.04+dfsg1-9]
<cpaelzer> the former security update is released =.24 and my upload did not revert or skip the former sec update (it is quite normal a.25 on top of .24)
<cpaelzer> sil2100: so please let me know what the reason was here, so that I can address your needs
<apw> cpaelzer, did you look in the bug, as if it was rejected by the review tools i believe it puts that in the bug too
<cpaelzer> apw: I found it - sil2100 realized it was cut and posted the full text in the bug
-queuebot:#ubuntu-release- Unapproved: accepted bubblewrap [sync] (bionic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted libtemplate-perl [sync] (bionic-proposed) [2.27-1]
<sil2100> cpaelzer: yeah, sorry about it, finger-error
-queuebot:#ubuntu-release- Unapproved: accepted network-manager-pptp [sync] (bionic-proposed) [1.2.6-1]
<cpaelzer> sil2100: I foudn it in the bug, but I don't follow
<cpaelzer> sil2100: .24 to .25 is
<cpaelzer>  changelog                                              |   12
<cpaelzer>  patches/series                                         |    2
<cpaelzer>  patches/ubuntu/lp-1723904-sprs-backport.patch          |  634 +++++++++++++++++
<cpaelzer>  patches/ubuntu/lp-1723914-ppc64-set-msr-register.patch |   38 +
<cpaelzer>  4 files changed, 686 insertions(+)
<cpaelzer> that is the two bugs for the SRU 1 patch each and 1 line in d/p/series
<cpaelzer> + changelog
<cpaelzer> nothing else
<sil2100> So the debdiff that was generated by LP was removing the two CVE patches and commenting them out in the debian/patches/series file
<sil2100> Let me fetch the package and see if that's really how it looked in the package
-queuebot:#ubuntu-release- Unapproved: accepted devhelp [sync] (bionic-proposed) [3.28.1-1]
<cpaelzer> sil2100: yeah please, if anything is odd by me I want to learn what it was
<cpaelzer> sil2100: and if not lets sort it out and I can requeue for your ack instead then
<cpaelzer> sil2100: IMHO it should be https://git.launchpad.net/~paelzer/ubuntu/+source/qemu/log/?h=ubuntu/xenial-devel
<sil2100> cpaelzer: just so you know what I was talking about, the debdiff from LP: http://launchpadlibrarian.net/363323677/qemu_1%3A2.5+dfsg-5ubuntu10.23_1%3A2.5+dfsg-5ubuntu10.25.diff.gz
 * cpaelzer is reading
<sil2100> cpaelzer: if you check debian/patches/series, you'll see something strange happened
 * sil2100 downloads the source
<cpaelzer> sil2100: this is a debdiff against the -2 version
<cpaelzer> sil2100: .23 never existed in real life
<cpaelzer> sil2100: .22 was a security update
<cpaelzer> .23 was a security update
<cpaelzer> we found a bug in .23 while in proposed
<sil2100> Ok, I think I know what's up
<cpaelzer> .24 fixes that up
<cpaelzer> .24 is what is released now
<sil2100> cpaelzer: could you re-upload?
<cpaelzer> sure, just a sec
<sil2100> Actually I can just re-upload it now
<cpaelzer> as you prefer
<cpaelzer> I have the cmdline ready
-queuebot:#ubuntu-release- Unapproved: rsyslog (bionic-proposed/main) [8.32.0-1ubuntu1 => 8.32.0-1ubuntu2] (core)
<cpaelzer> you just stopped me hitting enter
<sil2100> Ok, so you had it handy too, please proceed!
<cpaelzer> uploaded
<cpaelzer> sil2100: and now showing up int the queue again for me
<cpaelzer> warning - the diff LP creates is again against .23 (for whatever reason)
-queuebot:#ubuntu-release- Unapproved: qemu (xenial-proposed/main) [1:2.5+dfsg-5ubuntu10.24 => 1:2.5+dfsg-5ubuntu10.25] (ubuntu-server, virt)
<apw> now that would explain a lot ...
<cpaelzer> and with .23 never existing it is quite reasonable that this diff made the least sense
 * cpaelzer is double checking his changes file and rmadison
<cpaelzer> no .24 is really the oen listed everywhere https://launchpad.net/ubuntu/xenial/+source/qemu
<sil2100> That's all good, the mistake here was on my part - I read the changes wrongly
<cpaelzer> ok, thanks for sorting it out with me so quickly
<sil2100> I read it in reverse
<cpaelzer> to finish this as FYI .23 never made it further than -proposed
<sil2100> Yeah, this I know, I checked the bug and the package itself, this part was clear
<sil2100> What I though happened was that the security regression update got reverted, but in fact no, it was just appearing in the diff as expected
<cpaelzer> ok
<cpaelzer> And since this was way too much text in here I feel obliged to ask again @Release team to ack qemu currently in bionic-unapproved :-)
<sil2100> cpaelzer: I can take care of that too ;p
<cpaelzer> I'm here in case this one looks odd as well :-)
-queuebot:#ubuntu-release- Unapproved: groovy (bionic-proposed/universe) [2.4.14-1 => 2.4.15-1] (no packageset) (sync)
<cpaelzer> TL;DR changes in there that are not allowed as 0-day-SRU but have to be on -release pocket
-queuebot:#ubuntu-release- Unapproved: accepted groovy [sync] (bionic-proposed) [2.4.15-1]
<sil2100> cpaelzer: not a blocker I think, but is it common for changelog entries to have links to private bugs?
<sil2100> cpaelzer: since LP: #1704312 seems to be privateish
<ubot5`> Error: Launchpad bug 1704312 could not be found
<sil2100> I have access, but I guess other people might get sad ;)
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (xenial-proposed) [1:2.5+dfsg-5ubuntu10.25]
-queuebot:#ubuntu-release- Packageset: 183 entries have been added or removed
<cpaelzer> sil2100: it is not yet opened, but eventually will no more be provate
<cpaelzer> sil2100: private
<sil2100> ACK ;)
<cpaelzer> sil2100: and yes, I even link to those (even if they stay private)
 * cpaelzer looks for a policy on this to adapt ...
<cpaelzer> this was opened when the feature was still secret - therefore the private on this particular case
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (bionic-proposed) [1:2.11+dfsg-1ubuntu6]
<sil2100> I just don't really know myself, I would expect all bugs mentioned in public uploads to be public, but as said I don't consider that a blocker as I don't really know if there's any policy for that
<sil2100> At least not for devel, for SRUs they have to be public
-queuebot:#ubuntu-release- Unapproved: rsyslog (bionic-proposed/main) [8.32.0-1ubuntu1 => 8.32.0-1ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntukylin-theme [source] (bionic-proposed) [1.7.6]
-queuebot:#ubuntu-release- Unapproved: accepted ukui-panel [source] (bionic-proposed) [1.1.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ukwm [source] (bionic-proposed) [1.1.8-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ukui-media [source] (bionic-proposed) [1.1.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ukui-settings-daemon [source] (bionic-proposed) [1.1.6-0ubuntu1]
<acheronuk> sil2100: will that packagset update show soon, or not until tomorrow?
-queuebot:#ubuntu-release- Unapproved: apt (trusty-proposed/main) [1.0.1ubuntu2.17 => 1.0.1ubuntu2.18] (core)
-queuebot:#ubuntu-release- Unapproved: accepted vala [sync] (bionic-proposed) [0.40.3-1]
-queuebot:#ubuntu-release- New source: networkd-dispatcher (bionic-proposed/primary) [1.7-0ubuntu1]
<acheronuk> sil2100: ok. seems I can upload things I wanted now even through the online list has not update yet. thanks :)
-queuebot:#ubuntu-release- Unapproved: mm-common (bionic-proposed/universe) [0.9.11-2 => 0.9.12-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mm-common [sync] (bionic-proposed) [0.9.12-1]
<sil2100> acheronuk: yeah, it doesn't refresh super often
<sil2100> acheronuk: ok, good! yw
<Laney> acheronuk: you can use edit-acl from lp:ubuntu-archive-tools to query that in realtime
<acheronuk> Laney: cheers. handy to know :)
-queuebot:#ubuntu-release- Unapproved: zfs-linux (bionic-proposed/main) [0.7.5-1ubuntu13 => 0.7.5-1ubuntu14] (core)
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (bionic-proposed) [0.7.5-1ubuntu14]
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (bionic-proposed/main) [1.414 => 1.415] (core)
-queuebot:#ubuntu-release- New: accepted networkd-dispatcher [source] (bionic-proposed) [1.7-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: pluma (bionic-proposed/universe) [1.20.1-0ubuntu1 => 1.20.1-2ubuntu1] (ubuntu-mate, ubuntukylin)
<doko> Laney: do armhf autopkg testers need some attention?
-queuebot:#ubuntu-release- New binary: networkd-dispatcher [amd64] (bionic-proposed/none) [1.7-0ubuntu1] (no packageset)
<Laney> possibly
-queuebot:#ubuntu-release- New: accepted networkd-dispatcher [amd64] (bionic-proposed) [1.7-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: kdelibs4support (bionic-proposed/universe) [5.44.0-0ubuntu1 => 5.44.0-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- New source: cxlflash (bionic-proposed/primary) [5.0.2669-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gnome-session (bionic-proposed/main) [3.28.0-0ubuntu3 => 3.28.0-0ubuntu4] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: poppler (bionic-proposed/main) [0.62.0-1ubuntu1 => 0.62.0-2ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: pkgbinarymangler (bionic-proposed/main) [135 => 136] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: virtualbox (bionic-proposed/multiverse) [5.2.8-dfsg-5 => 5.2.8-dfsg-6] (ubuntu-cloud) (sync)
-queuebot:#ubuntu-release- Unapproved: libcommons-compress-java (bionic-proposed/universe) [1.13-1 => 1.13-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libcommons-compress-java [sync] (bionic-proposed) [1.13-2]
<doko> stgraber, slangasek: please update the hint for vagrant-lxc. same failure as before
<stgraber> doko: no idea who maintains this thing but it's not something the LXC/LXD team cares about or supports in any way. I'm on vacation this week so if I have any spare time to look at it it'd be next week
<slangasek> jbicha: is one of these versions of yorick going to fix the autopkgtests and not require hinting?
<doko> stgraber: you spend more time typing that than fixing it and just replying "ok". but maybe you're typing as fast as you are speaking ;p
<stgraber> doko: well, I have no idea what that package is or what it does, so I don't think it'd be something I can fix in 30s :)
<stgraber> doko: unless you consider me running remove-package as a fix :)
<slangasek> doko: hint updated
<slangasek> stgraber: this was a release-team-oriented request, perhaps he misread tumbleweed's file as yours, no implication of package ownership
-queuebot:#ubuntu-release- Unapproved: kubuntu-settings (bionic-proposed/universe) [1:18.04ubuntu10 => 1:18.04ubuntu11] (kubuntu)
<acheronuk> slangasek: if you have time, could you perhaps take a look at LP: #1762479
<ubot5`> Launchpad bug 1762479 in kdeconnect (Ubuntu Bionic) "[FFe] KdeConnect 1.3.0 for Bionic" [Undecided,New] https://launchpad.net/bugs/1762479
<acheronuk> thanks
<slangasek> acheronuk: FFe approved.  Historically, flavors were allowed latitude in self-managing FFes for packages that were core parts of their image and that only they had seeded; perhaps we should discuss (but not just at this moment) getting back to that state, so that we don't need to be a bottleneck for you
<acheronuk> slangasek: oh, I did not realise that. I know when kubuntu had core devs, release team, and AAs on the team, things obviously went quicker, but what you say makes sense
<doko> xnox: I'm going to reject cxlflash
<slangasek> acheronuk: it was instigated at a time when that was true, but not implicitly tied to the flavor leads having those roles
<acheronuk> case in point, I may have another one for kstars later, if I can get the devs to give up a human readable changelog
<doko> xnox: src/build/install/resources/license/* looks like it's non-free. or do you want to have that in multiverse?
<acheronuk> right. I see. lets discuss that for next time around (18.10) then
<slangasek> doko: why are you directing that comment to xnox? wasn't sil2100 working on cxlflash?
<doko> ahh, ok
-queuebot:#ubuntu-release- New: rejected cxlflash [source] (bionic-proposed) [5.0.2669-0ubuntu1]
<doko> and email him about it
-queuebot:#ubuntu-release- Unapproved: kdeconnect (bionic-proposed/universe) [1.2.1-0ubuntu2 => 1.3.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: pylint-django (bionic-proposed/universe) [0.9.0-2 => 0.9.4-1] (no packageset) (sync)
<doko> ginggs: could you have a look at pandas? ftbfs on arm64 and s390x
-queuebot:#ubuntu-release- Unapproved: accepted pylint-django [sync] (bionic-proposed) [0.9.4-1]
<ginggs> doko: is removing 0.22.0-2 from proposed and uploading 0.20.3-11 (which seemed to build everywhere) an option?
<slangasek> ginggs: 0.20.3-11 was previously in -proposed and at the time it ftbfs everywhere in Ubuntu; would that no longer be the case? https://launchpad.net/ubuntu/+source/pandas/0.20.3-11
<ginggs> testing it my PPA now... but just wanted to know if that was an option
-queuebot:#ubuntu-release- Unapproved: maxima (bionic-proposed/universe) [5.41.0-2 => 5.41.0-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted maxima [sync] (bionic-proposed) [5.41.0-3]
<doko> slangasek: your python-cdo change isn't forwarded to debian
<slangasek> doko: ok
-queuebot:#ubuntu-release- Unapproved: pylint (bionic-proposed/universe) [1.8.1-1 => 1.8.3-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pylint [sync] (bionic-proposed) [1.8.3-1]
-queuebot:#ubuntu-release- Unapproved: accepted pkgbinarymangler [source] (bionic-proposed) [136]
-queuebot:#ubuntu-release- Unapproved: pyserial (bionic-proposed/main) [3.4-1 => 3.4-2] (edubuntu, kubuntu, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: elfutils (bionic-proposed/main) [0.170-0.3 => 0.170-0.4] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted elfutils [sync] (bionic-proposed) [0.170-0.4]
-queuebot:#ubuntu-release- Unapproved: accepted pyserial [sync] (bionic-proposed) [3.4-2]
-queuebot:#ubuntu-release- Unapproved: etl (bionic-proposed/universe) [1.2.1-0ubuntu1 => 1.2.1-0.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted etl [sync] (bionic-proposed) [1.2.1-0.1]
<ginggs> it looks like pandas 0.20.3-11 is still going to FTBFS everywhere :( I will have a look at 0.22.0-2 tomorrow
<jbicha> slangasek: no idea about yorick, maybe :|
<doko> slangasek: please badtest ruby-pkg-config/1.2.9-1. the autopkg test fails because it has some -I include flags twice. no idea how to fix that. but that's something which doesn't hurt
<jbicha> ok, I see that the new yorick version didn't pass its Ubuntu autopkgtests either :(
<slangasek> jbicha: this was my point, yes :)
<slangasek> doko: looking
-queuebot:#ubuntu-release- Unapproved: software-properties (bionic-proposed/main) [0.96.24.26 => 0.96.24.27] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cups (bionic-proposed/main) [2.2.7-1ubuntu1 => 2.2.7-1ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted kio-extras [source] (bionic-proposed) [4:17.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted rsyslog [source] (bionic-proposed) [8.32.0-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted rsyslog [source] (bionic-proposed) [8.32.0-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: gcc-7-cross (bionic-proposed/main) [20ubuntu1 => 20ubuntu2] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: python-oslo.versionedobjects (artful-proposed/main) [1.26.0-0ubuntu1 => 1.26.0-0ubuntu2] (kubuntu, openstack, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-oslo.versionedobjects (bionic-proposed/main) [1.31.2-0ubuntu1 => 1.31.2-0ubuntu2] (kubuntu, openstack, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: buildbot (bionic-proposed/universe) [1.1.1-2 => 1.1.1-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted buildbot [source] (bionic-proposed) [1.1.1-3]
<infinity> tsimonq2: Looks like you got a bunch of concensus before posting.  Excellent.
-queuebot:#ubuntu-release- Unapproved: accepted gcc-7-cross [sync] (bionic-proposed) [20ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.versionedobjects [source] (bionic-proposed) [1.31.2-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: python-oslo.versionedobjects (xenial-proposed/main) [1.8.0-1 => 1.8.0-1ubuntu1] (openstack, ubuntu-server)
<flocculant> infinity: did you notice my ping re the additional software tool leaving conf file behind when removing nvidia? bug 1761593
<ubot5`> bug 1761593 in software-properties (Ubuntu) "Uninstall left nouveau blacklisted" [Undecided,Confirmed] https://launchpad.net/bugs/1761593
<flocculant> thought that it might be prudent to flag that
<tsimonq2> infinity: I did, yeahp
<infinity> flocculant: I'm not sure reassigning that from nvidia-graphics to software-properties makes sense.
<infinity> flocculant: If a package's unpurged conffiles cause the system to misbehave, the package is at fault, not the user who removed instead of purging.
<flocculant> ok - made sense to me at the time
-queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (bionic-proposed) [10.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (bionic-proposed) [1.415]
<flocculant> but I had just installed/reinstalled a bunch of times in different methods - so possibly losing the plot a bit ;)
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox [sync] (bionic-proposed) [5.2.8-dfsg-6]
<flocculant> regardless of which package - I thought I'd best let someone in here know about it
<tsimonq2> slangasek: You hit the nail on the head with what I was insinuating wrt the whole "let's improve our automated testing" part of the email.
-queuebot:#ubuntu-release- Unapproved: ruby-gnome2 (bionic-proposed/universe) [3.2.3-2 => 3.2.4-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gnome-boxes (bionic-proposed/universe) [3.27.92-1 => 3.28.1-1] (desktop-extra) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ruby-gnome2 [sync] (bionic-proposed) [3.2.4-1]
-queuebot:#ubuntu-release- Unapproved: aseba (bionic-proposed/universe) [1.6.0-2 => 1.6.0-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted aseba [sync] (bionic-proposed) [1.6.0-3]
-queuebot:#ubuntu-release- Unapproved: sblim-sfcb (bionic-proposed/multiverse) [1.4.9-0ubuntu3 => 1.4.9-0ubuntu4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: partman-md (bionic-proposed/main) [85 => 86] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted sblim-sfcb [source] (bionic-proposed) [1.4.9-0ubuntu4]
<flocculant> infinity: also I guess I didn't look deeply enough at what happened in 17.10 there - I just checked what softwre-properties did there - and it removed the conf file
-queuebot:#ubuntu-release- Unapproved: appstream-glib (xenial-proposed/main) [0.5.13-1ubuntu5 => 0.5.13-1ubuntu6] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: sblim-sfcb (bionic-proposed/multiverse) [1.4.9-0ubuntu3 => 1.4.9-0ubuntu5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted sblim-sfcb [source] (bionic-proposed) [1.4.9-0ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted sssd [source] (bionic-proposed) [1.16.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: budgie-desktop-environment (bionic-proposed/universe) [0.9.7 => 0.9.8] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- Unapproved: budgie-extras (bionic-proposed/universe) [0.4.3-0ubuntu1 => 0.4.4-0ubuntu1] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- Unapproved: ruby-gollum-lib (bionic-proposed/universe) [4.2.1+debian-1 => 4.2.7-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ruby-gollum-lib [sync] (bionic-proposed) [4.2.7-1]
-queuebot:#ubuntu-release- Unapproved: hyphen-ru (bionic-proposed/main) [20030310-1ubuntu2 => 20030310-1ubuntu3] (personal-gunnarhj, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: myspell-hr (bionic-proposed/main) [20060617-2.4 => 20060617-2.4ubuntu1] (personal-gunnarhj, ubuntu-desktop)
<doko> this is fun, even gsl and maxima transitioned now \o/
<slangasek> doko: reran ruby-pkg-config autopkgtest against release pocket and confirmed it's broken there also; hint added
<doko> now that's ruby-concurrent left on armhf ...
<slangasek> why oh why did someone make redis build on i386
<nacc> lol
-queuebot:#ubuntu-release- Unapproved: accepted pluma [source] (bionic-proposed) [1.20.1-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (bionic-proposed) [0.96.24.27]
-queuebot:#ubuntu-release- Unapproved: ruby-delayed-job (bionic-proposed/universe) [4.0.6-2ubuntu1 => 4.1.4-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ruby-delayed-job [sync] (bionic-proposed) [4.1.4-1]
<tsimonq2> infinity: Was any progress made on that Ubiquity bug?
<infinity> tsimonq2: Steve has an MP that I need to revisit because over the weekend, I had a thought that maybe the fix was correct, but the placement was not.  And need to verify that.
<infinity> Also, "correct", in that I still don't understand *why* this is happening, and *why* it's only on lubuntu.
<tsimonq2> OK.
<infinity> Which annoys me.
-queuebot:#ubuntu-release- Unapproved: jellyfish (bionic-proposed/universe) [2.2.8-3 => 2.2.8-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted jellyfish [sync] (bionic-proposed) [2.2.8-3]
-queuebot:#ubuntu-release- Unapproved: pdbg (bionic-proposed/universe) [1.0-1 => 1.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pdbg [source] (bionic-proposed) [1.0-1ubuntu1]
-queuebot:#ubuntu-release- New binary: pdbg [ppc64el] (bionic-proposed/universe) [1.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: unity (bionic-proposed/universe) [7.5.0+18.04.20180404-0ubuntu2 => 7.5.0+18.04.20180409-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted unity [sync] (bionic-proposed) [7.5.0+18.04.20180409-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gnome-getting-started-docs (bionic-proposed/main) [3.28.0+git20180331-0ubuntu1 => 3.28.1-0ubuntu1] (personal-gunnarhj, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: nautic (bionic-proposed/universe) [1.5-3 => 1.5-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted nautic [sync] (bionic-proposed) [1.5-4]
-queuebot:#ubuntu-release- Unapproved: libwx-scintilla-perl (bionic-proposed/universe) [0.39-3build2 => 0.39-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libwx-scintilla-perl [sync] (bionic-proposed) [0.39-4]
-queuebot:#ubuntu-release- Unapproved: gnome-user-docs (bionic-proposed/main) [3.28.0+git20180331-0ubuntu1 => 3.28.1-0ubuntu1] (personal-gunnarhj, ubuntu-desktop)
<slangasek> doko: I'm not sure, but I think the tpm2-tss armhf FTBFS may be a toolchain bug; trying to step through with gdb, and test/unit/tcti-device.c:164 is never executed
#ubuntu-release 2018-04-10
<cyphermox> I can haz a look at that
<cyphermox> oh, cute, and the enddianness failure on s390x...
-queuebot:#ubuntu-release- Unapproved: clamsmtp (bionic-proposed/universe) [1.10-16ubuntu1 => 1.10-17ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted clamsmtp [source] (bionic-proposed) [1.10-17ubuntu1]
-queuebot:#ubuntu-release- Unapproved: pocl (bionic-proposed/universe) [1.1-4 => 1.1-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pocl [sync] (bionic-proposed) [1.1-5]
<slangasek> doko: solfege build failure is a segfault within initialization of /usr/lib/python3.6/lib-dynload/readline.cpython-36m-x86_64-linux-gnu.so, which seems somewhat improbable...
<slangasek> doko: you're removing packages from -proposed that are not buggy and could become installable again if their dependencies were fixed in Debian?
-queuebot:#ubuntu-release- Unapproved: psortb (bionic-proposed/universe) [3.0.5+dfsg-1 => 3.0.5+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted psortb [source] (bionic-proposed) [3.0.5+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New binary: psortb [amd64] (bionic-proposed/universe) [3.0.5+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: primer3 (bionic-proposed/universe) [2.4.0-1 => 2.4.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted primer3 [source] (bionic-proposed) [2.4.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kdelibs4support [source] (bionic-proposed) [5.44.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-session [source] (bionic-proposed) [3.28.0-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted poppler [source] (bionic-proposed) [0.62.0-2ubuntu1]
-queuebot:#ubuntu-release- New binary: gnome-session [amd64] (bionic-proposed/main) [3.28.0-0ubuntu4] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gnome-session [s390x] (bionic-proposed/main) [3.28.0-0ubuntu4] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gnome-session [ppc64el] (bionic-proposed/main) [3.28.0-0ubuntu4] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gnome-session [i386] (bionic-proposed/main) [3.28.0-0ubuntu4] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: pymoc (bionic-proposed/universe) [0.5.0-2 => 0.5.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pymoc [source] (bionic-proposed) [0.5.0-2ubuntu1]
-queuebot:#ubuntu-release- New binary: gnome-session [arm64] (bionic-proposed/main) [3.28.0-0ubuntu4] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gnome-session [armhf] (bionic-proposed/main) [3.28.0-0ubuntu4] (ubuntu-desktop)
<acheronuk> morning. could the kdeconnect FFe in unapproved be let through if convenient. thanks
-queuebot:#ubuntu-release- Unapproved: libinput (bionic-proposed/main) [1.10.3-2 => 1.10.4-1] (desktop-core) (sync)
<sil2100> Looking
<sil2100> acheronuk: uh, did you put the wrong bug number for kdeconnect? Since the bug seems to point to krita
<sil2100> acheronuk: if that's indeed a mistake, please re-upload with the same version number, I'll reject this one and approve the other
<acheronuk> sil2100: could be. I had both open in tabs yesterday. thanks
<sil2100> acheronuk: I'll look at the bug then ;)
<sil2100> acheronuk: also, the kubuntu-settings upload - it sounds like it changes visible parts of the UI? I guess it would need an UIFe?
<sil2100> (correct me if I'm wrong)
<acheronuk> trivially, and I thought that was to ensure that UI did not change for people doing documentation for main ubuntu. this has zero impact on those issues
-queuebot:#ubuntu-release- Unapproved: kdeconnect (bionic-proposed/universe) [1.2.1-0ubuntu2 => 1.3.0-0ubuntu1] (kubuntu)
<acheronuk> sil2100: we certainly have no documentation that promise whether we have that small separator or not
<sil2100> acheronuk: ok, I must say I am not sure about flavour-specific changes myself
<sil2100> So yeah, I guess we'll just slip it in
<acheronuk> it is sort of a grey area. or at least debatable
<acheronuk> thank. if it had been a bigger change affecting other things, I would have FFed or asked in advance
<acheronuk> *thanks
-queuebot:#ubuntu-release- Unapproved: rejected kdeconnect [source] (bionic-proposed) [1.3.0-0ubuntu1]
<sil2100> (also, basically since you're from the Kubuntu team I'd anyway ACK your UIFe request ;) )
<sil2100> Approved both, yw!
<acheronuk> sil2100: did you see slangasek's comment on this yesterday?
-queuebot:#ubuntu-release- Unapproved: accepted cups [source] (bionic-proposed) [2.2.7-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kubuntu-settings [source] (bionic-proposed) [1:18.04ubuntu11]
-queuebot:#ubuntu-release- Unapproved: accepted kdeconnect [source] (bionic-proposed) [1.3.0-0ubuntu1]
<acheronuk> regards kdeconnect ffe
<acheronuk> [18:36] <slangasek> acheronuk: FFe approved.  Historically, flavors were allowed latitude in self-managing FFes for packages that were core parts of their image and that only they had seeded; perhaps we should discuss (but not just at this moment) getting back to that state, so that we don't need to be a bottleneck for you
-queuebot:#ubuntu-release- Unapproved: accepted partman-md [sync] (bionic-proposed) [86]
<acheronuk> sil2100: anyway. thank you :)
-queuebot:#ubuntu-release- Unapproved: accepted budgie-desktop-environment [source] (bionic-proposed) [0.9.8]
-queuebot:#ubuntu-release- Unapproved: accepted budgie-extras [source] (bionic-proposed) [0.4.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted hyphen-ru [source] (bionic-proposed) [20030310-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted myspell-hr [source] (bionic-proposed) [20060617-2.4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-getting-started-docs [source] (bionic-proposed) [3.28.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-user-docs [source] (bionic-proposed) [3.28.1-0ubuntu1]
<sil2100> acheronuk: I guess I didn't :) Yeah, I'd really like this to be made clear somewhere so that we don't cause unnecessary delays here and there
<acheronuk> +1 there
-queuebot:#ubuntu-release- New binary: gnome-user-docs [amd64] (bionic-proposed/main) [3.28.1-0ubuntu1] (personal-gunnarhj, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: pillow (bionic-proposed/main) [5.0.0-1 => 5.1.0-1] (desktop-core, ubuntu-server) (sync)
-queuebot:#ubuntu-release- New: accepted gnome-session [amd64] (bionic-proposed) [3.28.0-0ubuntu4]
-queuebot:#ubuntu-release- New: accepted gnome-session [armhf] (bionic-proposed) [3.28.0-0ubuntu4]
-queuebot:#ubuntu-release- New: accepted gnome-session [ppc64el] (bionic-proposed) [3.28.0-0ubuntu4]
-queuebot:#ubuntu-release- New: accepted gnome-user-docs [amd64] (bionic-proposed) [3.28.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted psortb [amd64] (bionic-proposed) [3.0.5+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnome-session [arm64] (bionic-proposed) [3.28.0-0ubuntu4]
-queuebot:#ubuntu-release- New: accepted gnome-session [s390x] (bionic-proposed) [3.28.0-0ubuntu4]
-queuebot:#ubuntu-release- New: accepted gnome-session [i386] (bionic-proposed) [3.28.0-0ubuntu4]
-queuebot:#ubuntu-release- New: accepted pdbg [ppc64el] (bionic-proposed) [1.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-boxes [sync] (bionic-proposed) [3.28.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted pillow [sync] (bionic-proposed) [5.1.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted libinput [sync] (bionic-proposed) [1.10.4-1]
<doko> slangasek: why would you want to keep buildN packages without binaries in proposed?
-queuebot:#ubuntu-release- Unapproved: enki-aseba (bionic-proposed/universe) [1:1.6.0-3 => 1:1.6.0-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted enki-aseba [sync] (bionic-proposed) [1:1.6.0-5]
-queuebot:#ubuntu-release- Unapproved: gnome-disk-utility (bionic-proposed/main) [3.28.0-1ubuntu1 => 3.28.1-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: ukui-session-manager (bionic-proposed/universe) [1.1.1-0ubuntu1 => 1.1.2-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: ristretto (bionic-proposed/universe) [0.8.2-1 => 0.8.2-1ubuntu1] (ubuntustudio, xubuntu)
-queuebot:#ubuntu-release- Unapproved: pulseaudio (xenial-proposed/main) [1:8.0-0ubuntu3.8 => 1:8.0-0ubuntu3.9] (core)
-queuebot:#ubuntu-release- New source: python-motor (bionic-proposed/primary) [1.2.1-1build1]
-queuebot:#ubuntu-release- Unapproved: mongodb (bionic-proposed/universe) [1:3.4.7-1ubuntu4 => 1:3.4.14-3] (mozilla) (sync)
-queuebot:#ubuntu-release- New: accepted python-motor [source] (bionic-proposed) [1.2.1-1build1]
-queuebot:#ubuntu-release- New binary: python-motor [amd64] (bionic-proposed/none) [1.2.1-1build1] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-motor [amd64] (bionic-proposed) [1.2.1-1build1]
-queuebot:#ubuntu-release- Unapproved: synfigstudio (bionic-proposed/universe) [1.2.1-0ubuntu3 => 1.2.1-0.1] (ubuntustudio) (sync)
<LocutusOfBorg> can you please accept mongodb so I can upload my merge without the orig tarball? it timeouts
<LocutusOfBorg> it has an FFe for 3.6 already acked
<LocutusOfBorg> I'm just uploading a 3.4 merge in the meanwhile, to unblock python-motor
<jbicha> LocutusOfBorg: please talk to rbasak about mongodb work. I think there was a reason he wasn't just syncing the Debian version yet
<jbicha> oh never mind, I see there was already discussion
-queuebot:#ubuntu-release- Unapproved: mongodb (bionic-proposed/universe) [1:3.4.7-1ubuntu4 => 1:3.4.14-3ubuntu1] (mozilla)
<LocutusOfBorg> hurray mongodb uploaded
-queuebot:#ubuntu-release- Unapproved: r-cran-openssl (bionic-proposed/universe) [1.0.1-1 => 1.0.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-openssl [source] (bionic-proposed) [1.0.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: openoffice.org-hyphenation-pl (bionic-proposed/main) [1:3.0a-4 => 1:3.0a-4ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: ubuntu-report (bionic-proposed/universe) [1.0.5 => 1.0.6] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-report [source] (bionic-proposed) [1.0.6]
-queuebot:#ubuntu-release- Unapproved: ubuntu-report (bionic-proposed/universe) [1.0.6 => 1.0.7] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-report [source] (bionic-proposed) [1.0.7]
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (bionic-proposed/partner) [1:20180313.1-0ubuntu1 => 1:20180410.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libreoffice (bionic-proposed/main) [1:6.0.2-0ubuntu1 => 1:6.0.3-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-session (bionic-proposed/main) [3.28.0-0ubuntu4 => 3.28.1-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: libreoffice-l10n (bionic-proposed/main) [1:6.0.2-0ubuntu1 => 1:6.0.3-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: remmina (bionic-proposed/main) [1.2.0-rcgit.27+dfsg-4ubuntu1 => 1.2.0-rcgit.29+dfsg-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: r-cran-future (bionic-proposed/universe) [1.7.0-1 => 1.7.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-future [source] (bionic-proposed) [1.7.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected mongodb [sync] (bionic-proposed) [1:3.4.14-3]
-queuebot:#ubuntu-release- Unapproved: accepted synfigstudio [sync] (bionic-proposed) [1.2.1-0.1]
-queuebot:#ubuntu-release- Unapproved: accepted mongodb [source] (bionic-proposed) [1:3.4.14-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: fastnetmon (bionic-proposed/universe) [1.1.3+dfsg-6 => 1.1.3+dfsg-6build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted fastnetmon [source] (bionic-proposed) [1.1.3+dfsg-6build1]
<slangasek> doko: I'm not talking about buildN packages.  You removed e.g. grafana-zabbix, which is not buggy but depends on a buggy package.  If grafana gets fixed in Debian, it will be synced and grafana-zabbix will become migratable with no source changes; but now grafana-zabbix is gone, and won't reappear automatically when grafana is fixed
<cjwatson> FYI, I'm currently deploying a new Launchpad revision that adds InRelease etc. to by-hash directories
<cjwatson> It looks fine in tests, and I'll keep an eye on it, but please let me know if you see weirdness in that general area
<doko> ahh, I see. good, then looking at the new upstream =)
<xnox> sil2100, last subiquity respin fails to build =( http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/bionic/daily-live-20180410.1.log -> no live filesystems build succeeded
<xnox> and diggin into there https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/bionic/ubuntu-server-live/+build/129016
<xnox> in https://launchpadlibrarian.net/364257125/buildlog_ubuntu_bionic_amd64_ubuntu-server-live_BUILDING.txt.gz shows that
<xnox> + SNAPPY_STORE_NO_CDN=1 snap download core
<xnox> 2018/04/10 12:47:07.907440 cmd.go:156: cannot read /proc/self/exe: readlink /proc/self/exe: no such file or directory
<xnox> is this known? or need debugging / escalating? i guess something changed and snapd is no longer a happy camper inside lxd inside launchpad builder?
<slangasek> doko: I don't care strongly about grafana-zabbix, but I've been avoiding removing such packages from -proposed as a policy
<xnox> has all of zabbix been upgraded to support systemd as pid1? at one point it was upstart-only on ubuntu, and thus not working at all, and I thought all of zabbix needs removing
<sil2100> xnox: hmmm
<sil2100> xnox: looking, strange as I started it through nusakan so I'd expect it to work - let me see what I actually run
<sil2100> Ah
<sil2100> heh
-queuebot:#ubuntu-release- Unapproved: plasma-framework (bionic-proposed/universe) [5.44.0-0ubuntu2 => 5.44.0-0ubuntu3] (kubuntu)
<acheronuk> I tested that patch for upstream code review, so please let through when convenient ^^^
<sil2100> xnox: no idea why this is now failing and was not failing 7 hours ago, I guess you'll have to ask around ;)
<slangasek> xnox: no clue about that, and again I don't care about this particular package ;)  I just care about knowing what rules we should follow when keeping or removing packages from -proposed, since that has implications for them coming back later
<xnox> sil2100, or i guess the actuall error is:
<xnox> xnox> error: received an unexpected http response code (503) when trying to download https://public.apps.ubuntu.com/download-origin/local/99T7MUlRhtI3U0QFgl5mXXESAiSwt776_4206.snap?sig=Ijk5VDdNVWxSaHRJM1UwUUZnbDVtWFhFU0FpU3d0Nzc2XzQyMDYuc25hcCI.Da44wA.PqfN1fhAv3tZT-1qaRnz5239kxg
-queuebot:#ubuntu-release- Unapproved: ubiquity (bionic-proposed/main) [18.04.4 => 18.04.5] (core)
<cyphermox> jibel: ^
-queuebot:#ubuntu-release- Unapproved: aseba (bionic-proposed/universe) [1.6.0-3 => 1.6.0-3ubuntu1] (no packageset)
<cyphermox> slangasek: ubiquity in unapproved would need a review/approval if you have the time; this is the upload for your TTY fixes, as well as the zram fix
-queuebot:#ubuntu-release- Unapproved: accepted aseba [source] (bionic-proposed) [1.6.0-3ubuntu1]
<slangasek> cyphermox: accepted, thanks
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (bionic-proposed) [18.04.5]
<jibel> cyphermox, thanks
<cyphermox> ta
<doko> is OpenGL supposed to work on arm64?
<ginggs> would someone please 'force-badtest nanopolish/0.9.0-1/arm64 nanopolish/0.9.0-1/armhf nanopolish/0.9.0-1/ppc64el nanopolish/0.9.0-1/s390x' ? it is only built for amd64 and i386 now
<LocutusOfBorg> doko, is context enki-aseba aseba? debian enabled OpenGL with latest qt in arm64, ubuntu didn't, probably because qt in bionic is too old? /cc tsimonq2
<slangasek> doko: "ish".  Qt is built against GLES instead of GL, so it has a similar set of qt-related ANAIS as armhf
<doko> aseba doesn't detect a working qt on arm64
<slangasek> LocutusOfBorg: Ubuntu hasn't enabled OpenGL in arm64 specifically because OpenGLES is considered the more interesting target for Ubuntu arm64 targets
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/qtbase-opensource-src/5.9.4+dfsg-0ubuntu4
<slangasek> LocutusOfBorg: unless you're saying that the new Qt can somehow do both
<LocutusOfBorg> this? :)
<LocutusOfBorg> slangasek, I vaguely remember something like this, but please don't take my words seriously
<slangasek> (OpenGL support on arm64 in Qt in Debian is not new)
<LocutusOfBorg> this is why I cc'd tsimonq2
-queuebot:#ubuntu-release- Unapproved: a7xpg (bionic-proposed/universe) [0.11.dfsg1-9build1 => 0.11.dfsg1-9ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted a7xpg [source] (bionic-proposed) [0.11.dfsg1-9ubuntu1]
 * tsimonq2 bounces to mitya57 
<tsimonq2> I still need to learn why the graphics stack is the way it is irt arm and Qt.
-queuebot:#ubuntu-release- Unapproved: linux-meta-gcp (bionic-proposed/main) [4.15.0.1003.4 => 4.15.0.1003.5] (kernel)
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-gcp [source] (bionic-proposed) [4.15.0.1003.5]
-queuebot:#ubuntu-release- Unapproved: wine-development (bionic-proposed/universe) [3.2-1 => 3.5-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted wine-development [sync] (bionic-proposed) [3.5-1]
-queuebot:#ubuntu-release- Unapproved: simplestreams (artful-proposed/main) [0.1.0~bzr450-0ubuntu1 => 0.1.0~bzr450-0ubuntu1.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: dell-recovery (bionic-proposed/universe) [1.57 => 1.58] (no packageset)
-queuebot:#ubuntu-release- Unapproved: simplestreams (xenial-proposed/main) [0.1.0~bzr426-0ubuntu1.2 => 0.1.0~bzr426-0ubuntu1.3] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted dell-recovery [source] (bionic-proposed) [1.58]
-queuebot:#ubuntu-release- Unapproved: pymoc (bionic-proposed/universe) [0.5.0-2ubuntu1 => 0.5.0-2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pymoc [source] (bionic-proposed) [0.5.0-2ubuntu2]
<doko> apw, please see https://bugs.launchpad.net/ubuntu/+source/usbip/+bug/1723717
<ubot5`> Ubuntu bug 1723717 in linux (Ubuntu) "Please remove from archives: usbip & usbip-source" [Undecided,New]
-queuebot:#ubuntu-release- Unapproved: patch (bionic-proposed/main) [2.7.6-1 => 2.7.6-2] (core) (sync)
<mitya57> doko, tsimonq2: in Debian, aseba FTBFS with OpenGL ES too (see armhf). The only difference with Ubuntu is that we use OpenGL ES also on arm64.
<mitya57> This upload is new, maybe the maintainer will fix that FTBFS soon.
<doko> ok, then I'll remove the binary on arm64
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice-l10n [source] (bionic-proposed) [1:6.0.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted openoffice.org-hyphenation-pl [source] (bionic-proposed) [1:3.0a-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (bionic-proposed) [1:6.0.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted patch [sync] (bionic-proposed) [2.7.6-2]
-queuebot:#ubuntu-release- Unapproved: buildbot (bionic-proposed/universe) [1.1.1-3 => 1.1.1-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted buildbot [source] (bionic-proposed) [1.1.1-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ristretto [source] (bionic-proposed) [0.8.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-session [source] (bionic-proposed) [3.28.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: vte2.91 (bionic-proposed/main) [0.52.0-1ubuntu2 => 0.52.1-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: glib2.0 (bionic-proposed/main) [2.56.0-4ubuntu1 => 2.56.1-2ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: aseba (bionic-proposed/universe) [1.6.0-3ubuntu1 => 1.6.0-3.1~build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted aseba [source] (bionic-proposed) [1.6.0-3.1~build1]
<smoser> hi. could someone NACK the artful and xenial uploads of simplestreams please ?
<nacc> smoser: are you going to upload again?
<smoser> well, wolsen requested another cherry-pick
<smoser> i've updated the merge prposal to have those
<nacc> smoser: if in unapproved, you can re-upload the same version
<smoser> i can, yes. but just more clear if we NACK what is there.
<nacc> smoser: as the version hasn't been burned yet, and the SRU team should review the latest upload
<smoser> but yeah. not burned.
<nacc> smoser: yeah i agree with you, just not necessarily blocking you either
<smoser> right
-queuebot:#ubuntu-release- Unapproved: gnome-terminal (bionic-proposed/main) [3.28.0-1ubuntu1 => 3.28.1-1ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: jellyfish (bionic-proposed/universe) [2.2.8-3 => 2.2.8-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: primer3 (bionic-proposed/universe) [2.4.0-1ubuntu1 => 2.4.0-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted jellyfish [source] (bionic-proposed) [2.2.8-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted primer3 [source] (bionic-proposed) [2.4.0-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (bionic-proposed) [1:20180410.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (trusty-proposed/partner) [1:20180313.1-0ubuntu0.14.04.1 => 1:20180410.1-0ubuntu0.14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20180313.1-0ubuntu0.16.04.1 => 1:20180410.1-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20180410.1-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (trusty-proposed) [1:20180410.1-0ubuntu0.14.04.1]
-queuebot:#ubuntu-release- Unapproved: gnome-calculator (bionic-proposed/main) [1:3.28.0-1ubuntu1 => 1:3.28.1-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: ruby-graphviz (bionic-proposed/universe) [1.2.3-1 => 1.2.3-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ruby-graphviz [source] (bionic-proposed) [1.2.3-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: buildbot (bionic-proposed/universe) [1.1.1-3ubuntu1 => 1.1.1-3ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted buildbot [source] (bionic-proposed) [1.1.1-3ubuntu2]
-queuebot:#ubuntu-release- Unapproved: software-properties (bionic-proposed/main) [0.96.24.27 => 0.96.24.28] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-settings (bionic-proposed/universe) [18.04.14 => 18.04.15] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: mate-desktop (bionic-proposed/universe) [1.20.1-1ubuntu1 => 1.20.1-1ubuntu2] (ubuntu-mate, ubuntukylin, xubuntu)
-queuebot:#ubuntu-release- Unapproved: gnome-builder (bionic-proposed/universe) [3.28.0-1ubuntu1 => 3.28.1-1ubuntu1] (desktop-extra)
-queuebot:#ubuntu-release- Unapproved: atril (bionic-proposed/universe) [1.20.1-2ubuntu1 => 1.20.1-2ubuntu2] (ubuntu-mate, ubuntukylin, xubuntu)
<acheronuk> slangasek: we still have sddm starting with a minimum VT7. I guess your new ubiquity version will not like that?
 * tsimonq2 volunteers to fix SDDM if that's the problem.
<slangasek> acheronuk: I don't expect sddm to care.  It just means that if you run ubiquity-dm in 'maybe' mode, then choose 'try', you'll have a VT switch
<slangasek> whereas since plymouth AFAIK is across the board on vt1 now, there's no advantage to starting ubiquity-dm on vt7
<tsimonq2> slangasek: This commit was spotted earlier: https://packaging.neon.kde.org/3rdparty/sddm.git/commit/?h=Neon/unstable_bionic&id=4567d3f85cfc5ba0a594f4b5c547311be3275302
<tsimonq2> We might need to cherry-pick it?
<acheronuk> slangasek: well, I just rolled our own Kubuntu CI iso image, and the try/install screen now crashes and dumps you into the live session on VT7
-queuebot:#ubuntu-release- Unapproved: flashplugin-nonfree (bionic-proposed/multiverse) [29.0.0.113ubuntu1 => 29.0.0.140ubuntu1] (no packageset)
<acheronuk> so I'm jumping the gun on our daily iso build right now to test
<slangasek> acheronuk: I don't know of any reason why this change would cause it to crash.  Where can I poke at your image?
-queuebot:#ubuntu-release- Unapproved: accepted flashplugin-nonfree [source] (bionic-proposed) [29.0.0.140ubuntu1]
<acheronuk> slangasek: http://kci.pangea.pub/images/iso_bionic_stable_amd64/current/
-queuebot:#ubuntu-release- Unapproved: gnome-initial-setup (bionic-proposed/universe) [3.28.0-2ubuntu1 => 3.28.0-2ubuntu2] (ubuntugnome)
<acheronuk> it is one with CI packages (though stable branches) so it could be something else causing the crash
<acheronuk> but I tested as it's one I can just spin up
<acheronuk> tsimonq2: yeah. if that commit is sane, may be worth taking
<slangasek> acheronuk, tsimonq2: yes, that sddm commit looks reasonable to take, but I also don't want to have flavors individually chasing down post-beta damage caused by a change that shouldn't have broken things; so I'm still going to dig on that side
<tsimonq2> slangasek: OK.
<tsimonq2> Thank you.
<slangasek> doko: the openfoam/ppc64el build failure is confusing me, I have failed to reproduce it on diamond but it's reproducible in LP.  does this smell like an OOM to you?
<doko> priotized https://launchpad.net/ubuntu/+archive/test-rebuild-20180408/+build/14609269 and https://launchpad.net/ubuntu/+archive/test-rebuild-20180408-gcc8/+build/14704137
<doko> let's see
<doko> slangasek: how much memory are the cc1plus processes consuming?
-queuebot:#ubuntu-release- Unapproved: buildbot (bionic-proposed/universe) [1.1.1-3ubuntu2 => 1.1.1-3ubuntu3] (no packageset)
<slangasek> doko: don't know. what's a good way to check the high watermark on this?
-queuebot:#ubuntu-release- Unapproved: accepted buildbot [source] (bionic-proposed) [1.1.1-3ubuntu3]
<doko> watching top?
<doko> if I would know a better way, I would like to see that printed out at the end of each build in the log
<tsimonq2> You mean htop? :P
 * tsimonq2 runs
<wxl> neither of them will help with logging
<doko> build failure with gcc8, so that doesn't help
<doko> I love that gnome-shell-pomodoro autopkg test ... running for 93h now
<doko> slangasek: I removed the primer3 binaries on s390x, however the autopkg tests are still run. what am I doing wrong?
<slangasek> doko: cc1plus looks to be around 425MB each for openfoam, but who knows if that's the highwater mark.  and maybe I should just speculatively change it to -O2
<slangasek> doko: primer3> probably the problem is that there are arch: all packages from the source, so it probably needs hinted badtest
<acheronuk> slangasek: real Kubuntu iso respin also crashes straight to live session: http://cdimage.ubuntu.com/kubuntu/daily-live/20180410.1/
<acheronuk> caveat - that is in a VM
<acheronuk> slangasek: this morning's iso works fine
-queuebot:#ubuntu-release- Unapproved: vim (bionic-proposed/main) [2:8.0.1401-1ubuntu3 => 2:8.0.1453-1ubuntu1] (core) (sync)
<doko> mdeslaur: your patch sync ftbfs
<slangasek> one the words in the previous line is a package name
<doko> =)
<doko> why can't I give back update-notifier on armhf? "You submitted an invalid request: update-notifier/3.190 is not published in bionic"
<slangasek> doko: an unusual error message; what I see is update-notifier 3.190 is built on armhf
<LocutusOfBorg> oh I was looking at the same update-notifier message
<acheronuk> slangasek: https://paste.ubuntu.com/p/4bjQgJg9pv/
<doko> slangasek: re openfoam, you could limit the parallel build to two cpus as well
<LocutusOfBorg> doko, I don't know how you did fix aseba, but the reason for the failure were in enki-aseba being qt4, so I reverted your upload and "fixed" it (actually your change has been subsequent to enki-aseba sync/publish, this is maybe why you thought the linking order was a fix?)
-queuebot:#ubuntu-release- Unapproved: gnome-initial-setup (bionic-proposed/universe) [3.28.0-2ubuntu1 => 3.28.0-2ubuntu3] (ubuntugnome)
<slangasek> doko: lala, just found this in debian/rules: # Limit parallel build to 3 processes on Ubuntu amd64 and arm64
<doko> slangasek: seriously, we should fix the buildd infrastructure, not the packaging
<slangasek> we don't agree that this is broken infrastructure
<doko> if you think that building with the same limits (or even lower ones) as four or five years ago ...
-queuebot:#ubuntu-release- Unapproved: openfoam (bionic-proposed/universe) [4.1+dfsg1-1build2 => 4.1+dfsg1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted openfoam [source] (bionic-proposed) [4.1+dfsg1-1ubuntu1]
<mdeslaur> doko: UGH, thanks.
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.518 => 2.519] (desktop-core)
<tsimonq2> Somebody could sync nodejs if they wanted to. Won't be me. :P
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.519]
<doko> tsimonq2: are you comitted to fix all the autopkg test failures?
<tsimonq2> doko: As I said, won't be me. :P
 * doko curses the person who synced that from experimental
<nacc> that would be tsimonq2, no? :)
<slangasek> acheronuk: and that failure is consistently reproducible on boot?  any indication of why the X server died?
<tsimonq2> nacc: shhhhhhhhhhhhhhhhhhhhhhhhhhhhh
<tsimonq2> I knew soon after the fact that it was a *horrible* mistake.
<nacc> tsimonq2: it doesn't appear to be that important to sync
<slangasek> tsimonq2: did you learn not to do it for next time? ;)
<nacc> heh
<tsimonq2> nacc, slangasek: This is why I'm casually suggesting it over IRC, so someone *else* can deal with the absolute mess that nodejs is.
<tsimonq2> :P
<slangasek> tsimonq2: I mean about not starting /new/ transitions for language ecosystems by syncing from experimental
<slangasek> :)
<acheronuk> slangasek: so far has crashed every time. that is all the output in syslog just before and after
<tsimonq2> slangasek: Yes, that. ;)
<slangasek> acheronuk: there may be X logs separately; or systemd journal entries for the ubiquity service (journalctl --no-pager -lu ubiquity.service)
<tsimonq2> slangasek: I learned that next time I sync something starting a new transition, it should be in Gianfranco's name. :P
<tsimonq2> Imeanwhat.
<tsimonq2> (I'm kidding, of course. :P)
-queuebot:#ubuntu-release- Unapproved: patch (bionic-proposed/main) [2.7.6-2 => 2.7.6-2ubuntu1] (core)
<acheronuk> slangasek: https://paste.ubuntu.com/p/WQh9z3Fzh5/
-queuebot:#ubuntu-release- Unapproved: rejected gnome-initial-setup [source] (bionic-proposed) [3.28.0-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted vim [sync] (bionic-proposed) [2:8.0.1453-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted patch [source] (bionic-proposed) [2.7.6-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ukui-session-manager [source] (bionic-proposed) [1.1.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted atril [source] (bionic-proposed) [1.20.1-2ubuntu2]
<slangasek> acheronuk: so if you, say, try to run 'service ubiquity start', what happens?  Is it reproducible post-boot?
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-settings [source] (bionic-proposed) [18.04.15]
-queuebot:#ubuntu-release- Unapproved: accepted mate-desktop [source] (bionic-proposed) [1.20.1-1ubuntu2]
<acheronuk> slangasek: seems to fail the same
<doko> slangasek: please could you consider overriding the snapd/i386 autopkg test failure? according to #snappy that doesn't appear in their own testing, and it looks completely unrelated to git
<slangasek> acheronuk: well good news, that means you should be able to debug it and get some logs then? :)  you probably want to 'service sddm stop' before you try to get any logs though, otherwise you could have conflicts with the already-running X server
<acheronuk> slangasek: if I 'sudo service sddm stop' then 'sudo service ubiquity start' ubiquity-dm starts without a crash
<acheronuk> and I land on the try/install screen
<tsimonq2> slangasek: Spanish is messed up as well: bug 1754646.
<ubot5`> bug 1754646 in debian-installer (Ubuntu Bionic) "Texts in the dialogue in Swedish is faulty in Lubuntu alternate Bionic beta 1" [Critical,Confirmed] https://launchpad.net/bugs/1754646
<slangasek> acheronuk: hmph ok
<slangasek> acheronuk: I think I'll need to boot it here to get a handle on it
<slangasek> (as opposed to just digging around on the fs)
<acheronuk> slangasek: now, while I was doing all this, I applied that sddm VT change, uploaded a package to our Kubuntu CI PPA, and rolled a new iso when it published
<slangasek> tsimonq2: yes, it's a language-agnostic bug
<acheronuk> which now boots ok!
<acheronuk> this could of course be completely coincidence!
<acheronuk> but.....
<tsimonq2> slangasek: OK.
<acheronuk> slangasek: it would be handing is we could do test rebuilds of official images, adding a PPA source with a test package like new sddm
<acheronuk> s/handing/handy
<doko> Laney: there is a doc-rfc autopkg test failure blocking your poppler upload
<acheronuk> slangasek: 12:40 am here, so I am going to have to give up for the day shortly
<acheronuk> tsimonq2: if a new sddm upload can fix this, can you sort that please?
<tsimonq2> acheronuk: Affirmative.
<acheronuk> tsimonq2: in fact, if the change is good going forward, maybe just do it anyway
<tsimonq2> acheronuk: ok
-queuebot:#ubuntu-release- Unapproved: gnome-software (bionic-proposed/main) [3.28.0-0ubuntu7 => 3.28.1-0ubuntu1] (ubuntu-desktop)
#ubuntu-release 2018-04-11
<slangasek> acheronuk, tsimonq2: ok, I think the regular dm and ubiquity having different opinions about which tty to run on may at least be contributing to the issue - in particular, I see that if display-manager doesn't Conflicts=getty@tty1.service, getty@tty1.service tries to start in parallel with ubiquity.service, which is going to be bad
<slangasek> acheronuk, tsimonq2: so I think from the ubiquity side, we solve this by adding that Conflicts to ubiquity.service; but that sddm also changing would be sensible; I'll test the first part here
<tsimonq2> slangasek: ack
<slangasek> tsimonq2: that worked on the first go
<slangasek> so I'll push that change
<slangasek> (for review, at least)
<tsimonq2> ok
-queuebot:#ubuntu-release- Unapproved: mate-settings-daemon (bionic-proposed/universe) [1.20.1-0ubuntu1 => 1.20.1-2ubuntu1] (ubuntu-mate)
<acheronuk> slangasek: thank you.
<acheronuk> good night
<slangasek> infinity, cyphermox: one of you care to review https://code.launchpad.net/~vorlon/ubiquity/conflict-with-getty1/+merge/342977 ?
-queuebot:#ubuntu-release- Unapproved: buildbot (bionic-proposed/universe) [1.1.1-3ubuntu3 => 1.1.1-3ubuntu4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted buildbot [source] (bionic-proposed) [1.1.1-3ubuntu4]
<doko> what's wrong wih systemd on arm64?
<cyphermox> slangasek: yay
<cyphermox> slangasek: is your other MP, for regain_privileges(), ready too?
<cyphermox> infinity wanted to have a look and better understand it
<slangasek> cyphermox: I haven't gotten feedback yet on that one, I suggest leaving it
-queuebot:#ubuntu-release- Unapproved: xubuntu-community-artwork (bionic-proposed/universe) [16.04.0 => 18.04.0] (ubuntustudio, xubuntu)
<slangasek> doko: why did primer3 need a no-change rebuild?
<doko> slangasek: I had the impression that this was needed to drop the s390x test rebuilds
<slangasek> ok
<slangasek> it didn't drop them
<slangasek> :)
<slangasek> oh, test rebuilds
<slangasek> so unrelated to the autopkgtests?
<doko> no, I really mean autopkgtests
<slangasek> ok
<slangasek> doko: incidentally, Debian bug #850065 looks relevant on openfoam, apparently this package doesn't obey the build env's guidance around parallelization
<ubot5`> Debian bug 850065 in src:openfoam "openfoam: Build runs way more parallel processes than specified by DEB_BUILD_OPTIONS" [Important,Open] http://bugs.debian.org/850065
<doko> slangasek: this is unrelated, caused by make 4.2. I removed that for Ubuntu proposed
<slangasek> doko: I don't think so?  That bug report is a year old
<doko> hmm
-queuebot:#ubuntu-release- Unapproved: cloud-init (bionic-proposed/main) [18.2-4-g05926e48-0ubuntu1 => 18.2-4-g05926e48-0ubuntu2] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: peony (bionic-proposed/universe) [1.1.0-0ubuntu1 => 1.1.1-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (bionic-proposed) [18.2-4-g05926e48-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted peony [source] (bionic-proposed) [1.1.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-settings-daemon [source] (bionic-proposed) [1.20.1-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted xubuntu-community-artwork [source] (bionic-proposed) [18.04.0]
-queuebot:#ubuntu-release- New binary: xubuntu-community-artwork [amd64] (bionic-proposed/universe) [18.04.0] (ubuntustudio, xubuntu)
-queuebot:#ubuntu-release- New: accepted xubuntu-community-artwork [amd64] (bionic-proposed) [18.04.0]
-queuebot:#ubuntu-release- Unapproved: snapd-glib (bionic-proposed/main) [1.38-1 => 1.39-0ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: atf-allwinner (bionic-proposed/universe) [1.0.apritzel.81-1 => 1.0.apritzel.81-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted atf-allwinner [source] (bionic-proposed) [1.0.apritzel.81-1ubuntu1]
<slangasek> LocutusOfBorg: is rollup bootstrap still on your radar?  by grepping logs I found you asked for node-rollup-plugin-commonjs 9.0 to be kicked out of -proposed; is that still the right thing to do?
-queuebot:#ubuntu-release- New binary: atf-allwinner [arm64] (bionic-proposed/universe) [1.0.apritzel.81-1ubuntu1] (no packageset)
<slangasek> tsimonq2: any plans for telepathy-qt?
<slangasek>         uint64_t k1 = gu_le64(blocks[i]);
<slangasek>  // Block read - if your platform needs to do endian-swapping or can only
<slangasek>  // handle aligned reads, do the conversion here
<slangasek> aligned reads, you do not understand them
<acheronuk> slangasek: is this possibly linked to the general (not ubiquity) switch to VT1? https://bugs.launchpad.net/bugs/1762885
<ubot5`> Ubuntu bug 1762885 in sddm (Ubuntu) "SDDM fails to start on laptops modern NVidia cards" [Undecided,New]
<acheronuk> or just maybe general nvidia ****iness
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.519 => 2.520] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: krita (bionic-proposed/universe) [1:4.0.0+dfsg-0ubuntu1 => 1:4.0.1+dfsg-0ubuntu1] (kubuntu)
<Laney> doko: rfc thing> I know, I filed a bug and pinged Till about it, new ghostscript broke it
<LocutusOfBorg> yes slangasek it is still the right thing, unfortunately
<LocutusOfBorg> I could finish the bootstrap, but no change rebuilding the package ends to different/unworking content
<LocutusOfBorg> so I don't want to do an archive publishing with something that starts from a "npm install" on my pc
<LocutusOfBorg> so, kicking up commonjs will prevent this bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892742
<ubot5`> Debian bug 892742 in src:node-rollup "rollup FTBFS with node-rollup-plugin-commonjs 9.0" [Serious,Open]
<LocutusOfBorg> but we will stuck with: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892133
<ubot5`> Debian bug 892133 in node-rollup "node-rollup: does not work after a no-change rebuild (the one in the archive is not suitable for main?)" [Serious,Open]
-queuebot:#ubuntu-release- Unapproved: command-not-found (bionic-proposed/main) [18.04.0 => 18.04.1] (core)
<LocutusOfBorg> hello, wrt remmina in queue, upstream asked me to do the merge, they feel confident about the release, and they would appreciate it being part of bionic
<LocutusOfBorg> while this is not a bug-fix only release, it is true that new features are related to "new plugins", without changing the actual code
<LocutusOfBorg> and there is a serious ssh bug fixed in this release
<LocutusOfBorg> with lots of RDP crashes fixes, and some ubuntu patch merged upstream
-queuebot:#ubuntu-release- Unapproved: rejected command-not-found [source] (bionic-proposed) [18.04.1]
<apw> ^ rejecting as there is some expected change which needs investigation
<LocutusOfBorg> Laney, did you find the "hey can't retry failed update-notifier on armhf tests" written above? :)
<LocutusOfBorg> my mind is blowing because of that :D
<Laney> no
<Laney> weird though, that call is doing archive.getPublishedSources
<LocutusOfBorg> rmadison shows it as published
<LocutusOfBorg> also, britney
<LocutusOfBorg> are we somewhat confusing update-manager and update-notifier?
<LocutusOfBorg> or... epoch issue?
<LocutusOfBorg> oh I can schedule a test against 0.189 and not 0.190
<Laney> https://api.launchpad.net/1.0/ubuntu/+archive/primary?distro_series=https%3A%2F%2Fapi.launchpad.net%2F1.0%2Fubuntu%2Fbionic&version=3.190&status=Published&source_name=update-notifier&ws.op=getPublishedSources
<Laney> this is what we're hitting
<Laney> what's wrong with that then?
<LocutusOfBorg> You submitted an invalid request: update-notifier/3.190 is not published in bionic
<LocutusOfBorg> maybe bionic-proposed?
<LocutusOfBorg> oh, this works indeed https://api.launchpad.net/1.0/ubuntu/+archive/primary?distro_series=https%3A%2F%2Fapi.launchpad.net%2F1.0%2Fubuntu%2Fbionic&version=3.189&status=Published&source_name=update-notifier&ws.op=getPublishedSources
<Laney> yes, and if you remove the version it shows 3.190
<LocutusOfBorg> maybe publisher was killed while publishing and didn't retry to do something?
<Laney> so I need to understand what the problem is there
<cjwatson> bad serialisation
<cjwatson> you're sending version as a float
<cjwatson> should be version=%223.190%22
<cjwatson> otherwise it turns into 3.19 ...
<LocutusOfBorg> LOOOOOOOOOOOOL
<LocutusOfBorg> good catch! :)
<cjwatson> I guess you're constructing the query manually rather than using launchpadlib here?
<cjwatson> also, you should really add &exact_match=true
<Laney> it's doing         if version is not None:
<Laney>             req['version'] = version
<cjwatson> can you point me to the code?
<Laney> https://git.launchpad.net/autopkgtest-cloud/tree/webcontrol/request/submit.py#n256
<cjwatson> right, so you're constructing the request yourself and not doing the marshalling properly
<cjwatson> let me see where the canonical code for this is
<Laney> cheers, didn't occur to me that this wasn't being treated as a string
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.31.2 => 2.32.3.1] (desktop-core, ubuntu-server)
<Laney> I'll add exact_match: true too
 * apw giggles, those are so the hardest things to see
<LocutusOfBorg> mmm I see nvidia test is not ignored on armhf, but why britney started complaining now, with a test that seems to have been failing since the begin on armhf?
<LocutusOfBorg> http://autopkgtest.ubuntu.com/packages/n/nvidia-graphics-drivers-340/bionic/armhf
<cjwatson> Laney: Right, so everything except binary parameters and option values (the latter including ws.op and enumerations like status='Published') should be run through json.dumps
<cjwatson> Laney: Switching to launchpadlib would be best if at all possible, but if you really really can't then you'll have to sprinkle json.dumps around
<cjwatson> The way it nearly works but not quite if you don't follow that protocol is certainly unfortunate
<apw> LocutusOfBorg, that is odd, as the summary does imply it has never passed, and other mentions of that package/version for armhf are always failed
<apw> Laney, is the package/series/arch page complete, ie are all runs considered by britney on there ?  http://autopkgtest.ubuntu.com/packages/n/nvidia-graphics-drivers-340/bionic/armhf
<Laney> should be
<Laney> maybe there's a problem in britney if anyone fancies looking at that
<apw> hrm, then it is perplexing that britney is calling that nvidia-g-d-340/armhf a regression, only for patch
<Laney> that's where the "is this a regression?" logic lives
<apw> right it is per-package, but ... that package has never passed either
<apw> it is per trigger package, but that trigger package, test package combination has never passed either
<apw> (to be more accurate)
<apw> well not if that list is complete
<LocutusOfBorg> or maybe somebody deleted the hint in the last few days?
<LocutusOfBorg> but I don't know how to "git log -p" in bzr
<apw> bzr log -p ?
<apw> it never passes in artful either
<LocutusOfBorg> damn, it never stops, but it is enough
<LocutusOfBorg> -force-badtest nvidia-graphics-drivers-340/all/armhf
<LocutusOfBorg> -# Force nvidia-graphics-drivers-390 in, because new armhf packages being uninstallable is way less important than libglvnd being broken.
<LocutusOfBorg> pitti
<Laney> Certainly looks to me like it should be alwaysfailed, but like I say it needs someone to look into it
<Laney> and if nobody wants to, then I guess add the hint back :-)
<LocutusOfBorg> maybe slangasek removed too much of that file in this revision? https://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/revision/2976
<apw> cirtainly it seems reasonable to hint it given it should to all reading be alwaysfail
<apw> perhaps i should add it but with a reason of "britney needs invesitgaing@
<apw> Laney, i am wondeirng if s-langasek is using a script wihch checks if the version in the hint matches the archive, and all != version and it gets removed.
<apw> Laney, or if he is just removing all /all/ hints so that we see if they are needed and readd them
<apw> oh that one is under "vivid" so i can see how one might ... anyhow ... readding with a current comment
<apw> OH OH we got some team hints ... yay
<apw> LocutusOfBorg, hinted again
<sil2100> Oh, I just now noticed I have my own hint file in britney, huh
 * sil2100 always used Steve's
<apw> sil2100, heh you should indeed, but ... now we have team ones, general hints seem more appropriate there
<LocutusOfBorg> thanks!
-queuebot:#ubuntu-release- Unapproved: accepted glib2.0 [source] (bionic-proposed) [2.56.1-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-framework [source] (bionic-proposed) [5.44.0-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted vte2.91 [source] (bionic-proposed) [0.52.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-disk-utility [source] (bionic-proposed) [3.28.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted remmina [source] (bionic-proposed) [1.2.0-rcgit.29+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: snapd (artful-proposed/main) [2.31.2+17.10 => 2.32.3.1+17.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (bionic-proposed/main) [2.32+18.04 => 2.32.3.1+18.04] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.31.2~14.04 => 2.32.3.1~14.04] (no packageset)
 * apw will review all those snapd updates ^
-queuebot:#ubuntu-release- Unapproved: accepted kmod [sync] (xenial-security) [22-1ubuntu5]
-queuebot:#ubuntu-release- Unapproved: bijiben (bionic-proposed/universe) [3.28.0-1 => 3.28.1-1] (desktop-extra) (sync)
-queuebot:#ubuntu-release- Unapproved: shotwell (bionic-proposed/main) [0.28.1-0ubuntu1 => 0.28.2-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: dtkcore (bionic-proposed/universe) [2.0.7-1 => 2.0.7.1-3] (lubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: gnome-sound-recorder (bionic-proposed/universe) [3.27.90-1 => 3.28.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-sound-recorder [sync] (bionic-proposed) [3.28.1-1]
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-taskbar (bionic-proposed/universe) [56.0-1 => 57.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-taskbar [sync] (bionic-proposed) [57.0-1]
-queuebot:#ubuntu-release- Unapproved: evince (bionic-proposed/main) [3.28.0-1 => 3.28.2-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: evolution-ews (bionic-proposed/universe) [3.28.0-1 => 3.28.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: evolution (bionic-proposed/universe) [3.28.0-4 => 3.28.1-1] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted evolution-ews [sync] (bionic-proposed) [3.28.1-1]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.32]
<apw> ^ snapd superceeded in the queue
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.31.2 => 2.32.3.2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected neutron [source] (xenial-proposed) [2:8.4.0-0ubuntu7.3]
<apw> ^ neutron superceeded in the queue by the same version with more changes
-queuebot:#ubuntu-release- Unapproved: evolution-data-server (bionic-proposed/main) [3.28.0-2ubuntu2 => 3.28.1-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: snapd (artful-proposed/main) [2.31.2+17.10 => 2.32.3.2+17.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.31.2~14.04 => 2.32.3.2~14.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapd (bionic-proposed/main) [2.32+18.04 => 2.32.3.2+18.04] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (bionic-proposed) [2.32.3.1+18.04]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (artful-proposed) [2.32.3.1+17.10]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.32.3.1]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (trusty-proposed) [2.32.3.1~14.04]
<apw> ^ snapd* superceeded in the queue, again
-queuebot:#ubuntu-release- Unapproved: gnome-chess (bionic-proposed/universe) [1:3.28.0-2 => 1:3.28.1-1] (desktop-extra) (sync)
-queuebot:#ubuntu-release- Unapproved: gnome-maps (bionic-proposed/universe) [3.28.0-1 => 3.28.1-1] (desktop-extra, ubuntu-budgie, ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: libdazzle (bionic-proposed/main) [3.28.0-1 => 3.28.1-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: libsoup2.4 (bionic-proposed/main) [2.62.0-1 => 2.62.1-1] (core) (sync)
<darkxst> Laney, https://bileto.ubuntu.com/#/ticket/3230
<darkxst> include libzip 1.5.1 release from today
<darkxst> for bug 1674057
<ubot5`> bug 1674057 in libzip (Ubuntu) "[FFe] upgrade libzip to version 1.5.0" [Wishlist,New] https://launchpad.net/bugs/1674057
<Laney> darkxst: thx
<Laney> looks like you missed the bug reference in libzip
<Laney> i'll try to look later on
<Laney> (anyone else on the team should feel free though)
<darkxst> Laney, hmm so I did, but can't fix it while its in a ppa
-queuebot:#ubuntu-release- Unapproved: ecj (bionic-proposed/universe) [3.12.3-1 => 3.13.2-1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: python3-defaults (bionic-proposed/main) [3.6.5-2 => 3.6.5-3] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: jericho-html (bionic-proposed/universe) [3.2-1 => 3.2-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted jericho-html [sync] (bionic-proposed) [3.2-2]
-queuebot:#ubuntu-release- New: accepted atf-allwinner [arm64] (bionic-proposed) [1.0.apritzel.81-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ecj [sync] (bionic-proposed) [3.13.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted python3-defaults [sync] (bionic-proposed) [3.6.5-3]
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.519 => 2.521] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (bionic-proposed) [2.32.3.2+18.04]
<rbasak> Deriving from something licensed under Expat and then releasing the result under Apache-2.0 is fine, right?
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (artful-proposed) [2.32.3.2+17.10]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.32.3.2]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.32.3.2~14.04]
-queuebot:#ubuntu-release- Unapproved: kmod (trusty-proposed/main) [15-0ubuntu6 => 15-0ubuntu7] (core)
-queuebot:#ubuntu-release- Unapproved: sysprof (bionic-proposed/universe) [3.28.0-1 => 3.28.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: webkit2gtk (bionic-proposed/main) [2.20.0-2ubuntu1 => 2.20.1-1] (desktop-core) (sync)
-queuebot:#ubuntu-release- Unapproved: kicad (bionic-proposed/universe) [4.0.7+dfsg1-1ubuntu1 => 4.0.7+dfsg1-1ubuntu2] (no packageset)
<infinity> rbasak: Yes.
-queuebot:#ubuntu-release- Unapproved: accepted sysprof [sync] (bionic-proposed) [3.28.1-1]
-queuebot:#ubuntu-release- Unapproved: zenity (bionic-proposed/main) [3.28.0-1 => 3.28.1-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted kicad [source] (bionic-proposed) [4.0.7+dfsg1-1ubuntu2]
-queuebot:#ubuntu-release- New sync: golang-github-sanity-io-litter (bionic-proposed/primary) [1.1.0+git20171129.f8fd6a5-1]
-queuebot:#ubuntu-release- Unapproved: golang-github-alecthomas-chroma (bionic-proposed/universe) [0.3.0-1 => 0.4.0+git20180402.51d250f-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted golang-github-alecthomas-chroma [sync] (bionic-proposed) [0.4.0+git20180402.51d250f-1]
<rbasak> infinity: thanks. Apache-2.0 always seemed a bit weird to me so I thought I'd make sure.
<infinity> rbasak: It's not really about the Apache license, but rather that anything under the MIT/X11/Expat license can have pretty much anything done to it, so long as you retain the copyright.
<infinity> rbasak: See the Windows TCP stack from 1993 to 2000 or so as an example.
<infinity> (Well, that was BSD, but same concept)
-queuebot:#ubuntu-release- Unapproved: ca-certificates (bionic-proposed/main) [20170717 => 20180409] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ca-certificates [sync] (bionic-proposed) [20180409]
-queuebot:#ubuntu-release- Unapproved: accepted zenity [sync] (bionic-proposed) [3.28.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted webkit2gtk [sync] (bionic-proposed) [2.20.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted bijiben [sync] (bionic-proposed) [3.28.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted evince [sync] (bionic-proposed) [3.28.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted evolution [sync] (bionic-proposed) [3.28.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-maps [sync] (bionic-proposed) [3.28.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted libsoup2.4 [sync] (bionic-proposed) [2.62.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted dtkcore [sync] (bionic-proposed) [2.0.7.1-3]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-chess [sync] (bionic-proposed) [1:3.28.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted shotwell [sync] (bionic-proposed) [0.28.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted evolution-data-server [source] (bionic-proposed) [3.28.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libdazzle [sync] (bionic-proposed) [3.28.1-1]
-queuebot:#ubuntu-release- New binary: libbpp-phyl [s390x] (bionic-proposed/universe) [2.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-phyl [ppc64el] (bionic-proposed/universe) [2.4.0-1] (no packageset)
<juliank> Should we ignore the ganeti failure for i386 for socat? This thing failed before with the same error messages
<juliank> it only worked 3 times so far
-queuebot:#ubuntu-release- New binary: libbpp-phyl [i386] (bionic-proposed/universe) [2.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-phyl [amd64] (bionic-proposed/universe) [2.4.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gnome-desktop3 (bionic-proposed/main) [3.28.0-0ubuntu1 => 3.28.1-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libbpp-phyl [armhf] (bionic-proposed/universe) [2.4.0-1] (no packageset)
<LocutusOfBorg> please accept mongodb, fixing a stupid mistake on my side
-queuebot:#ubuntu-release- Unapproved: mongodb (bionic-proposed/universe) [1:3.4.14-3ubuntu1 => 1:3.4.14-3ubuntu2] (mozilla)
-queuebot:#ubuntu-release- New binary: libbpp-phyl [arm64] (bionic-proposed/universe) [2.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-github-sanity-io-litter [sync] (bionic-proposed) [1.1.0+git20171129.f8fd6a5-1]
-queuebot:#ubuntu-release- New: accepted libbpp-phyl [arm64] (bionic-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- New: accepted libbpp-phyl [i386] (bionic-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- New: accepted libbpp-phyl [s390x] (bionic-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- New: accepted libbpp-phyl [amd64] (bionic-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- New: accepted libbpp-phyl [ppc64el] (bionic-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- New: accepted libbpp-phyl [armhf] (bionic-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- New binary: golang-github-sanity-io-litter [amd64] (bionic-proposed/none) [1.1.0+git20171129.f8fd6a5-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: sddm (bionic-proposed/universe) [0.17.0-1ubuntu2 => 0.17.0-1ubuntu3] (kubuntu)
-queuebot:#ubuntu-release- New: accepted golang-github-sanity-io-litter [amd64] (bionic-proposed) [1.1.0+git20171129.f8fd6a5-1]
-queuebot:#ubuntu-release- Unapproved: mongodb (bionic-proposed/universe) [1:3.4.14-3ubuntu1 => 1:3.4.14-3ubuntu2] (mozilla)
<slangasek> acheronuk: the hybrid videa issue is unlikely to be related to the VT configuration.  But I guess you could ask people to retest with an sddm that does start on VT1?
<slangasek> LocutusOfBorg: ok, node-rollup-plugin-commonjs removed from -proposed
<slangasek> LocutusOfBorg, apw: I don't currently have good scripting when removing the hints... but http://autopkgtest.ubuntu.com/packages/n/nvidia-graphics-drivers-340/bionic/armhf shows no passes, so I assumed it was wrong to hint a non-regression
<slangasek> so, we can add it back, sure
<slangasek> but it seems that's cleared up somehow in the meantime?
<Laney> there is something interesting with regression / alwaysfailed calculation
<Laney> python3-defaults is showing "autopkgtest for glib2.0: amd64: Test in progress (always failed), arm64: Test in progress (always failed), i386: Test in progress (always failed), ppc64el: Test in progress (always failed), s390x: Test in progress (always failed)"
<Laney> always failed is lies
<ginggs> slangasek: nvidia cleared up because it was hinted
<slangasek> ginggs: ok, but under linux-meta-raspi2, nvidia-graphics-drivers-340/armhf shows as 'always failed', which is not based on hinting
<slangasek> Laney: doh
<apw> slangasek, that is under a linux-meta-* so it is not representative of reality
<apw> slangasek, remember those are specially neutered for history
<slangasek> apw: ah ok
-queuebot:#ubuntu-release- Unapproved: certmonger (bionic-proposed/universe) [0.79.5-3 => 0.79.5-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted certmonger [source] (bionic-proposed) [0.79.5-3ubuntu1]
-queuebot:#ubuntu-release- New binary: deepin-qt5dxcb-plugin [amd64] (bionic-proposed/universe) [1.1.8.4+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-qt5dxcb-plugin [ppc64el] (bionic-proposed/universe) [1.1.8.4+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-qt5dxcb-plugin [s390x] (bionic-proposed/universe) [1.1.8.4+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-qt5dxcb-plugin [armhf] (bionic-proposed/universe) [1.1.8.4+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-qt5dxcb-plugin [i386] (bionic-proposed/universe) [1.1.8.4+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-qt5dxcb-plugin [arm64] (bionic-proposed/universe) [1.1.8.4+ds-1] (no packageset)
-queuebot:#ubuntu-release- New sync: linux-meta-oem (bionic-proposed/primary) [4.15.0.1002.3]
-queuebot:#ubuntu-release- New sync: linux-oem (bionic-proposed/primary) [4.15.0-1002.3]
-queuebot:#ubuntu-release- New sync: linux-signed-oem (bionic-proposed/primary) [4.15.0-1002.3]
-queuebot:#ubuntu-release- New: accepted deepin-qt5dxcb-plugin [amd64] (bionic-proposed) [1.1.8.4+ds-1]
-queuebot:#ubuntu-release- New: accepted deepin-qt5dxcb-plugin [arm64] (bionic-proposed) [1.1.8.4+ds-1]
-queuebot:#ubuntu-release- New: accepted deepin-qt5dxcb-plugin [armhf] (bionic-proposed) [1.1.8.4+ds-1]
-queuebot:#ubuntu-release- New: accepted deepin-qt5dxcb-plugin [i386] (bionic-proposed) [1.1.8.4+ds-1]
-queuebot:#ubuntu-release- New: accepted deepin-qt5dxcb-plugin [ppc64el] (bionic-proposed) [1.1.8.4+ds-1]
-queuebot:#ubuntu-release- New: accepted deepin-qt5dxcb-plugin [s390x] (bionic-proposed) [1.1.8.4+ds-1]
-queuebot:#ubuntu-release- Unapproved: accepted kmod [source] (trusty-proposed) [15-0ubuntu7]
-queuebot:#ubuntu-release- Unapproved: deepin-picker (bionic-proposed/universe) [1.6.2-1 => 1.6.2-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted deepin-picker [sync] (bionic-proposed) [1.6.2-3]
-queuebot:#ubuntu-release- Unapproved: dtkwidget (bionic-proposed/universe) [2.0.7-1 => 2.0.7.2-2] (lubuntu) (sync)
<tsimonq2> slangasek: telepathy-qt> I knew I was forgetting something. :/  I'll look tonight.
<slangasek> tsimonq2: k, thanks!
-queuebot:#ubuntu-release- New binary: libbpp-phyl-omics [ppc64el] (bionic-proposed/universe) [2.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-phyl-omics [i386] (bionic-proposed/universe) [2.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-phyl-omics [s390x] (bionic-proposed/universe) [2.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-phyl-omics [amd64] (bionic-proposed/universe) [2.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-phyl-omics [armhf] (bionic-proposed/universe) [2.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-phyl-omics [arm64] (bionic-proposed/universe) [2.4.0-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-taskflow (bionic-proposed/main) [3.1.0-0ubuntu1 => 3.1.0-0ubuntu2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-meta (bionic-proposed/universe) [1.221 => 1.222] (ubuntu-mate)
-queuebot:#ubuntu-release- New: accepted libbpp-phyl-omics [amd64] (bionic-proposed) [2.4.0-2]
-queuebot:#ubuntu-release- New: accepted libbpp-phyl-omics [armhf] (bionic-proposed) [2.4.0-2]
-queuebot:#ubuntu-release- New: accepted libbpp-phyl-omics [ppc64el] (bionic-proposed) [2.4.0-2]
-queuebot:#ubuntu-release- New: accepted libbpp-phyl-omics [arm64] (bionic-proposed) [2.4.0-2]
-queuebot:#ubuntu-release- New: accepted libbpp-phyl-omics [s390x] (bionic-proposed) [2.4.0-2]
-queuebot:#ubuntu-release- New: accepted libbpp-phyl-omics [i386] (bionic-proposed) [2.4.0-2]
<ErichEickmeyer> infinity, slangasek: I'm Erich from the Ubuntu Studio team. On tsimonq2's advice, I need to give you a heads-up that Ubuntu Studio might not be LTS this release and only go 9-month. We are lacking manpower and are working on a refresh for 18.10 for a number of features, but we simply don't have the manpower for an LTS at this point in time.
<tsimonq2> o/ ErichEickmeyer
<slangasek> ErichEickmeyer: thanks for the info - from what tsimonq2 had said I thought it was an open question, but if you're definitively not doing an LTS I'm happy to make that adjustment now to the metadata
<ErichEickmeyer> slangasek: It's an open question still.
<ErichEickmeyer> I just got the email out to the ML to get a pulse check on the idea.
<slangasek> ErichEickmeyer: you mean you might still change your minds and go LTS?
<slangasek> ah you did say "might not"
<slangasek> ok
<ErichEickmeyer> Yeah, this mostly was a "heads up".
<ErichEickmeyer> I also want to give sakrecoer the opportunity to advise on this since he's still the lead.
<ErichEickmeyer> His time is limited, so I''ve been leading the charge on a number of things.
-queuebot:#ubuntu-release- Unapproved: stress-ng (bionic-proposed/universe) [0.09.23-1 => 0.09.24-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted stress-ng [sync] (bionic-proposed) [0.09.24-1]
-queuebot:#ubuntu-release- Unapproved: gcc-7 (bionic-proposed/main) [7.3.0-15ubuntu2 => 7.3.0-16ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted python-taskflow [source] (bionic-proposed) [3.1.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted mongodb [source] (bionic-proposed) [1:3.4.14-3ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-7 [source] (bionic-proposed) [7.3.0-16ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted dtkwidget [sync] (bionic-proposed) [2.0.7.2-2]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-meta [source] (bionic-proposed) [1.222]
-queuebot:#ubuntu-release- Unapproved: hugo (bionic-proposed/universe) [0.37.1-1 => 0.38-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted hugo [sync] (bionic-proposed) [0.38-1]
-queuebot:#ubuntu-release- Unapproved: foxtrotgps (bionic-proposed/universe) [1.2.0-1build2 => 1.2.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted foxtrotgps [sync] (bionic-proposed) [1.2.1-1]
-queuebot:#ubuntu-release- Unapproved: python-oslo.privsep (bionic-proposed/main) [1.27.0-0ubuntu2 => 1.27.0-0ubuntu3] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: gtkhash (bionic-proposed/universe) [1.1.1-1 => 1.1.1-2] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: apcupsd (bionic-proposed/universe) [3.14.14-1 => 3.14.14-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted apcupsd [sync] (bionic-proposed) [3.14.14-2]
-queuebot:#ubuntu-release- Unapproved: pandas (bionic-proposed/universe) [0.22.0-2 => 0.22.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pandas [source] (bionic-proposed) [0.22.0-2ubuntu1]
<rbasak> Please could some reject mongodb 1:3.4.14-3ubuntu2 from Bionic unapproved? It's been superseded (a 1:3.4.14-3ubuntu2 has already gone in).
<slangasek> rbasak: done
-queuebot:#ubuntu-release- Unapproved: rejected mongodb [source] (bionic-proposed) [1:3.4.14-3ubuntu2]
<rbasak> Thanks!
<ginggs> slangasek: pandas tests/io/test_pytables.py::TestHDFStore::test_encoding Bus error (core dumped) in case you are inclined
<slangasek> ginggs: on armhf?
<ginggs> slangasek: yes, I meant to write that.  You seem to be good at fixing alignment issues
<slangasek> ginggs: yeah but pandas was already removed from armhf over these issues and I'm not in a hurry to bring it back
-queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (bionic-proposed) [2.520]
<slangasek> ginggs: IIRC I looked at it a while ago and couldn't isolate which library actually contained the bug, in the stack of a half dozen
<ginggs> slangasek: ok, how about an alignment error in an R package then?  :) r-cran-memoise
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.521]
<slangasek> ginggs: so basically at this point, it's safe to assume that any armhf sigbuses left in update_excuses are ones that I've looked at and walked away from ;)
-queuebot:#ubuntu-release- Unapproved: golang-github-spf13-afero (bionic-proposed/universe) [1.0.2-1 => 1.1.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted golang-github-spf13-afero [sync] (bionic-proposed) [1.1.0-1]
<ginggs> slangasek: :)
-queuebot:#ubuntu-release- Unapproved: debdelta (bionic-proposed/universe) [0.60 => 0.61] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted debdelta [sync] (bionic-proposed) [0.61]
-queuebot:#ubuntu-release- Unapproved: libnfs (bionic-proposed/universe) [1.11.0-3 => 2.0.0-1~exp1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: strace (bionic-proposed/main) [4.19-1ubuntu2 => 4.21-1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: ryu (bionic-proposed/main) [4.15-0ubuntu1 => 4.15-0ubuntu2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: gcc-5 (bionic-proposed/universe) [5.5.0-11ubuntu1 => 5.5.0-12ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libbpp-qt (bionic-proposed/universe) [2.3.2-1build1 => 2.4.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-5 [source] (bionic-proposed) [5.5.0-12ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libbpp-qt [sync] (bionic-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- Unapproved: bppsuite (bionic-proposed/universe) [2.3.2-1build1 => 2.4.0-1] (no packageset) (sync)
<doko> jbicha: did you become a debian-med member? ;p
-queuebot:#ubuntu-release- Unapproved: accepted bppsuite [sync] (bionic-proposed) [2.4.0-1]
<jbicha> no, just slightly cleaning up after them
<jbicha> depending on how big of a hurry you're in, you could remove bppphyview and physamp until debian-med cares enough about them to make them buildable again
-queuebot:#ubuntu-release- New binary: libbpp-qt [ppc64el] (bionic-proposed/universe) [2.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-qt [s390x] (bionic-proposed/universe) [2.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-qt [arm64] (bionic-proposed/universe) [2.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-qt [i386] (bionic-proposed/universe) [2.4.0-1] (no packageset)
<jbicha> maybe ignore physamp 1.0.3-1's autopkgtests too
-queuebot:#ubuntu-release- New binary: libbpp-qt [amd64] (bionic-proposed/universe) [2.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbpp-qt [armhf] (bionic-proposed/universe) [2.4.0-1] (no packageset)
<slangasek> better in general to remove a package than to knowingly regress autopkgtests
<slangasek> doko: I didn't see an answer to my question about removals of non-buggy packages from -proposed that are blocked by missing deps.  What policy do you think we should be applying here?
-queuebot:#ubuntu-release- Unapproved: gcc-7-cross-ports (bionic-proposed/universe) [16ubuntu2 => 16ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: slic3r-prusa (bionic-proposed/universe) [1.39.0+dfsg-1 => 1.39.1+dfsg-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gcc-7-cross (bionic-proposed/main) [20ubuntu2 => 20ubuntu3] (ubuntu-desktop)
<doko> hmm, keeping them there makes people look at them again and again. otoh removing will need manual actual by looking into debian
<doko> still curious why gcc-7-cross is a desktop package
<tsimonq2> doko: bug 1683749, perhaps.
<ubot5`> bug 1683749 in britney "Please list bugs tagged as "update-excuse" on update_excuses" [Undecided,Confirmed] https://launchpad.net/bugs/1683749
<doko> well, starts with g* ;p
-queuebot:#ubuntu-release- Unapproved: accepted slic3r-prusa [sync] (bionic-proposed) [1.39.1+dfsg-3]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-7-cross-ports [source] (bionic-proposed) [16ubuntu3]
-queuebot:#ubuntu-release- New: accepted libbpp-qt [amd64] (bionic-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- New: accepted libbpp-qt [armhf] (bionic-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- New: accepted libbpp-qt [ppc64el] (bionic-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- New: accepted libbpp-qt [arm64] (bionic-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- New: accepted libbpp-qt [s390x] (bionic-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- New: accepted libbpp-qt [i386] (bionic-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- New: accepted linux-meta-oem [sync] (bionic-proposed) [4.15.0.1002.3]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [sync] (bionic-proposed) [4.15.0-1002.3]
-queuebot:#ubuntu-release- New: accepted linux-oem [sync] (bionic-proposed) [4.15.0-1002.3]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-7-cross [source] (bionic-proposed) [20ubuntu3]
<slangasek> doko: yes, that is the tradeoff.  If we're going to kick them out of -proposed, perhaps we should keep a list somewhere else and revisit (or automatically process) a few times during the cycle?
<slangasek> doko: but certainly if we are going to remove packages from -proposed that are not-buggy-but-blocked, nearly everything else > 90 days should also be removed
<jbicha> yes please keep a list
<doko> the list sounds fine
<slangasek> doko: where would you like to put this list?
<jbicha> there won't necessarily be a new Debian upload since it's a dependency that's broken in some of these cases not the package itself
<slangasek> jbicha: precisely
<doko> if you remove them, can you revive these packages by some copy magic?
<slangasek> doko: yes, absolutely
-queuebot:#ubuntu-release- Unapproved: bind-dyndb-ldap (bionic-proposed/universe) [11.1-1 => 11.1-2] (no packageset) (sync)
<doko> slangasek: keep it in a place where I can write =)
<slangasek> doko: the wiki?  the sync-blacklist branch?
-queuebot:#ubuntu-release- Unapproved: accepted bind-dyndb-ldap [sync] (bionic-proposed) [11.1-2]
<doko> sync-blocklist would make sense
<slangasek> doko: also I don't know a good way to query the list of packages that you have recently removed; I know grafana-zabbix only because it was such an outlier, but I think it probably wasn't the only one
<doko> I'll look in my shell history. will prepare a list tomrrow and send it to you
<slangasek> doko: thanks
<slangasek> doko: https://bazaar.launchpad.net/~ubuntu-archive/+junk/sync-blacklist/view/head:/extra-removals.txt
<tsimonq2> I really wish we could see who accepts/rejects a package and why, while we're at it. Would LP be the right thing to file against, or does a separate piece of tooling handle queue management?
<LocutusOfBorg> g'night folks!
 * tsimonq2 waves to LocutusOfBorg 
<slangasek> tsimonq2: yes, LP
<slangasek> tsimonq2: removals are documented in the history however
<tsimonq2> slangasek: Correct, in the publishing history.
<slangasek> ah yes you said accepts/rejects not accepts/removals, ignore me
<tsimonq2> slangasek: So I can be specific in the bug report, Soyuz?
<slangasek> tsimonq2: yes
<tsimonq2> slangasek: okl
<slangasek> (not sure if that matters)
<tsimonq2> *ok
<tsimonq2> Â¯\_(ã)_/Â¯
<doko> ginggs: now nodejs migrated, and I see js tests failing ... https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/armhf/s/sphinx/20180411_204814_f63f9@/log.gz
<tsimonq2> slangasek: bug 1763174, how's it look?
<ubot5`> bug 1763174 in Launchpad itself "Soyuz should document acceptions/rejections from the queue" [Undecided,New] https://launchpad.net/bugs/1763174
<doko> ;p
<slangasek> tsimonq2: no opinion ;)
<tsimonq2> slangasek: No opinion on the clarity of the bug report and how accurately it describes the current situation at hand, as well as what's desired? ;)
<slangasek> yep!
<tsimonq2> Alright. :)
-queuebot:#ubuntu-release- Unapproved: accepted gtkhash [sync] (bionic-proposed) [1.1.1-2]
-queuebot:#ubuntu-release- Unapproved: accepted libnfs [sync] (bionic-proposed) [2.0.0-1~exp1]
<tsimonq2> slangasek: Assigned it to myself; it'll probably be handled post-18.04 but ideally before the floodgates open, much like bug 1654761.
<ubot5`> bug 1654761 in Auto Package Testing "Make sure duplicate tests cannot be queued" [Undecided,In progress] https://launchpad.net/bugs/1654761
-queuebot:#ubuntu-release- New binary: libnfs [s390x] (bionic-proposed/universe) [2.0.0-1~exp1] (kubuntu)
 * tsimonq2 wonders how quick the Calculating Camel will be announced...
-queuebot:#ubuntu-release- New binary: libnfs [ppc64el] (bionic-proposed/universe) [2.0.0-1~exp1] (kubuntu)
<tsimonq2> slangasek: Would you happen to know where I can find the autoaccepter script?
-queuebot:#ubuntu-release- New binary: libnfs [amd64] (bionic-proposed/universe) [2.0.0-1~exp1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libnfs [i386] (bionic-proposed/universe) [2.0.0-1~exp1] (kubuntu)
<tsimonq2> lp:ubuntu-archive-publishing?
<ginggs> tsimonq2: see sphinx autopkgtest failures http://autopkgtest.ubuntu.com/packages/sphinx/bionic/armhf - related to your nodejs?
<slangasek> tsimonq2: I don't know; afaik stgraber operates it
-queuebot:#ubuntu-release- New binary: libnfs [arm64] (bionic-proposed/universe) [2.0.0-1~exp1] (kubuntu)
<tsimonq2> ginggs: I'm not sure; are we talking about the nodejs you synced in my name? ;P
<tsimonq2> slangasek: ack, he's on vac?
<cyphermox> yes
<tsimonq2> Ok, I'll ping next week.
<slangasek> tsimonq2: so he said
-queuebot:#ubuntu-release- New: accepted libnfs [amd64] (bionic-proposed) [2.0.0-1~exp1]
-queuebot:#ubuntu-release- New: accepted libnfs [i386] (bionic-proposed) [2.0.0-1~exp1]
-queuebot:#ubuntu-release- New: accepted libnfs [s390x] (bionic-proposed) [2.0.0-1~exp1]
-queuebot:#ubuntu-release- New: accepted libnfs [arm64] (bionic-proposed) [2.0.0-1~exp1]
<tsimonq2> nodejs> To be serious here, I'm not entirely sure what the problem is with those tests.
-queuebot:#ubuntu-release- New: accepted libnfs [ppc64el] (bionic-proposed) [2.0.0-1~exp1]
<ginggs> doko: FAILURES / test_build_sphinx / ModuleNotFoundError: No module named \'distutils.core\'
<tsimonq2> Right, why would that be nodejs?
<doko> oops
<doko> but just armhf?
<ginggs> doko: the others haven't run yet - (well ppc64el and s390x did, but they always fail)
-queuebot:#ubuntu-release- Unapproved: sphinx (bionic-proposed/main) [1.6.7-1 => 1.6.7-1ubuntu1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted sphinx [source] (bionic-proposed) [1.6.7-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted strace [source] (bionic-proposed) [4.21-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.privsep [source] (bionic-proposed) [1.27.0-0ubuntu3]
<Bashing-om> TJ-: Watching in #ubuntu-release. heavy discussion on the release testing schedules .
<tsimonq2> Bashing-om: "heavy discussion"? :)
<Bashing-om> opps wrong window ^ // Yeah .. been a bit following what yall are discussing .
<tsimonq2> Maybe on the mailing list, but unless I missed something, not here?
<Bashing-om> tsimonq2: mailing list for the most part . some reference here .. else I would not have much of a clue :)
<tsimonq2> Bashing-om: I assume I can continue this conversation with you in #ubuntu-discuss? ;)
<Bashing-om> tsimonq2: Yes my mentor . I await .
-queuebot:#ubuntu-release- Unapproved: gnocchi (bionic-proposed/universe) [4.2.0-0ubuntu2 => 4.2.0-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gnocchi [source] (bionic-proposed) [4.2.0-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: gpaw (bionic-proposed/universe) [1.3.0-2 => 1.3.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gpaw [source] (bionic-proposed) [1.3.0-2ubuntu1]
<ginggs> doko: will you send that gpaw fix to debian please?
-queuebot:#ubuntu-release- Unapproved: python-testtools (bionic-proposed/main) [2.3.0-3ubuntu1 => 2.3.0-3ubuntu2] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-future (bionic-proposed/main) [0.15.2-4ubuntu1 => 0.15.2-4ubuntu2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted python-future [source] (bionic-proposed) [0.15.2-4ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted python-testtools [source] (bionic-proposed) [2.3.0-3ubuntu2]
<doko> ginggs: yes
<ginggs> doko: :) I was waiting for the problem to appear in ubuntu
-queuebot:#ubuntu-release- Unapproved: libunity (bionic-proposed/main) [7.1.4+18.04.20180209.1-0ubuntu1 => 7.1.4+18.04.20180209.1-0ubuntu2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted libunity [source] (bionic-proposed) [7.1.4+18.04.20180209.1-0ubuntu2]
<ginggs> doko: you get a panda! arm64 you get a panda! s390x you get a panda!  \o/ everyone gets pandas! except you, armhf, you and your silly bus error
<slangasek> armhf, TI already gave you pandas
<valorie>  aren't we handing out beavers this round?
<tsimonq2> I want camels :P
<valorie> lol
<xnox> shit, cancel order of 100s of pandas
<tsimonq2> hahahahahahaa
-queuebot:#ubuntu-release- Unapproved: gcc-7 (bionic-proposed/main) [7.3.0-16ubuntu1 => 7.3.0-16ubuntu2] (core)
<mwhudson> i have a broken pandaboard if anyone is feeling left out
<mwhudson> i think technically it belongs to linaro
<xnox> I went to zoo in Hong Kong and saw a very sad panda
-queuebot:#ubuntu-release- Unapproved: accepted gcc-7 [source] (bionic-proposed) [7.3.0-16ubuntu2]
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/universe) [4.15.0-1002.3] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1002.3]
<ginggs> I went to a zoo that only had a dog
<tsimonq2> hahahaha
<ginggs> it was a shih tzu
<tsimonq2> xnox: Sad pandas are bad. You cheered it up, I hope?
<doko> they have limits on noise levels over there
<tsimonq2> Ah.
#ubuntu-release 2018-04-12
-queuebot:#ubuntu-release- Unapproved: gnome-system-monitor (bionic-proposed/main) [3.28.0-1 => 3.28.1-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: xubuntu-meta (bionic-proposed/universe) [2.224 => 2.225] (xubuntu)
-queuebot:#ubuntu-release- Unapproved: kodi (bionic-proposed/universe) [2:17.6+dfsg1-1 => 2:17.6+dfsg1-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: vlc (bionic-proposed/universe) [3.0.1-3 => 3.0.1-3build1] (kubuntu, mozilla)
-queuebot:#ubuntu-release- Unapproved: mpd (bionic-proposed/universe) [0.20.18-1 => 0.20.18-1build1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted kodi [source] (bionic-proposed) [2:17.6+dfsg1-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted mpd [source] (bionic-proposed) [0.20.18-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted vlc [source] (bionic-proposed) [3.0.1-3build1]
-queuebot:#ubuntu-release- Unapproved: sgt-launcher (bionic-proposed/universe) [0.2.3-0ubuntu1 => 0.2.4-0ubuntu1] (xubuntu)
-queuebot:#ubuntu-release- Unapproved: python-xarray (bionic-proposed/universe) [0.9.6-1 => 0.10.2-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-xarray [sync] (bionic-proposed) [0.10.2-1]
-queuebot:#ubuntu-release- Unapproved: dirtbike (bionic-proposed/universe) [0.3-2 => 0.3-2.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted dirtbike [source] (bionic-proposed) [0.3-2.1]
<tsimonq2> slangasek: telepathy-qt> Argh, please just remove it from proposed. The tarball mismatch causes dh_missing to complain, and the sync was done for the purpose of keeping Ubuntu in sync with Debian, not because it included actually good changes.
<tsimonq2> (Well, I mean, the changes are absolutely sane, but it's not like they *needed* to be introduced.)
<slangasek> tsimonq2: nuked
<tsimonq2> slangasek: Thanks.
-queuebot:#ubuntu-release- Unapproved: gnocchi (bionic-proposed/universe) [4.2.0-0ubuntu3 => 4.2.0-0ubuntu4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gnocchi [source] (bionic-proposed) [4.2.0-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: dee (bionic-proposed/main) [1.2.7+17.10.20170616-0ubuntu3 => 1.2.7+17.10.20170616-0ubuntu4] (kubuntu, ubuntu-desktop)
<slangasek> ahaha and harfbuzz's armhf rebuild sigbus is freetype's fault
<tsimonq2> Silly question: can I dput to ubuntu via sftp with tsimonq2 as the username like with PPAs?
<tsimonq2> I can't seem to dput *anything* atm. :/
<tsimonq2> It might be my connection, actually... hmm...
<tsimonq2> Oh so I CAN. Yay, default setting changed.
-queuebot:#ubuntu-release- Unapproved: mpv (bionic-proposed/universe) [0.27.0-2ubuntu4 => 0.27.2-1ubuntu1] (ubuntu-budgie, ubuntukylin)
<tsimonq2> slangasek: src:mpv has a CVE fix, would be cool to get it through unapproved quickly if you could.
-queuebot:#ubuntu-release- Unapproved: accepted mpv [source] (bionic-proposed) [0.27.2-1ubuntu1]
<tsimonq2> Thanks.
-queuebot:#ubuntu-release- Unapproved: ffmpeg (bionic-proposed/universe) [7:3.4.2-1build1 => 7:3.4.2-2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: boinc (bionic-proposed/universe) [7.9.3+dfsg-3 => 7.9.3+dfsg-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted boinc [sync] (bionic-proposed) [7.9.3+dfsg-4]
-queuebot:#ubuntu-release- Unapproved: bind9 (bionic-proposed/main) [1:9.11.2.P1-1ubuntu5 => 1:9.11.3+dfsg-1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted dee [source] (bionic-proposed) [1.2.7+17.10.20170616-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (bionic-proposed) [0.96.24.28]
-queuebot:#ubuntu-release- Unapproved: ubuntu-dev-tools (bionic-proposed/universe) [0.161 => 0.162] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-dev-tools [sync] (bionic-proposed) [0.162]
<doko> Laney, slangasek: the ppc64el autopkg testers need some attention
-queuebot:#ubuntu-release- Unapproved: gradle (bionic-proposed/universe) [3.4.1-6 => 3.4.1-7] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gradle [sync] (bionic-proposed) [3.4.1-7]
-queuebot:#ubuntu-release- Unapproved: ethtool (bionic-proposed/main) [1:4.15-0ubuntu1 => 1:4.15-1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: pyopenssl (bionic-proposed/main) [17.5.0-1 => 17.5.0-1ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server)
<Laney> doko: don't think so, we just have less capacity there than on other arches so it takes longer
-queuebot:#ubuntu-release- Unapproved: command-not-found (bionic-proposed/main) [18.04.0 => 18.04.1] (core)
<doko> ahh, ok
<Laney> there's another cloud region we should be able to use soon though
<tjaalton> that bind9 merge above fixes a crash I'm seeing with freeipa
-queuebot:#ubuntu-release- Unapproved: lvm2 (bionic-proposed/main) [2.02.176-4.1ubuntu2 => 2.02.176-4.1ubuntu3] (core)
<juliank> doko: ^ there we go
-queuebot:#ubuntu-release- Unapproved: buildbot (bionic-proposed/universe) [1.1.1-3ubuntu4 => 1.1.1-3ubuntu5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted buildbot [source] (bionic-proposed) [1.1.1-3ubuntu5]
<oSoMoN> sil2100, good morning! can the i386 autopkgtest failure for libreoffice 1:6.0.3-0ubuntu1 be ignored for the migration to proceed? this is still bug #1699772 hitting us (which btw I think I heard might be fixed with openjdk 10, which will be pulled in by the new default-jdk package in -proposed)
<ubot5`> bug 1699772 in linux (Ubuntu Bionic) "linux-image-4.13.0-12-generic, linux-image-4.10.0-24-generic, linux-image-4.8.0-56-generic, linux-image-4.4.0-81-generic, linux-image-3.13.0-121-generic | Regression: many user-space apps crashing" [Critical,Incomplete] https://launchpad.net/bugs/1699772
-queuebot:#ubuntu-release- Unapproved: sosreport (bionic-proposed/main) [3.5-1ubuntu2 => 3.5-1ubuntu3] (ubuntu-desktop, ubuntu-server)
<sil2100> oSoMoN: I have already accepted libreoffice, like around an hour ago ;) The test failure has been added to the hints
<oSoMoN> sil2100, oh, excellent, thanks!
<oSoMoN> sil2100, it's not the 5.4.6 SRU to artful though, in that case it's the new upload to bionic
<sil2100> oSoMoN: ah
 * sil2100 didn't look at the bionic queue yet
<sil2100> queue/excuses
<sil2100> oSoMoN: I'll hint it in now
<oSoMoN> thanks!
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-input-libinput (bionic-proposed/main) [0.27.0-1 => 0.27.1-1] (desktop-core) (sync)
<sil2100> coreycb: hey! The latest pike stable release is stuck in artful due to 2 bugs still not getting verified - could you poke someone to get those tested?
<sil2100> coreycb: there's a follow-up neutron upload in the queue
-queuebot:#ubuntu-release- Unapproved: accepted command-not-found [source] (bionic-proposed) [18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (bionic-proposed) [3.5-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted pyopenssl [source] (bionic-proposed) [17.5.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: debconf-kde (bionic-proposed/universe) [1.0.2-1 => 1.0.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted lvm2 [source] (bionic-proposed) [2.02.176-4.1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (xenial-proposed) [2:8.4.0-0ubuntu7.3]
-queuebot:#ubuntu-release- Unapproved: python-apt (bionic-proposed/main) [1.6.0~rc2ubuntu1 => 1.6.0~rc2ubuntu2] (core)
<juliank> sil2100: ^ urgent. this adds critical validation to depcache calls which might break some stuff.
<juliank> can you help? :)
<sil2100> juliank: looking!
-queuebot:#ubuntu-release- Unapproved: accepted python-apt [source] (bionic-proposed) [1.6.0~rc2ubuntu2]
<sil2100> jbicha: hey! For me not to waste time too much looking, the gnome-* bionic uploads you made, do those have any new features and FFe's related to them?
-queuebot:#ubuntu-release- Unapproved: accepted snapd-glib [source] (bionic-proposed) [1.39-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted krita [source] (bionic-proposed) [1:4.0.1+dfsg-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ryu [source] (bionic-proposed) [4.15-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted sddm [source] (bionic-proposed) [0.17.0-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted sgt-launcher [source] (bionic-proposed) [0.2.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted xubuntu-meta [source] (bionic-proposed) [2.225]
<sil2100> hmmm, the bind9 upload looks like it needs a FFe
<sil2100> Who prepared this merge?
-queuebot:#ubuntu-release- Unapproved: accepted pulseaudio [source] (xenial-proposed) [1:8.0-0ubuntu3.9]
-queuebot:#ubuntu-release- Unapproved: parole (bionic-proposed/universe) [1.0.0-1 => 1.0.1-0ubuntu1] (ubuntustudio, xubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted debconf-kde [source] (bionic-proposed) [1.0.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: xfce4-pulseaudio-plugin (bionic-proposed/universe) [0.4.0-0ubuntu1 => 0.4.1-0ubuntu1] (xubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (trusty-proposed) [204-5ubuntu20.28]
<sil2100> juliank: hey! Could you fill in a regression potential field to LP: #1332440 ?
<ubot5`> Launchpad bug 1332440 in apt (Ubuntu Trusty) "apt-get update very slow when ulimit -n is big" [Undecided,In progress] https://launchpad.net/bugs/1332440
<sil2100> Damn, this is one really old bug
<juliank> oh, did I forget it?
<juliank> sil2100: added
<sil2100> Ossum
<sil2100> Thanks!
-queuebot:#ubuntu-release- Unapproved: accepted parole [source] (bionic-proposed) [1.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (trusty-proposed) [1.0.1ubuntu2.18]
<juliank> thanks sil2100
<bluesabre> thanks sil2100 :)
-queuebot:#ubuntu-release- Unapproved: doc-rfc (bionic-proposed/multiverse) [20170121-1 => 20170121-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted doc-rfc [source] (bionic-proposed) [20170121-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: nvidia-prime (bionic-proposed/main) [0.8.6 => 0.8.7] (ubuntu-desktop)
<jbicha> sil2100: everything gnome- in bionic queue are regular bugfix releases except for gnome-initial-setup which is still getting UI & string adjustments
-queuebot:#ubuntu-release- Unapproved: accepted gnome-builder [source] (bionic-proposed) [3.28.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-terminal [source] (bionic-proposed) [3.28.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-calculator [source] (bionic-proposed) [1:3.28.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-prime [source] (bionic-proposed) [0.8.7]
-queuebot:#ubuntu-release- Unapproved: accepted xfce4-pulseaudio-plugin [source] (bionic-proposed) [0.4.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (bionic-proposed) [3.28.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-desktop3 [source] (bionic-proposed) [3.28.1-1ubuntu1]
<sil2100> jbicha: is there an UIFe for gnome-initial-setup then? Is the translations/docs team aware?
<jbicha> so, um gnome-initial-setup isn't in main yet
<sil2100> jbicha: oh, indeed, I guess in my mind I just put them in the same bucket
<jbicha> sil2100: you sort of did grant a UIFe at LP: #1755456
<ubot5`> Launchpad bug 1755456 in ubuntu-release-upgrader (Ubuntu) "[ffe] Optional recording/sending of installer&system details to help improving Ubuntu" [Undecided,Triaged] https://launchpad.net/bugs/1755456
-queuebot:#ubuntu-release- Unapproved: accepted gnome-initial-setup [source] (bionic-proposed) [3.28.0-2ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-system-monitor [sync] (bionic-proposed) [3.28.1-1]
<jbicha> unfortunately, we're not quite down with the UI tweaks, for instance there's LP: #1763164 and we may still add more graphics
<ubot5`> Launchpad bug 1763164 in gnome-initial-setup (Ubuntu) "Typos in translatable strings of GNOME Initial Setup" [High,Confirmed] https://launchpad.net/bugs/1763164
<sil2100> jbicha: ah, yeah, I actually only granted the FFe for the other parts, it was La_ney that did it for gnome-initial-setup
<sil2100> Anyway, all clear, it's easier to poke the uploader for this info than digging through LP projects with various bug task states
<sil2100> This is why I poked you
<sil2100> Thanks!
<coreycb> sil2100: it looks like the 2 bugs are verified for neutron in artful-proposed unless i'm missing something
<coreycb> sil2100: yes would like to get those moving along though!
<jbicha> sorry about gnome-initial-setup being late in stablizing. Hopefully we'll finalize things for 18.04.0 really soon
<doko> Laney: are the autopkg tester overcomitted? looking at the python-attrs failures, it looks like some timeout
<Laney> doko: not from our side at least, and looks like it got worse with -2?
<sil2100> coreycb: those two aren't: https://bugs.launchpad.net/cloud-archive/+bug/1757433 https://bugs.launchpad.net/cloud-archive/+bug/1754015
<ubot5`> Ubuntu bug 1757433 in mistral (Ubuntu Artful) "[SRU] mistral-event-engine conflicts mistral-event" [High,Fix committed]
<ubot5`> Ubuntu bug 1754015 in libvirt (Ubuntu Artful) "[SRU] nova-compute-kvm does not pull ipxe-qemu on non-amd64 archs" [Undecided,Confirmed]
<sil2100> coreycb: and since we release all those packages together in a batch, they're blocking the whole stack - at least I think the general idea was to release all of them at once
<doko> yes, started with -2
<coreycb> sil2100: got it, thanks. will work on untangling that and get back to you.
<sil2100> coreycb: thanks!
-queuebot:#ubuntu-release- Unapproved: dhelp (bionic-proposed/universe) [0.6.24 => 0.6.24-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted dhelp [source] (bionic-proposed) [0.6.24-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: resolvconf (bionic-proposed/universe) [1.79ubuntu9 => 1.79ubuntu10] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted resolvconf [source] (bionic-proposed) [1.79ubuntu10]
-queuebot:#ubuntu-release- Unapproved: ukui-control-center (bionic-proposed/universe) [1.1.1-0ubuntu1 => 1.1.2-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: gnome-todo (bionic-proposed/main) [3.28.0-1 => 3.28.1-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: babl (bionic-proposed/universe) [0.1.44-1 => 0.1.46-1] (edubuntu, ubuntugnome, ubuntustudio) (sync)
<coreycb> sil2100: this one can be rejected please: bug 1760918
<ubot5`> bug 1760918 in python-oslo.versionedobjects (Ubuntu Artful) "[SRU] Fixing UUID coerce function for unicode non uuid form" [High,Triaged] https://launchpad.net/bugs/1760918
<sil2100> coreycb: ACK
-queuebot:#ubuntu-release- Unapproved: mailman-suite (bionic-proposed/universe) [0+20170523-13 => 0+20170523-14] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mailman-suite [sync] (bionic-proposed) [0+20170523-14]
-queuebot:#ubuntu-release- Unapproved: rejected python-oslo.versionedobjects [source] (artful-proposed) [1.26.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: rejected python-oslo.versionedobjects [source] (xenial-proposed) [1.8.0-1ubuntu1]
<xnox> slangasek, with new dogtag-pki freeipa tests get to go on further and then break with SASL
<xnox> ACIError: Insufficient access: SASL(-4): no mechanism available: No worthy mechs found (Unknown authentication method)
<xnox> any ideas? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/s390x/f/freeipa/20180412_123337_5f432@/log.gz
<xnox> missing runtime deps on sasl things? openssl 1.1.0 fallout?
-queuebot:#ubuntu-release- Unapproved: ubuntu-wallpapers (bionic-proposed/main) [18.04.0-0ubuntu1 => 18.04.1-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (bionic-proposed/multiverse) [5.2.8-dfsg-5ubuntu18.04.1 => 5.2.8-dfsg-7ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-hwe [source] (bionic-proposed) [5.2.8-dfsg-7ubuntu18.04.1]
<jbicha> do I need a FFe if I want to drop an unused python2 library like python-software-properties?
-queuebot:#ubuntu-release- Unapproved: python-tinyrpc (bionic-proposed/main) [0.5-0ubuntu1 => 0.6-1] (ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu7 => 237-3ubuntu8] (core)
-queuebot:#ubuntu-release- Unapproved: mythtv (bionic-proposed/multiverse) [2:29.1+fixes.20180220.9b7b962-0ubuntu3 => 2:29.1+fixes.20180412.329c235-0ubuntu1] (mythbuntu)
-queuebot:#ubuntu-release- Unapproved: mongodb (bionic-proposed/universe) [1:3.4.14-3ubuntu2 => 1:3.6.3-0ubuntu1] (mozilla)
-queuebot:#ubuntu-release- Unapproved: mongo-tools (bionic-proposed/universe) [3.4.14-2 => 3.6.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (bionic-proposed/main) [1:0.5 => 1:0.5.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted mongo-tools [source] (bionic-proposed) [3.6.3-0ubuntu1]
<jbicha> I suggest rejecting mythtv since it accidentally drops the python-imaging > python-pil recommends change
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-390 (bionic-proposed/restricted) [390.48-0ubuntu1 => 390.48-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: software-properties (bionic-proposed/main) [0.96.24.28 => 0.96.24.29] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: runc (bionic-proposed/universe) [1.0.0~rc4+dfsg1-5 => 1.0.0~rc4+dfsg1-6] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: s3cmd (bionic-proposed/universe) [2.0.1-1 => 2.0.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted runc [sync] (bionic-proposed) [1.0.0~rc4+dfsg1-6]
-queuebot:#ubuntu-release- Unapproved: accepted s3cmd [source] (bionic-proposed) [2.0.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: r-bioc-biocgenerics (bionic-proposed/universe) [0.24.0-1ubuntu1 => 0.24.0-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted r-bioc-biocgenerics [source] (bionic-proposed) [0.24.0-1ubuntu2]
<jbicha> man, Fedora is really copying our schedule
<jbicha> they did a Beta the same week as us, their Final Freeze is the same week, and their scheduled release is within days of ours
<jbicha> https://fedoraproject.org/wiki/Releases/28/Schedule
<tsimonq2> hehe
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-120.144~14.04.1] (kernel)
-queuebot:#ubuntu-release- Unapproved: simplestreams (bionic-proposed/main) [0.1.0~bzr459-0ubuntu1 => 0.1.0~bzr460-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-120.144~14.04.1]
<Bashing-om> Immitation the best form of flattery ?
<ErichEickmeyer> infinity, slangasek: The response has been overall in favor of Ubuntu Studio not being LTS this time around. Unfortunate, but until we can drum-up the manpower, that's kindof where we're at. :/
<infinity> ErichEickmeyer: Unfortunate indeed, but understood.  Will adjust as appropriate.
-queuebot:#ubuntu-release- Unapproved: virtualbox (bionic-proposed/multiverse) [5.2.8-dfsg-6 => 5.2.8-dfsg-7] (ubuntu-cloud) (sync)
-queuebot:#ubuntu-release- Unapproved: epiphany-browser (bionic-proposed/universe) [3.28.0.1-1ubuntu1 => 3.28.1-1ubuntu1] (desktop-extra)
-queuebot:#ubuntu-release- Unapproved: cinnamon-control-center (bionic-proposed/universe) [3.6.5-1 => 3.6.5-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gjs (bionic-proposed/main) [1.52.0-1 => 1.52.1-1] (desktop-extra, mozilla, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted cinnamon-control-center [sync] (bionic-proposed) [3.6.5-2]
-queuebot:#ubuntu-release- Unapproved: deepin-image-viewer (bionic-proposed/universe) [1.2.18-1 => 1.2.19-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted deepin-image-viewer [sync] (bionic-proposed) [1.2.19-1]
-queuebot:#ubuntu-release- Unapproved: evolution (bionic-proposed/universe) [3.28.1-1 => 3.28.1-2] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-system-monitor (bionic-proposed/universe) [33-2 => 35-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-system-monitor [sync] (bionic-proposed) [35-1]
-queuebot:#ubuntu-release- Unapproved: freeipa (bionic-proposed/universe) [4.6.3-1ubuntu1 => 4.7.0~pre1+git20180411-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted freeipa [sync] (bionic-proposed) [4.7.0~pre1+git20180411-1]
-queuebot:#ubuntu-release- Unapproved: update-manager (bionic-proposed/main) [1:18.04.10 => 1:18.04.11] (core)
-queuebot:#ubuntu-release- Unapproved: nghttp2 (bionic-proposed/main) [1.30.0-1 => 1.30.0-1ubuntu1] (core)
<acheronuk> slangasek infinity et al. could someone perhaps take a look at? LP: #1763448
<ubot5`> Launchpad bug 1763448 in libindi (Ubuntu Bionic) "[FFe] Kstars 2.9.4 with libindi 1.7.1 for Bionic" [Undecided,New] https://launchpad.net/bugs/1763448
<slangasek> acheronuk: fwiw queues will generally take priority over bugs at this point in the cycle; if it's not an FFe that you think you need feedback on, I recommend just uploading to the queue
<acheronuk> slangasek: fair enough. will do. thanks.
-queuebot:#ubuntu-release- Unapproved: libindi (bionic-proposed/universe) [1.4.1+dfsg-3ubuntu1 => 1.7.1-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kstars (bionic-proposed/universe) [5:2.9.3-0ubuntu2 => 5:2.9.4-1ubuntu1] (kubuntu)
<tjaalton> please accept bind9 point-release update/merge, freeipa needs it
<tjaalton> fixes a crash on named startup
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (bionic-proposed/main) [1:18.04.15 => 1:18.04.16] (core)
<slangasek> tjaalton: yeesh, massive delta; can you tell me more about this update?  bugfix-only, how well tested, etc?
<slangasek> + -- Ubuntu Merge-o-Matic <mom@ubuntu.com>  Fri, 23 Mar 2018 15:53:22 +0000
<slangasek> pretty sure that's not who did this upload
<tsimonq2> Somebody used grab-merge and went too fast. :P
-queuebot:#ubuntu-release- Unapproved: rejected bind9 [source] (bionic-proposed) [1:9.11.3+dfsg-1ubuntu1]
<jbicha> btw, there's a dad too now https://salsa.debian.org/debian/libnfs/commit/b30aa05b
<tsimonq2> HAH.
<tsimonq2> I like it.
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (bionic-proposed/universe) [20180129+dfsg1-0ubuntu2 => 20180129+dfsg1-0ubuntu3] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (bionic-proposed) [20180129+dfsg1-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (bionic-proposed) [237-3ubuntu8]
-queuebot:#ubuntu-release- Unapproved: appstream (bionic-proposed/main) [0.11.8-3 => 0.12.0-3] (desktop-core) (sync)
<jbicha> ffe for appstream is bug 1762292
<ubot5`> bug 1762292 in appstream (Ubuntu) "FFE: Sync appstream 0.12.0-3 (main) from Debian unstable (main)" [Undecided,Triaged] https://launchpad.net/bugs/1762292
-queuebot:#ubuntu-release- Unapproved: nautilus (bionic-proposed/main) [1:3.26.3-0ubuntu1 => 1:3.26.3-0ubuntu2] (ubuntu-desktop)
#ubuntu-release 2018-04-13
-queuebot:#ubuntu-release- Unapproved: cloud-init (bionic-proposed/main) [18.2-4-g05926e48-0ubuntu2 => 18.2-9-g49b562c9-0ubuntu1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- New source: kylin-video (bionic-proposed/primary) [1.1.6-0ubuntu1]
<tjaalton> slangasek: haha, missed that..
-queuebot:#ubuntu-release- Unapproved: lubuntu-meta (bionic-proposed/universe) [0.93 => 0.94] (lubuntu)
<tsimonq2> slangasek: Can I get lubuntu-meta through fairly quickly please?
<slangasek> tsimonq2: queue-jumper
-queuebot:#ubuntu-release- Unapproved: freetype (bionic-proposed/main) [2.8.1-2ubuntu1 => 2.8.1-2ubuntu2] (core)
<tsimonq2> slangasek: Â¿QuÃ©?
<tsimonq2> :)
<slangasek> tsimonq2: done, even though there are 26 other packages ahead of you in the queue ;)
<tsimonq2> slangasek: Ah.
-queuebot:#ubuntu-release- Unapproved: accepted lubuntu-meta [source] (bionic-proposed) [0.94]
<tsimonq2> Thanks. :)
-queuebot:#ubuntu-release- Unapproved: accepted freetype [source] (bionic-proposed) [2.8.1-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: cloud-utils (bionic-proposed/main) [0.30-0ubuntu3 => 0.30-0ubuntu4] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: harfbuzz (bionic-proposed/main) [1.7.2-1 => 1.7.2-1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted harfbuzz [source] (bionic-proposed) [1.7.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: bind9 (bionic-proposed/main) [1:9.11.2.P1-1ubuntu5 => 1:9.11.3+dfsg-1ubuntu1] (core)
<lotuspsychje> morning guys, where to start for packaging, creating .deb and propose to the repos?
-queuebot:#ubuntu-release- Unapproved: openfoam (bionic-proposed/universe) [4.1+dfsg1-1ubuntu1 => 4.1+dfsg1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted openfoam [sync] (bionic-proposed) [4.1+dfsg1-2]
-queuebot:#ubuntu-release- Unapproved: s3cmd (bionic-proposed/universe) [2.0.1-1ubuntu1 => 2.0.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted s3cmd [sync] (bionic-proposed) [2.0.1-2]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-wallpapers [source] (bionic-proposed) [18.04.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mongodb [source] (bionic-proposed) [1:3.6.3-0ubuntu1]
<slangasek> jbicha: software-properties> build system changes are risky; have you diffed the resulting binary packages?
<slangasek>   * Fix FTBFS caused by nodejs setting O_NONBLOCK on the build log pipe.
<slangasek> bwahaha
-queuebot:#ubuntu-release- Unapproved: accepted ffmpeg [sync] (bionic-proposed) [7:3.4.2-2]
-queuebot:#ubuntu-release- Unapproved: rejected ethtool [sync] (bionic-proposed) [1:4.15-1]
<acheronuk> lotuspsychje: http://packaging.ubuntu.com/html/
<lotuspsychje> tnx acheronuk
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-input-libinput [sync] (bionic-proposed) [0.27.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted ukui-control-center [source] (bionic-proposed) [1.1.2-0ubuntu1]
<LocutusOfBorg> please accept virtualbox from unapproved!
<sil2100> Uh oh, give me 5-10 minutes and I'll take care of the bionic queue
<LocutusOfBorg> thanks! I'm happy that we fixed a long stading issue with the guest kernel modules
-queuebot:#ubuntu-release- Unapproved: gnome-contacts (bionic-proposed/universe) [3.28.0-1ubuntu1 => 3.28.1-0ubuntu1] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-todo [sync] (bionic-proposed) [3.28.1-1]
<sil2100> I hate reviewing synces
<sil2100> jbicha: the sync of new babl, is that a bugfix-only release?
<sil2100> jbicha: I have issues finding the changes file for that version, and in overall I seem to have problem accessing their git repo to check
-queuebot:#ubuntu-release- Unapproved: accepted mythtv [source] (bionic-proposed) [2:29.1+fixes.20180412.329c235-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-390 [source] (bionic-proposed) [390.48-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-drivers-common [source] (bionic-proposed) [1:0.5.1]
<sil2100> jbicha: the package is seeded in ubuntustudio, so I'd like to know if it's not breaking FF
-queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (bionic-proposed) [0.96.24.29]
-queuebot:#ubuntu-release- Unapproved: accepted simplestreams [source] (bionic-proposed) [0.1.0~bzr460-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox [sync] (bionic-proposed) [5.2.8-dfsg-7]
-queuebot:#ubuntu-release- Unapproved: gnome-settings-daemon (bionic-proposed/main) [3.28.0-0ubuntu2 => 3.28.1-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted epiphany-browser [source] (bionic-proposed) [3.28.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted nghttp2 [source] (bionic-proposed) [1.30.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (bionic-proposed) [1:18.04.11]
-queuebot:#ubuntu-release- Unapproved: accepted kstars [source] (bionic-proposed) [5:2.9.4-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libindi [source] (bionic-proposed) [1.7.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (bionic-proposed) [1:18.04.16]
-queuebot:#ubuntu-release- Unapproved: accepted appstream [sync] (bionic-proposed) [0.12.0-3]
-queuebot:#ubuntu-release- Unapproved: accepted nautilus [source] (bionic-proposed) [1:3.26.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-utils [source] (bionic-proposed) [0.30-0ubuntu4]
-queuebot:#ubuntu-release- New binary: appstream [amd64] (bionic-proposed/main) [0.12.0-3] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-contacts [source] (bionic-proposed) [3.28.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-settings-daemon [source] (bionic-proposed) [3.28.1-0ubuntu1]
<jbicha> sil2100: the upstream repo is https://git.gnome.org/browse/babl/tree/
 * sil2100 has issues reaching gnome.org
<sil2100> None of their pages load for me, guess I'll have to investigate why one of these days
<Laney> why not just download the package and diff it?
<sil2100> I did that, I wanted to see if they have changelogs attached to their tags
<sil2100> Since the diff is quite big
<Mirv> sil2100: short answer, no they don't seem to have (checked 0.1.42, 0.1.44, 0.1.46)
<sil2100> In the meantime I found their NEWS file in the source
<Mirv> they just update NEWS when releasing
<jbicha> sil2100: ok you could try Salsa instead https://salsa.debian.org/gnome-team/babl/tree/upstream/latest
<Mirv> yes, that :)
<jbicha> https://salsa.debian.org/gnome-team/babl/commits/upstream/latest
<Mirv> sil2100: here's git checkout as a tarball if you need to check the logs http://people.ubuntu.com/~timo-jyrinki/babl-git.tar.xz
<sil2100> Mirv: thanks, but the debdiff is enough
<sil2100> Still, it's hard to assess if this breaks FF or not
<sil2100> With new extensions added and one getting renamed
<jbicha> sil2100: I won't be too offended if you reject it. I only synced it because maybe it's one less package to backport if someone wanted to play with gimp 2.10
<jbicha> that's not really a strong reason since gimp will also want new gegl and babl releases
<jbicha> *gimp will always want
<sil2100> jbicha: well, I don't say no, but to me it looks like it might need an FFe before we proceed as I personally consider those changes feature-affecting - I'll reject it for now
<jbicha> sil2100: thanks for reviewing
<tjaalton> xserver-xorg-input-libinput sync should fix bug 1758306
<ubot5`> bug 1758306 in xserver-xorg-input-libinput (Ubuntu) "Cannot switch mouse primary button to Right (left-handed) in Settings" [Undecided,Confirmed] https://launchpad.net/bugs/1758306
-queuebot:#ubuntu-release- Unapproved: rejected babl [sync] (bionic-proposed) [0.1.46-1]
<jbicha> sil2100: btw evolution is actually a useful bug fix for people that use evolution, thanks
<jbicha> https://salsa.debian.org/gnome-team/evolution/commit/7bf76fbd is the only change
<sil2100> Ah, missed that one
-queuebot:#ubuntu-release- Unapproved: accepted evolution [sync] (bionic-proposed) [3.28.1-2]
<jbicha> thanks again :)
<sil2100> yw!
<LocutusOfBorg> thanks sil2100
<juliank> sil2100: ganeti on i386 is still blocking several things in proposed; lvm2, pyopenssl, sphinx, socat - it loves to fail with struct.pack('hhllhh', fcntl.F_WRLCK, 0, 0, 0, 0, 0))
<juliank> that happened before, so it's not a regression; but it worked about 4 times
<juliank> so I'm not sure if it should be force-badtest or not
<juliank> (sphinx also has other regressions, but the rest is solely blocked on that)
-queuebot:#ubuntu-release- Unapproved: rustc (bionic-proposed/universe) [1.24.1+dfsg1+llvm-0ubuntu1 => 1.24.1+dfsg1+llvm-0ubuntu2] (no packageset)
<chrisccoulson> ^can someone reject that please - I might not actually need it
-queuebot:#ubuntu-release- Unapproved: accepted rustc [source] (bionic-proposed) [1.24.1+dfsg1+llvm-0ubuntu2]
<Laney> it was auto accepted :(
<chrisccoulson> heh, never mind
<Laney> Someone could delete it from -proposed if you wanted
<chrisccoulson> It doesn't matter too much. I realized just after I uploaded it that the fix for another issue I'm looking at will also resolve this one too
<chrisccoulson> but it's not going to do any harm
-queuebot:#ubuntu-release- Unapproved: software-properties (bionic-proposed/main) [0.96.24.29 => 0.96.24.30] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: deal.ii (bionic-proposed/universe) [8.5.1-1 => 8.5.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted deal.ii [source] (bionic-proposed) [8.5.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: software-properties (bionic-proposed/main) [0.96.24.29 => 0.96.24.31] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-utils (bionic-proposed/main) [0.30-0ubuntu4 => 0.30-0ubuntu5] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: command-not-found (bionic-proposed/main) [18.04.1 => 18.04.2] (core)
-queuebot:#ubuntu-release- Unapproved: kpatch (bionic-proposed/universe) [0.3.2-3ubuntu1 => 0.5.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted kpatch [source] (bionic-proposed) [0.5.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (xenial-proposed/universe) [4.13.0-1024.27] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (xenial-proposed) [4.13.0-1024.27]
-queuebot:#ubuntu-release- Unapproved: xorg-server (bionic-proposed/main) [2:1.19.6-1ubuntu3 => 2:1.19.6-1ubuntu4] (desktop-core, xorg)
-queuebot:#ubuntu-release- Unapproved: golang-github-juju-testing (bionic-proposed/universe) [0.0~git20170608.2fe0e88-3 => 0.0~git20170608.2fe0e88-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted golang-github-juju-testing [source] (bionic-proposed) [0.0~git20170608.2fe0e88-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libunwind (bionic-proposed/main) [1.2.1-6 => 1.2.1-8] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (bionic-proposed/multiverse) [5.2.8-dfsg-7ubuntu18.04.1 => 5.2.8-dfsg-8ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-hwe [source] (bionic-proposed) [5.2.8-dfsg-8ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: tryton-server (bionic-proposed/universe) [4.6.2-1 => 4.6.3-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted tryton-server [sync] (bionic-proposed) [4.6.3-2]
<flocculant> infinity: seems that iso's are booting straight to desktop without stopping at the Try/Install dialogue - checked us, Mate and Budgie all have iso's built either 12th or 13th - all go straight to desktop, Ubuntu still has build from 9th, there was a change to ubiquity on the 10th
<flocculant> bug 1763739
<ubot5`> bug 1763739 in ubiquity (Ubuntu) "ISO boots directly to desktop" [Undecided,New] https://launchpad.net/bugs/1763739
<slangasek> flocculant: which version of ubiquity do you have in those images?
<slangasek> https://code.launchpad.net/~vorlon/ubiquity/conflict-with-getty1 was merged but has not been uploaded yet
<cyphermox> working on it!
<slangasek> ok
<flocculant> slangasek: 18.04.5 in Xubuntu, Budgie and Mate
<cyphermox> is the privileges branch ready too?
<slangasek> cyphermox: no, so please don't block on it
<cyphermox> ok
-queuebot:#ubuntu-release- Unapproved: gedit (bionic-proposed/main) [3.28.0-1ubuntu1 => 3.28.1-1ubuntu1] (ubuntu-desktop)
<flocculant> slangasek: I take it from ^^ that you're aware then?
<slangasek> flocculant: well, I wrote the fix for the bug
<flocculant> yea - what I meant
<slangasek> but I'm not a committer on the ubiquity repo (which is broken, all core-devs should be), so I didn't upload it
<flocculant> slangasek: is there an existing bug? if so I'll dupe my one to it when LP stops timing out
<slangasek> flocculant: no, didn't open a bug
<flocculant> oh right - ok
 * flocculant toddles off again 
-queuebot:#ubuntu-release- Unapproved: adwaita-icon-theme (bionic-proposed/main) [3.27.90-1ubuntu1 => 3.28.0-1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-settings (bionic-proposed/main) [18.04.2 => 18.04.3] (ubuntu-desktop)
<ginggs> slangasek: please ping me if you have a chance to discuss options for python-xarray autopkgtest failures
-queuebot:#ubuntu-release- Unapproved: gnome-calendar (bionic-proposed/main) [3.28.0-1 => 3.28.1-1ubuntu1] (desktop-extra, ubuntu-desktop)
<tsimonq2> infinity, slangasek: Bump re: Ubiquity permissions bug.
-queuebot:#ubuntu-release- Unapproved: apport (bionic-proposed/main) [2.20.9-0ubuntu4 => 2.20.9-0ubuntu5] (core)
-queuebot:#ubuntu-release- Unapproved: gnome-online-accounts (bionic-proposed/main) [3.27.92-1ubuntu3 => 3.28.0-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gsettings-desktop-schemas (bionic-proposed/main) [3.27.90-1ubuntu1 => 3.28.0-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-keyring (bionic-proposed/main) [3.28.0.1-1ubuntu1 => 3.28.0.2-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: nautilus (bionic-proposed/main) [1:3.26.3-0ubuntu2 => 1:3.26.3-0ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: cargo (bionic-proposed/universe) [0.25.0-1ubuntu1 => 0.26.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cargo [source] (bionic-proposed) [0.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: yelp (bionic-proposed/main) [3.26.0-1ubuntu1 => 3.26.0-1ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: debian-installer (bionic-proposed/main) [20101020ubuntu535 => 20101020ubuntu536] (core)
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (bionic-proposed) [20101020ubuntu536]
-queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (bionic-proposed) [0.96.24.30]
-queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (bionic-proposed) [0.96.24.31]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-utils [source] (bionic-proposed) [0.30-0ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted command-not-found [source] (bionic-proposed) [18.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted xorg-server [source] (bionic-proposed) [2:1.19.6-1ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted nautilus [source] (bionic-proposed) [1:3.26.3-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted yelp [source] (bionic-proposed) [3.26.0-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (bionic-proposed) [18.2-9-g49b562c9-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-settings [source] (bionic-proposed) [18.04.3]
-queuebot:#ubuntu-release- Unapproved: accepted gjs [sync] (bionic-proposed) [1.52.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted python-tinyrpc [sync] (bionic-proposed) [0.6-1]
-queuebot:#ubuntu-release- Unapproved: accepted libunwind [sync] (bionic-proposed) [1.2.1-8]
-queuebot:#ubuntu-release- Unapproved: accepted adwaita-icon-theme [source] (bionic-proposed) [3.28.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-calendar [source] (bionic-proposed) [3.28.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-online-accounts [source] (bionic-proposed) [3.28.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gedit [source] (bionic-proposed) [3.28.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gsettings-desktop-schemas [source] (bionic-proposed) [3.28.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-keyring [source] (bionic-proposed) [3.28.0.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (bionic-proposed) [2.20.9-0ubuntu5]
<infinity> slangasek: Do you have opinions on the bind9 in the queue?  I'm inclined to let it happen, but it will cause us to headless chicken a small SOVER transition for the libs.
<infinity> tjaalton: Have you tested isc-dhcp against the new bind9?
<slangasek> infinity: when I rejected the previous upload I had opinions.  I don't know how much the new version has changed from the previous
<slangasek> does it link to any bugs with an FFe rationale?
<infinity> https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1763572
<ubot5`> Ubuntu bug 1763572 in bind9 (Ubuntu) "FFE: (mostly) bugfix release 9.11.3" [Undecided,New]
<slangasek> k
<slangasek> I don't think this is the most efficient way to get tjaalton what he wants wrt freeipa.  Surely a cherry-pick for his crash is a better use of everyone's time
<infinity> Possibly, though some of the upstream changes are also securityish bugfixes.
<infinity> Of the sort that probably don't warrant a CVE but are likely still worth having.
<infinity> On the other hand, giant unreviewable delta, so have to rely on rdep builds and tests and some thoughts and prayers.
<infinity> It's been in testing for 2 weeks, and I don't see any new bugs there.
<infinity> That's something, at least.
<infinity> slangasek: So, from an FFe perspective, the feature changes all seem reasonable, and the rest of the delta is bugfixes.  I have no issues with it from a (feature) freeze perspective, just the concern of reviewability/testability in a short timeframe.
<slangasek> infinity: alright, in any case that's the extent of my opinion.  I'm not reviewing that delta, because by the time I got halfway through the review to the point of being willing to accept it myself, I'd have the cherry-pick done
<infinity> Fair.
<infinity> It does help the security team not have to cherry-pick another 6 CVE fixes too. :P
<infinity> I'll waffle on it for a bit and peruse the delta.  But I think I'm going to allow it and reserve the right to yell at Timo if it goes sideways.
<infinity> Also, libdns169 -> libdns1100
<infinity> Counting is hard.
<jbicha> 1100 sounds like a much better number to me
<infinity> jbicha: Bigger DNS is better DNS?
<tsimonq2> All The DNS.
<jbicha> I am disappointed that they still have 160 and 169 numbers
<slangasek> hey accidentally switched the base at the same time they incremented
<slangasek> +t
<infinity> That's not actually implausible.
<slangasek> from base 9 to base 3
<infinity> That's slightly less plausible.
<slangasek> (not actually - but I got tired of a brute-force search for bases that would make those numbers work ;)
<slangasek> ginggs: I think I can spare some attention for python-xarrays without screaming in horror ;)
<slangasek> LocutusOfBorg: with node-rollup-plugin-commonjs gone from -proposed, do you think you'll try to tackle the rollup bootstrap again before GA?
<ginggs> slangasek: nvm, I convinced tumbleweed to have a look - he was sunning his buns at minidebconf
<slangasek> hah ok
-queuebot:#ubuntu-release- Unapproved: autofs (bionic-proposed/main) [5.1.2-1ubuntu2 => 5.1.2-1ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: ubiquity (bionic-proposed/main) [18.04.5 => 18.04.6] (core)
-queuebot:#ubuntu-release- Unapproved: gvfs (bionic-proposed/main) [1.36.0-1ubuntu1 => 1.36.1-0ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: ubiquity (bionic-proposed/main) [18.04.5 => 18.04.6] (core)
<LocutusOfBorg> slangasek, honestly, I don't want in -release something that fails to work after a no-change rebuild
<LocutusOfBorg> :/
<LocutusOfBorg> unless upstream fixes it
<tjaalton> infinity: heh, well 9.12 packaging will drop that madness, and bundle everything in bind-libs
<infinity> tjaalton: But the libraries rev SOVER independently and have external rdeps.  That's entirely the wrong direction for the packaging to go.
<infinity> They were broken out for valid reasons...
-queuebot:#ubuntu-release- Unapproved: autopkgtest (bionic-proposed/main) [5.1 => 5.3] (core) (sync)
<tjaalton> maybe talk to ondrej then
<tjaalton> https://salsa.debian.org/dns-team/bind
-queuebot:#ubuntu-release- New binary: python-tinyrpc [amd64] (bionic-proposed/main) [0.6-1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: gsequencer (bionic-proposed/universe) [1.4.24-1 => 1.4.24-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gsequencer [source] (bionic-proposed) [1.4.24-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: glade (bionic-proposed/universe) [3.22.0-1 => 3.22.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted glade [sync] (bionic-proposed) [3.22.1-1]
-queuebot:#ubuntu-release- Unapproved: libwx-perl (bionic-proposed/universe) [1:0.9932-3 => 1:0.9932-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libwx-perl [sync] (bionic-proposed) [1:0.9932-4]
<ahasenack> if anybody has questions about the autofs upload, I'm here for about 1h still today
<nacc> ahasenack: i think it'll go through ok -- do you have any idea about how to fix the old bug properly?
<ahasenack> nacc: medium term it's to update libtirpc to a current version
<ahasenack> 1.0.3 works
<nacc> ahasenack: so in 18.10?
<ahasenack> 1.0.2 probably works too (it didn't build in bionic, gcc7 madness)
<ahasenack> I went over git log, bugzillas all over the place, and didn't find something that could be related
<ahasenack> also looked at the actual diff between ours and 1.0.3, nothing jumped out as the fix
<ahasenack> all I know is that for some reason, two function pointers that should be pointing at auth functions were intialized with 0x0
<ahasenack> nacc: 18.10 sure, it will need a transition, since some packages are linked against .so.1
<ahasenack> and new one is .so.3
<ahasenack> debian even created a new source package for it, in experimental (libtirpc3)
<ahasenack> it's a package that just lagged behind for some reason
<ahasenack> ours is 4yo :/
<ahasenack> https://sourceforge.net/p/libtirpc/activity/?page=0&limit=100 <-- releases
<nacc> ahasenack: sure
<nacc> ahasenack: just wondered
<ahasenack> someone with more experience with rpc and xdr and all that low level stuff could perhaps come up with a patch
<ahasenack> since our package is so old, I didn't bother contacting upstream
<slangasek> "someone with more experience with rpc and xdr" get behind me, satan
<ahasenack> :)
<nacc> lol
<ahasenack> biseting is still an option, since it's all in git and we have a simple test case
<ahasenack> but this was getting a rabbit hole and I wanted to avoid shipping a crashing service quickly
-queuebot:#ubuntu-release- Unapproved: makedumpfile (artful-proposed/main) [1:1.6.1-2ubuntu0.1 => 1:1.6.1-2ubuntu0.2] (core)
-queuebot:#ubuntu-release- Unapproved: makedumpfile (xenial-proposed/main) [1:1.5.9-5ubuntu0.6 => 1:1.5.9-5ubuntu0.7] (core)
-queuebot:#ubuntu-release- Unapproved: kexec-tools (xenial-proposed/main) [1:2.0.10-1ubuntu2.4 => 1:2.0.10-1ubuntu2.5] (core)
#ubuntu-release 2018-04-14
-queuebot:#ubuntu-release- Unapproved: poppler (bionic-proposed/main) [0.62.0-2ubuntu1 => 0.62.0-2ubuntu2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: libopenmpt (bionic-proposed/universe) [0.3.6-1 => 0.3.8-1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: mbedtls (bionic-proposed/universe) [2.7.0-2 => 2.8.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mbedtls [sync] (bionic-proposed) [2.8.0-1]
-queuebot:#ubuntu-release- Unapproved: pcs (bionic-proposed/universe) [0.9.162-1 => 0.9.164-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pcs [sync] (bionic-proposed) [0.9.164-1]
-queuebot:#ubuntu-release- Unapproved: r-cran-readxl (bionic-proposed/universe) [1.0.0-1build1 => 1.0.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-readxl [sync] (bionic-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- Unapproved: pycryptodome (bionic-proposed/main) [3.4.7-1ubuntu1 => 3.4.11-1] (ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: r-base (bionic-proposed/universe) [3.4.3-1build1 => 3.4.4-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted r-base [sync] (bionic-proposed) [3.4.4-1]
-queuebot:#ubuntu-release- Unapproved: r-cran-cardata (bionic-proposed/universe) [3.0.0-1 => 3.0.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-cardata [sync] (bionic-proposed) [3.0.1-1]
-queuebot:#ubuntu-release- Unapproved: atf-allwinner (bionic-proposed/universe) [1.0.apritzel.81-1ubuntu1 => 1.0.aw-6-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted atf-allwinner [sync] (bionic-proposed) [1.0.aw-6-1]
-queuebot:#ubuntu-release- Unapproved: a7xpg (bionic-proposed/universe) [0.11.dfsg1-9ubuntu1 => 0.11.dfsg1-9.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ariba (bionic-proposed/universe) [2.11.1+ds-2ubuntu1 => 2.11.1+ds-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted a7xpg [sync] (bionic-proposed) [0.11.dfsg1-9.1]
-queuebot:#ubuntu-release- Unapproved: accepted ariba [sync] (bionic-proposed) [2.11.1+ds-3]
-queuebot:#ubuntu-release- Unapproved: gcc-8 (bionic-proposed/main) [8-20180408-0ubuntu1 => 8-20180414-1ubuntu1] (core)
-queuebot:#ubuntu-release- New: accepted appstream [amd64] (bionic-proposed) [0.12.0-3]
-queuebot:#ubuntu-release- New: accepted python-tinyrpc [amd64] (bionic-proposed) [0.6-1]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-8 [source] (bionic-proposed) [8-20180414-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: mythtv (bionic-proposed/multiverse) [2:29.1+fixes.20180412.329c235-0ubuntu1 => 2:29.1+fixes.20180413.329c235-0ubuntu2] (mythbuntu)
-queuebot:#ubuntu-release- Unapproved: ucspi-unix (bionic-proposed/universe) [0.36-4 => 1.0-0.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (bionic-proposed/multiverse) [5.2.8-dfsg-8ubuntu18.04.1 => 5.2.8-dfsg-9ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ucspi-unix [sync] (bionic-proposed) [1.0-0.1]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-hwe [source] (bionic-proposed) [5.2.8-dfsg-9ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: mate-applets (bionic-proposed/universe) [1.20.1-0ubuntu1 => 1.20.1-2ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: xubuntu-artwork (bionic-proposed/universe) [18.04.4 => 18.04.5] (xubuntu)
-queuebot:#ubuntu-release- New sync: vtk7 (bionic-proposed/primary) [7.1.1+dfsg1-2]
<LocutusOfBorg> vtk7 is a leaf package, I don't want to do any kind of transition, but I think we should at least provide it for developers in the LTS context ^^
-queuebot:#ubuntu-release- Unapproved: xfce4-notifyd (bionic-proposed/universe) [0.4.2-0ubuntu1 => 0.4.2-0ubuntu2] (xubuntu)
-queuebot:#ubuntu-release- Unapproved: qtvirtualkeyboard-opensource-src (bionic-proposed/universe) [5.9.4+dfsg-0ubuntu2 => 5.9.4+dfsg-0ubuntu3] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: gsequencer (bionic-proposed/universe) [1.4.24-1ubuntu1 => 1.4.24-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gsequencer [source] (bionic-proposed) [1.4.24-1ubuntu2]
<tsimonq2> Can I get my email to ubuntu-release let through please?
 * cjwatson runs listadmin
<cjwatson> done
<tsimonq2> Thank you.
-queuebot:#ubuntu-release- Unapproved: konsole (bionic-proposed/universe) [4:17.12.3-0ubuntu1 => 4:17.12.3-1ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: eog (bionic-proposed/main) [3.28.0-2 => 3.28.1-1] (ubuntu-desktop) (sync)
<tsimonq2> Final Freeze is next *Thursday*, not Monday, right?
-queuebot:#ubuntu-release- Unapproved: kubuntu-meta (bionic-proposed/universe) [1.369 => 1.370] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ubuntu-docs (bionic-proposed/main) [18.04.2 => 18.04.3] (personal-gunnarhj, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: language-selector (bionic-proposed/main) [0.187 => 0.188] (core, personal-gunnarhj)
-queuebot:#ubuntu-release- Unapproved: ubuntu-settings (bionic-proposed/main) [18.04.3 => 18.04.4] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: mate-power-manager (bionic-proposed/universe) [1.20.1-0ubuntu1 => 1.20.1-2ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: mythtv (bionic-proposed/multiverse) [2:29.1+fixes.20180412.329c235-0ubuntu1 => 2:29.1+fixes.20180414.329c235-0ubuntu3] (mythbuntu)
-queuebot:#ubuntu-release- Unapproved: dwarf-fortress (bionic-proposed/multiverse) [0.44.07-1 => 0.44.09-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted dwarf-fortress [sync] (bionic-proposed) [0.44.09-1]
-queuebot:#ubuntu-release- Unapproved: sonic (bionic-proposed/main) [0.2.0-5 => 0.2.0-6] (kubuntu, ubuntu-desktop) (sync)
#ubuntu-release 2018-04-15
-queuebot:#ubuntu-release- Unapproved: openjdk-lts (bionic-proposed/main) [10~46-4ubuntu1 => 10~46-5ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted vtk7 [sync] (bionic-proposed) [7.1.1+dfsg1-2]
-queuebot:#ubuntu-release- Unapproved: accepted mythtv [source] (bionic-proposed) [2:29.1+fixes.20180413.329c235-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-lts [source] (bionic-proposed) [10~46-5ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mythtv [source] (bionic-proposed) [2:29.1+fixes.20180414.329c235-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted sonic [sync] (bionic-proposed) [0.2.0-6]
-queuebot:#ubuntu-release- New binary: vtk7 [s390x] (bionic-proposed/universe) [7.1.1+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: vtk7 [ppc64el] (bionic-proposed/universe) [7.1.1+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: vtk7 [i386] (bionic-proposed/universe) [7.1.1+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: vtk7 [amd64] (bionic-proposed/universe) [7.1.1+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New sync: leiningen-clojure (bionic-proposed/primary) [2.8.1-5]
-queuebot:#ubuntu-release- Unapproved: complete-clojure (bionic-proposed/universe) [0.2.4-2 => 0.2.4-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted complete-clojure [sync] (bionic-proposed) [0.2.4-3]
-queuebot:#ubuntu-release- Unapproved: libbultitude-clojure (bionic-proposed/universe) [0.2.8-2 => 0.2.8-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libtools-macro-clojure (bionic-proposed/universe) [0.1.5-1 => 0.1.5-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: parsley-clojure (bionic-proposed/universe) [0.9.3-1 => 0.9.3-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: rejected libtools-macro-clojure [sync] (bionic-proposed) [0.1.5-2]
-queuebot:#ubuntu-release- Unapproved: accepted parsley-clojure [sync] (bionic-proposed) [0.9.3-2]
-queuebot:#ubuntu-release- Unapproved: accepted libbultitude-clojure [sync] (bionic-proposed) [0.2.8-4]
-queuebot:#ubuntu-release- Unapproved: stencil-clojure (bionic-proposed/universe) [0.5.0-1 => 0.5.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: com-hypirion-io-clojure (bionic-proposed/universe) [0.3.1-2 => 0.3.1-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: tools-nrepl-clojure (bionic-proposed/universe) [0.2.12-1 => 0.2.12-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted com-hypirion-io-clojure [sync] (bionic-proposed) [0.3.1-3]
-queuebot:#ubuntu-release- Unapproved: accepted tools-nrepl-clojure [sync] (bionic-proposed) [0.2.12-2]
-queuebot:#ubuntu-release- Unapproved: accepted stencil-clojure [sync] (bionic-proposed) [0.5.0-2]
-queuebot:#ubuntu-release- New: accepted leiningen-clojure [sync] (bionic-proposed) [2.8.1-5]
-queuebot:#ubuntu-release- New: accepted vtk7 [i386] (bionic-proposed) [7.1.1+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted vtk7 [s390x] (bionic-proposed) [7.1.1+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted vtk7 [amd64] (bionic-proposed) [7.1.1+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted vtk7 [ppc64el] (bionic-proposed) [7.1.1+dfsg1-2]
-queuebot:#ubuntu-release- Unapproved: kodi (bionic-proposed/universe) [2:17.6+dfsg1-1build1 => 2:17.6+dfsg1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted kodi [source] (bionic-proposed) [2:17.6+dfsg1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gcc-7 (bionic-proposed/main) [7.3.0-16ubuntu2 => 7.3.0-16ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: smb4k (bionic-proposed/universe) [2.0.2-1 => 2.1.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted smb4k [sync] (bionic-proposed) [2.1.0-1]
<acheronuk> ^^^^ https://bugs.launchpad.net/ubuntu/+source/smb4k/+bug/1763615
<ubot5`> Ubuntu bug 1763615 in smb4k (Ubuntu) "[FFe] Sync smb4k 2.1.0-1 (universe) from Debian unstable (main)" [Wishlist,New]
<acheronuk> as per slangasek's request the others day to just get things in the queue to decide the FFe on leaf stuff there
-queuebot:#ubuntu-release- Unapproved: alkimia (bionic-proposed/universe) [7.0.1-1 => 7.0.2-1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: virtualbox (bionic-proposed/multiverse) [5.2.8-dfsg-7 => 5.2.8-dfsg-9] (ubuntu-cloud) (sync)
-queuebot:#ubuntu-release- Unapproved: python-msgpack (bionic-proposed/main) [0.5.4-0ubuntu2 => 0.5.6-0ubuntu1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-7 [source] (bionic-proposed) [7.3.0-16ubuntu3]
-queuebot:#ubuntu-release- Unapproved: rejected ubiquity [source] (bionic-proposed) [18.04.6]
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (bionic-proposed) [18.04.6]
-queuebot:#ubuntu-release- Unapproved: accepted kubuntu-meta [source] (bionic-proposed) [1.370]
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-guide (bionic-proposed/universe) [18.04.1-0ubuntu1 => 18.04.3-0ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: bugz (bionic-proposed/universe) [0.10.1-3 => 0.10.1-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: n2n (bionic-proposed/universe) [1.3.1~svn3789-5build1 => 1.3.1~svn3789-6] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted bugz [sync] (bionic-proposed) [0.10.1-4]
-queuebot:#ubuntu-release- Unapproved: accepted n2n [sync] (bionic-proposed) [1.3.1~svn3789-6]
-queuebot:#ubuntu-release- Unapproved: xubuntu-default-settings (bionic-proposed/universe) [18.04.5 => 18.04.6] (xubuntu)
<bluesabre> Please accept the xubuntu-artwork, xfce4-notifyd, and xubuntu-default-settings packages :)
-queuebot:#ubuntu-release- Unapproved: caja (bionic-proposed/universe) [1.20.2-0ubuntu1 => 1.20.2-1ubuntu1] (ubuntu-mate, ubuntukylin, xubuntu)
-queuebot:#ubuntu-release- Unapproved: mate-menu (bionic-proposed/universe) [18.04.2-1ubuntu1 => 18.04.3-1] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: dehydrated-hook-ddns-tsig (bionic-proposed/universe) [0.1.2-2 => 0.1.2-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted dehydrated-hook-ddns-tsig [sync] (bionic-proposed) [0.1.2-3]
-queuebot:#ubuntu-release- New sync: roundcube (bionic-proposed/primary) [1.3.6+dfsg.1-1]
-queuebot:#ubuntu-release- Unapproved: skanlite (bionic-proposed/universe) [2.0.1-1 => 2.1.0.1-1] (kubuntu) (sync)
-queuebot:#ubuntu-release- New binary: leiningen-clojure [amd64] (bionic-proposed/universe) [2.8.1-5] (no packageset)
<LocutusOfBorg> xnox, hello, can I please blame systemd for this regression in release? https://autopkgtest.ubuntu.com/packages/gdnsd/bionic/amd64
<LocutusOfBorg> but 237-3ubuntu6->237-3ubuntu8  has not that much diff to cause an error during statup...
-queuebot:#ubuntu-release- New: accepted leiningen-clojure [amd64] (bionic-proposed) [2.8.1-5]
-queuebot:#ubuntu-release- Unapproved: python-msgpack (bionic-proposed/main) [0.5.4-0ubuntu2 => 0.5.6-0ubuntu1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: leiningen-clojure (bionic-proposed/universe) [2.8.1-5 => 2.8.1-6] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted leiningen-clojure [sync] (bionic-proposed) [2.8.1-6]
-queuebot:#ubuntu-release- Unapproved: djvubind (bionic-proposed/universe) [1.2.1-3 => 1.2.1-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted djvubind [sync] (bionic-proposed) [1.2.1-5]
-queuebot:#ubuntu-release- Unapproved: sddm (bionic-proposed/universe) [0.17.0-1ubuntu3 => 0.17.0-1ubuntu4] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: libcapi20-3 (bionic-proposed/universe) [1:3.27-2 => 1:3.27-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: scim (bionic-proposed/universe) [1.4.18-1 => 1.4.18-2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: fslint (bionic-proposed/universe) [2.44-2ubuntu1 => 2.44-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted fslint [sync] (bionic-proposed) [2.44-3]
-queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (bionic-proposed/multiverse) [5.2.8-dfsg-9ubuntu18.04.1 => 5.2.8-dfsg-10ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-hwe [source] (bionic-proposed) [5.2.8-dfsg-10ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected python-msgpack [source] (bionic-proposed) [0.5.6-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted roundcube [sync] (bionic-proposed) [1.3.6+dfsg.1-1]
-queuebot:#ubuntu-release- New binary: roundcube [amd64] (bionic-proposed/universe) [1.3.6+dfsg.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted roundcube [amd64] (bionic-proposed) [1.3.6+dfsg.1-1]
-queuebot:#ubuntu-release- Unapproved: python2.7 (bionic-proposed/main) [2.7.14-8 => 2.7.15~rc1-1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted python2.7 [source] (bionic-proposed) [2.7.15~rc1-1]
<xnox> LocutusOfBorg, resolved now binds to port :53
<xnox> LocutusOfBorg, what is gdnsd and why does it bind to 53?
-queuebot:#ubuntu-release- Unapproved: pastebinit (bionic-proposed/main) [1.5-1 => 1.5-2] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: budgie-desktop-environment (bionic-proposed/universe) [0.9.8 => 0.9.9] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- Unapproved: debian-reference (bionic-proposed/universe) [2.70 => 2.72] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted debian-reference [sync] (bionic-proposed) [2.72]
-queuebot:#ubuntu-release- Unapproved: gobject-introspection (bionic-proposed/main) [1.56.0-2 => 1.56.1-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: tiff (bionic-proposed/main) [4.0.9-4ubuntu1 => 4.0.9-5] (core) (sync)
#ubuntu-release 2019-04-08
-queuebot:#ubuntu-release- Unapproved: accepted qtbase-opensource-src [sync] (disco-proposed) [5.12.2+dfsg-4]
-queuebot:#ubuntu-release- Unapproved: accepted language-selector [source] (disco-proposed) [0.194]
-queuebot:#ubuntu-release- Unapproved: accepted qqc2-desktop-style [source] (disco-proposed) [5.56.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted openipmi [source] (disco-proposed) [2.0.25-2.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ristretto [source] (disco-proposed) [0.8.3-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: pbgenomicconsensus (disco-proposed/universe) [2.3.2-4 => 2.3.2-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pbgenomicconsensus [sync] (disco-proposed) [2.3.2-5]
-queuebot:#ubuntu-release- Unapproved: libspring-java (disco-proposed/universe) [4.3.22-3 => 4.3.22-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libspring-java [sync] (disco-proposed) [4.3.22-4]
-queuebot:#ubuntu-release- Unapproved: javatools (disco-proposed/universe) [0.72.7 => 0.72.8] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted javatools [sync] (disco-proposed) [0.72.8]
-queuebot:#ubuntu-release- Unapproved: akonadi-calendar-tools (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: akonadi-contacts (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: akonadi-mime (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: akonadi-search (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: akonadiconsole (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: grantlee-editor (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: akonadi-calendar (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: akonadi-notes (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: akregator (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: akonadi-import-wizard (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kaddressbook (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: akonadi (disco-proposed/universe) [4:18.12.3-0ubuntu2 => 4:18.12.3-0ubuntu3] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kalarm (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kblog (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kcalutils (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kdav (disco-proposed/universe) [18.12.3-0ubuntu1 => 18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kdepim-runtime (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kf5-messagelib (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kidentitymanagement (disco-proposed/universe) [18.12.3-0ubuntu1 => 18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kitinerary (disco-proposed/universe) [18.12.3-0ubuntu1 => 18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kalarmcal (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kcontacts (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kf5-kdepim-apps-libs (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kimap (disco-proposed/universe) [18.12.3-0ubuntu1 => 18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kcalcore (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kgpg (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kdepim-addons (disco-proposed/universe) [18.12.3-0ubuntu1 => 18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kldap (disco-proposed/universe) [18.12.3-0ubuntu1 => 18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kleopatra (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kmail (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kmbox (disco-proposed/universe) [18.12.3-0ubuntu1 => 18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: knotes (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kontactinterface (disco-proposed/universe) [18.12.3-0ubuntu1 => 18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: korganizer (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kpkpass (disco-proposed/universe) [18.12.3-0ubuntu1 => 18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: ktnef (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: libkf5eventviews (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: libkf5gravatar (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kmail-account-wizard (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kmime (disco-proposed/universe) [18.12.3-0ubuntu1 => 18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kopete (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: ksmtp (disco-proposed/universe) [18.12.3-0ubuntu1 => 18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: libkf5grantleetheme (disco-proposed/universe) [18.12.3-0ubuntu1 => 18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: libkf5ksieve (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kmailtransport (disco-proposed/universe) [18.12.3-0ubuntu1 => 18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kpimtextedit (disco-proposed/universe) [18.12.3-0ubuntu1 => 18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: libkf5incidenceeditor (disco-proposed/universe) [18.12.3-0ubuntu1 => 18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kontact (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: libkf5libkdepim (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: libkf5calendarsupport (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: libkf5libkleo (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: libkf5mailimporter (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: libkgapi (disco-proposed/universe) [18.12.3-0ubuntu1 => 18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: pim-data-exporter (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: libkf5mailcommon (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: mbox-importer (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: libkf5pimcommon (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: pim-sieve-editor (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu2] (kubuntu) (sync)
<acheronuk> ^ LP: #1822978
<ubot5`> Launchpad bug 1822978 in akonadi (Ubuntu Disco) "Backport upstream fixes for regression in Akonadi and PIM (stack rebuild)" [High,New] https://launchpad.net/bugs/1822978
<acheronuk> FYI sil2100 apw or other release team ^^
-queuebot:#ubuntu-release- Unapproved: accepted akonadi-calendar-tools [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted akonadi-contacts [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted akonadi-mime [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted akonadi-search [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted akonadiconsole [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted akonadi-calendar [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted akonadi-notes [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted akregator [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted akonadi-import-wizard [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted akonadi [sync] (disco-proposed) [4:18.12.3-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted kmbox [sync] (disco-proposed) [18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted knotes [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kontactinterface [sync] (disco-proposed) [18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted korganizer [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kpkpass [sync] (disco-proposed) [18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ktnef [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted libkf5eventviews [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted libkf5gravatar [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted libkf5ksieve [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted libkf5libkleo [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kmime [sync] (disco-proposed) [18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kopete [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ksmtp [sync] (disco-proposed) [18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted libkf5grantleetheme [sync] (disco-proposed) [18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted libkf5libkdepim [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted libkf5mailimporter [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted libkgapi [sync] (disco-proposed) [18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted pim-data-exporter [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kontact [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted libkf5calendarsupport [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted libkf5mailcommon [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted mbox-importer [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kpimtextedit [sync] (disco-proposed) [18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted libkf5pimcommon [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted libkf5incidenceeditor [sync] (disco-proposed) [18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted pim-sieve-editor [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted grantlee-editor [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kalarm [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kblog [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kcalutils [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kdav [sync] (disco-proposed) [18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kdepim-runtime [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kf5-messagelib [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kidentitymanagement [sync] (disco-proposed) [18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kitinerary [sync] (disco-proposed) [18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kleopatra [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kaddressbook [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kcalcore [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kdepim-addons [sync] (disco-proposed) [18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kgpg [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kldap [sync] (disco-proposed) [18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kmail [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kalarmcal [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kf5-kdepim-apps-libs [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kmail-account-wizard [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kcontacts [sync] (disco-proposed) [4:18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kmailtransport [sync] (disco-proposed) [18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted kimap [sync] (disco-proposed) [18.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted cups-filters [sync] (disco-proposed) [1.22.4-1]
<infinity> acheronuk: Accepted.  Thanks for your spam^Wcontribution to Ubuntu.
<acheronuk> infinity: thanks (I think)
<infinity> ;)
-queuebot:#ubuntu-release- Unapproved: android-platform-tools-apksig (disco-proposed/universe) [0.8-2ubuntu1 => 0.8-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted android-platform-tools-apksig [sync] (disco-proposed) [0.8-3]
-queuebot:#ubuntu-release- Unapproved: glibc (disco-proposed/main) [2.29-0ubuntu1 => 2.29-0ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted glibc [source] (disco-proposed) [2.29-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: swift (disco-proposed/main) [2.20.0-0ubuntu2 => 2.21.0-0ubuntu1] (openstack, ubuntu-server)
<ginggs> would someone please kick the scipy/i386 can along?  'force-badtest python-scipy/1.1.0-2/i386 python-scipy/1.2.1-0ubuntu3/i386'
-queuebot:#ubuntu-release- Unapproved: nova-lxd (disco-proposed/main) [19.0.0~b1~git2019031316.3c01bfc-0ubuntu1 => 19.0.0~rc1-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (bionic-proposed/main) [4.18.0-18.19~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-48.51~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (bionic-proposed/main) [4.18.0-18.19~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-48.51~16.04.1] (kernel)
-queuebot:#ubuntu-release- Unapproved: robocode (disco-proposed/universe) [1.9.3.3-1 => 1.9.3.3-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted robocode [sync] (disco-proposed) [1.9.3.3-2]
-queuebot:#ubuntu-release- Unapproved: shimdandy (disco-proposed/universe) [1.2.0-2 => 1.2.0-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted shimdandy [sync] (disco-proposed) [1.2.0-3]
-queuebot:#ubuntu-release- Unapproved: sweethome3d-furniture-editor (disco-proposed/universe) [1.24-1ubuntu1 => 1.24-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted sweethome3d-furniture-editor [sync] (disco-proposed) [1.24-2]
-queuebot:#ubuntu-release- Unapproved: sweethome3d (disco-proposed/universe) [6.1.2+dfsg-1ubuntu1 => 6.1.2+dfsg-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted sweethome3d [sync] (disco-proposed) [6.1.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (bionic-proposed) [4.18.0-18.19~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (bionic-proposed) [4.18.0-18.19~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-48.51~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-48.51~16.04.1]
<rbalint> sil2100, please accept lxd to cosmic if you have time in your sru cycle, it fixes LP: #1821924
<ubot5`> Launchpad bug 1821924 in lxd (Ubuntu Cosmic) "LXD Deb->snap transition fails in WSL due to snap command not working (yet)" [Low,In progress] https://launchpad.net/bugs/1821924
<sil2100> rbalint: sure, let me just finish up with some kernels
-queuebot:#ubuntu-release- Unapproved: netlib-java (disco-proposed/multiverse) [0.9.3-4 => 0.9.3-6] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted netlib-java [sync] (disco-proposed) [0.9.3-6]
<jibel> Could anyone trigger a build of ubuntu-canary?
<jibel> sil2100, ^
<jibel> plz
<sil2100> jibel: sure, on it
<sil2100> ...ok, one moment
<sil2100> jibel: there's a regular ubuntu desktop build in progress, that one needs to finish before I can kick a new canary one
<sil2100> The livefs build finished so it should be done soon
<jibel> sil2100, yeah, I was wondering if a regular build was also triggering subprojects so I  could do it myself
<sil2100> jibel: ok, triggered the build now
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-146.172~14.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1036.41] (kernel)
<jibel> sil2100, image built successfully, could you copy /srv/cdimage.ubuntu.com/scratch/ubuntu/disco/daily-live/debian-cd/amd64/disco-desktop-canary-amd64.raw somewhere it can be downloaded from?
<sil2100> jibel: sure, on it o/
-queuebot:#ubuntu-release- Unapproved: pcre3 (disco-proposed/main) [2:8.39-11 => 2:8.39-12] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pcre3 [sync] (disco-proposed) [2:8.39-12]
<sil2100> jibel: http://people.canonical.com/~platform/ubuntu-canary/20190408/
<jibel> sil2100, great, thanks!
-queuebot:#ubuntu-release- Unapproved: pcre3 (cosmic-proposed/main) [2:8.39-11 => 2:8.39-12~18.10] (core)
<doko> vorlon, xnox: what's the status of the openssl updates for cosmic? is it safe to upload new pythonX:Y versions?
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1036.41]
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-146.172~14.04.1]
-queuebot:#ubuntu-release- Unapproved: gcc-8-cross (disco-proposed/main) [27ubuntu3 => 27ubuntu4] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gcc-8-cross-ports (disco-proposed/universe) [20ubuntu6 => 20ubuntu7] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-8-cross-ports [source] (disco-proposed) [20ubuntu7]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-8-cross [source] (disco-proposed) [27ubuntu4]
-queuebot:#ubuntu-release- Unapproved: gcc-8 (cosmic-proposed/main) [8.2.0-7ubuntu1 => 8.3.0-6ubuntu1~18.10] (core)
-queuebot:#ubuntu-release- Unapproved: gcc-8-cross-ports (bionic-proposed/universe) [9ubuntu0.2 => 9ubuntu0.3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gcc-8-cross (bionic-proposed/main) [18ubuntu0.2 => 18ubuntu0.3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: ibus (disco-proposed/main) [1.5.19-1ubuntu1 => 1.5.19-1ubuntu2] (desktop-core, input-methods)
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (cosmic-proposed) [1:0.4.1]
-queuebot:#ubuntu-release- Unapproved: libdmapsharing (disco-proposed/main) [2.9.39-4 => 2.9.39-4ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gcc-8-cross-ports (cosmic-proposed/universe) [12ubuntu1 => 12ubuntu1.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gcc-8-cross (cosmic-proposed/main) [21ubuntu1 => 21ubuntu1.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-8-cross [source] (bionic-proposed) [18ubuntu0.3]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-8-cross-ports [source] (bionic-proposed) [9ubuntu0.3]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-defaults [source] (bionic-proposed) [1.176ubuntu2.2]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-defaults-ports [source] (bionic-proposed) [1.176ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: systemd (cosmic-proposed/main) [239-7ubuntu10.12 => 239-7ubuntu10.13] (core)
<teward> regarding OpenSSL SRU in Bionic, https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1823476 was requested, should I upload a no-changes rebuild item to bionic-proposed so that when the OpenSSL SRU releases the changes are included?  Or should I wait for the OpenSSL SRU to complete?  It's a valid question but I thought I'd ask before I do anything.
<ubot5`> Ubuntu bug 1823476 in nginx (Ubuntu Bionic) "Rebuild with OpenSSL 1.1.1" [Wishlist,In progress]
-queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu10.19 => 237-3ubuntu10.20] (core)
<ddstreet_away> hello sil2100!  hope you had a good wkend :)  if you have time during your sru vanguarding today, those systemd uploads are from me
<sil2100> ddstreet: morning o/ Let me get to those in some minutes ;)
<ddstreet> sil2100 thanks!
-queuebot:#ubuntu-release- Unapproved: gnome-control-center (disco-proposed/main) [1:3.32.1-1ubuntu1 => 1:3.32.1-1ubuntu2] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-8 [source] (cosmic-proposed) [8.3.0-6ubuntu1~18.10]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-8-cross [source] (cosmic-proposed) [21ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (disco-proposed) [1:3.32.1-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted libdmapsharing [source] (disco-proposed) [2.9.39-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted swift [source] (disco-proposed) [2.21.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ibus [source] (disco-proposed) [1.5.19-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted nova-lxd [source] (disco-proposed) [19.0.0~rc1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-8-cross-ports [source] (cosmic-proposed) [12ubuntu1.1]
<vorlon> doko: I don't understand the question, re: openssl updates for cosmic.  I see that there's been one accepted into cosmic-proposed, but that's for LP: #1822984, which I don't think we should be SRUing at all on cosmic, but all of the state is in the bugs and http://people.canonical.com/~ubuntu-archive/pending-sru.html
<ubot5`> Launchpad bug 1822984 in openssl (Ubuntu Cosmic) "revert tls security level back to 1" [Undecided,Fix committed] https://launchpad.net/bugs/1822984
-queuebot:#ubuntu-release- Unapproved: gnome-user-docs (disco-proposed/main) [3.32.0-0ubuntu1 => 3.32.0+git20190406-0ubuntu1] (personal-gunnarhj, ubuntu-desktop)
<ginggs> vorlon: would you bump the python-scipy/i386 hint please?  you did amd64, but not i386
-queuebot:#ubuntu-release- Unapproved: ubuntu-docs (disco-proposed/main) [19.04.1 => 19.04.2] (desktop-core, personal-gunnarhj)
<vorlon> ginggs: I will check
<ginggs> vorlon: thanks!
-queuebot:#ubuntu-release- Unapproved: gdb (disco-proposed/main) [8.2.91.20190405-0ubuntu2 => 8.2.91.20190405-0ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: accepted gdb [source] (disco-proposed) [8.2.91.20190405-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-docs [source] (disco-proposed) [19.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-user-docs [source] (disco-proposed) [3.32.0+git20190406-0ubuntu1]
<LocutusOfBorg> can we please hint cryfs/0.9.10-2	
<LocutusOfBorg> on i386? looks like it is regressed in release and blocking curl migration
-queuebot:#ubuntu-release- Unapproved: libfuture-asyncawait-perl (disco-proposed/universe) [0.21-2 => 0.22-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libfuture-asyncawait-perl [sync] (disco-proposed) [0.22-1]
<bdmurray> vorlon: I'm working on an update-manager bug fix and have discovered that it's autopkgtests use pyflakes instead of pyflakes3. Its fixing that okay with this upload given the release state?
<infinity> bdmurray: Yes.
<bdmurray> infinity: cool, thanks!
<teward> would there be anything against accepting a no changes rebuild against the openssl in -proposed for nginx as part of the openssl 1.1.1 transition/sru?
<cyphermox> sil2100: do you have a moment to review shim-signed in xenial and trusty unapproved queues?
-queuebot:#ubuntu-release- Unapproved: samba (disco-proposed/main) [2:4.10.0+dfsg-0ubuntu1 => 2:4.10.0+dfsg-0ubuntu2] (core)
<sil2100> cyphermox: hey! Let me try getting to that
-queuebot:#ubuntu-release- Unapproved: update-manager (disco-proposed/main) [1:19.04.4 => 1:19.04.5] (core)
<cyphermox> sil2100: ta
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (cosmic-proposed) [239-7ubuntu10.13]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (bionic-proposed) [237-3ubuntu10.20]
-queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (xenial-proposed) [1.33.1~16.04.5]
-queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (trusty-proposed) [1.33.1~14.04.5]
<cyphermox> thanks!
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (trusty-proposed/main) [2.208.16 => 2.208.17] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (trusty-proposed) [2.208.17]
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.44 => 2.408.45] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: ubiquity (disco-proposed/main) [19.04.8 => 19.04.9] (core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (disco-proposed/main) [1:19.04.14 => 1:19.04.15] (core)
-queuebot:#ubuntu-release- Unapproved: eog (disco-proposed/main) [3.32.0-1 => 3.32.0-2] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: ruby-hangouts-chat (disco-proposed/universe) [0.0.5-1ubuntu1 => 0.0.5-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libpng1.6 (disco-proposed/main) [1.6.36-5 => 1.6.36-6] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: openssh (disco-proposed/main) [1:7.9p1-9 => 1:7.9p1-10] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: lirc (disco-proposed/main) [0.10.1-5.1 => 0.10.1-5.2] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ruby-hangouts-chat [sync] (disco-proposed) [0.0.5-2]
-queuebot:#ubuntu-release- New source: intel-opencl-clang (disco-proposed/primary) [8.0.0-0ubuntu1]
<bdmurray> vorlon, infinity: Could one of your reject ubuntu-release-upgrader? I've another upload coming shortly.
<bdmurray> for disco that is
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-release-upgrader [source] (disco-proposed) [1:19.04.15]
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (disco-proposed) [1:19.04.5]
-queuebot:#ubuntu-release- New source: intel-graphics-compiler (disco-proposed/primary) [1.0.0-0ubuntu1]
<tsimonq2> I believe the latest Lubuntu ISO build failure is due to an internal mirror issue, or something of that sort: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/disco/lubuntu/
<infinity> tsimonq2: Network/firewall blip probably, yeahp.
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (disco-proposed/main) [1:19.04.14 => 1:19.04.15] (core)
<tsimonq2> Alright.
-queuebot:#ubuntu-release- Unapproved: cross-toolchain-base (disco-proposed/main) [33ubuntu2 => 33ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted cross-toolchain-base [source] (disco-proposed) [33ubuntu3]
<infinity> bdmurray: I'm a bit fuzzy on the changes to DistUpgradeController.py
<infinity> bdmurray: Are those intentional?  Do they match something in the changelog?  Was it debugging cruft that you meant to revert?
<bdmurray> infinity: y, n, n
<bdmurray> infinity: https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/trunk/revision/3229 but should have been a part of 3227.
-queuebot:#ubuntu-release- Unapproved: openssh (disco-proposed/main) [1:7.9p1-9 => 1:7.9p1-10] (core) (sync)
<tsimonq2> infinity: Would you like any paperwork prior to accepting kpmcore (once I have tested this fix) or is prior discussion sufficient?
<infinity> tsimonq2: I don't need paperwork, but depending on the complexity of the patch, I might need context.
<infinity> (and I might not)
<cjwatson> Oh, somebody already requested that openssh sync
<cjwatson> Keener
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (disco-proposed) [1:19.04.15]
<tsimonq2> infinity: It's a one-liner.
<tsimonq2> (Also famous last words, heh...)
-queuebot:#ubuntu-release- Unapproved: accepted samba [source] (disco-proposed) [2:4.10.0+dfsg-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: rejected openssh [sync] (disco-proposed) [1:7.9p1-10]
-queuebot:#ubuntu-release- Unapproved: accepted openssh [sync] (disco-proposed) [1:7.9p1-10]
-queuebot:#ubuntu-release- Unapproved: apport (disco-proposed/main) [2.20.10-0ubuntu25 => 2.20.10-0ubuntu26] (core)
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (disco-proposed) [19.04.9]
<tsimonq2> infinity: Oh, nice, so it turns out highvoltage beat me to it: https://tracker.debian.org/news/1037472/accepted-kpmcore-330-5-source-amd64-into-unstable/
<tsimonq2> Testing anyway.
-queuebot:#ubuntu-release- Unapproved: kpmcore (disco-proposed/universe) [3.3.0-4 => 3.3.0-5] (kubuntu) (sync)
<tsimonq2> infinity: ^
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-settings (disco-proposed/universe) [19.04.0 => 19.04.1] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (disco-proposed) [2.20.10-0ubuntu26]
-queuebot:#ubuntu-release- Unapproved: accepted kpmcore [sync] (disco-proposed) [3.3.0-5]
-queuebot:#ubuntu-release- Unapproved: mixxx (cosmic-proposed/universe) [2.1.3~dfsg-1 => 2.2.0~dfsg-1ubuntu0.18.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: geogebra (disco-proposed/universe) [4.0.34.0+dfsg1-6ubuntu1 => 4.0.34.0+dfsg1-7] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted geogebra [sync] (disco-proposed) [4.0.34.0+dfsg1-7]
-queuebot:#ubuntu-release- New binary: geogebra [amd64] (disco-proposed/universe) [4.0.34.0+dfsg1-7] (no packageset)
-queuebot:#ubuntu-release- New: accepted geogebra [amd64] (disco-proposed) [4.0.34.0+dfsg1-7]
-queuebot:#ubuntu-release- Unapproved: binutils-mingw-w64 (disco-proposed/universe) [8.3ubuntu1 => 8.3ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted binutils-mingw-w64 [source] (disco-proposed) [8.3ubuntu2]
-queuebot:#ubuntu-release- Unapproved: gcc-mingw-w64 (disco-proposed/universe) [21.1build1 => 21.1build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-mingw-w64 [source] (disco-proposed) [21.1build2]
#ubuntu-release 2019-04-09
-queuebot:#ubuntu-release- Unapproved: ristretto (disco-proposed/universe) [0.8.3-1ubuntu1 => 0.8.4-0ubuntu1] (ubuntustudio, xubuntu)
-queuebot:#ubuntu-release- Unapproved: gcc-defaults-ports (cosmic-proposed/universe) [1.178ubuntu1 => 1.178ubuntu1.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gcc-defaults (cosmic-proposed/main) [1.179ubuntu1 => 1.179ubuntu1.1] (core)
-queuebot:#ubuntu-release- New binary: golang-github-ivpusic-grpool [amd64] (disco-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gnome-control-center (disco-proposed/main) [1:3.32.1-1ubuntu2 => 1:3.32.1-1ubuntu3] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: gdb-mingw-w64 (disco-proposed/universe) [10.8 => 10.8build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gdb-mingw-w64 [source] (disco-proposed) [10.8build1]
-queuebot:#ubuntu-release- Unapproved: python2.7 (cosmic-proposed/main) [2.7.15-4ubuntu4 => 2.7.16-2~18.10] (core)
-queuebot:#ubuntu-release- Unapproved: python-stdlib-extensions (cosmic-proposed/main) [2.7.15-1 => 2.7.16-2~18.10] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: python3.7 (cosmic-proposed/main) [3.7.1-1~18.10 => 3.7.3-2~18.10] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: python3.6 (cosmic-proposed/main) [3.6.7-1~18.10 => 3.6.8-1~18.10] (core)
-queuebot:#ubuntu-release- Unapproved: python3-stdlib-extensions (cosmic-proposed/main) [3.6.7-1~18.10 => 3.6.8-1~18.10] (core)
-queuebot:#ubuntu-release- Unapproved: peony (disco-proposed/universe) [1.1.5-1build1 => 1.1.5.1-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: python3-stdlib-extensions (bionic-proposed/main) [3.6.7-1~18.04 => 3.6.8-1~18.04] (core)
-queuebot:#ubuntu-release- Unapproved: python-stdlib-extensions (bionic-proposed/main) [2.7.15~rc1-1 => 2.7.16-2~18.04] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-defaults [source] (cosmic-proposed) [1.179ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-defaults-ports [source] (cosmic-proposed) [1.178ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted pcre3 [source] (cosmic-proposed) [2:8.39-12~18.10]
-queuebot:#ubuntu-release- Unapproved: lexicon (disco-proposed/universe) [3.0.8-1 => 3.0.8-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted lexicon [sync] (disco-proposed) [3.0.8-2]
-queuebot:#ubuntu-release- Unapproved: gnome-disk-utility (disco-proposed/main) [3.32.0-1ubuntu1 => 3.32.1-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-initial-setup (disco-proposed/main) [3.32.0-1ubuntu2 => 3.32.1-1ubuntu1] (ubuntu-desktop, ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: initramfs-tools-devices (disco-proposed/main) [0.3 => 0.4] (core)
-queuebot:#ubuntu-release- Unapproved: neutron (disco-proposed/main) [2:14.0.0~rc1-0ubuntu2 => 2:14.0.0~rc1-0ubuntu3] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: mutter (disco-proposed/main) [3.32.0-1ubuntu1 => 3.32.0-1ubuntu2] (desktop-core, desktop-extra)
-queuebot:#ubuntu-release- Unapproved: neutron (bionic-proposed/main) [2:12.0.5-0ubuntu3 => 2:12.0.5-0ubuntu4] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron (cosmic-proposed/main) [2:13.0.2-0ubuntu3 => 2:13.0.2-0ubuntu3.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (xenial-proposed/main) [4.15.0-1011.13~16.04.1] (kernel)
-queuebot:#ubuntu-release- Unapproved: vsftpd (disco-proposed/main) [3.0.3-11 => 3.0.3-12] (ubuntu-server) (sync)
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (xenial-proposed) [4.15.0-1011.13~16.04.1]
-queuebot:#ubuntu-release- Unapproved: gnome-calculator (disco-proposed/main) [1:3.32.0-1ubuntu1 => 1:3.32.1-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: mpi4py (disco-proposed/universe) [2.0.0-3build3 => 2.0.0-3build4] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: mpi4py (disco-proposed/universe) [2.0.0-3build3 => 2.0.0-3build4] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: lmfit-py (disco-proposed/universe) [0.9.11+dfsg-2 => 0.9.11+dfsg-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted lmfit-py [source] (disco-proposed) [0.9.11+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: linux-gcp-edge (bionic-proposed/main) [4.18.0-1008.9~18.04.1 => 4.18.0-1009.10~18.04.1] (kernel)
<smb> sil2100, could you quickly drop linux-[meta-,signed-]-gcp-edge from bionics unapproved queues
<smb> apw, ^
<smb> Actually I think only the kernel part made it accidentally
<apw> smb, on it
-queuebot:#ubuntu-release- Unapproved: rejected linux-gcp-edge [source] (bionic-proposed) [4.18.0-1009.10~18.04.1]
<apw> smb, ^
<smb> apw, thanks. I hope that is enough to be able to try again with the ckt-ppa
<apw> smb, yep that version does not exist as it didn't make it thorugh the queue
<smb> ack
-queuebot:#ubuntu-release- Unapproved: accepted eog [sync] (disco-proposed) [3.32.0-2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-disk-utility [source] (disco-proposed) [3.32.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libpng1.6 [sync] (disco-proposed) [1.6.36-6]
-queuebot:#ubuntu-release- Unapproved: accepted mutter [source] (disco-proposed) [3.32.0-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted peony [source] (disco-proposed) [1.1.5.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-settings [source] (disco-proposed) [19.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (disco-proposed) [1:3.32.1-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted lirc [sync] (disco-proposed) [0.10.1-5.2]
-queuebot:#ubuntu-release- Unapproved: accepted ristretto [source] (disco-proposed) [0.8.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-initial-setup [source] (disco-proposed) [3.32.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (disco-proposed) [2:14.0.0~rc1-0ubuntu3]
-queuebot:#ubuntu-release- New binary: lirc [amd64] (disco-proposed/main) [0.10.1-5.2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: lirc [s390x] (disco-proposed/main) [0.10.1-5.2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: lirc [i386] (disco-proposed/main) [0.10.1-5.2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New: rejected linux-restricted-modules [source] (disco-proposed) [5.0.0-8.9]
-queuebot:#ubuntu-release- New binary: lirc [ppc64el] (disco-proposed/main) [0.10.1-5.2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: libxcursor (disco-proposed/main) [1:1.1.15-2 => 1:1.2.0-1] (core, xorg) (sync)
-queuebot:#ubuntu-release- New binary: lirc [arm64] (disco-proposed/main) [0.10.1-5.2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: lirc [armhf] (disco-proposed/main) [0.10.1-5.2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (disco-proposed/partner) [1:20190312.1-0ubuntu1 => 1:20190409.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gnome-terminal (disco-proposed/main) [3.32.0-1ubuntu1 => 3.32.1-1ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: vte2.91 (disco-proposed/main) [0.56.0-1ubuntu1 => 0.56.1-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New source: linux-restricted-modules (disco-proposed/primary) [5.0.0-8.9]
<LocutusOfBorg> please any AA accept lirc binaries, dropping them made FTBFS all the reverse-deps...
<doko> vorlon: would it be feasable to have an update_output_notest for bionic and cosmic, or should we just add overrides to see the update_output?
-queuebot:#ubuntu-release- Unapproved: openldap (disco-proposed/main) [2.4.47+dfsg-3ubuntu1 => 2.4.47+dfsg-3ubuntu2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: heat-dashboard (disco-proposed/universe) [1.5.0-0ubuntu2 => 1.5.0-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted heat-dashboard [source] (disco-proposed) [1.5.0-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: session-migration (disco-proposed/main) [0.3.3 => 0.3.4] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-report (disco-proposed/main) [1.4.0 => 1.4.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: shotwell (disco-proposed/main) [0.30.2-0ubuntu1 => 0.30.2-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: lua5.3 (disco-proposed/main) [5.3.3-1.1build1 => 5.3.3-1.1ubuntu1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: wget (disco-proposed/main) [1.20.1-1ubuntu3 => 1.20.1-1ubuntu4] (core)
-queuebot:#ubuntu-release- Unapproved: intel-media-driver-non-free (disco-proposed/multiverse) [18.4.0+ds1-1ubuntu1 => 18.4.1+ds1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted intel-media-driver-non-free [sync] (disco-proposed) [18.4.1+ds1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-ivpusic-grpool [amd64] (disco-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted lirc [arm64] (disco-proposed) [0.10.1-5.2]
-queuebot:#ubuntu-release- New: accepted lirc [i386] (disco-proposed) [0.10.1-5.2]
-queuebot:#ubuntu-release- New: accepted lirc [s390x] (disco-proposed) [0.10.1-5.2]
-queuebot:#ubuntu-release- New: accepted lirc [amd64] (disco-proposed) [0.10.1-5.2]
-queuebot:#ubuntu-release- New: accepted lirc [ppc64el] (disco-proposed) [0.10.1-5.2]
-queuebot:#ubuntu-release- New: accepted lirc [armhf] (disco-proposed) [0.10.1-5.2]
-queuebot:#ubuntu-release- Unapproved: python-oslo.cache (cosmic-proposed/main) [1.30.1-0ubuntu1 => 1.30.1-0ubuntu1.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lsof (disco-proposed/main) [4.91+dfsg-1 => 4.91+dfsg-1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: intel-media-driver-non-free (disco-proposed/multiverse) [18.4.1+ds1-1 => 18.4.1+ds1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted intel-media-driver-non-free [source] (disco-proposed) [18.4.1+ds1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: masakari-monitors (disco-proposed/universe) [7.0.0~rc1-0ubuntu1 => 7.0.0~rc1-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted masakari-monitors [source] (disco-proposed) [7.0.0~rc1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: intel-media-driver (disco-proposed/universe) [18.4.0+dfsg1-1 => 18.4.0+dfsg1-1ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-calculator [source] (disco-proposed) [1:3.32.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mpi4py [source] (disco-proposed) [2.0.0-3build4]
-queuebot:#ubuntu-release- Unapproved: accepted vsftpd [sync] (disco-proposed) [3.0.3-12]
-queuebot:#ubuntu-release- Unapproved: accepted libxcursor [sync] (disco-proposed) [1:1.2.0-1]
-queuebot:#ubuntu-release- Unapproved: rejected mpi4py [source] (disco-proposed) [2.0.0-3build4]
-queuebot:#ubuntu-release- Unapproved: accepted lua5.3 [source] (disco-proposed) [5.3.3-1.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted session-migration [source] (disco-proposed) [0.3.4]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-report [source] (disco-proposed) [1.4.1]
-queuebot:#ubuntu-release- Unapproved: accepted openldap [source] (disco-proposed) [2.4.47+dfsg-3ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted wget [source] (disco-proposed) [1.20.1-1ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted shotwell [source] (disco-proposed) [0.30.2-0ubuntu2]
<Laney> cyphermox: lsof could do with patch headers / forwarding imho
<cyphermox> Laney: ah, indeed sorry
<cyphermox> I did forward
<cyphermox> just absolutely forgot the patch headers
<Laney> nod
<vorlon> doko: we should not add overrides for failing tests unless they are actually meant to be overridden, NOT to get notest-like output.
<vorlon> doko: setting up a notest should be possible, I'll try to look at this a little later
<Laney> please consider if and how much that'll slow down britney runs by
<cyphermox> could someone on the SRU team please publish the 2.02~beta2-9ubuntu1.17 SRU in trusty-updates?  (along with grub-signed 1.34.20)
-queuebot:#ubuntu-release- Unapproved: rejected lsof [source] (disco-proposed) [4.91+dfsg-1ubuntu1]
<cyphermox> Laney: you want me to reupload?
<Laney> ah, sorry, I thought that was the implication of what you said
<Laney> do you mind?
<cyphermox> not at all
-queuebot:#ubuntu-release- Unapproved: lsof (disco-proposed/main) [4.91+dfsg-1 => 4.91+dfsg-1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: lxc (xenial-proposed/main) [3.0.3-0ubuntu1~16.04.1 => 2.0.11-0ubuntu1~16.04.2] (ubuntu-server)
<stgraber> bdmurray: if you have a minute, can you let that lxc upload through ^ should fix a very odd regression from the previous one (static binary being oddly broken on a few arches)
<stgraber> we'll need that lxc released to xenial-updates before trusty EOLs so starting to get a bit short on time :)
-queuebot:#ubuntu-release- Unapproved: accepted lsof [source] (disco-proposed) [4.91+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: linux-firmware-raspi2 (disco-proposed/multiverse) [1.20180919-0ubuntu2 => 1.20190215-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware-raspi2 [source] (disco-proposed) [1.20190215-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: materia-gtk-theme (disco-proposed/universe) [20190201-1ubuntu1 => 20190201-1ubuntu2] (ubuntustudio)
<Eickmeyer> ^ Fixes a bug with Ubiquity (was black text on dark gray, text now white).
<cyphermox> ah, cool
<bdmurray> stgraber: I'll have a look shortly
<stgraber> bdmurray: thanks
<Eickmeyer> Had to manually create the patch myself based on an upstream commit. Tedious, but it works. Will have to get it synced from Debian when the author releases a new version.
<Eickmeyer> Any AA want to push materia-gtk-theme through? Fixes a readability bug in Ubiquity on Ubuntu Studio.
<bdmurray> stgraber: Can you elaborate about the change and why removing pie is a good idea?
<stgraber> bdmurray: building a static binary on ppc64el with -pie results in an invalid binary which is seen as dynamically linked and isn't executable
<bdmurray> stgraber: but -pie was removed for all arches?
<stgraber> bdmurray: correct because the binary is still wrong on the other arches, just apparently does get executed fine
<bdmurray> stgraber: So it is like this in the development release?
<stgraber> bdmurray: correct, looking at build logs, pie isn't involved with that particular binary when building on more recent versions of Ubuntu
<stgraber> bdmurray: I don't know if it's a change in build flag management, compiler or hardening-wrapper, but looking at bionic+, -pie isn't passed for this particular binary
<bdmurray> stgraber: alrighty, thanks for the additional information
<stgraber> bdmurray: np, sure was a really weird one...
<stgraber> root@xenial:~# ./init.lxc.static
<stgraber> bash: ./init.lxc.static: No such file or directory
<stgraber> root@xenial:~# file init.lxc.static
<stgraber> init.lxc.static: ELF 64-bit LSB shared object, 64-bit PowerPC or cisco 7500, version 1 (GNU/Linux), dynamically linked, interpreter /usr/lib, for GNU/Linux 3.2.0, BuildID[sha1]=6c8088d4c4570c64064e88e0c4a9e8b01d4f4a1f, stripped
<stgraber> root@xenial:~# ldd init.lxc.static
<stgraber>  statically linked
<stgraber> notice how the tools don't even agree with themselves :)
-queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (xenial-proposed) [2.0.11-0ubuntu1~16.04.2]
-queuebot:#ubuntu-release- Unapproved: lxc (xenial-proposed/main) [3.0.3-0ubuntu1~16.04.1 => 2.0.11-0ubuntu1~16.04.3] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected lxc [source] (xenial-proposed) [2.0.11-0ubuntu1~16.04.3]
-queuebot:#ubuntu-release- Unapproved: lxc (xenial-proposed/main) [3.0.3-0ubuntu1~16.04.1 => 2.0.11-0ubuntu1~16.04.3] (ubuntu-server)
<stgraber> bdmurray: sorry about that, we just tracked down our second regression to a liblxc bug rather than go-lxc as we expected, 16.04.3 has the relevant cherry-picks ^
<stgraber> bdmurray: I've just built and tested that one on ppc64el for good measure so we should be good for real with it :)
<stgraber> there will also be a fixed go-lxc hitting the queue in a few minutes, finishing preparing that one (kinda a mistery how those tests used to pass, effectively depending on bad error handling in the lib to pass when they shouldn't have)
<bdmurray> stgraber: okay, let me know when they are all ready
-queuebot:#ubuntu-release- Unapproved: golang-gopkg-lxc-go-lxc.v2 (xenial-proposed/main) [0.0~git20161126.1.82a07a6-0ubuntu1~ubuntu16.04.1 => 0.0~git20161126.1.82a07a6-0ubuntu1~ubuntu16.04.2] (no packageset)
<stgraber> bdmurray: both are in the xenial unapproved queue now, thanks!
-queuebot:#ubuntu-release- Unapproved: gnome-system-monitor (disco-proposed/main) [3.32.0-1 => 3.32.1-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: file-roller (disco-proposed/main) [3.32.0-1 => 3.32.1-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: cheese (disco-proposed/main) [3.31.90-1 => 3.32.1-1] (desktop-core, desktop-extra) (sync)
-queuebot:#ubuntu-release- Unapproved: evolution-data-server (disco-proposed/main) [3.32.0-1 => 3.32.1-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: eog (disco-proposed/main) [3.32.0-2 => 3.32.1-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: gnome-characters (disco-proposed/main) [3.32.0-2 => 3.32.1-1] (ubuntu-desktop, ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: budgie-indicator-applet (disco-proposed/universe) [0.5-0ubuntu1 => 0.5-0ubuntu2] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- Unapproved: gnome-logs (disco-proposed/main) [3.32.0-1 => 3.32.1-1] (ubuntu-desktop, ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: yelp (disco-proposed/main) [3.32.0-1 => 3.32.1-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: vala (disco-proposed/universe) [0.44.1-1 => 0.44.3-1] (ubuntu-desktop) (sync)
<bdmurray> cyphermox: does bug 1401532 not need fixing in Xenial?
<ubot5`> bug 1401532 in grub2-signed (Ubuntu Xenial) "GRUB's Secure Boot implementation loads unsigned kernel without warning" [High,In progress] https://launchpad.net/bugs/1401532
<cyphermox> it does, but we're blocked for now on being able to make that SRU in xenial
<bdmurray> cyphermox: blocked for now on what?
<cyphermox> FIPS kernels are currently unsigned, enforcing signature there would break that.
<cyphermox> or at least, that's what the status of things was as of March 20th; I haven't exactly gone back to check since, and trusty is soon to be EOL.
<vorlon> yes
<vorlon> I will spare bdmurray all of the gory details; but in any case, trusty must be released before EOL-not-EOL, and xenial does not have this deadline
<bdmurray> okay, I'll trust you guys this time
<cyphermox> bdmurray: if you want another trust exercise; there's netplan.io in bionic too. all the tests are passing except two tunnels tests in networkd, something that is completely new in netplan (ie. not a regression); failures are a because the kernel handles the tunnels differently on that version than cosmic and above.
-queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (xenial-proposed) [2.0.11-0ubuntu1~16.04.3]
-queuebot:#ubuntu-release- Unapproved: accepted golang-gopkg-lxc-go-lxc.v2 [source] (xenial-proposed) [0.0~git20161126.1.82a07a6-0ubuntu1~ubuntu16.04.2]
<vorlon> cyphermox: far better to reupload and disable those tests than to have to ignore failing testsuite results as a whole for a core system component
<cyphermox> vorlon: ok; I will reupload disabling these tests.
-queuebot:#ubuntu-release- Unapproved: accepted neon27 [source] (cosmic-proposed) [0.30.2-3~ubuntu18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted neon27 [source] (bionic-proposed) [0.30.2-3~ubuntu18.04.1]
<rbalint> bdmurray, if you have some time in your sru cycle please take a look at u-u, all bugs are verified now and the package is ready to go
<rbalint> bdmurray, well - some time -> a fair amount of time, but you are familiar with the upload ;-)
-queuebot:#ubuntu-release- Unapproved: horizon (disco-proposed/main) [3:15.0.0~rc2-0ubuntu1 => 3:15.0.0~rc2-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: netplan.io (bionic-proposed/main) [0.96-0ubuntu0.18.04.2 => 0.96-0ubuntu0.18.04.3] (core)
-queuebot:#ubuntu-release- Unapproved: ureadahead (bionic-proposed/main) [0.100.0-20 => 0.100.0-21] (core)
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.cache [source] (cosmic-proposed) [1.30.1-0ubuntu1.1]
<infinity> mitya57: Is it possible that the kpmcore/s390x FTBFS is fallout from the QString endian fix?  Is the problem maybe deeper?
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-settings (disco-proposed/universe) [19.04.1 => 19.04.2] (ubuntu-mate)
#ubuntu-release 2019-04-10
-queuebot:#ubuntu-release- Unapproved: update-manager (bionic-proposed/main) [1:18.04.11.9 => 1:18.04.11.10] (core)
-queuebot:#ubuntu-release- Unapproved: update-manager (cosmic-proposed/main) [1:18.10.10.1 => 1:18.10.10.2] (core)
-queuebot:#ubuntu-release- Unapproved: systemd (disco-proposed/main) [240-6ubuntu3 => 240-6ubuntu4] (core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (cosmic-proposed/main) [1:18.10.11.5 => 1:18.10.11.6] (core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (bionic-proposed/main) [1:18.04.30 => 1:18.04.31] (core)
-queuebot:#ubuntu-release- Unapproved: eclipse-titan (cosmic-proposed/universe) [6.3.1-1build4 => 6.3.1-1build4.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: eclipse-titan (bionic-proposed/universe) [6.3.1-1build1.1 => 6.3.1-1build1.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: android-platform-system-core (bionic-proposed/universe) [1:8.1.0+r23-4~18.04 => 1:8.1.0+r23-5~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: android-platform-system-core (cosmic-proposed/universe) [1:8.1.0+r23-4~18.10 => 1:8.1.0+r23-5~18.10] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted android-platform-system-core [sync] (cosmic-proposed) [1:8.1.0+r23-5~18.10]
-queuebot:#ubuntu-release- Unapproved: accepted android-platform-system-core [sync] (bionic-proposed) [1:8.1.0+r23-5~18.04]
<vorlon> anyone know why update_excuses hasn't updated for 6h?
<vorlon> possibly a hung package-subscribers process
<handsome_feng> Hi, Any chance someone in release team have a look at LP: #1809214, It has been there for 4 months. :(
<ubot5`> Launchpad bug 1809214 in ubuntukylin-theme (Ubuntu) "[UIFe] Please upgrade ubuntukylin-theme to 1.8.2.1" [High,New] https://launchpad.net/bugs/1809214
<mitya57> infinity: that looks like a different endianness bug. I started looking at it yesterday, will continue tomorrow.
-queuebot:#ubuntu-release- Unapproved: maven (bionic-proposed/universe) [3.6.0-1~18.04 => 3.6.0-1~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: maven (cosmic-proposed/universe) [3.6.0-1~18.04 => 3.6.0-1~18.04.1] (no packageset) (sync)
<mitya57> *will continue today
-queuebot:#ubuntu-release- Unapproved: accepted maven [sync] (cosmic-proposed) [3.6.0-1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: evolution-ews (disco-proposed/universe) [3.32.0-1 => 3.32.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: evolution (disco-proposed/universe) [3.32.0-1 => 3.32.1-2] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted maven [sync] (bionic-proposed) [3.6.0-1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted evolution-ews [sync] (disco-proposed) [3.32.1-1]
-queuebot:#ubuntu-release- Unapproved: gobject-introspection (disco-proposed/main) [1.60.0-1 => 1.60.1-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: libsoup2.4 (disco-proposed/main) [2.66.0-1 => 2.66.1-1] (core) (sync)
<didrocks> sil2100: hey, mind syncing latest canary image to the usual place?
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (disco-proposed/main) [2.575 => 2.576] (desktop-core)
<sil2100> didrocks: hey, sure, just need a few moments o/
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (disco-proposed) [2.576]
-queuebot:#ubuntu-release- Unapproved: ukui-control-center (disco-proposed/universe) [1.1.6-2 => 1.1.7-0ubuntu1] (ubuntukylin)
<didrocks> sil2100: thx ;)
<jibel> sil2100, you can delete previous images
-queuebot:#ubuntu-release- Unapproved: gnome-boxes (disco-proposed/universe) [3.31.90-2 => 3.32.0.2-0ubuntu1] (desktop-extra)
<sil2100> jibel: http://people.canonical.com/~platform/ubuntu-canary/20190410/
<didrocks> sil2100: thx! Can we envision having a scp if the ubuntu-cdimage path isn't doable?
<jibel> sil2100, thx
<didrocks> like automated, in a single directory, erasing previous builds
<didrocks> so that we don't bother you everyday :)
<jibel> or every 2 days
<sil2100> didrocks: yeah, this could be quite easily automated I suppose (although I'm doing it in a bit of a tricky way right now since I want do to the copies inside the network and somehow my key forwarding doesn't work), but let me just quickly chat with Steve today about maybe special casing this somehow in cdimage
<didrocks> sil2100: thx, keep us posted!
<seb128> whoever accepted evolution-ews, that needs the corresponding evolution-data-server/evolution accepted as well to build
<sil2100> seb128: I didn't, but I can take a look at those
<seb128> thx
<seb128> well there is a stack of GNOME .1 updates to review
-queuebot:#ubuntu-release- Unapproved: accepted evolution-data-server [sync] (disco-proposed) [3.32.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted evolution [sync] (disco-proposed) [3.32.1-2]
<seb128> would be welcome as well, the sooner the better ... :)
<seb128> (they are mostly translations update only)
<Laney> ews was auto approved
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (disco-proposed) [240-6ubuntu4]
<seb128> what's the criterious for auto-approve?
<seb128> evolution is in universe as well but was not
<Laney> no package set
<seb128> I guess it's being on some ISO rather than universe?
<seb128> ah
<seb128> thx
-queuebot:#ubuntu-release- Unapproved: accepted cheese [sync] (disco-proposed) [3.32.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted file-roller [sync] (disco-proposed) [3.32.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-logs [sync] (disco-proposed) [3.32.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted materia-gtk-theme [source] (disco-proposed) [20190201-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted eog [sync] (disco-proposed) [3.32.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-system-monitor [sync] (disco-proposed) [3.32.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-characters [sync] (disco-proposed) [3.32.1-1]
<seb128> woot, thx for the reviews :)
<Laney> I can't accept the flash one, guess that needs a ~canonical-partner-dev
<Laney> or whatever the team is
-queuebot:#ubuntu-release- Unapproved: accepted budgie-indicator-applet [source] (disco-proposed) [0.5-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted vala [sync] (disco-proposed) [0.44.3-1]
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (disco-proposed) [3:15.0.0~rc2-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted yelp [sync] (disco-proposed) [3.32.1-1]
<sil2100> Oh
<sil2100> I can do that then
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-mate-settings [source] (disco-proposed) [19.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (disco-proposed) [1:20190409.1-0ubuntu1]
 * Laney deliberately let his membership in that team expire :>
-queuebot:#ubuntu-release- Unapproved: accepted gnome-boxes [source] (disco-proposed) [3.32.0.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ukui-control-center [source] (disco-proposed) [1.1.7-0ubuntu1]
<acheronuk> is anyone able to look at the ubuntukylin-theme UIFFe that was mentioned earlier?
<sil2100> Laney: hah, tricky! ;)
<sil2100> acheronuk: no, but let me look at it now
<sil2100> eeek, that's really quite old
<acheronuk> yeah, which is why I highlighted
<handsome_feng> acheronuk, sil2100: Many thanks!
<cpaelzer> jfh: hey I loose "likes" of bdmurray due to bug 1817258 - have you heard anything if IBM is even trying to verify the actual SRU
<ubot5`> bug 1817258 in numactl (Ubuntu Cosmic) ""numastat" doesn't display correct information for the guest." [High,Fix committed] https://launchpad.net/bugs/1817258
<doko> apw, sforshee: weekly linux/5.0.0-8.9 autopkg test fail ping
<jfh> cpaelzer: didn't heard anything special on that - but I see that Santwana tested version 2.0.11-2.1ubuntu0.2 from the PPA (for Leonardo) on bionic - comment #18
<sil2100> handsome_feng: approved o/
<jfh> cpaelzer: I'll sent her a note and ask to retest from proposed ...
-queuebot:#ubuntu-release- Unapproved: firefox (disco-proposed/main) [66.0.2+build1-0ubuntu1 => 66.0.3+build1-0ubuntu1] (mozilla, ubuntu-desktop)
<handsome_feng> sil2100: Thanks! :D
<acheronuk> sil2100: shall I put that in the queue then?
-queuebot:#ubuntu-release- Unapproved: webkit2gtk (disco-proposed/main) [2.24.0-1 => 2.24.1-1] (desktop-core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted language-selector [source] (bionic-proposed) [0.188.2]
-queuebot:#ubuntu-release- Unapproved: accepted ureadahead [source] (bionic-proposed) [0.100.0-21]
<handsome_feng> acheronuk, thank you, I really appreciate it if you could sponsor the package! And I thank you can do that?  sil2100 left a comment to approved that. :)
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-appindicator (disco-proposed/main) [23.1-1 => 28-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntukylin-theme (disco-proposed/universe) [1.7.9.2 => 1.8.2.1] (ubuntukylin)
<acheronuk> handsome_feng: ^^
<handsome_feng> acheronuk, Thannnnnnnnnnnks! :)
-queuebot:#ubuntu-release- Unapproved: notary (disco-proposed/universe) [0.6.1~ds1-2 => 0.6.1~ds1-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted notary [sync] (disco-proposed) [0.6.1~ds1-3]
-queuebot:#ubuntu-release- Unapproved: spf-engine (disco-proposed/universe) [2.9.0-2 => 2.9.0-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted spf-engine [sync] (disco-proposed) [2.9.0-3]
-queuebot:#ubuntu-release- Unapproved: zsh (disco-proposed/main) [5.5.1-1ubuntu2 => 5.5.1-1ubuntu3] (core)
<xnox> ^ fixes FTBFS / autopkgtest as triggered by glibc
<rbalint> AA people, could you please publish ubuntu-meta's new ubuntu-wsl binary for all stable releases?
<rbalint> rbasak, if you have time in your sru cycle please take a look at u-u, all bugs are verified now and the package is ready to go and the master bug is LP: #1702793
<ubot5`> Launchpad bug 1702793 in unattended-upgrades (Ubuntu Xenial) "Full backport SRU for unattended-upgrades" [Low,Fix committed] https://launchpad.net/bugs/1702793
<sil2100> handsome_feng: thanks for the upload, let me review it o/
-queuebot:#ubuntu-release- Unapproved: accepted ubuntukylin-theme [source] (disco-proposed) [1.8.2.1]
<handsome_feng> sil2100, Thanks for your review. :)
<handsome_feng> sil2100: BTW, It would be great if you can review another FFe bug when you are free, LP: #1818769 :P
<ubot5`> Launchpad bug 1818769 in ubuntu-kylin-software-center (Ubuntu) "[FFe] Please upgrade ubuntu-kylin-software-center to 1.5.4" [High,New] https://launchpad.net/bugs/1818769
-queuebot:#ubuntu-release- Unapproved: accepted firefox [source] (disco-proposed) [66.0.3+build1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted zsh [source] (disco-proposed) [5.5.1-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted webkit2gtk [sync] (disco-proposed) [2.24.1-1]
<sil2100> handsome_feng: on it
-queuebot:#ubuntu-release- Unapproved: unity-tweak-tool (disco-proposed/universe) [0.0.7ubuntu4 => 0.0.7+-0ubuntu5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted unity-tweak-tool [source] (disco-proposed) [0.0.7+-0ubuntu5]
<sil2100> handsome_feng: approved o/
<handsome_feng> sil2100, Wow, It's a wonderful night, Thanks! :)
<handsome_feng> acheronuk, So could you help to upload this too, and I promise this is the last package. :P
-queuebot:#ubuntu-release- Unapproved: netbeans (cosmic-proposed/universe) [10.0-3~18.04.1 => 10.0-3~18.04.1ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: linux (disco-proposed/main) [5.0.0-8.9 => 5.0.0-10.11] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-aws (disco-proposed/main) [5.0.0-1001.1 => 5.0.0-1002.2] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-kvm (disco-proposed/main) [5.0.0-1001.1 => 5.0.0-1002.2] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-kvm (disco-proposed/main) [5.0.0.1001.1 => 5.0.0.1002.2] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-azure (disco-proposed/main) [5.0.0-1001.1 => 5.0.0-1002.2] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-raspi2 (disco-proposed/universe) [5.0.0-1004.4 => 5.0.0-1005.5] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-aws (disco-proposed/main) [5.0.0.1001.1 => 5.0.0.1002.2] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-raspi2 (disco-proposed/universe) [5.0.0.1004.1 => 5.0.0.1005.2] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed (disco-proposed/main) [5.0.0-8.9 => 5.0.0-10.11] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed-azure (disco-proposed/main) [5.0.0-1001.1 => 5.0.0-1002.2] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-amdgpu (disco-proposed/main) [19.0.0-1 => 19.0.1-1] (desktop-core) (sync)
<acheronuk> handsome_feng: uploading, slowly on a cr*p connection
-queuebot:#ubuntu-release- Unapproved: netbeans (bionic-proposed/universe) [10.0-3~18.04.1 => 10.0-3~18.04.1ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- New: accepted ubuntu-meta [amd64] (cosmic-proposed) [1.425.1]
-queuebot:#ubuntu-release- New: accepted ubuntu-meta [arm64] (cosmic-proposed) [1.425.1]
<handsome_feng> acheronuk, \^o^/
<acheronuk> np
 * acheronuk thinks a 75MB for a software centre is a big bloated, but wth
-queuebot:#ubuntu-release- Unapproved: ubuntu-kylin-software-center (disco-proposed/universe) [1.3.14 => 1.5.4] (ubuntukylin)
<acheronuk> handsome_feng sil2100 ^^
<handsome_feng> acheronuk, This is fantastic!
<sil2100> \o/
<sil2100> acheronuk: thanks o/
-queuebot:#ubuntu-release- Unapproved: linux-meta-azure (disco-proposed/main) [5.0.0.1001.1 => 5.0.0.1002.2] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta (disco-proposed/main) [5.0.0.8.9 => 5.0.0.10.11] (core, kernel) (sync)
<sil2100> handsome_feng, acheronuk: I don't like the debian/changelog in ubuntu-kylin-software-center since it has a few UNRELEASED entries, but I'll accept it anyway
<sil2100> Just be sure to fix that up sometime
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-kylin-software-center [source] (disco-proposed) [1.5.4]
-queuebot:#ubuntu-release- Unapproved: casper (disco-proposed/main) [1.402 => 1.403] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted ubuntu-meta [amd64] (bionic-proposed) [1.417.1]
-queuebot:#ubuntu-release- New: accepted ubuntu-meta [arm64] (bionic-proposed) [1.417.1]
-queuebot:#ubuntu-release- New: accepted ubuntu-meta [amd64] (xenial-proposed) [1.361.3]
-queuebot:#ubuntu-release- New: accepted ubuntu-meta [arm64] (xenial-proposed) [1.361.3]
-queuebot:#ubuntu-release- Unapproved: accepted netbeans [sync] (cosmic-proposed) [10.0-3~18.04.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted netbeans [sync] (bionic-proposed) [10.0-3~18.04.1ubuntu1]
<bdmurray> sil2100: Could you have a look at my u-r-u & update-manager uploads for B and C? Its rather important.
-queuebot:#ubuntu-release- Unapproved: pdl (disco-proposed/universe) [1:2.019-5 => 1:2.019-5build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pdl [source] (disco-proposed) [1:2.019-5build1]
-queuebot:#ubuntu-release- Unapproved: gnome-desktop3 (disco-proposed/main) [3.32.0-1ubuntu1 => 3.32.1-1ubuntu1] (ubuntu-desktop)
<sil2100> bdmurray: hum hum, ok, will try looking at that today still
<bdmurray> sil2100: I could ask someone else if you are short on itme
-queuebot:#ubuntu-release- Unapproved: accepted gnome-desktop3 [source] (disco-proposed) [3.32.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-amdgpu [sync] (disco-proposed) [19.0.1-1]
-queuebot:#ubuntu-release- Unapproved: cloud-init (disco-proposed/main) [18.5-45-g3554ffe8-0ubuntu1 => 18.5-61-gb76714c3-0ubuntu1] (core, edubuntu, ubuntu-cloud)
<Odd_Bloke> Could someone please accept ^ in to -proposed so we can start doing the testing our FFE calls for?
<Odd_Bloke> (I'm not sure if it would be blocked from migrating by the freeze, but I've filed https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1824185 with block-proposed just in case.)
<ubot5`> Ubuntu bug 1824185 in cloud-init (Ubuntu) "Release a new upstream snapshot to disco" [Undecided,New]
<Odd_Bloke> vorlon: ^, if you have a minute
<vorlon> Odd_Bloke: on it
<Odd_Bloke> Thanks!
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (disco-proposed) [18.5-61-gb76714c3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (cosmic-proposed/partner) [1:20190312.1-0ubuntu0.18.10.1 => 1:20190409.1-0ubuntu0.18.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20190312.1-0ubuntu0.16.04.1 => 1:20190409.1-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (bionic-proposed/partner) [1:20190312.1-0ubuntu0.18.04.1 => 1:20190409.1-0ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (trusty-proposed/partner) [1:20190312.1-0ubuntu0.14.04.1 => 1:20190409.1-0ubuntu0.14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: jhove (cosmic-proposed/multiverse) [1.20.1-5~18.04.1 => 1.20.1-5~18.10.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: jhove (bionic-proposed/multiverse) [1.20.1-5~18.04.1 => 1.20.1-5~18.04.1ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted jhove [sync] (cosmic-proposed) [1.20.1-5~18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted jhove [sync] (bionic-proposed) [1.20.1-5~18.04.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: jetty9 (cosmic-proposed/universe) [9.4.15-1~18.04 => 9.4.15-1~18.04.1ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: jetty9 (bionic-proposed/universe) [9.4.15-1~18.04 => 9.4.15-1~18.04.1ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted jetty9 [sync] (cosmic-proposed) [9.4.15-1~18.04.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted jetty9 [sync] (bionic-proposed) [9.4.15-1~18.04.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: tomcat8 (bionic-proposed/universe) [8.5.39-1ubuntu1~18.04 => 8.5.39-1ubuntu1~18.04.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: tomcat8 (cosmic-proposed/universe) [8.5.39-1ubuntu1~18.04 => 8.5.39-1ubuntu1~18.10] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted tomcat8 [sync] (cosmic-proposed) [8.5.39-1ubuntu1~18.10]
-queuebot:#ubuntu-release- Unapproved: accepted tomcat8 [sync] (bionic-proposed) [8.5.39-1ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (cosmic-proposed) [1:18.10.10.2]
-queuebot:#ubuntu-release- Unapproved: wpa (disco-proposed/main) [2:2.6-21ubuntu2 => 2:2.6-21ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: flashplugin-nonfree (disco-proposed/multiverse) [32.0.0.156ubuntu1 => 32.0.0.171ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted flashplugin-nonfree [source] (disco-proposed) [32.0.0.171ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (bionic-proposed) [1:18.04.11.10]
<sil2100> bdmurray: ekhm, where is teh template on LP: #1822886 ?
<ubot5`> Launchpad bug 1822886 in ubuntu-release-upgrader (Ubuntu Cosmic) "universe missing after bionic->cosmic do-release-upgrade" [Critical,Triaged] https://launchpad.net/bugs/1822886
 * sil2100 stares at bdmurray in an evil way
<bdmurray> sil2100: See this is why I needed a review!
<sil2100> ;)
<sil2100> bdmurray: just poke me once you update teh bug
-queuebot:#ubuntu-release- New sync: linux-meta-snapdragon (disco-proposed/primary) [5.0.0.1009.2]
-queuebot:#ubuntu-release- New sync: linux-snapdragon (disco-proposed/primary) [5.0.0-1009.9]
-queuebot:#ubuntu-release- Unapproved: linux-gcp (disco-proposed/main) [5.0.0-1001.1 => 5.0.0-1002.2] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed-gcp (disco-proposed/main) [5.0.0-1001.1 => 5.0.0-1002.2] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-gcp (disco-proposed/main) [5.0.0.1001.1 => 5.0.0.1002.2] (core, kernel) (sync)
<bdmurray> sil2100: Sorry about that I was involved in something, I may not get to it before you eod
<sil2100> bdmurray: ok, no worries, I'll pick it up tomorrow on my SRU shift then
-queuebot:#ubuntu-release- New source: intel-compute-runtime (disco-proposed/primary) [19.13.12717-0ubuntu1]
<ddstreet> stgraber rbalint not sure if you noticed yet, but the lxd upload for lp #1821924 appears to have broken the docker.io autopkgtests
<ubot5`> Launchpad bug 1821924 in lxd (Ubuntu Cosmic) "LXD Deb->snap transition fails in WSL due to snap command not working (yet)" [Low,Fix committed] https://launchpad.net/bugs/1821924
<stgraber> ddstreet: hmm, not sure what to think of it, the exact same package in disco is all green on autopkgtest
<stgraber> ddstreet: yeah, pretty sure that upload isn't what broke it, if you look at your own retry, it's failing despite not using the new lxd package
<stgraber> ddstreet: there's something weird going on with snapd in this case but it doesn't look like a lxd problem
<stgraber> you'll notice:
<stgraber> ==> Installing the LXD snap from the latest track for ubuntu-18.10
<stgraber> snap "lxd" is already installed, see 'snap help refresh'
<stgraber> which shows that the lxd snap is supposedly installed, the lxd shim package (0.4 from October) sees it as all good
<ddstreet> stgraber i think you're right, looks like snapd is failing as well, with a similarly weird error:
<ddstreet> + /snap/bin/go get -u github.com/snapcore/spread/cmd/spread
<ddstreet> /snap/go/3542/gowrapper: line 3: /snap/go/3542/bin/go: No such file or directory
<stgraber> and then things blow up on /snap/bin/lxd being missing
<ddstreet> yeah something off with snap
<stgraber> ddstreet: yep, so there's something pretty wrong going on with snapd in there
-queuebot:#ubuntu-release- Unapproved: ureadahead (xenial-proposed/main) [0.100.0-19 => 0.100.0-19.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted linux-aws [sync] (disco-proposed) [5.0.0-1002.2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-gcp [sync] (disco-proposed) [5.0.0-1002.2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-aws [sync] (disco-proposed) [5.0.0.1002.2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-gcp [sync] (disco-proposed) [5.0.0.1002.2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-raspi2 [sync] (disco-proposed) [5.0.0.1005.2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-raspi2 [sync] (disco-proposed) [5.0.0-1005.5]
-queuebot:#ubuntu-release- Unapproved: accepted linux-azure [sync] (disco-proposed) [5.0.0-1002.2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-azure [sync] (disco-proposed) [5.0.0.1002.2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta [sync] (disco-proposed) [5.0.0.10.11]
-queuebot:#ubuntu-release- Unapproved: accepted linux-kvm [sync] (disco-proposed) [5.0.0-1002.2]
-queuebot:#ubuntu-release- Unapproved: accepted linux [sync] (disco-proposed) [5.0.0-10.11]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-kvm [sync] (disco-proposed) [5.0.0.1002.2]
-queuebot:#ubuntu-release- Unapproved: pyparted (disco-proposed/main) [3.11.2-7 => 3.11.2-7ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed-azure [sync] (disco-proposed) [5.0.0-1002.2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed [sync] (disco-proposed) [5.0.0-10.11]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed-gcp [sync] (disco-proposed) [5.0.0-1002.2]
-queuebot:#ubuntu-release- Unapproved: accepted pyparted [source] (disco-proposed) [3.11.2-7ubuntu1]
-queuebot:#ubuntu-release- Unapproved: pyparted (disco-proposed/main) [3.11.2-7ubuntu1 => 3.11.2-10] (desktop-core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pyparted [sync] (disco-proposed) [3.11.2-10]
-queuebot:#ubuntu-release- Unapproved: accepted intel-media-driver [source] (disco-proposed) [18.4.0+dfsg1-1ubuntu1]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (disco-proposed/main) [5.0.0-1002.2] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (disco-proposed/main) [5.0.0-1002.2] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (disco-proposed/main) [5.0.0-10.11] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (trusty-proposed/main) [4.15.0-1042.46~14.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (disco-proposed/main) [5.0.0-10.11] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (disco-proposed/main) [5.0.0-10.11] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: console-setup (disco-proposed/main) [1.178ubuntu11 => 1.178ubuntu12] (core)
<vorlon> rcj: ^^
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (disco-proposed) [5.0.0-1002.2]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (disco-proposed) [5.0.0-10.11]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (disco-proposed) [5.0.0-10.11]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (disco-proposed) [5.0.0-1002.2]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (disco-proposed) [5.0.0-10.11]
<rcj> vorlon: thank you
-queuebot:#ubuntu-release- Unapproved: console-setup (cosmic-proposed/main) [1.178ubuntu9 => 1.178ubuntu9.1] (core)
-queuebot:#ubuntu-release- Unapproved: rejected console-setup [source] (cosmic-proposed) [1.178ubuntu9.1]
-queuebot:#ubuntu-release- Unapproved: rejected console-setup [source] (disco-proposed) [1.178ubuntu12]
-queuebot:#ubuntu-release- Unapproved: console-setup (disco-proposed/main) [1.178ubuntu11 => 1.178ubuntu12] (core)
-queuebot:#ubuntu-release- Unapproved: console-setup (cosmic-proposed/main) [1.178ubuntu9 => 1.178ubuntu9.1] (core)
-queuebot:#ubuntu-release- Unapproved: console-setup (bionic-proposed/main) [1.178ubuntu2.7 => 1.178ubuntu2.8] (core)
-queuebot:#ubuntu-release- Unapproved: console-setup (xenial-proposed/main) [1.108ubuntu15.4 => 1.108ubuntu15.5] (core)
<vorlon> bdmurray: ^^ do you have time for some off-day SRU reviews?  (with xenial being the most important, as it currently blocks rcj)
<bdmurray> vorlon: in a little bit yeah
-queuebot:#ubuntu-release- Unapproved: cloud-init (disco-proposed/main) [18.5-61-gb76714c3-0ubuntu1 => 18.5-62-g6322c2dd-0ubuntu1] (core, edubuntu, ubuntu-cloud)
<Odd_Bloke> vorlon: We discovered a regression, could you accept ^, please?
-queuebot:#ubuntu-release- Unapproved: librsvg (disco-proposed/main) [2.44.10-1 => 2.44.10-1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: emacs (disco-proposed/main) [1:26.1+1-3.2ubuntu1 => 1:26.1+1-3.2ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: software-properties (disco-proposed/main) [0.97.9 => 0.97.10] (core)
<vorlon> Odd_Bloke: looking
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (disco-proposed) [18.5-62-g6322c2dd-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted console-setup [source] (cosmic-proposed) [1.178ubuntu9.1]
-queuebot:#ubuntu-release- Unapproved: accepted console-setup [source] (bionic-proposed) [1.178ubuntu2.8]
-queuebot:#ubuntu-release- Unapproved: accepted console-setup [source] (xenial-proposed) [1.108ubuntu15.5]
-queuebot:#ubuntu-release- Unapproved: accepted netplan.io [source] (bionic-proposed) [0.96-0ubuntu0.18.04.3]
<ddstreet> stgraber you were right, the core snap is broken in cosmic, i opened lp #1824237 for it
<ubot5`> Launchpad bug 1824237 in snapd (Ubuntu Cosmic) "snap 'core' broken/missing and causing autopkgtest failures" [Undecided,New] https://launchpad.net/bugs/1824237
-queuebot:#ubuntu-release- Unapproved: openldap (bionic-proposed/main) [2.4.45+dfsg-1ubuntu1.1 => 2.4.45+dfsg-1ubuntu1.2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: openldap (cosmic-proposed/main) [2.4.46+dfsg-5ubuntu1.1 => 2.4.46+dfsg-5ubuntu1.2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: openldap (xenial-proposed/main) [2.4.42+dfsg-2ubuntu3.4 => 2.4.42+dfsg-2ubuntu3.5] (ubuntu-server)
<vorlon> ddstreet, stgraber: is this only reproducible with snapd 2.38+18.10?
<vorlon> ddstreet: I've marked your bug regression-proposed, and marked LP: #1818648 verification-failed-cosmic, so we immediately stop the line on the SRU
<ubot5`> Launchpad bug 1818648 in snapd (Ubuntu Cosmic) "[SRU] 2.38" [Undecided,Fix committed] https://launchpad.net/bugs/1818648
<vorlon> the only differences between pyparted 3.11.2-7ubuntu1 and 3.11.2-10 are the changelog, the maintainer field, and debian/tests.  So why did the one build on armhf, and the other fails with a SIGBUS? >:|
-queuebot:#ubuntu-release- Unapproved: accepted wpa [source] (disco-proposed) [2:2.6-21ubuntu3]
-queuebot:#ubuntu-release- Unapproved: fwupd (disco-proposed/main) [1.2.5-1 => 1.2.5-1ubuntu1] (desktop-core)
<vorlon> infinity, wgrant: ^^ is there anything that's changed recently with the launchpad buildd chroots?  because this is crazy
<vorlon> (pyparted)
<mwhudson> vorlon: changes in build dependencies?
<vorlon> mwhudson: complete debdiff is http://launchpadlibrarian.net/418712335/pyparted_3.11.2-7ubuntu1_3.11.2-10.diff.gz - nada
<mwhudson> vorlon: i mean, maybe a new binutils or something
<vorlon> ah
<mwhudson> changes in the archive
<mwhudson> wtb a thing to wdiff the build environment sections of the two build logs
<vorlon> mwhudson: the only package that's different in the log is linux-libc-dev which seems an unlikely culprit for impacting distutils
<mwhudson> yes
<vorlon> and the window when this broke is *narrow*, I literally uploaded 7ubuntu1, went to submittodebian, noticed the maintainer had already fixed this issue in 10, synced it
<mwhudson> oh that is silly!
<vorlon> disco-changes shows they were accepted 8 minutes apart
<mwhudson> next ideas: builder specific (but i think all our builders are the same these days), it's just random?
<vorlon> I've retried the build 2 more times
<vorlon> the builder names are similar (bos02-arm64-06{0,8}) for all that's worth
<infinity> vorlon: I really wanted to blame the kernel, but that seems to be unchanged. :/
<infinity> vorlon: Do we have a process to ask for the Microsoft solution in scalingstack (reboot the base compute nodes)?
<vorlon> uh
<vorlon> that'd be an RT I guess
<infinity> Cause an FPE is rather suspiciously weird.
<vorlon> oh it was sigfpe, not sigbus?  yeah I didn't even read it right
<xnox> vorlon, speaking of puma.... the autopkgtest is generated with autodep8, and it's just this:
<xnox> $ autodep8
<xnox> Test-Command: gem2deb-test-runner --autopkgtest --check-dependencies 2>&1
<xnox> Depends: @, libssl-dev,rake,ruby-rack, gem2deb-test-runner
<xnox> aka
<xnox> just run the test-suite.... and it does pass for me, in disco-release
<xnox> i'll do that again in disco-proposed now locally, if that passes too.... i wonder if we can try putting puma into "large packages" to give it more than one cpu. as it runs client and server, that supposed to talk to each other....
<xnox> and there is already one known test skip in single-cpu case.
<xnox> but also, puma does not look broken to me on ubuntu.
<xnox> passes in a chroot in disco-proposed too
<vorlon> xnox: but all of this is reactive; people are willing to spend time on picking at the specific autopkgtest failures only because attention has been drawn to them on ubuntu-devel
<xnox> vorlon, dude i'm not pretending that i'm doing something other than exactly that.
<xnox> =)))))))))
<vorlon> xnox: I can't imagine why it would need a 'large' testbed, it only takes 2 minutes to fail on a small one
<xnox> it's just if puma builds on builders, but fails to do the same thing in autopkgtest, we are at odds with like host kernel, or different size of resources.
<xnox> well, trying to reproduce the failure, and failing at the moment =)
<vorlon> xnox: the command run in the autopkgtest is not one that's run in the package build
<xnox> vorlon, the command run in autopkgtest, should be the one generated by autodep8 see my message from 00:04:16 UK time.
<vorlon> which is not the same as the command run during the build
<xnox> vorlon, which is ~= run the test-suite, and it's trivial to run that command locally.
<xnox> and running the autodep8 generated command locally, passes everything.
<vorlon> TestPathHandler#test_handler_boots
<vorlon> I see the problem
<vorlon> this is an anagram of 'boost'
<vorlon> all is explained
<xnox> vorlon, i notice that there is "CI" mode in test harness that we are not using.
<xnox> specifically it appears to enable autoretry and timeout of the tests.
<xnox> patching things to take AUTOPKGTEST_TMP into account.
-queuebot:#ubuntu-release- Unapproved: probert (disco-proposed/universe) [0.0.14.2build1 => 0.0.15] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted probert [source] (disco-proposed) [0.0.15]
-queuebot:#ubuntu-release- Unapproved: lubuntu-default-settings (disco-proposed/universe) [19.04.1 => 19.04.2] (lubuntu)
#ubuntu-release 2019-04-11
-queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (disco-proposed/main) [18 => 19.2] (core)
<powersj> vorlon, if you are around can you poke ^
<vorlon> sure
<powersj> thank you
-queuebot:#ubuntu-release- Unapproved: calamares (disco-proposed/universe) [3.2.4-0ubuntu1 => 3.2.4-0ubuntu2] (lubuntu)
<tsimonq2> software-properties, lubuntu-default-settings, calamares, and calamares-settings-ubuntu should be the last non-RC Lubuntu updates this cycle. It would be appreciated if these could be processed prior to final freeze.
-queuebot:#ubuntu-release- Unapproved: calamares-settings-ubuntu (disco-proposed/universe) [1:19.04.3 => 1:19.04.4] (lubuntu)
<tsimonq2> (Well, RC-critical in the Final Freeze sense. I still think all are important to get in this cycle.)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-advantage-tools [source] (disco-proposed) [19.2]
-queuebot:#ubuntu-release- Unapproved: cups-filters (disco-proposed/main) [1.22.4-1 => 1.22.5-1] (desktop-core, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: lxml (disco-proposed/main) [4.3.2-1 => 4.3.3-1] (ubuntu-desktop, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: libabigail (disco-proposed/universe) [1.5-1 => 1.6-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libabigail [sync] (disco-proposed) [1.6-1]
-queuebot:#ubuntu-release- Unapproved: libosinfo (disco-proposed/universe) [1.4.0-0ubuntu1 => 1.4.0-0ubuntu2] (desktop-extra, ubuntugnome)
<acheronuk> Kubuntu livefs fails to build today
<acheronuk> W: Failure while configuring base packages.  This will be re-attempted up to five times.
<acheronuk> W: See /build/chroot/debootstrap/debootstrap.log for details (possibly the package python3-nacl is at fault)
<acheronuk> and, yes. a local debootstrap of disco fails this morning on the same error :/
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [4.15.0-1030.32] (kernel)
<infinity> acheronuk: That would be ubuntu-advantage-tools growing a bunch of new deps. :/
<acheronuk> infinity: yeah, I just found that via python3-pymacaroons
<acheronuk> and looking what migrated in the small hours
<infinity> vorlon: What happened to the "ubuntu-advantage-tools can be in minimal, as long as it doesn't pull more things into minimal" plan?  Was this change a week before release okayed?
<infinity> ahasenack: ^
<infinity> Ahh, and found the FFe bug.
<infinity> Gross.
<infinity> acheronuk: Fixing overrides to fix debootstrap, I guess.
<Ukikie> It'd be far better if this could be downgraded to recommends of minimal.
<infinity> How would that be useful?
<infinity> It'd still be on all installations by default, and I can't imagine any end user is so upset by it that they'll tear it out.
<infinity> It's not large or intrusive.
<infinity> (My whining about increasing the size of minimal is just that *any* size increase to minimal should be talked about, as the bloat creepy in a few bytes at a time)
<infinity> s/creepy/creeps/
<Ukikie> s/far/slightly/  Though yes you certainly have a point about it pulling it a bit more. :/
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [source] (disco-proposed) [1.2.5-1ubuntu1]
<acheronuk> infinity: I assume final freeze will approx 9pm UTC as usual? (give or take)
<infinity> acheronuk: Yep.
-queuebot:#ubuntu-release- Unapproved: accepted gnome-terminal [source] (disco-proposed) [3.32.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted vte2.91 [source] (disco-proposed) [0.56.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-appindicator [sync] (disco-proposed) [28-1]
-queuebot:#ubuntu-release- Unapproved: accepted libsoup2.4 [sync] (disco-proposed) [2.66.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted gobject-introspection [sync] (disco-proposed) [1.60.1-1]
-queuebot:#ubuntu-release- Unapproved: fwupd (disco-proposed/main) [1.2.5-1 => 1.2.5-1ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: fwupd (disco-proposed/main) [1.2.5-1ubuntu1 => 1.2.5-1ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: fwupd (disco-proposed/main) [1.2.5-1ubuntu1 => 1.2.5-1ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted calamares-settings-ubuntu [source] (disco-proposed) [1:19.04.4]
-queuebot:#ubuntu-release- Unapproved: accepted console-setup [source] (disco-proposed) [1.178ubuntu12]
-queuebot:#ubuntu-release- Unapproved: accepted emacs [source] (disco-proposed) [1:26.1+1-3.2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted calamares [source] (disco-proposed) [3.2.4-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted librsvg [source] (disco-proposed) [2.44.10-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted cups-filters [sync] (disco-proposed) [1.22.5-1]
-queuebot:#ubuntu-release- Unapproved: fwupd (disco-proposed/main) [1.2.5-1ubuntu1 => 1.2.5-1ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [amd64] (disco-proposed) [1.2.5-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [armhf] (disco-proposed) [1.2.5-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [arm64] (disco-proposed) [1.2.5-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [i386] (disco-proposed) [1.2.5-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gvfs (disco-proposed/main) [1.40.0-1 => 1.40.1-1] (desktop-core) (sync)
-queuebot:#ubuntu-release- New: rejected linux-restricted-modules [source] (disco-proposed) [5.0.0-8.9]
-queuebot:#ubuntu-release- Unapproved: pcsc-cyberjack (disco-proposed/universe) [3.99.5final.sp09-1.1ubuntu1 => 3.99.5final.sp09-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pcsc-cyberjack [sync] (disco-proposed) [3.99.5final.sp09-2]
-queuebot:#ubuntu-release- Unapproved: deja-dup (disco-proposed/main) [38.3-1 => 38.4-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: lammps (disco-proposed/universe) [0~20181211.gitad1b1897d+dfsg1-1 => 0~20181211.gitad1b1897d+dfsg1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: pcp (disco-proposed/universe) [4.3.0-1build1 => 4.3.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted lammps [sync] (disco-proposed) [0~20181211.gitad1b1897d+dfsg1-2]
-queuebot:#ubuntu-release- Unapproved: accepted pcp [sync] (disco-proposed) [4.3.1-1]
-queuebot:#ubuntu-release- Unapproved: graphicsmagick (disco-proposed/universe) [1.4~hg15916-1 => 1.4~hg15916-2] (ubuntustudio) (sync)
-queuebot:#ubuntu-release- Unapproved: graphviz (disco-proposed/universe) [2.40.1-5build2 => 2.40.1-6] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: leveldb (disco-proposed/main) [1.20-2 => 1.20-2.1] (ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: libbpp-core (disco-proposed/universe) [2.4.1-2 => 2.4.1-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libbpp-core [sync] (disco-proposed) [2.4.1-3]
-queuebot:#ubuntu-release- Unapproved: leveldb (disco-proposed/main) [1.20-2 => 1.20-2.1] (ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: lemonldap-ng (disco-proposed/universe) [2.0.2+ds-5 => 2.0.2+ds-6] (no packageset) (sync)
<LocutusOfBorg> any AA, I think we should do the leveldb renaming...
-queuebot:#ubuntu-release- Unapproved: weston (disco-proposed/universe) [5.0.0-2 => 5.0.0-3] (xorg) (sync)
-queuebot:#ubuntu-release- Unapproved: x2godesktopsharing (disco-proposed/universe) [3.2.0.0-1 => 3.2.0.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: xml-core (disco-proposed/main) [0.18 => 0.18+nmu1] (ubuntu-desktop, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: xnee (disco-proposed/universe) [3.19-2 => 3.19-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: workrave (disco-proposed/universe) [1.10.23-2 => 1.10.23-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: xmms2 (disco-proposed/universe) [0.8+dfsg-18.1build7 => 0.8+dfsg-18.2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: x2goserver (disco-proposed/universe) [4.1.0.3-3 => 4.1.0.3-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-input-libinput (disco-proposed/main) [0.28.2-1 => 0.28.2-2] (desktop-core) (sync)
<LocutusOfBorg> bugs.debian.org/877773
-queuebot:#ubuntu-release- Unapproved: accepted lemonldap-ng [sync] (disco-proposed) [2.0.2+ds-6]
-queuebot:#ubuntu-release- Unapproved: accepted x2godesktopsharing [sync] (disco-proposed) [3.2.0.0-2]
-queuebot:#ubuntu-release- Unapproved: accepted xnee [sync] (disco-proposed) [3.19-3]
-queuebot:#ubuntu-release- Unapproved: accepted workrave [sync] (disco-proposed) [1.10.23-5]
-queuebot:#ubuntu-release- Unapproved: accepted x2goserver [sync] (disco-proposed) [4.1.0.3-4]
-queuebot:#ubuntu-release- Unapproved: accepted xmms2 [sync] (disco-proposed) [0.8+dfsg-18.2]
-queuebot:#ubuntu-release- Unapproved: mesa (disco-proposed/main) [19.0.1-1ubuntu2 => 19.0.2-1ubuntu1] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: intel-media-driver (disco-proposed/universe) [18.4.0+dfsg1-1ubuntu1 => 18.4.1+dfsg1-2ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: python-reportlab (disco-proposed/main) [3.5.13-1 => 3.5.18-1] (desktop-core) (sync)
<jibel> sil2100, today's ubuntu desktop build failed in debootstrap. Is someone looking into it?
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1030.32~16.04.1] (kernel)
<sil2100> jibel: infinity was looking into that (you can check the details in the backlog here on this channel)
<jibel> k
<jibel> thanks
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1030.32~16.04.1]
-queuebot:#ubuntu-release- Unapproved: gtk+3.0 (disco-proposed/main) [3.24.7-1ubuntu1 => 3.24.8-1ubuntu1] (ubuntu-desktop)
<rbalint> ddstreet, thanks for the note,  re lxd
-queuebot:#ubuntu-release- Unapproved: accepted casper [source] (disco-proposed) [1.403]
-queuebot:#ubuntu-release- Unapproved: accepted graphicsmagick [sync] (disco-proposed) [1.4~hg15916-2]
-queuebot:#ubuntu-release- Unapproved: accepted gtk+3.0 [source] (disco-proposed) [3.24.8-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted intel-media-driver [source] (disco-proposed) [18.4.1+dfsg1-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted lubuntu-default-settings [source] (disco-proposed) [19.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted lxml [sync] (disco-proposed) [4.3.3-1]
-queuebot:#ubuntu-release- Unapproved: accepted python-reportlab [sync] (disco-proposed) [3.5.18-1]
-queuebot:#ubuntu-release- Unapproved: accepted weston [sync] (disco-proposed) [5.0.0-3]
-queuebot:#ubuntu-release- Unapproved: accepted deja-dup [sync] (disco-proposed) [38.4-1]
-queuebot:#ubuntu-release- Unapproved: accepted gvfs [sync] (disco-proposed) [1.40.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (disco-proposed) [0.97.10]
-queuebot:#ubuntu-release- Unapproved: accepted graphviz [sync] (disco-proposed) [2.40.1-6]
-queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (disco-proposed) [19.0.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libosinfo [source] (disco-proposed) [1.4.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-input-libinput [sync] (disco-proposed) [0.28.2-2]
-queuebot:#ubuntu-release- New binary: intel-media-driver [i386] (disco-proposed/universe) [18.4.1+dfsg1-2ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: intel-media-driver [amd64] (disco-proposed/universe) [18.4.1+dfsg1-2ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New source: linux-restricted-modules (disco-proposed/primary) [5.0.0-10.11]
-queuebot:#ubuntu-release- Unapproved: meson (bionic-proposed/universe) [0.45.1-2 => 0.45.1-2ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: openjdk-lts (bionic-proposed/main) [11.0.2+9-3ubuntu1~18.04.2 => 11.0.2+9-3ubuntu1~18.04.3] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: openjdk-lts (cosmic-proposed/main) [11.0.2+9-3ubuntu1~18.10.2 => 11.0.2+9-3ubuntu1~18.10.3] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-lts [sync] (bionic-proposed) [11.0.2+9-3ubuntu1~18.04.3]
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-lts [sync] (cosmic-proposed) [11.0.2+9-3ubuntu1~18.10.3]
<ahasenack> acheronuk: what was the debootstrap failure?
<acheronuk> ahasenack: W: Failure while configuring base packages.  This will be re-attempted up to five times.
<acheronuk> W: See /build/chroot/debootstrap/debootstrap.log for details (possibly the package python3-nacl is at fault)
<ahasenack> do you have said debootstrap.log?
<ahasenack> I just ran a "debootstrap disco" here and it finished, including that package
<ahasenack> I'm looking at https://launchpadlibrarian.net/418797037/buildlog_ubuntu_disco_amd64_ubuntu-server-live_BUILDING.txt.gz now
<acheronuk> ahasenack: http://paste.ubuntu.com/p/5yx7m8WgC6/
<ahasenack> dpkg: dependency problems prevent configuration of python3-nacl:
<ahasenack>  python3-nacl depends on python3-cffi-backend-api-min (<= 9729); however:
<ahasenack>   Package python3-cffi-backend-api-min is not installed.
<ahasenack>  python3-nacl depends on python3-cffi-backend-api-max (>= 9729); however:
<ahasenack>   Package python3-cffi-backend-api-max is not installed.
 * ahasenack fires up a disco container
<acheronuk> ahasenack: I just tried a new debootstrap locally, and it completed
<ahasenack> yeah, and I'm checking python3-cffi-backend, it provides python3-cffi-backend-api-max and python3-cffi-backend-api-min
<ahasenack> at least now
<acheronuk> either someone fixed something, or archive/migration churn smoothed something out perhaps
<acheronuk> big test is retrying my ISO fail.....
 * ahasenack checks publishing history
<ahasenack> python-cffi didn't change recently (https://launchpad.net/ubuntu/+source/python-cffi/+publishinghistory)
<ahasenack> acheronuk: are you kicking one now?
<acheronuk> ahasenack: trying. though the qa page is stuck on a (rebuilding) status from last fail, so not sure if it is registering my request
<acheronuk> Kubuntu ^
 * acheronuk refreshes log page
<acheronuk> sil2100: do you know if that ^^ just taking a long time to respond, or ignoring me!
<acheronuk> no new build appearing
<ahasenack> what is the url, if it's something a non team member can see? (read/only)
<acheronuk> ahasenack: cd logs: http://people.canonical.com/~ubuntu-archive/cd-build-logs/kubuntu/disco/
<ahasenack> and where do you trigger it, in lp?
<acheronuk> a new build should be daily-live-20190411.2.log	
<acheronuk> ahasenack: http://iso.qa.ubuntu.com/qatracker/milestones/398/builds
<acheronuk> tick box, and request rebuild from menus at bottom
<ahasenack> it says "Kubuntu Desktop amd64 (re-building)", that's what you see?
<acheronuk> if you are in a team who can
<acheronuk> yep. but it said that before I tried
<acheronuk> status looks 'stuck'
<ahasenack> k
<acheronuk> looks like its not going to play ball
 * acheronuk wanders off for now
<mitya57> infinity: this should fix kpmcore on s390x: https://github.com/thiagomacieira/tinycbor/pull/1
<gitbot> thiagomacieira issue (Pull request) 1 in tinycbor "Parser: fix reading it->extra on big endian when bytesNeeded == 1" [Open]
<mitya57> I will wait until tomorrow to let upstream review it, and then make an upload. (tinycbor is bundled into qtbase currently)
<xnox> apw, funny story, looks like scalingstack VMs can boot fine with the azure kernel. Fixing systemd test suites to work with azure kernel.
<infinity> mitya57: By tomorow, do you mean today? (final feeze!) :)
 * xnox is preparing a systemd upload with morrrre bugfixes. like journalctl broken, udevadm broken, machinectl broken.
<mitya57> infinity: ok, today is also possible, though I will have to upload it directly to Ubuntu rather than to Debian first.
<mitya57> But first I will check in a PPA that kpmcore really builds on all architectures with this fix.
<apw> xnox, !
-queuebot:#ubuntu-release- Unapproved: openexr (disco-proposed/main) [2.2.1-4build1 => 2.2.1-4.1] (ubuntu-desktop) (sync)
<ahasenack> infinity: hi, did you fix something regarding the iso build? wrt "<infinity> 07:48:05> acheronuk: Fixing overrides to fix debootstrap, I guess."
<infinity> ahasenack: Yes.
<ahasenack> what caused the failure? From http://paste.ubuntu.com/p/5yx7m8WgC6/ I can see that somehow python3-cffi-backend wasn't installable or available
<infinity> Priorities needed updating when you pulled a bunch of stuff into important.
<infinity> (debootstrap installs based on priority)
<ahasenack> where did you fix it?
<infinity> Archive overrides.
<ahasenack> something I could have checked before?
<infinity> No, but some warning before pulling a bunch more packages into minimal/important would have been nice. :P
<infinity> But I'm trying not to be too bitter about that, it's before 8am, and I'm bitter enough about just being awake.
<ahasenack> sorry about that
<ahasenack> and good morning
 * ahasenack on his second coffee cup
<ahasenack> and thanks for fixing it
-queuebot:#ubuntu-release- Unapproved: accepted openexr [sync] (disco-proposed) [2.2.1-4.1]
-queuebot:#ubuntu-release- Unapproved: apport (disco-proposed/main) [2.20.10-0ubuntu26 => 2.20.10-0ubuntu27] (core)
-queuebot:#ubuntu-release- Unapproved: python-opcua (disco-proposed/universe) [0.98.6-1 => 0.98.6-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-opcua [source] (disco-proposed) [0.98.6-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: systemd (disco-proposed/main) [240-6ubuntu4 => 240-6ubuntu5] (core)
<infinity> xnox: Maybe it would be easier just to upload a systemd containing upstart or sysvinit.
<xnox> infinity, hahahhahahhahahahhahaha
<infinity> xnox: Dude, that's an eye-bleeding number of cherrypicks to get reviewed on the last day.  Well job.
<xnox> infinity, they all came from systemd-stable tree, and i only picked the non-crazy ones. and we did have ~53 cherrypicks from stable already.
<xnox> infinity, and well there are a few really bad regressions, and others are nice to haves (documentation updates).
<xnox> like users in adm group not able to $ journalctl
<xnox> is quite bad
<infinity> xnox: Oh, I'm not questioning the provenance, nor if it's appropriate, just mentioning that it's unreviewable, so I have to take a lot on faith here. :P
<infinity> xnox: Also, wow, these people could do with a strict commit message policy.
<infinity> +Subject: basic/prioq: add prioq_peek_item()
<infinity> (The entire commit message)
<infinity> Also, it's wrong.
<infinity> Amazingly.
-queuebot:#ubuntu-release- Unapproved: gnome-shell (disco-proposed/main) [3.32.0-1ubuntu1 => 3.32.0+git20190410-1ubuntu1] (desktop-core, desktop-extra, mozilla) (sync)
-queuebot:#ubuntu-release- Unapproved: mutter (disco-proposed/main) [3.32.0-1ubuntu2 => 3.32.0+git20190410-1ubuntu1] (desktop-core, desktop-extra) (sync)
<infinity> Aaaand then there's the infamous 1-line change with 50 lines of explanation, which I now feel I need to spend the next half hour researching to make sure I come to the same conclusion.
-queuebot:#ubuntu-release- Unapproved: gedit (cosmic-proposed/main) [3.30.2-0ubuntu0.18.10.2 => 3.30.2-0ubuntu0.18.10.3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gedit (bionic-proposed/main) [3.28.1-1ubuntu1.1 => 3.28.1-1ubuntu1.2] (ubuntu-desktop)
<infinity> xnox: Is there somewhere I can rank systemd committers, maybe with a goal of voting some off the island?
-queuebot:#ubuntu-release- Unapproved: fwupd-signed (disco-proposed/main) [1.5 => 1.6] (desktop-core)
<xnox> infinity, well, there is a tonne of contributors and very little committers. Which stuff in particular are you unhappy about? I can lookup who wrote, who reviewed, who cherrypicked into stable.
<infinity> xnox: Oh, no code quality complaints (yet), but huge commit quality complaints from some. :P
<xnox> out of https://github.com/systemd/systemd/graphs/contributors i personally like keszybz yuwata and evverx the best
<infinity> xnox: And Aaron Plattner at nvidia gets a gold star for actually writing informative and useful commit messages.
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (cosmic-proposed) [1:20190409.1-0ubuntu0.18.10.1]
<infinity> A second gold star because one of these fixes was clearly a drive-by "oh, and I noticed in passing!" fix while he was fixing something else 10 lines away.
<xnox> infinity, that puzzles me to. there do all the time " please split these three one-liners into one-liner per commit" and then "we have this 10k pull request of 10+ commits, let's squash that all into one"
<infinity> (Pretty obvious because the context for fix A shows up in fix B)
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (bionic-proposed) [1:20190409.1-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20190409.1-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (trusty-proposed) [1:20190409.1-0ubuntu0.14.04.1]
<infinity> +Subject: core/mount: move static function earlier in file
<infinity> +
<infinity> +No functional change.
<infinity> ^-- y tho?
<xnox> because the next patch, depends on it.
<xnox> cause it's cherrypicks from master
<xnox> and probably something starts using this function.
<infinity> xnox: Sure, I don't mean why did you CP it, I mean HAVE A COMMIT MESSAGE THAT EXPLAINS WHY YOU'RE COMMITTING A NO-OP.
<xnox> cause they do obscene amount of refactors =)
<infinity> Cause it's clearly not a no-op, in larger context.
 * xnox ponders to record infinity doing a standup code commit reviews.
<xnox> with evan doing the voice-over of the commiters commit messages, to make it more of a dialogue.
<infinity> So, really, you just want to see me punch Evan?
<sergiusens> Laney: hey, I have been meaning to ask, I have been getting "SKIP Test requires machine-level isolation but testbed does not provide that" for a while on armhf and IIRC the test beds used to be able to do this. Any pointers?
<Laney> sergiusens: nein, they've always been this way
<sergiusens> Laney: ah, then I recall incorrectly. Are there plans to support machine-level-isolation?
<infinity> sergiusens: armhf has always run in lxc/lxd, which doesn't provide machine isolation.
-queuebot:#ubuntu-release- Unapproved: lxd (disco-proposed/main) [1:0.6 => 1:0.7] (edubuntu, ubuntu-server)
<infinity> sergiusens: "Plans" might be the wrong word.  We've wanted nova/kvm-based armhf runners basically since day 1, and we're vaguely aware of the work required to make that happen, but I don't think anyone's taken it to the next step of "making a plan", nevermind "sizing/costing" or "implementing".
<infinity> sergiusens: (To be honest, I think it's not unlikely that some people involved are just hoping armhf dies and we can stop caring)
<xnox> infinity, sergiusens - there was progress on getting that done. We do build armhf cloud images with grub-uefi to achieve nova-armhf but last time we checked there was bad interaction of patch series. meaning it didn't boot yet.
<stgraber> rbalint: uploaded your fix to both disco and cosmic
<xnox> infinity, sergiusens - i think next steps is to recheck how good/bad disco grub is, and basically try harder to get disco armhf images.
<rbalint> stgraber, thanks sorry for missing those, i focused on postinst too much
-queuebot:#ubuntu-release- Unapproved: lxd (cosmic-proposed/main) [1:0.4.1 => 1:0.4.2] (edubuntu, ubuntu-server)
<infinity> xnox: Well, even if we can get a working boot protocol (which, indeed, was many years in the making; many more than it should have been), then there's the question of resources.  nova instances are much fatter than lxd/lxc.  The way arm64/armhf queues drain today, I don't think we can add any more strain to that without getting a lot more hardware first.
<xnox> and that as well.
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (disco-proposed) [1:0.7]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd-signed [source] (disco-proposed) [1.6]
<infinity> +Subject: curl-util: fix use after free
<infinity> +-        *ret = c;
<infinity> ++        *ret = TAKE_PTR(c);
<sergiusens> thanks for the answers
<infinity> Thanks for all the context, useless commit message 37.
<infinity> xnox: Is TAKE_PTR some magic macro that still works if its argument doesn't exist, or did they just kick the use-after-free can three feet down the road and call it "fixed"?
<ddstreet> infinity so what's the deal with mariadb-10.1 on cosmic?  it looks like all the versions except cosmic-release have been deleted?  I don't care about mariadb-10.1 itself, but its autopkgtests still are run and fail every time...if we don't want to touch it on cosmic, can a AA please hint its cosmic tests as ignored?
<ddstreet> or, i can upload a version that fixes the autopkgtests (for bionic and cosmic...bionic's tests fail too, but are hinted ignored)
<xnox> infinity, it sets c to NULL, and whatever c pointed to is returned.
<xnox> infinity, let me read that code with more context.
<infinity> ddstreet: I don't see why we wouldn't want to touch it on cosmic.  There was a bionic security update that surely also applies to comsic?
<xnox> infinity, TAKE_PTR is defined in src/basic/alloc-util.h
<infinity> (And both could use autopkgtest fixes, if such fixes exist)
<ddstreet> infinity yeah i don't know why the cosmic newer releases aren't available to install - i assumed there was some hidden reason
<ddstreet> i'll fix the b/c autopkgtests and upload to both b/c
<xnox> infinity, to be read in conjuction with _ceanup_(curl_easy_cleanupp) which tries to free(c) but given that we moved the pointer to **ret it would be wiped under the feet of the person.
<infinity> ddstreet: What "cosmic newer releases"?
<ddstreet> infinity well rmadison shows no mariadb-10.1 release for cosmic except what's in cosmic-release
<xnox> infinity, hence TAKE_PTR is correct here, as we reset c to NULL on succesful returning c vai **ret.
<infinity> ddstreet: Yes...
<ddstreet> but, there are newer cosmic builds
<xnox> in all other error cases, we do have _cleanup_(curl_easy_cleanupp) to free the stuct.
<ddstreet> infinity e.g. https://launchpad.net/ubuntu/cosmic/+source/mariadb-10.1
<infinity> ddstreet: Pre-dating cosmic release, yes.  They never made it through proposed-migration, and were moved to disco.
<xnox> infinity, _cleanup_ & TAKE_PTR are awesome magics =)
<ddstreet> latest is 1:10.1.35-1ubuntu1
<infinity> ddstreet: Reading the delete messages helps.
<ddstreet> i must have missed it
<ddstreet> where is that?
<infinity> https://launchpad.net/ubuntu/+source/mariadb-10.1/+publishinghistory
<infinity> You can see it moving from cosmic-proposed to disco-proposed when disco opens.  And then deleted from disco when 10.3 replaces it.
<ddstreet> moved to disco-proposed?
<ddstreet> ah
<ddstreet> so that removed it from cosmic too eh
<infinity> ... no?
<infinity> Moving it from cosmic-proposed to disco-proposed removed it from cosmic-proposed.  The keyword being "moved".
<xnox> ddstreet, we have 4 suites per series. just because something is removed from -proposed doesn't affect what's published in release.
<infinity> Anything in devel-proposed gets moved to next-devel-proposed when we release.  We don't assume all the junk in there is magically an SRU.
<ddstreet> ok, so there was never any mariadb-10.1 in cosmic-updates ever, only in -proposed
<infinity> Cause it's not.
<ddstreet> ok got it, i'll upload to fix the test problesm then
<ddstreet> first time i've seen a pkg not make it out of -proposed before the release drops
<ddstreet> thnx!
<infinity> ddstreet: There are 269 in disco-proposed right now, the vast majority of which will not migrate before release.
<Laney> bdmurray: Bit dubious about this apport. That 'pass' doesn't actually do anything AFAIK. Shouldn't you move the code to bail out inside an "if e.errno != errno.ENOENT:" or try/catch AttributeError instead?
<bdmurray> Laney: in a meeting at the moment, I'll look shortly
<Laney> nod
-queuebot:#ubuntu-release- Unapproved: ca-certificates-java (disco-proposed/main) [20180516ubuntu1 => 20190405ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [sync] (disco-proposed) [3.32.0+git20190410-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mutter [sync] (disco-proposed) [3.32.0+git20190410-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: tzsetup (disco-proposed/main) [1:0.94ubuntu1 => 1:0.94ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: rejected ca-certificates-java [source] (disco-proposed) [20190405ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ca-certificates-java (disco-proposed/main) [20180516ubuntu1 => 20190405ubuntu1] (core)
<tdaitx> Laney: sorry for the ca-certificate-java wrong signature, I didn't pay attention that dch -r didn't update correctly, correct upload on the way
<Laney> :D
<vorlon> infinity: yeah, the ua implementation now definitely requires more bits, it's not great but I don't think there are other options (and the overall plan for the client has been in discussion for a long time before freeze, and this is trusty SRU material as well...)
<vorlon> infinity: you didn't have any concerns about the specifics of what priority-mismatches showed?
<wxl> infinity: As a member of both the SRU and Release team I'd like your opinion on two options. I've found usb-creator-kde is essentially non-functional. We have a patch. But it affects releases back to Xenial. Question is: 0 day SRU for all of them or release for Disco and SRU the others later. bug 1629715
<ubot5`> bug 1629715 in usb-creator (Ubuntu) "usb-creator-kde shows the install popup after a few seconds of launching without any input" [High,Triaged] https://launchpad.net/bugs/1629715
<infinity> vorlon: I mean, I have no reason to hate those 5 packages in specific, but adding another MB of random junk to the debootstrap set annoys me on principle.
<infinity> vorlon: (And I still feel like u-a-t should be in standard, not minimal)
 * vorlon nods
<infinity> I know why it was put in minimal, but I don't generally agree with it. :P
 * vorlon nods
<mvo> vorlon: hey - quick question about snapd 2.38 in xenial. it does not build on powerpc anymore because we have no golang-1.10 for powerpc. iirc we talked about this and agreed that its ok to not support powerpc on our side in the package (we also have no core snap for powerpc so nothing really changes if we don't update the package). but http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#snapd now tel
<mvo> ls me no ADT tests are running - do we need to hint something somewhere to get ADT back :) ?
<mvo> vorlon: if you prefer that I put this into an email please say so, thats fine too of course
-queuebot:#ubuntu-release- Unapproved: apport (disco-proposed/main) [2.20.10-0ubuntu26 => 2.20.10-0ubuntu27] (core)
<bdmurray> Laney: ^ sorted
<vorlon> mvo: checking
<vorlon> mvo: I think if I remove the powerpc binaries from xenial it should be happy
<vorlon> mvo: done; watch this space
-queuebot:#ubuntu-release- Unapproved: cacti (disco-proposed/universe) [1.2.2+ds1-1 => 1.2.2+ds1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- New sync: gpustat (disco-proposed/primary) [0.5.0-2]
-queuebot:#ubuntu-release- Unapproved: accepted cacti [sync] (disco-proposed) [1.2.2+ds1-2]
<mvo> vorlon: thank you!
-queuebot:#ubuntu-release- Unapproved: gnome-music (disco-proposed/universe) [3.32.0-1 => 3.32.1-1] (desktop-extra, ubuntugnome) (sync)
<tsimonq2> This is (for real) the last Calamares upload unless we find something broke.
<tsimonq2> Memory management-related patches and ensuring a critical configuration value is set.
-queuebot:#ubuntu-release- Unapproved: calamares (disco-proposed/universe) [3.2.4-0ubuntu2 => 3.2.4-0ubuntu3] (lubuntu)
<mvo> vorlon: hm, update_excuses now tells me: "missing build on powerpc: snapd (from 2.0.2)" - is there more that needs to be done to unblock this?
<tsimonq2> Oh, and software-properties is fixing a simple packaging mistake.
<tsimonq2> That's it for software-properties I think.
-queuebot:#ubuntu-release- Unapproved: software-properties (disco-proposed/main) [0.97.10 => 0.97.11] (core)
<vorlon> mvo: ah yes, I also need to do a powerpc-only removal of the arch: all binaries <eyeroll>
<mvo> vorlon: no worries, thank you!
<vorlon> Wimpress: hi, the ubuntu-mate disco ISOs have been reported as oversized for a while now. a) who should be getting emails about this on behalf of the mate team, besides just the cdimage folks? b) do you have any expectation of reducing the size for disco release, or do you want to bump the limit?
<vorlon> tsimonq2: ^^
<tsimonq2> vorlon: Kick the can to 2 GB please.
<vorlon> tsimonq2: that's where we are already
<vorlon> -rw-rw-r-- 1 cdimage cdimage 2189230080 Apr 10 03:06 disco-desktop-amd64.iso
<tsimonq2> That was at 1.5 GB the other day...
<tsimonq2> That's a bug.
<vorlon> tsimonq2: uh no, it's been reporting as oversized for weeks
<infinity> It was 2G last release.
<vorlon> -rw-rw-r-- 2 cdimage cdimage 2181038080 Mar 26 22:55 ubuntu-mate/releases/disco/beta/ubuntu-mate-19.04-beta-desktop-amd64.iso
<infinity> Are you maybe thinking he's talking about lubuntu because he pinged you for some reason? :P
<tsimonq2> Ohh.
<vorlon> I pinged him because he's a member of ubuntu-mate-dev :)
<infinity> Aren't we all?
<vorlon> infinity: not directly like him ;)
<vorlon> yeah this is ubuntu-mate, everyone else is fine at this point
<infinity> 2G sticks are still a wildly common size for people to pick up in random junk and schwag piles, would be a shame to oversize that if it can be avoided.
<tsimonq2> If I'm wearing that hat, let me talk to the boss then. :P
<infinity> Although, that said, the last time my dad got a bulk bag of junk USB sticks, the smallest was 8G.
<infinity> So maybe it's time to goldfish all our ISOs!
 * infinity goes to find 6G worth of stuff.
<tsimonq2> Let's do a full archive d-i image. :P
<vorlon> let's ship uncompressed squashfs for faster boot
<Wimpress> vorlon I am aware. I did recently reduced the isos by 300MB.
<infinity> Pretty sure that would be slower, not faster.
<vorlon> infinity: <furious handwave>
<infinity> vorlon: <furiosa hookwave>
<Wimpress> I've got some options to further reduce the iso size, but it's too late to do that this cycle.
<vorlon> infinity: let's ship 3 copies of the squashfs as a raid5 for better data integrity
<infinity> I'm okay with getting the oversize warning when publishing disco if your goal is to shrink again for EE.
<Wimpress> But on my task list for 19.10. Something I'll do very early in the cycle.
<infinity> But, out of interest, what other ideas did you have, and why can't we just bang 'em out right now? :P
<vorlon> missing build on powerpc: snapd (from 2.0.2)
<vorlon> mvo: ^^ lol I can't win
<vorlon> mvo: I'll just add a force hint now
<Wimpress> Switching from fcitx to ibus to reduce the many different toolkits seeded in the iso is one.
<mvo> vorlon: weee, thanks again!
<Wimpress> Switching everything the python3 is a other. We have py2 and py3 components now.
<Wimpress> I need MATE Desktop 1.22 to eradicate py2. I only committed those packages to Debian Salsa lastnight.
<vorlon> Wimpress: does fcitx depend on the "wrong" toolkit, or does it just have overly-aggressive recommends: that pull in multiple?
<vorlon> because the latter is definitely a bug in fcitx and I think would be appropriate to fix before release
<Wimpress> The later.
<xnox> vorlon, infinity - speaking of our squashfs, why does booting any livefs squashfs has kernel complaining about unable to read metadata something rather.
<xnox> is that because our iso9660 is a bad substrate to carry squashfs files?
<vorlon> No results found for "unable to read metadata something rather".
<vorlon> Results for unable to read metadata something rather (without quotes):
<vorlon> Search Results
<vorlon> Web results
<Wimpress> I don't think the fcitx Recommeds is a bug.
<vorlon> Wimpress: I do.
<xnox> vorlon, i will file a bug report with that tile in a moment, such that google will find it!
<vorlon> xnox: good show
<Wimpress> It is adding yet another toolkit to the image.
<Wimpress> Switching to ibus I can prevent that.
<vorlon> it's a wrong use of Recommends to pull in toolkits that otherwise wouldn't be present, for an input method
<Wimpress> It has an Indicator which is where the toolkit gets pulled in.
<vorlon> ah, and that indicator is only implemented in the one toolkit?
<xnox> vorlon, bug #1824407
<ubot5`> bug 1824407 in linux (Ubuntu) " why does booting any livefs squashfs has kernel complaining about unable to read metadata something rather" [Undecided,New] https://launchpad.net/bugs/1824407
<infinity> ...
<vorlon> Wimpress: but 'fcitx-frontend-all' is on ubuntu-mate-live, and that piece definitely looks wrong
<xnox> shit like
<xnox> Apr 11 18:32:52 ubuntu-server kernel: SQUASHFS error: squashfs_read_data failed to read block 0x6ff3660032757063
<xnox> Apr 11 18:32:52 ubuntu-server kernel: SQUASHFS error: Unable to read metadata cache entry [6ff3660032757063]
<tjaalton> I sent an email to ubuntu-release@ asking for a reviewer to get intel-compute-runtime etc in disco before release, if possible.. any takers?-)
<vorlon> Recommends: fcitx-frontend-gtk2, fcitx-frontend-gtk3, fcitx-frontend-qt4, fcitx-frontend-qt5
<vorlon> yeah no die
 * cjwatson has flashbacks to the dapper release sprint
<vorlon> a) if the package is called *all*, why is it a Recommends instead of a Depends
<vorlon> b) seriously who wants this
<vorlon> Package: fcitx
<vorlon> Recommends: [...] fcitx-frontend-all | fcitx-frontend-fbterm
<infinity> Seeding fcitx looks like a mistake, period.
<infinity> One should seed the config and frontend modules they want.
<vorlon> quite possibly
<cjwatson> surely that should be done with a virtual instead
<infinity> (config and frontend should also have Provides that fcitx can Recommend, but fixing that today seems less fun)
<cjwatson> Package: fcitx / Recommends: fcitx-frontend-whateverisbest | fcitx-frontend
<cjwatson> or something
<cjwatson> -all is just a weird approach
<infinity> cjwatson: Yes, that would be ideal, but I'd also rather do that in Debian first, to avoid upgrade headaches when they take the patch but change the names. :P
<vorlon> Wimpress: ^^ so all of that is fixable before release; we can support you in getting it fixed, but I don't know which of the frontends / configs are the right ones for mate without digging
<cjwatson> yep
<infinity> MATE is still gtk2, no?
<infinity> Or is it 3?
<infinity> I forget.
<infinity> Anyhow, thanks to amazingly consistent package naming, you'd want either fcitx-frontend-gtk2 + fcitx-config-gtk2 or (wait for it) fcitx-frontend-gtk3 + fcitx-config-gtk
<infinity> Because wat.
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-ubuntu-dock (disco-proposed/main) [64ubuntu5 => 64ubuntu6] (ubuntu-desktop) (sync)
<Wimpress> Seeding fcitx in live is (was?) required so when CJK users select their language Ubiquity installs/configures fcitx as the IME. It was the case fcitx was preferred by CJK users. That has changed now.
 * infinity notes that lubuntu, kylin, and kubuntu also seed fcitx.
<Wimpress> More than happy to work on this.
<Wimpress> Ubuntu MATE should only require GTK3 but I "think" the different toolkit versions of fcitx are to facilitate IME compatibility for apps using the different toolkits.
<infinity> Probably.  How many Qt applications do you have installed on your ISO?
<Wimpress> None.
<infinity> There you go.
-queuebot:#ubuntu-release- Unapproved: software-properties (bionic-proposed/main) [0.96.24.32.7 => 0.96.24.32.8] (desktop-core, ubuntu-server)
<Wimpress> For post-install compatibility
<Wimpress> I could make the changes to switch to Ibus now, and drop fcitx.
<Wimpress> It will require I update the seeds, meta packages and ubuntu-mate-settings.
<Wimpress> All things I can do easily and upload.
<infinity> To be fair, for ibus, I only see a gtk2 and gtk3...
<infinity> Actually, I think you're likely wrong.
<infinity> I think the frontends are more tied to desktop than application toolkit.
<infinity> As in, they provide modules for the IM widgets that you'd expect to ship on a gtk2/gtk3/qt4/qt5 desktop.
<infinity> Maybe.
<infinity> Either way.  Paring down fcitx packages or switching entirely seems to drop some unknown quantity of Qt stuff.  And that's likely fine.  But I'd say the fcitx changes would be less likely to cascade on the day of final freeze.
<Wimpress> If the release team are happy for me to make the transition to Ibus at this stage in the cycle, I'm happy to do it.
<infinity> Do you know what that transition entails, if there's actually a "transition" (data migration, etc?), and how to test that it's not broken?
<Wimpress> I don't know how a transistion would work when doing a release upgrade. I'd have to talk with some of the CJK users to learn more.
<infinity> 4a08a5af7f22db8a8791252f3f17e22442a31573 in the Ubuntu seeds seems to be the corresponding commit.
<infinity> And I don't think we did any data migration in Ubuntu, but you could ask Gunnar.
-queuebot:#ubuntu-release- Unapproved: update-notifier (bionic-proposed/main) [3.192.1.5 => 3.192.1.6] (ubuntu-desktop, ubuntu-server)
<Wimpress> Yes, that is my understanding from Gunnar. But there are some Japanese users who I can ask.
<Wimpress> Is migration important for an interim?
<infinity> I mean, it's not important to me at all if I'm told it's not necessary. :P
<Wimpress> If it is possible, can it be done in 19.10 so LTS upgrades for 20.04 are catered for?
<infinity> And if we didn't/don't do any migration in Ubuntu proper (like I said, ask Gunnar?), I certainly won't set a higher bar for flavours.
<tsimonq2> fcitx> Did someone say Qt 4? *finds a hammer*
<infinity> andyrock: It's generally considered good practice to use the same version of automake as the previous uploader (ie: the one from bionic, not the one from xenial) when updating a package that autoreconfiscates to avoid all the noise.
<Wimpress> infinity vorlon I'll double check on migration options. But, are you OK with me making the switch now?
<vorlon> Wimpress: to ibus, or to drop the fcitx alternate toolkits?
<vorlon> Wimpress: if I were you I would be nervous about migrating to ibus so close to release
<infinity> I'm okay with either, if it's testable.  The fcitx problem might require some uploads so that it's insane circular deps don't just pull everything in anyway.
<infinity> (note that literally the only seeded package right now is 'fcitx-bin', and that pulls in the world)
<infinity> Wimpress: I'm also entirely okay with punting this until post-release, and releasing slightly oversized.
<infinity> Wimpress: 2G sticks will be left out for a while, but oh well.
<infinity> Wimpress: My "why can't it be done now" inquiry was an inquiry, not a demand. :)
<Wimpress> infinity, OK. Then I'd rather do this early in 19.10.
<Wimpress> Our QA guys have been testing our isos this week and we're in good shape.
<Wimpress> I'd prefer to not rock the boat right now.
<acheronuk> is anyone able to fix this by release day? http://cdimage.ubuntu.com/kubuntu/releases/disco/beta/
<acheronuk> if not, I might think reverting to the standard ubuntu would look less awful
<acheronuk> lubuntu's is also a bit 'glitched', but not quite so bad
<vorlon> acheronuk: what is it you're asking to have fixed, and who are you asking?
<vorlon> acheronuk: the orange in the header? something else in addition?
<vorlon> ok, a reference to https://assets.ubuntu.com/v1/775cc62b-vanilla-grad-background.png is embedded in the html we generate
<vorlon> that's bad... style
 * vorlon puts on his NCIS shades
-queuebot:#ubuntu-release- Unapproved: curtin (disco-proposed/main) [18.2-19-g36351dea-0ubuntu1 => 18.2-22-g08bf6ff7-0ubuntu1] (ubuntu-desktop, ubuntu-server)
<vorlon> acheronuk: is that the only thing that needs fixing?
<acheronuk> vorlon: mostly the orange header. some of the other formatting has gone odd as well. main page content used to be more like: https://i.imgur.com/7v9DuDv.png
<acheronuk> Simon was going to look at one point....
<tsimonq2> xnox volunteered I think
<tsimonq2> I can look though.
-queuebot:#ubuntu-release- Unapproved: unity-lens-photos (disco-proposed/universe) [1.0+17.10.20170605-0ubuntu3 => 1.0+17.10.20170605-0ubuntu4] (no packageset)
<vorlon> all I ever saw was an MP that reverted all of the HTML changes in an if kubuntu: else: which I nacked
-queuebot:#ubuntu-release- Unapproved: accepted unity-lens-photos [source] (disco-proposed) [1.0+17.10.20170605-0ubuntu4]
<acheronuk> with old header: https://i.imgur.com/x6Bjdg6.png
<xnox> vorlon, i did say, we should have at least min-effort attempt at having vanilla like banner for derivatives, and i did get assets for lubuntu to use.
<acheronuk> vorlon: yeah, that sounds familiar
<vorlon> xnox: I guess even moving this background-image style out of the html and into the css include for Ubuntu would improve
<tsimonq2> +1
<tsimonq2> We'd then mostly drop custom CSS and switch out that background.
<wxl> infinity: not sure you saw my message above about usb-creator-kde, but i'm inclined to do the 0 day SRU. if you feel otherwise, please let me know asap.
<wxl> ^^ vorlon: since you are also SRU/Release Team you might have an opinion on whether or not to do 0 day SRU for xenial-disco on usb-creator versus release in disco and SRU the others. see bug 1629715
<ubot5`> bug 1629715 in usb-creator (Ubuntu Disco) "usb-creator-kde shows the install popup after a few seconds of launching without any input" [High,Triaged] https://launchpad.net/bugs/1629715
-queuebot:#ubuntu-release- Unapproved: qtbase-opensource-src (disco-proposed/universe) [5.12.2+dfsg-4 => 5.12.2+dfsg-4ubuntu1] (kubuntu, qt5)
<mitya57> infinity: â here is the Qt upload. Tested in a PPA and kpmcore builds fine (https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3696/+packages)
<wxl> thanks for that btw mitya57
<xnox> vorlon, stuff in http://cdimage.ubuntu.com/include/ is just there on disk, right? no git repo, no backups?
<mitya57> wxl: Np. Unfortunately because of feature freeze this goes without upstream review, but it passes upstream tests so it should be fine.
<mitya57> s/feature/final/
<xnox> (well i assume there are actually whole machine backups....)
<vorlon> xnox: yup
<wxl> mitya57: fingers crossed :)
<infinity> wxl: The bug's been known for years, apparently, not sure how it's suddenly urgent enough to be worth a discussion.
<infinity> wxl: If you want to SRU it, by all means, fix it whenever, but "0-day" is a bit much.
<wxl> infinity: yeah, i'm kind of shocked, honestly. i never use the darn thing, so..
<wxl> infinity: i mean lubuntu's late to the game on this one.. kubuntu should have picked this up a while back.
<wxl> infinity: that said, i blame acheronuk
<infinity> *smirk*
<infinity> wxl: Anyhow, regular process applies, SRU at will, I just see no reason to expedite or rush anything.
<infinity> "Package that's been broken for years is still broken" isn't really news.
<wxl> infinity: okie dokie. i guess i get a little alarmed when an application does not work *at all* but given the history, you're right: it's probably not that urgent.
<acheronuk> # * (usb-creator-kde) [i386 amd64] # disabled cos it's broken
<wxl> X'D
<acheronuk>     Committer: Jonathan Riddell
<acheronuk>     Date: 2014-11-11 15:58:31 UTC
<infinity> Solid bugfix.
<wxl> X''''''''''''''''''''''''''''''''D
<infinity> Good job Riddell.
<infinity> wxl: "Don't ship it" is also an entirely valid position. :P
<acheronuk> About once every 6 months I see that and think, oh I forgot!
 * acheronuk hides
<wxl> infinity: yeah, i'm sure someone will whine.
<infinity> mitya57: My hero.
-queuebot:#ubuntu-release- Unapproved: accepted python2.7 [source] (cosmic-proposed) [2.7.16-2~18.10]
<wxl> admittedly the patch is rather new.. may of last year
-queuebot:#ubuntu-release- Unapproved: accepted qtbase-opensource-src [source] (disco-proposed) [5.12.2+dfsg-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted tzsetup [source] (disco-proposed) [1:0.94ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (disco-proposed) [2.20.10-0ubuntu27]
-queuebot:#ubuntu-release- Unapproved: rejected apport [source] (disco-proposed) [2.20.10-0ubuntu27]
-queuebot:#ubuntu-release- Unapproved: rejected leveldb [sync] (disco-proposed) [1.20-2.1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (cosmic-proposed) [1:18.10.11.6]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (bionic-proposed) [1:18.04.31]
<vorlon> acheronuk: how does http://cdimage.ubuntu.com/kubuntu/releases/disco/beta/ look now?
<acheronuk> vorlon: I can live with that in the short term :)
<acheronuk> thanks
<vorlon> acheronuk: ok, I'll raise an mp to ubuntu-cdimage that should do this
-queuebot:#ubuntu-release- Unapproved: wireshark (disco-proposed/universe) [2.6.7-1 => 2.6.8-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted wireshark [sync] (disco-proposed) [2.6.8-1]
-queuebot:#ubuntu-release- Unapproved: accepted python-stdlib-extensions [source] (cosmic-proposed) [2.7.16-2~18.10]
-queuebot:#ubuntu-release- Unapproved: accepted python3.7 [source] (cosmic-proposed) [3.7.3-2~18.10]
-queuebot:#ubuntu-release- Unapproved: accepted python3.6 [source] (cosmic-proposed) [3.6.8-1~18.10]
-queuebot:#ubuntu-release- Unapproved: accepted python3-stdlib-extensions [source] (cosmic-proposed) [3.6.8-1~18.10]
 * tsimonq2 waits for final freeze to be declared
<Eickmeyer> ^ditto tsimonq2
<tsimonq2> I believe last time I checked it was 20  UTC?
<infinity> 2100
<tsimonq2> oh, ok :)
<infinity> Which is, apparently, in 10 minutes.
<infinity> Time flies.
<tsimonq2> Right.
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (disco-proposed/main) [1.10ubuntu2 => 1.10ubuntu3] (core)
<tsimonq2> infinity: Can I safely assume already-uploaded stuff is safe? Or should I be profusely nagging you? :P
<infinity> tsimonq2: You can assume that nagging won't change anything.
<tsimonq2> That's fair.
<infinity> tsimonq2: Ultimately, for packages only you seed, you have final say anyway (up to a point).  If you want to upload something and respin and retest all your crap 6 hours before release, be my guest.
<infinity> tsimonq2: If you want to do it an hour before release, you might have missed your window. :P
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (cosmic-proposed/main) [1.5ubuntu3.18.10.3 => 1.5ubuntu3.18.10.4] (desktop-core, ubuntu-server)
<wxl> LET"S DO IT
<tsimonq2> XD
 * acheronuk watches the gates slam shut
<rbalint> ha i made it with u-u :-)
<xnox> vorlon, can you please put https://people.canonical.com/~xnox/lubuntu/ into http://cdimage.ubuntu.com/include/lubuntu/ ?
<xnox> the two pngs from there, to there?
<wxl> oooh fancy
<wxl> thanks xnox
<Eickmeyer> Oooh! Nice, xnox!
<Eickmeyer> We need one for Ubuntu Studio, too.
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (bionic-proposed/main) [1.1ubuntu1.18.04.10 => 1.1ubuntu1.18.04.11] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: budgie-desktop (bionic-proposed/universe) [10.4+git20171031.10.g9f71bb8-1.2ubuntu1.1 => 10.4+git20171031.10.g9f71bb8-1.2ubuntu1.2] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- Unapproved: budgie-desktop (cosmic-proposed/universe) [10.4+git20180830.02.f2dbc215fdb-2ubuntu0.1 => 10.4+git20180830.02.f2dbc215fdb-2ubuntu0.2] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- Unapproved: budgie-desktop (disco-proposed/universe) [10.5-0ubuntu1 => 10.5-0ubuntu1.1] (personal-fossfreedom, ubuntu-budgie)
<xnox> tested ubuntu-server -> probably did not break anything
<tsimonq2> xnox: The include directory as a whole isn't in a Git repo but Lubuntu's is.
<tsimonq2> https://code.launchpad.net/~lubuntu-art/+git/cdimage-css
<tsimonq2> Thanks though :)
<xnox> now testing the new lubuntu
<xnox> tsimonq2, but you don't have access to drop things on cdimage anyway, right?
<xnox> tsimonq2, i will send the assets back to you later, with sources.
<tsimonq2> Right.
<tsimonq2> Thanks!
<vorlon> xnox: who's signing off on those on behalf of the lubuntu team?
<xnox> tsimonq2, that's a junk repository -> not part of any project, so i cannot give a merge proposal for it. i can like email a git patch.
<xnox> vorlon, it's better than current stuff, and it's new logos -> not replacing anything existing to _adding_ them shouldn't be a problem, until after cdimage code is merged.
<xnox> vorlon, and well, lubuntu will need to check out the cdimage code and possibly tweak things from there.
<tsimonq2> I'm currently afk, I'll ack/nack in a bit unless wxl can.
<tsimonq2> xnox: Put the commits somewhere and I can review
<rbalint> please reject all unattended-upgrades uploads, i'd like to add one more thing
<rbalint> (tomorrow)
<xnox> tsimonq2, git pull https://git.launchpad.net/~xnox/+git/lubuntu-cdimage-css  master
<tsimonq2> ta
<vorlon> xnox: "it's better than current stuff" does not mean I take changes to the lubuntu directory from non-lubuntu devs.  anyway, since that one is git, I will only take updates via git :)
<vorlon> acheronuk: https://code.launchpad.net/~vorlon/ubuntu-cdimage/no-hard-coded-style/+merge/365882
<xnox> i wonder if we can make ubuntu use a css with includes too
<acheronuk> vorlon: commented as far as I am able to
<vorlon> xnox: that's what the cssincludes() function already does
<xnox> vorlon, well, i've been changing it locally, and have a big diff which will become unmergable if you merge your hack in =)
<xnox> vorlon, i guess i'll have to reincorporate your changes, if you merge that.
<xnox> vorlon, tsimonq2 - http://people.canonical.com/~xnox/lubuntu/
<xnox> is what i have created in my cdimage branch, making merge proposal now.
<vorlon> xnox: you're still inlining the background style, which I don't agree with; this requires more ubuntu-cdimage code changes in the future for things that flavors should be able to manage entirely through stylesheets
<vorlon> what you called my "hack" was a deliberate decision ;)
<xnox> vorlon, i wasn't make any decisions around there, i am more focused on making flavour page look actually good.
<xnox> vorlon, i can incorporate your change into my code as well (i.e. move things out of inline style into the <style> block)
<xnox> vorlon, and you want the same to be done with the p-navigation__image i guess?
<vorlon> xnox: hmm in principle yes, though I was taking it one step at a time
<xnox> vorlon, note, this switches lubuntu to vanilla css, without any override.
<vorlon> ?
<xnox> vorlon, i guess we can include a lubuntu/vanilla.css override.
<xnox> vorlon, well, we dropped our ubuntu.css too
<xnox> vorlon, my code is same as ubuntu's one, with just target url replaced + top left logo + banner background.
<vorlon> right
<vorlon> but those overrides should live in a per-flavor css include
<xnox> vorlon, ok, and do we have an ubuntu project css include?
<xnox> or should I do
<vorlon> xnox: no; currently that's the "default" and is all inlined, which I think is reasonable
<xnox> ack
<xnox> so inline inline inline, include override
<vorlon> yah
<xnox> rather than encode inlining all the projects
<xnox> vorlon, and what to do with the favicon? (which i am not sure work)
<vorlon> what I definitely don't want to do is to have cdimage mirrors of releases.u.c dependent on css from both assets.u.c and releases.u.c (or worse, cdimage.u.c)
<xnox> ack
<vorlon> i.e. I don't want the pipe flooded w/ non-mirrorable css requests on release day
<xnox> and releases.u.c only hosts ubuntu at the moment?
<vorlon> yes
<xnox> cause cdimage kubuntu depends on assets on releases.ubuntu.com i believe
<vorlon> the kubuntu css happens to also be on releases for historical reasons, and that's ok
<vorlon> as a percentage of total traffic
<xnox> hahahhaha
<xnox> ok
<xnox> tsimonq2, what do you think about http://people.canonical.com/~xnox/lubuntu/ ?
<xnox> vs i guess the last good old publication at http://cdimage.ubuntu.com/lubuntu/releases/cosmic/release/
<vorlon> xnox: basically, having kubuntu css on releases.u.c vs cdimage.u.c doesn't make any net difference to Canonical's bandwidth; but having to hit releases.u.c for css for the Ubuntu pages on all the cd mirrors means a lot more traffic, because it's tied to a hostname that's much heavier to mirror (releases.u.c vs assets.u.c)
<vorlon> *and* we're already hitting assets, we don't want to hit both assets and releases
<xnox> vorlon, i personally think, all assets should be on assets.ubuntu.com
<xnox> vorlon, include ubuntu-cdimage.css snippet; and all flavour css/png snippets.
<xnox> the kubuntu css, the lubuntu logos, etc.
<xnox> back in the day we didn't have assets.ubuntu.com, but now we do, why not use it properly?
<xnox> tsimonq2, the biggest gain from using vanilla css is that it browsable on the phone much nicer.
<vorlon> xnox: I don't object to things moving to assets.u.c, but you need to talk with the web team about that :)
<xnox> vorlon, i shall
<xnox> vorlon, but i bet they are in lockdown this week.
<vorlon> infinity: any thoughts on https://code.launchpad.net/~vorlon/ubuntu-cdimage/no-hard-coded-style/+merge/365882 ?
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (trusty-proposed) [4.15.0-1042.46~14.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [4.15.0-1030.32]
<vorlon> infinity, Laney: I give up, I finally got a force hint to take effect for snapd on http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#snapd but it just made it a candidate without triggering any autopkgtests
#ubuntu-release 2019-04-12
<xnox> vorlon, remove powerpc binaries from xenial-security?
<vorlon> xnox: it was the binaries in xenial release that britney complained about, not security
<xnox> vorlon, britney can haz "virtual" packages? add a virtual snapd/powerpc for -proposed?
<xnox> i.e. those that only exist in britney's brain.
<vorlon> virtual packages are used for calculating dependencies, AFAIK they're not used for calculating whether a package is up-to-date across archs
<xnox> vorlon, drop powerpc from xenial arches har har har
-queuebot:#ubuntu-release- New binary: linux-signed-gcp-edge [amd64] (bionic-proposed/main) [4.18.0-1009.10~18.04.1] (kernel)
-queuebot:#ubuntu-release- New source: lxd-installer (disco-proposed/primary) [1]
<infinity> I mean, britney's not wrong, the way we're driving it.  Not having PPC binaries in post-release when release is immutable is "wrong".
<infinity> The better solution would be to stub those packages out on PPC (ie: produce empty ones)
<infinity> Really drives home the "lack of support" concept.
-queuebot:#ubuntu-release- Unapproved: containerd (disco-proposed/universe) [1.2.5-0ubuntu1 => 1.2.6-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted containerd [source] (disco-proposed) [1.2.6-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: docker.io (disco-proposed/universe) [18.09.3-0ubuntu1 => 18.09.5-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (disco-proposed) [18.09.5-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted lxd-installer [source] (disco-proposed) [1]
-queuebot:#ubuntu-release- New binary: lxd-installer [amd64] (disco-proposed/none) [1] (no packageset)
-queuebot:#ubuntu-release- New: accepted lxd-installer [amd64] (disco-proposed) [1]
-queuebot:#ubuntu-release- Unapproved: linux-aws (disco-proposed/main) [5.0.0-1002.2 => 5.0.0-1003.3] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-gcp (disco-proposed/main) [5.0.0-1002.2 => 5.0.0-1003.3] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-azure (disco-proposed/main) [5.0.0.1002.2 => 5.0.0.1003.3] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux (disco-proposed/main) [5.0.0-10.11 => 5.0.0-11.12] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-azure (disco-proposed/main) [5.0.0-1002.2 => 5.0.0-1003.3] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta (disco-proposed/main) [5.0.0.10.11 => 5.0.0.11.12] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-aws (disco-proposed/main) [5.0.0.1002.2 => 5.0.0.1003.3] (core, kernel) (sync)
-queuebot:#ubuntu-release- New sync: linux-meta-snapdragon (disco-proposed/primary) [5.0.0.1010.3]
-queuebot:#ubuntu-release- New sync: linux-snapdragon (disco-proposed/primary) [5.0.0-1010.10]
-queuebot:#ubuntu-release- Unapproved: linux-meta-gcp (disco-proposed/main) [5.0.0.1002.2 => 5.0.0.1003.3] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-raspi2 (disco-proposed/universe) [5.0.0-1005.5 => 5.0.0-1006.6] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-raspi2 (disco-proposed/universe) [5.0.0.1005.2 => 5.0.0.1006.3] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed-azure (disco-proposed/main) [5.0.0-1002.2 => 5.0.0-1003.3] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed (disco-proposed/main) [5.0.0-10.11 => 5.0.0-11.12] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed-gcp (disco-proposed/main) [5.0.0-1002.2 => 5.0.0-1003.3] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted linux-aws [sync] (disco-proposed) [5.0.0-1003.3]
-queuebot:#ubuntu-release- Unapproved: accepted linux-gcp [sync] (disco-proposed) [5.0.0-1003.3]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-azure [sync] (disco-proposed) [5.0.0.1003.3]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-raspi2 [sync] (disco-proposed) [5.0.0.1006.3]
-queuebot:#ubuntu-release- Unapproved: accepted linux-raspi2 [sync] (disco-proposed) [5.0.0-1006.6]
-queuebot:#ubuntu-release- Unapproved: accepted linux-azure [sync] (disco-proposed) [5.0.0-1003.3]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-gcp [sync] (disco-proposed) [5.0.0.1003.3]
-queuebot:#ubuntu-release- Unapproved: accepted linux [sync] (disco-proposed) [5.0.0-11.12]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-aws [sync] (disco-proposed) [5.0.0.1003.3]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta [sync] (disco-proposed) [5.0.0.11.12]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed-azure [sync] (disco-proposed) [5.0.0-1003.3]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed [sync] (disco-proposed) [5.0.0-11.12]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed-gcp [sync] (disco-proposed) [5.0.0-1003.3]
-queuebot:#ubuntu-release- New: accepted intel-media-driver [amd64] (disco-proposed) [18.4.1+dfsg1-2ubuntu1]
-queuebot:#ubuntu-release- New: rejected linux-meta-snapdragon [sync] (disco-proposed) [5.0.0.1009.2]
-queuebot:#ubuntu-release- New: rejected linux-snapdragon [sync] (disco-proposed) [5.0.0-1009.9]
-queuebot:#ubuntu-release- New: accepted intel-media-driver [i386] (disco-proposed) [18.4.1+dfsg1-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted linux-restricted-modules [source] (disco-proposed) [5.0.0-10.11]
-queuebot:#ubuntu-release- New binary: linux-restricted-modules [amd64] (disco-proposed/restricted) [5.0.0-10.11] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (disco-proposed/main) [5.0.0-1003.3] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (disco-proposed/main) [5.0.0-11.12] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (disco-proposed/main) [5.0.0-1003.3] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (disco-proposed/main) [5.0.0-11.12] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (disco-proposed/main) [5.0.0-11.12] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: ukui-screensaver (disco-proposed/universe) [2.0.5-0ubuntu1 => 2.0.6-0ubuntu1] (ubuntukylin)
<mvo> vorlon: http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#snapd shows the "forced" flag now but it does not show any autopkgtest results. will those come in later?
<mvo> vorlon: or is there (yet) more that needs to be done?
<sil2100> infinity: since we're in freeze now, I guess I'll start working on refreshing the base language-packs for disco
 * sil2100 goes to request a full language pack export
-queuebot:#ubuntu-release- Unapproved: aodh (disco-proposed/main) [8.0.0~rc1-0ubuntu1 => 8.0.0-0ubuntu1] (openstack, ubuntu-server)
<jamespage> hi ubuntu-release - I'm uploading final versions of lots of packages for OpenStack stein today - most will be version number change only
-queuebot:#ubuntu-release- Unapproved: barbican (disco-proposed/main) [1:8.0.0~rc1-0ubuntu1 => 1:8.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cinder (disco-proposed/main) [2:14.0.0~rc2-0ubuntu1 => 2:14.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: xf86-input-wacom (disco-proposed/main) [1:0.36.1-0ubuntu1 => 1:0.36.1-0ubuntu2] (desktop-core, xorg)
-queuebot:#ubuntu-release- Unapproved: designate (disco-proposed/main) [1:8.0.0~rc1-0ubuntu1 => 1:8.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: designate-dashboard (disco-proposed/universe) [8.0.0~rc1-0ubuntu1 => 8.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted designate-dashboard [source] (disco-proposed) [8.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ceilometer (disco-proposed/main) [1:12.0.0~rc1-0ubuntu1 => 1:12.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: glance (disco-proposed/main) [2:18.0.0~rc1-0ubuntu1 => 2:18.0.0-0ubuntu1] (openstack, ubuntu-server)
<seb128> hey there
<seb128> so, we are currently on an unstable version of gstreamer, they just rolled out their stable rc yesterday and Debian just picked those up
<Laney> vorlon: dunno what you're talking about, but it should be possible to construct a test
<Laney> to replicate this situation
<seb128> do you think there is a chance to get thos accepted? or is that SRU material at this point?
<seb128> (I'm mostly asking because if it's SRU material then I wait for Debian to have the updates published and just sync, but if we think it can still be in disco then I do some fakesyncs to lower delays)
<LocutusOfBorg> I also hope to have my new virtualbox release syncd soon, but upstream didn't release it yet...
<Laney> LocutusOfBorg: SRUs exist.
<LocutusOfBorg> sure
<LocutusOfBorg> but vbox is part of the virtualization process inside the iso...
<Laney> seb128: dunno, maybe if it can be done today, what's in it and how much would it benefit from having a specific testing phase that you'd get from an SRU?
-queuebot:#ubuntu-release- Unapproved: horizon (disco-proposed/main) [3:15.0.0~rc2-0ubuntu2 => 3:15.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: librsvg (disco-proposed/main) [2.44.10-1ubuntu1 => 2.44.10-2] (core) (sync)
<Laney> So a last minute release being slammed into the release, that breaks stuff, would be a very bad idea then?
<Laney> (to LocutusOfBorg)
<LocutusOfBorg> ehm, unfortunately it is not me who uploaded linux 5.0, breaking virtualization :)
<LocutusOfBorg> at least parts of it, its complicated
<LocutusOfBorg> anyhow, I use bionic, and my servers are on LTS, so I don't really care anymore about users using non-LTS releases TBH
<Laney> anyway, "it depends" is the answer to these questions :>
-queuebot:#ubuntu-release- Unapproved: heat (disco-proposed/main) [1:12.0.0~rc1-0ubuntu1 => 1:12.0.0-0ubuntu1] (openstack, ubuntu-server)
<Laney> juliank: UMMMMMMMMMMM did you see the server-live failures?
-queuebot:#ubuntu-release- Unapproved: keystone (disco-proposed/main) [2:15.0.0~rc2-0ubuntu1 => 2:15.0.0-0ubuntu1] (openstack, ubuntu-server)
<Laney> https://launchpadlibrarian.net/418951098/buildlog_ubuntu_disco_arm64_ubuntu-server-live_BUILDING.txt.gz
-queuebot:#ubuntu-release- Unapproved: magnum (disco-proposed/universe) [8.0.0~rc1-0ubuntu1 => 8.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted magnum [source] (disco-proposed) [8.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: manila (disco-proposed/universe) [1:8.0.0~rc1-0ubuntu1 => 1:8.0.0-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: masakari-monitors (disco-proposed/universe) [7.0.0~rc1-0ubuntu2 => 7.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted masakari-monitors [source] (disco-proposed) [7.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: masakari (disco-proposed/universe) [7.0.0~rc1-0ubuntu1 => 7.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted masakari [source] (disco-proposed) [7.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: kmod (disco-proposed/main) [25-1ubuntu3 => 25-1ubuntu4] (core)
<seb128> Laney, gstreamer1.0  isn't bad, it's only 34 commits between the versions and some being documentation/typo/readme type of changes
<seb128> I'm going to land them in the queue and give a good round of testing
<seb128> (or the other way around ;)
-queuebot:#ubuntu-release- Unapproved: murano (disco-proposed/universe) [1:7.0.0~rc1-0ubuntu1 => 1:7.0.0-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: python-opcua (disco-proposed/universe) [0.98.6-1ubuntu1 => 0.98.6-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-opcua [sync] (disco-proposed) [0.98.6-2]
-queuebot:#ubuntu-release- Unapproved: murano-dashboard (disco-proposed/universe) [1:7.0.0~rc1-0ubuntu1 => 1:7.0.0-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: networking-bagpipe (disco-proposed/universe) [10.0.0~rc1-0ubuntu1 => 10.0.0-0ubuntu1] (no packageset)
<Laney> seb128: ok, for the record I think SRU would be just fine if there's any concern at all
-queuebot:#ubuntu-release- Unapproved: accepted networking-bagpipe [source] (disco-proposed) [10.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: networking-bgpvpn (disco-proposed/universe) [10.0.0~rc1-0ubuntu1 => 10.0.0-0ubuntu1] (no packageset)
<seb128> Laney, you are probably like, I dislike releasing with a dev version but from our testing it isn't too buggy so it wouldn't be the end of the world (and most users will apply the SRU updates hopefully)
<Laney> I don't mean "please do an SRU", just that it's an equally valid option to landing something in the release now
-queuebot:#ubuntu-release- Unapproved: accepted networking-bgpvpn [source] (disco-proposed) [10.0.0-0ubuntu1]
<seb128> right
-queuebot:#ubuntu-release- Unapproved: networking-l2gw (disco-proposed/universe) [1:14.0.0~b1~git2019013126.259d558-0ubuntu1 => 1:14.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted networking-l2gw [source] (disco-proposed) [1:14.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: networking-odl (disco-proposed/universe) [1:14.0.0~rc1-0ubuntu1 => 1:14.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted networking-odl [source] (disco-proposed) [1:14.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gstreamer1.0 (disco-proposed/main) [1.15.2-1 => 1.15.90-1~sync1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: networking-sfc (disco-proposed/universe) [8.0.0~rc1-0ubuntu1 => 8.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted networking-sfc [source] (disco-proposed) [8.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: neutron (disco-proposed/main) [2:14.0.0~rc1-0ubuntu3 => 2:14.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron-dynamic-routing (disco-proposed/universe) [2:14.0.0~rc1-0ubuntu1 => 2:14.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted neutron-dynamic-routing [source] (disco-proposed) [2:14.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: neutron-fwaas (disco-proposed/main) [1:14.0.0~rc1-0ubuntu1 => 1:14.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron-fwaas-dashboard (disco-proposed/universe) [2.0.0-0ubuntu1 => 2.0.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted neutron-fwaas-dashboard [source] (disco-proposed) [2.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: mistral (disco-proposed/universe) [8.0.0~rc1-0ubuntu1 => 8.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: neutron-lbaas (disco-proposed/universe) [2:14.0.0~rc1-0ubuntu1 => 2:14.0.0-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: accepted mistral [source] (disco-proposed) [8.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: neutron-lbaas-dashboard (disco-proposed/universe) [6.0.0~rc1-0ubuntu1 => 6.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gst-plugins-base1.0 (disco-proposed/main) [1.15.2-1 => 1.15.90-1~sync1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted neutron-lbaas-dashboard [source] (disco-proposed) [6.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: neutron-vpnaas (disco-proposed/universe) [2:14.0.0~rc1-0ubuntu1 => 2:14.0.0-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: accepted ca-certificates-java [source] (disco-proposed) [20190405ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-music [sync] (disco-proposed) [3.32.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (disco-proposed) [0.97.11]
-queuebot:#ubuntu-release- Unapproved: accepted calamares [source] (disco-proposed) [3.2.4-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-ubuntu-dock [sync] (disco-proposed) [64ubuntu6]
-queuebot:#ubuntu-release- Unapproved: gst-plugins-good1.0 (disco-proposed/main) [1.15.2-1ubuntu1 => 1.15.90-1ubuntu1] (desktop-core, ubuntu-server)
<juliank> Laney: mwhudson just mentioned that in -devel earlier
<Laney> ok
<Laney> get to work then ;-)
<jamespage> could a release team member look at https://code.launchpad.net/~james-page/britney/mininet-badtest/+merge/365898 pls
<jamespage> mininet is blocking openvswitch migration due to the same underlying bug for which we badtest the openvswitch/i386 tests
-queuebot:#ubuntu-release- Unapproved: gst-plugins-ugly1.0 (disco-proposed/universe) [1.15.1-1 => 1.15.90-1~sync1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: iproute2 (xenial-proposed/main) [4.3.0-1ubuntu3.16.04.4 => 4.3.0-1ubuntu3.16.04.5] (core)
-queuebot:#ubuntu-release- Unapproved: gst-python1.0 (disco-proposed/universe) [1.15.2-1 => 1.15.90-1ubuntu1] (ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: gst-rtsp-server1.0 (disco-proposed/universe) [1.15.2-1 => 1.15.90-1~sync1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gst-python1.0 (disco-proposed/universe) [1.15.2-1 => 1.15.90-1~sync1] (ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: gst-plugins-bad1.0 (disco-proposed/universe) [1.15.2-1ubuntu1 => 1.15.90-1ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: gstreamer-editing-services1.0 (disco-proposed/universe) [1.15.2-1 => 1.15.90-1~sync1] (ubuntustudio)
<rbasak> Bug 1813317 is still outstanding. Is that on a final week checklist somewhere, or does it need pointing out?
<ubot5`> bug 1813317 in php7.3 (Ubuntu) "Please remove src:php7.3 from disco" [Undecided,New] https://launchpad.net/bugs/1813317
<rbasak> vorlon: ^
-queuebot:#ubuntu-release- Unapproved: zaqar (disco-proposed/universe) [8.0.0~rc1-0ubuntu1 => 8.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gstreamer-vaapi (disco-proposed/universe) [1.15.2-1 => 1.15.90-1~sync1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: watcher (disco-proposed/universe) [1:2.0.0~rc1-0ubuntu1 => 1:2.0.0-0ubuntu1] (no packageset)
<juliank> Laney: should be fixed later, I submitted https://github.com/CanonicalLtd/ubuntu-advantage-client/pull/362
-queuebot:#ubuntu-release- Unapproved: trove-dashboard (disco-proposed/universe) [12.0.0~rc1-0ubuntu1 => 12.0.0-0ubuntu1] (no packageset)
<gitbot> CanonicalLtd issue (Pull request) 362 in ubuntu-advantage-client "apt-hook: Do not crash/fail if we can't read /proc/self/status" [Open]
 * juliank disappears again
-queuebot:#ubuntu-release- Unapproved: senlin (disco-proposed/universe) [7.0.0~rc1-0ubuntu1 => 7.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: sahara (disco-proposed/universe) [1:10.0.0~rc1-0ubuntu1 => 1:10.0.0-0ubuntu1] (openstack)
<sil2100> Odd_Bloke, powersj: ^
-queuebot:#ubuntu-release- Unapproved: sahara-dashboard (disco-proposed/universe) [10.0.0~rc1-0ubuntu1 => 10.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: placement (disco-proposed/universe) [1.0.0~rc1-0ubuntu1 => 1.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: panko (disco-proposed/universe) [6.0.0~rc1-0ubuntu1 => 6.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: openstack-trove (disco-proposed/universe) [1:11.0.0~rc1-0ubuntu1 => 1:11.0.0-0ubuntu1] (no packageset)
<didrocks> sil2100: almost daily ping now to copy the canary-image to p.c.c please :)
<didrocks> and hey ;)
<sil2100> Hey! didrocks eek, forgot to talk about that, hopefull I won't forget today! Anyway, copying shortly
<didrocks> sil2100: thx! ;)
-queuebot:#ubuntu-release- Unapproved: nova (disco-proposed/main) [2:19.0.0~rc1-0ubuntu1 => 2:19.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted heat [source] (disco-proposed) [1:12.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kmod [source] (disco-proposed) [25-1ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted manila [source] (disco-proposed) [1:8.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted murano [source] (disco-proposed) [1:7.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron-lbaas [source] (disco-proposed) [2:14.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (disco-proposed) [2:14.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted panko [source] (disco-proposed) [6.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted sahara-dashboard [source] (disco-proposed) [10.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted senlin [source] (disco-proposed) [7.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted watcher [source] (disco-proposed) [1:2.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted keystone [source] (disco-proposed) [2:15.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted murano-dashboard [source] (disco-proposed) [1:7.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron-vpnaas [source] (disco-proposed) [2:14.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted placement [source] (disco-proposed) [1.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted trove-dashboard [source] (disco-proposed) [12.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted librsvg [sync] (disco-proposed) [2.44.10-2]
-queuebot:#ubuntu-release- Unapproved: accepted openstack-trove [source] (disco-proposed) [1:11.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted zaqar [source] (disco-proposed) [8.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron-fwaas [source] (disco-proposed) [1:14.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted sahara [source] (disco-proposed) [1:10.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted aodh [source] (disco-proposed) [8.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ceilometer [source] (disco-proposed) [1:12.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted designate [source] (disco-proposed) [1:8.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (disco-proposed) [3:15.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: nova-lxd (disco-proposed/main) [19.0.0~rc1-0ubuntu1 => 19.0.0-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted barbican [source] (disco-proposed) [1:8.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted glance [source] (disco-proposed) [2:18.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (disco-proposed) [2:14.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (disco-proposed) [2:19.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: octavia-dashboard (disco-proposed/universe) [3.0.0~rc1-0ubuntu1 => 3.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted budgie-desktop [source] (disco-proposed) [10.5-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted ukui-screensaver [source] (disco-proposed) [2.0.6-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (disco-proposed) [18.2-22-g08bf6ff7-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted xf86-input-wacom [source] (disco-proposed) [1:0.36.1-0ubuntu2]
-queuebot:#ubuntu-release- New source: nvidia-graphics-drivers-410 (bionic-proposed/primary) [410.104-0ubuntu0~18.04.1]
-queuebot:#ubuntu-release- Unapproved: octavia (disco-proposed/universe) [4.0.0~rc1-0ubuntu1 => 4.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: manila-ui (disco-proposed/universe) [2.17.0-0ubuntu1 => 2.18.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted manila-ui [source] (disco-proposed) [2.18.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted octavia-dashboard [source] (disco-proposed) [3.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (disco-proposed) [1.10ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted nova-lxd [source] (disco-proposed) [19.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted octavia [source] (disco-proposed) [4.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: atheist (disco-proposed/universe) [0.20110402-2.1 => 0.20110402-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: openmw (disco-proposed/multiverse) [0.45.0-2 => 0.45.0-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: iptables-persistent (bionic-proposed/universe) [1.0.4+nmu2 => 1.0.4+nmu2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: iptables-persistent (cosmic-proposed/universe) [1.0.7 => 1.0.7ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New source: nvidia-graphics-drivers-410 (bionic-proposed/primary) [410.104-0ubuntu0~18.04.1]
-queuebot:#ubuntu-release- Unapproved: tracker-miners (disco-proposed/main) [2.1.6-1 => 2.1.6-1ubuntu1] (ubuntu-desktop)
<ogra> sil2100, hey ... could i get initramfs-tools-devices in the disco queue approved (we do not seed it anywhere and we do not build core images from disco, it landed only there to fulfill SRU prerequisites)
<ogra> sil2100, the accompaning bug is #1819454
<sil2100> ogra: looking o/
<ogra> TA!
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools-devices [source] (disco-proposed) [0.4]
<sil2100> didrocks: ah, forgot to give heads up - copied the image o/
 * ogra hugs sil2100 
<tseliot> can an admin reject nvidia-graphics-drivers-410 (bionic-proposed/primary) please? That was meant to go to a PPA. Not sure what happened on my side
<apw> tseliot, looking
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (disco-proposed) [5.0.0-1003.3]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (disco-proposed) [5.0.0-11.12]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (disco-proposed) [5.0.0-11.12]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (disco-proposed) [5.0.0-1003.3]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (disco-proposed) [5.0.0-11.12]
<tseliot> apw: thanks
-queuebot:#ubuntu-release- New: rejected nvidia-graphics-drivers-410 [source] (bionic-proposed) [410.104-0ubuntu0~18.04.1]
-queuebot:#ubuntu-release- New: rejected nvidia-graphics-drivers-410 [source] (bionic-proposed) [410.104-0ubuntu0~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp-edge [amd64] (bionic-proposed) [4.18.0-1009.10~18.04.1]
<tseliot> apw: thanks again
-queuebot:#ubuntu-release- Unapproved: opensaml (disco-proposed/universe) [3.0.0-2 => 3.0.1-1] (no packageset) (sync)
<didrocks> sil2100:thx!
<rbalint> sil2100, could you please reject bb and cc u-u srus?
<rbalint> sil2100, i asked for the rejection of disco's as well, but it is not terribly bad that it landed, i just would like to extend the fix and add one more
<sil2100> rbalint: ok
-queuebot:#ubuntu-release- Unapproved: rejected unattended-upgrades [source] (bionic-proposed) [1.1ubuntu1.18.04.11]
-queuebot:#ubuntu-release- Unapproved: rejected unattended-upgrades [source] (cosmic-proposed) [1.5ubuntu3.18.10.4]
-queuebot:#ubuntu-release- Unapproved: linux-kvm (disco-proposed/main) [5.0.0-1002.2 => 5.0.0-1003.3] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-kvm (disco-proposed/main) [5.0.0.1002.2 => 5.0.0.1003.3] (core, kernel) (sync)
<ahasenack> hi release team, juliank gave us a fix for https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/1824523, we if upload now, can you respin disco server, or do we have to wait for the middle of the night?
<ubot5`> Ubuntu bug 1824523 in ubuntu-advantage-tools (Ubuntu) "Assertion error during iso build" [Critical,In progress]
<ahasenack> we have some questions about that fix, but he is not available atm
-queuebot:#ubuntu-release- Unapproved: morse-simulator (disco-proposed/universe) [1.4-4 => 1.4-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: opencascade (disco-proposed/universe) [7.3.0+dfsg1-4 => 7.3.0+dfsg1-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (disco-proposed/main) [19.2 => 19.3] (core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-meta (disco-proposed/universe) [1.231 => 1.232] (ubuntu-mate)
<LocutusOfBorg> seb128, please merge alsa-utils? there is a CVE-2019-5953 there...
<LocutusOfBorg> seb128, nevermind, sorry!
<seb128> LocutusOfBorg, ?
<seb128> nw
<LocutusOfBorg> I had a wrong tab open on my browser (and made confusion with the already fixed wget)
<seb128> ah ok
<seb128> good :)
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-settings (disco-proposed/universe) [19.04.1 => 19.04.2] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: gnome-bluetooth (bionic-proposed/main) [3.28.0-2ubuntu0.1 => 3.28.0-2ubuntu0.2] (ubuntu-desktop)
<Wimpress> sil2100: Please review/approve `ubuntu-mate-meta` and `ubuntu-mate-settings`
<sil2100> Wimpress: on it
<Wimpress> Cheers.
 * sil2100 waits for the diffs since he's lazy
<sil2100> ;)
<sil2100> (they're pending)
<Wimpress> sil2100: Thanks!
<sil2100> ...ok, those are taking forever
<LocutusOfBorg> lol
<LocutusOfBorg> I'm not the only one waiting for diffs that don't happen
<LocutusOfBorg> :)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-meta [source] (disco-proposed) [1.232]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-advantage-tools [source] (disco-proposed) [19.3]
<sil2100> LocutusOfBorg: ;p
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-settings [source] (disco-proposed) [19.04.2]
<ahasenack> sil2100: ubuntu-advantage-tools 19.3 has the fix for the disco ubuntu-server image build failure, is that something you can take a look at, and perhaps even spin a new build to verify it's fixed?
<sil2100> ahasenack: ^ approved it already (see above)
<sil2100> I guess we can spin images for that, yes
<ahasenack> ah, sorry, missed that
<sil2100> Let me finish up the langpack business though
<ahasenack> thx!
-queuebot:#ubuntu-release- Unapproved: nwchem (disco-proposed/universe) [6.8.1-4 => 6.8.1-5] (no packageset) (sync)
<seb128> Rejected:
<seb128> language-pack-en_19.04+20160720.dsc: Version older than that in the archive. 1:19.04+20160720 <= 1:19.04+20190408
<seb128> something went wrong there :p
<ahasenack> sil2100: we have to wait for it to migrate anyway
<sil2100> eek
<sil2100> EEEk
<sil2100> seb128: indeed ;p
 * sil2100 looks what the heck happened
<sil2100> What the fuu..
<sil2100> Ok, now this is WEIRD
<ahasenack> must be related to the blackhole discovery
 * Eickmeyer plays twilight zone music
<sil2100> Now it'll be good
<seb128> sil2100, what was the issue?
-queuebot:#ubuntu-release- Unapproved: gnome-control-center (disco-proposed/main) [1:3.32.1-1ubuntu3 => 1:3.32.1-1ubuntu4] (desktop-core)
<sil2100> seb128: a bit embarrasing really... I downloaded the latest tarball using the +latest-full-language-pack link, but didn't notice that there was already an old trusty tarball saved in the dir as well with the same name, so even though I downloaded the latest, I renamed the old one to be used for the import ;/
<seb128> lol, I see
<seb128> :)
<juliank> ahasenack: you have questions?
<sil2100> seb128: my WTF moment was because I checked my wget command and it was correctly pulling in disco, but my actual tarball was trusty
<ahasenack> juliank: rbasak had
<seb128> k
<seb128> well, good that it did lead to a reject then!
<rbasak> juliank: my question was: is the first hunk really required?
<sil2100> Yeah, phew
<rbasak> That was all.
<rbasak> I'm still +1 to land it
<rbasak> Though also it seems like quite a leaky abstraction for the caller to rely on the implementation detail of the function to know not to call it
<juliank> rbasak: Yeah, there were a few possible choices.
<juliank> rbasak: I wanted to drop the error handling in case /proc/foo/status is not readable at all
<rbasak> IMHO that check should be in the function itself but that refactoring is probably inappropriate for right now.
<juliank> and /proc/$foo/cmdline parsing also does not do any checking
<juliank> The idea is: If /proc exists and we can read the files we have to, continue with our task, otherwise don't complain
<juliank> this also handles cases where the hook might be run in a chroot or some weird thing where /proc/$ppid/ is not readable
<juliank> I guess we can make it warn instead of error in a later iteration
<juliank> in some cases
<juliank> But I don't want to print messages every time you run apt on a system without a /proc mounted
<juliank> (and I'm not sure which cases there exist where ppid(ppid(self)) has a non-readable proc)
-queuebot:#ubuntu-release- Unapproved: linux-firmware-raspi2 (disco-proposed/multiverse) [1.20190215-0ubuntu1 => 1.20190215-0ubuntu3] (no packageset)
<juliank> rbasak: as for the check in the function, well it does not need to be - the function just returns ""; it's just performing a self-test at start against getppid() and that fails
<juliank> But there might be cases where the function returns "" where it should not return that
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware-raspi2 [source] (disco-proposed) [1.20190215-0ubuntu3]
<juliank> the self-tests are not technically necessary
<juliank> they just assure you that the basic logic works :)
-queuebot:#ubuntu-release- New binary: pi-bluetooth [amd64] (disco-proposed/universe) [0.1.10ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected tracker-miners [source] (disco-proposed) [2.1.6-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gnome-maps (disco-proposed/universe) [3.32.0-1 => 3.32.1-1] (desktop-extra, ubuntu-budgie, ubuntugnome) (sync)
<rbasak> juliank: sure.
<rbasak> juliank: it might be worth specifying the edge cases in the function specification
<rbasak> (ie. the comment at the top)
<rbasak> Anyway, to be clear, this is for the future - I'm certainly not proposing on blocking on any of this right now
<sil2100> seb128: ok, this time I *properly* sanity checked those ;)
<seb128> good
<seb128> so r-t friends, there is a new gstreamer stack in the queue
<seb128> it's a bit late but upstream screwed their release cycle which means we are currently on a dev version
<seb128> where the new is the stable rc
<seb128> any chance to get that in (it has been uploaded to Debian and tested in the desktop ppa by a few persons)
<seb128> or should I turn tthat into a SRU and reupload?
-queuebot:#ubuntu-release- Unapproved: gpac (disco-proposed/universe) [0.5.2-426-gc5ad4e4+dfsg5-4build1 => 0.5.2-426-gc5ad4e4+dfsg5-4ubuntu1] (no packageset)
<vorlon> rbasak: removed, cheers (and no, it wasn't on radar)
<rbasak> Thanks!
<LocutusOfBorg> dear release team, instead of kicking out freecad, can we have 0.18~pre1+dfsg1-5 copied in porposed?
<ginggs> LocutusOfBorg: freecad/0.18~pre1+dfsg1-5 did not migrate http://autopkgtest.ubuntu.com/packages/f/freecad/disco/i386
-queuebot:#ubuntu-release- Unapproved: pi-bluetooth (disco-proposed/universe) [0.1.10ubuntu2 => 0.1.10ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pi-bluetooth [source] (disco-proposed) [0.1.10ubuntu3]
-queuebot:#ubuntu-release- Unapproved: leveldb (disco-proposed/main) [1.20-2 => 1.20-2.1] (ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: xml-core (disco-proposed/main) [0.18 => 0.18+nmu1] (ubuntu-desktop, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: gstreamer1.0 (disco-proposed/main) [1.15.2-1 => 1.15.90-1~sync1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: systemd (disco-proposed/main) [240-6ubuntu4 => 240-6ubuntu5] (core)
<vorlon> infinity: got to the bottom of the glibc autopkgtest regressions, we should be good now
-queuebot:#ubuntu-release- Unapproved: gst-plugins-base1.0 (disco-proposed/main) [1.15.2-1 => 1.15.90-1~sync1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: gstreamer1.0 (disco-proposed/main) [1.15.2-1 => 1.15.90-1~sync1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: systemd (disco-proposed/main) [240-6ubuntu4 => 240-6ubuntu5] (core)
-queuebot:#ubuntu-release- Unapproved: gst-plugins-good1.0 (disco-proposed/main) [1.15.2-1ubuntu1 => 1.15.90-1ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: xml-core (disco-proposed/main) [0.18 => 0.18+nmu1] (ubuntu-desktop, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: leveldb (disco-proposed/main) [1.20-2 => 1.20-2.1] (ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: gst-plugins-base1.0 (disco-proposed/main) [1.15.2-1 => 1.15.90-1~sync1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: leveldb (disco-proposed/main) [1.20-2 => 1.20-2.1] (ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: xml-core (disco-proposed/main) [0.18 => 0.18+nmu1] (ubuntu-desktop, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: gstreamer1.0 (disco-proposed/main) [1.15.2-1 => 1.15.90-1~sync1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: systemd (disco-proposed/main) [240-6ubuntu4 => 240-6ubuntu5] (core)
<ginggs> LocutusOfBorg: in fact, 0.18+dfsg1-1 no longer seems to have the math errr on i386
-queuebot:#ubuntu-release- Unapproved: duplicity (disco-proposed/main) [0.7.18.2-1ubuntu3 => 0.7.18.2-1ubuntu3.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: pi-bluetooth [amd64] (disco-proposed/universe) [0.1.10ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New: rejected pi-bluetooth [amd64] (disco-proposed) [0.1.10ubuntu2]
-queuebot:#ubuntu-release- New: accepted pi-bluetooth [amd64] (disco-proposed) [0.1.10ubuntu3]
-queuebot:#ubuntu-release- Unapproved: leveldb (disco-proposed/main) [1.20-2 => 1.20-2.1] (ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: xml-core (disco-proposed/main) [0.18 => 0.18+nmu1] (ubuntu-desktop, ubuntu-server) (sync)
<xnox> vorlon, ganeti-instance-debootstrap "failure" is a bit false... it looks like deb.debian.org no longer provides ports.
<vorlon> xnox: do you want to retrigger the tests against the release pocket so there's a log of this?
<LocutusOfBorg> ginggs, so, copying the previous version, and cherry-picking that fix, might work
<xnox> vorlon, no, i'm preparing a fix.
<xnox> vorlon, so actual issue is that jessie is hardcoded in ganeti, and jessie is EOL and removed from mirrors.
<vorlon> ok
<xnox> vorlon, switching default to use distro-info & thus stable all the time.
-queuebot:#ubuntu-release- New: accepted linux-restricted-modules [amd64] (disco-proposed) [5.0.0-10.11]
-queuebot:#ubuntu-release- Unapproved: tracker (disco-proposed/main) [2.1.8-1 => 2.1.8-2~fakesync] (desktop-extra, ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: ganeti-instance-debootstrap (disco-proposed/universe) [0.16-6 => 0.16-6ubuntu1] (no packageset)
<xnox> vorlon, but it means that multipath-tools did not migrate before final freeze
<ahasenack> sil2100: ua19.3 is in disco, can you respin the ubuntu server isos to see if this time they build?
<ahasenack> ubuntu-server-live
<Laney> I'll do it.
<Laney> More than one of us can do cdimage things, no need to ping Åukasz every time :>
<Laney> oh OK, https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/disco/ubuntu-server-live/+build/161983 is running already, I guess that'll do the job?
<ahasenack> Laney: h just had context
<ahasenack> thx
<infinity> xnox: Migration before freeze isn't necessary, as long as it migrates before we build RCs.
<infinity> xnox: (so make it go!)
<infinity> vorlon: Hrm, so you hinted the old fuse-zip, but not the new?  Isn't the failure the same for both?
<vorlon> infinity: I didn't check the new yet
<vorlon> infinity: I verified that the timeout was not reproducible before I upgraded my kernel locally, and was reproducible after
<infinity> vorlon: Kay.  Pretty sure the same surface issue (timeout) shows on the new version too, but if you could verify that it passes with an old kernel, that'd be awesome.
<vorlon> infinity: I upgraded my host and am not going to spend that much effort verifying its behavior on an old kernel
<infinity> vorlon: Then gimme a 20-second repro (which kernel worked, etc) and I'll do it in a VM? :P
<infinity> vorlon: Seems silly to block a new version if it's no worse than the old.
<vorlon> infinity: I was running in a disco chroot on top of a cosmic kernel
<vorlon> and I didn't say it /worked/, I said the timeout is linked to the kernel upgrade
<vorlon> (trying to run in a chroot may have been an invalid test setup)
<infinity> Ahh.
<infinity> Well, this is what VMs are for.
<vorlon> so why did checkbox dependencies get repromoted to main?
<infinity> Is this a trick question?
<infinity> I don't see checkbox-support being in universe since 2014.
<infinity> But more importantly, if plainbox/checkbox is removed, should we be demoting checkbox-support or removing it?
<infinity> Oh, it comes from Debian.
<infinity> Nevermind.
<infinity> ... but it comes from Debian via a Canonical maintainer who hasn't uploaded since 2015.
<infinity> So maybe that does need revisiting. :P
<cwayne> You can remove them
<cwayne> We're all about that snap life now
<xnox> infinity, i have requested in debian to remove them there too i think......
<xnox> cwayne, but do need to file RM RoM bugs in debian, no?
<cwayne> I think that's already been done?
<infinity> I don't see one.
<infinity> I see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913361
<ubot5`> Debian bug 913361 in src:checkbox-support "checkbox-support: Don't include in Buster" [Serious,Open]
-queuebot:#ubuntu-release- Unapproved: accepted gst-plugins-bad1.0 [source] (disco-proposed) [1.15.90-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gst-plugins-good1.0 [source] (disco-proposed) [1.15.90-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gst-python1.0 [source] (disco-proposed) [1.15.90-1~sync1]
<infinity> Which is a weird "warning, there might be a removal bug" bug.
-queuebot:#ubuntu-release- Unapproved: accepted gstreamer-editing-services1.0 [source] (disco-proposed) [1.15.90-1~sync1]
-queuebot:#ubuntu-release- Unapproved: accepted gstreamer1.0 [source] (disco-proposed) [1.15.90-1~sync1]
-queuebot:#ubuntu-release- Unapproved: accepted gst-plugins-base1.0 [source] (disco-proposed) [1.15.90-1~sync1]
-queuebot:#ubuntu-release- Unapproved: accepted gst-rtsp-server1.0 [source] (disco-proposed) [1.15.90-1~sync1]
-queuebot:#ubuntu-release- Unapproved: accepted gst-plugins-ugly1.0 [source] (disco-proposed) [1.15.90-1~sync1]
-queuebot:#ubuntu-release- Unapproved: accepted gstreamer-vaapi [source] (disco-proposed) [1.15.90-1~sync1]
-queuebot:#ubuntu-release- Unapproved: rejected gst-python1.0 [source] (disco-proposed) [1.15.90-1ubuntu1]
<xnox> cwayne, i don't see one either on https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=ftp.debian.org;dist=unstable
<xnox> and packages still exist:
<xnox> https://tracker.debian.org/pkg/plainbox
<xnox> https://tracker.debian.org/pkg/checkbox-ng
<xnox> https://tracker.debian.org/pkg/checkbox-support
<Eickmeyer> Interesting bug found. I was able to confirm it with my own hardware, but it might be worth mentioning in the release notes unless something can get fixed. Either way, a show-stopper bug for certain hardware. bug 1824546
<ubot5`> bug 1824546 in linux (Ubuntu) "Intel N3060 booting into black screen with 5.0 kernel" [Undecided,Confirmed] https://launchpad.net/bugs/1824546
<infinity> tjaalton: ^
<infinity> Eickmeyer: Oh, this *might* be fixed in the kernel in -proposed.  Can you easily test that?
<Eickmeyer> infinity: I can. Standby...
<Eickmeyer> (this might take a while)
<infinity> Eickmeyer: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1821820 is the bug ref.
<ubot5`> Ubuntu bug 1821820 in linux (Ubuntu) "Cannot boot or install - have to use nomodeset" [Undecided,Confirmed]
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (disco-proposed/main) [20190124+dfsg1-0ubuntu1 => 20190315-0ubuntu1~rbalint1] (core, ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gst-libav1.0 (disco-proposed/universe) [1.15.2-1 => 1.15.90-1] (kubuntu) (sync)
<cwayne> xnox: would the maintainer need to log such a bug?
<cwayne> Sorry for dumb question, haven't dealt with anything Debian in ages
<xnox> cwayne, yeah, using like reportbug cmdline tool against ftp.debian.org and follow the prompts, for each package.
<xnox> cwayne, i guess i can do that, and like CC people.... who should I cc?
<cwayne> xnox: Sylvain Pineau and myself please
<xnox> ok
<cwayne> thanks man
-queuebot:#ubuntu-release- Unapproved: accepted ganeti-instance-debootstrap [source] (disco-proposed) [0.16-6ubuntu1]
<infinity> Laney: Why the sketchy ~fakesync version for tracker when you could just grab the Debian source, generate a changes, and change target dist to disco?
 * infinity does that instead.
<xnox> cwayne, and done. you should have like 5 emails each.
<xnox> soon
<Eickmeyer> infinity: Looks like that kernel did the trick. :)
<infinity> Eickmeyer: Excellent, then I'll dupe that bug.
-queuebot:#ubuntu-release- Unapproved: accepted duplicity [source] (disco-proposed) [0.7.18.2-1ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: accepted gpac [source] (disco-proposed) [0.5.2-426-gc5ad4e4+dfsg5-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (disco-proposed) [1:3.32.1-1ubuntu4]
-queuebot:#ubuntu-release- Unapproved: tracker (disco-proposed/main) [2.1.8-1 => 2.1.8-2] (desktop-extra, ubuntugnome)
<infinity> rbalint: Was the ~rbalint1 upload of gce-compute-thingee meant for a PPA, not the archive?
-queuebot:#ubuntu-release- Unapproved: rejected gce-compute-image-packages [source] (disco-proposed) [20190315-0ubuntu1~rbalint1]
-queuebot:#ubuntu-release- Unapproved: accepted tracker [source] (disco-proposed) [2.1.8-2]
-queuebot:#ubuntu-release- Unapproved: rejected tracker [source] (disco-proposed) [2.1.8-2~fakesync]
<Eickmeyer> infinity: Thanks! We were working with someone in #ubuntu+1 on that very issue.
<rbalint> infinity, please reject, ppa indeed
<rbalint> infinity, thanks
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (disco-proposed) [240-6ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted atheist [sync] (disco-proposed) [0.20110402-3]
-queuebot:#ubuntu-release- Unapproved: accepted gst-libav1.0 [sync] (disco-proposed) [1.15.90-1]
-queuebot:#ubuntu-release- Unapproved: accepted nwchem [sync] (disco-proposed) [6.8.1-5]
-queuebot:#ubuntu-release- Unapproved: accepted openmw [sync] (disco-proposed) [0.45.0-3]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-maps [sync] (disco-proposed) [3.32.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted opencascade [sync] (disco-proposed) [7.3.0+dfsg1-5]
-queuebot:#ubuntu-release- Unapproved: accepted morse-simulator [sync] (disco-proposed) [1.4-5]
-queuebot:#ubuntu-release- Unapproved: accepted opensaml [sync] (disco-proposed) [3.0.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted leveldb [sync] (disco-proposed) [1.20-2.1]
-queuebot:#ubuntu-release- Unapproved: accepted xml-core [sync] (disco-proposed) [0.18+nmu1]
-queuebot:#ubuntu-release- Unapproved: tdbcmysql (disco-proposed/universe) [1.1.0-1 => 1.1.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- New binary: leveldb [amd64] (disco-proposed/main) [1.20-2.1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: leveldb [s390x] (disco-proposed/main) [1.20-2.1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: leveldb [i386] (disco-proposed/main) [1.20-2.1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: leveldb [ppc64el] (disco-proposed/main) [1.20-2.1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: leveldb [arm64] (disco-proposed/main) [1.20-2.1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: leveldb [armhf] (disco-proposed/main) [1.20-2.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted tdbcmysql [sync] (disco-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- New: accepted leveldb [amd64] (disco-proposed) [1.20-2.1]
-queuebot:#ubuntu-release- New: accepted leveldb [armhf] (disco-proposed) [1.20-2.1]
-queuebot:#ubuntu-release- New: accepted leveldb [ppc64el] (disco-proposed) [1.20-2.1]
-queuebot:#ubuntu-release- New: accepted leveldb [arm64] (disco-proposed) [1.20-2.1]
-queuebot:#ubuntu-release- New: accepted leveldb [s390x] (disco-proposed) [1.20-2.1]
-queuebot:#ubuntu-release- New: accepted leveldb [i386] (disco-proposed) [1.20-2.1]
-queuebot:#ubuntu-release- Unapproved: gpaste (disco-proposed/universe) [3.30.2-1 => 3.30.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (disco-proposed/main) [1:19.04.15 => 1:19.04.16] (core)
-queuebot:#ubuntu-release- Unapproved: derpconf (disco-proposed/universe) [0.8.2-1 => 0.8.2-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gitsome (disco-proposed/universe) [0.7.0+git20180130.5751a31+ds-1 => 0.7.0+git20180130.5751a31+ds-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: onionbalance (disco-proposed/universe) [0.1.8-3 => 0.1.8-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: preggy (disco-proposed/universe) [1.3.0-1 => 1.3.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: python-bottle (disco-proposed/universe) [0.12.15-1 => 0.12.15-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: python-osmapi (disco-proposed/universe) [1.2.2-1 => 1.2.2-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: python-scales (disco-proposed/universe) [1.0.9-1 => 1.0.9-2] (no packageset) (sync)
<infinity> vorlon: Do you have context on that u-r-u upload (or, rather, can I punt that review to you because reasons)?
-queuebot:#ubuntu-release- Unapproved: accepted derpconf [sync] (disco-proposed) [0.8.2-2]
-queuebot:#ubuntu-release- Unapproved: accepted gpaste [source] (disco-proposed) [3.30.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted preggy [sync] (disco-proposed) [1.3.0-2]
<vorlon> infinity: yes
-queuebot:#ubuntu-release- Unapproved: accepted python-osmapi [sync] (disco-proposed) [1.2.2-2]
-queuebot:#ubuntu-release- Unapproved: accepted gitsome [sync] (disco-proposed) [0.7.0+git20180130.5751a31+ds-2]
-queuebot:#ubuntu-release- Unapproved: accepted python-bottle [sync] (disco-proposed) [0.12.15-2]
-queuebot:#ubuntu-release- Unapproved: accepted onionbalance [sync] (disco-proposed) [0.1.8-4]
-queuebot:#ubuntu-release- Unapproved: accepted python-scales [sync] (disco-proposed) [1.0.9-2]
-queuebot:#ubuntu-release- Unapproved: librime (disco-proposed/universe) [1.4.0+dfsg1-2 => 1.4.0+dfsg1-2build1] (input-methods)
-queuebot:#ubuntu-release- Unapproved: node-leveldown (disco-proposed/universe) [1.5.0+dfsg-3 => 1.5.0+dfsg-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: minetest (disco-proposed/universe) [0.4.17.1+repack-1 => 0.4.17.1+repack-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-leveldb (disco-proposed/universe) [0~svn68-3build5 => 0~svn68-3build6] (no packageset)
-queuebot:#ubuntu-release- Unapproved: stenographer (disco-proposed/universe) [0.0~git20180422.0.73ce5dd-1 => 0.0~git20180422.0.73ce5dd-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: caffe-contrib (disco-proposed/multiverse) [1.0.0+git20180821.99bd997-2ubuntu1 => 1.0.0+git20180821.99bd997-2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: caffe (disco-proposed/universe) [1.0.0+git20180821.99bd997-2build1 => 1.0.0+git20180821.99bd997-2build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (disco-proposed) [1:19.04.16]
<Laney> infinity: So you can sync the real version over.
<Laney> I don't find it sketchy. But you already did what you wanted, so whatever.
-queuebot:#ubuntu-release- Unapproved: gnome-initial-setup (disco-proposed/main) [3.32.1-1ubuntu1 => 3.32.1-1ubuntu2] (ubuntu-desktop, ubuntugnome)
<infinity> Laney: Well, the upload I did is a real sync, just not using the API. :P
<infinity> Laney: (as in, it's your actual .dsc, with your signature on it)
-queuebot:#ubuntu-release- Unapproved: ontospy (disco-proposed/universe) [0~20190107~dfsg1-4 => 0~20190225~dfsg1-1] (no packageset) (sync)
<seb128> the gnome-initial-setup ^ is considered RC by desktop (since the initial setup wizard can't get updates before the first boot so SRU doesn't work to fix issues, and the bug is an annoying one (apps screen being empty in most cases))
-queuebot:#ubuntu-release- Unapproved: accepted ontospy [sync] (disco-proposed) [0~20190225~dfsg1-1]
-queuebot:#ubuntu-release- New: accepted linux-snapdragon [sync] (disco-proposed) [5.0.0-1010.10]
-queuebot:#ubuntu-release- Unapproved: binutils-xtensa-lx106 (disco-proposed/universe) [1 => 2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gcc-xtensa-lx106 (disco-proposed/universe) [1 => 2] (no packageset) (sync)
<vorlon> doko: is gcc-5 meant to stick around for disco?  (speaking of hard-to-process Debian removals...)
-queuebot:#ubuntu-release- Unapproved: caffe-contrib (disco-proposed/multiverse) [1.0.0+git20180821.99bd997-2ubuntu1 => 1.0.0+git20180821.99bd997-2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: caffe (disco-proposed/universe) [1.0.0+git20180821.99bd997-2build1 => 1.0.0+git20180821.99bd997-2build2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ceph (disco-proposed/main) [13.2.4+dfsg1-0ubuntu1 => 13.2.4+dfsg1-0ubuntu2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: librime (disco-proposed/universe) [1.4.0+dfsg1-2 => 1.4.0+dfsg1-2build1] (input-methods)
-queuebot:#ubuntu-release- Unapproved: accepted binutils-xtensa-lx106 [sync] (disco-proposed) [2]
-queuebot:#ubuntu-release- Unapproved: minetest (disco-proposed/universe) [0.4.17.1+repack-1 => 0.4.17.1+repack-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: persistent-cache-cpp (disco-proposed/universe) [1.0.4+16.10.20160823-0ubuntu3 => 1.0.4+16.10.20160823-0ubuntu4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: stenographer (disco-proposed/universe) [0.0~git20180422.0.73ce5dd-1 => 0.0~git20180422.0.73ce5dd-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-xtensa-lx106 [sync] (disco-proposed) [2]
-queuebot:#ubuntu-release- Unapproved: python-leveldb (disco-proposed/universe) [0~svn68-3build5 => 0~svn68-3build6] (no packageset)
-queuebot:#ubuntu-release- Unapproved: node-leveldown (disco-proposed/universe) [1.5.0+dfsg-3 => 1.5.0+dfsg-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected caffe-contrib [source] (disco-proposed) [1.0.0+git20180821.99bd997-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: rejected librime [source] (disco-proposed) [1.4.0+dfsg1-2build1]
-queuebot:#ubuntu-release- Unapproved: rejected node-leveldown [source] (disco-proposed) [1.5.0+dfsg-3build1]
-queuebot:#ubuntu-release- Unapproved: rejected stenographer [source] (disco-proposed) [0.0~git20180422.0.73ce5dd-1build1]
-queuebot:#ubuntu-release- Unapproved: rejected caffe [source] (disco-proposed) [1.0.0+git20180821.99bd997-2build2]
-queuebot:#ubuntu-release- Unapproved: rejected python-leveldb [source] (disco-proposed) [0~svn68-3build6]
-queuebot:#ubuntu-release- Unapproved: rejected minetest [source] (disco-proposed) [0.4.17.1+repack-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted caffe-contrib [source] (disco-proposed) [1.0.0+git20180821.99bd997-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (disco-proposed) [13.2.4+dfsg1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted minetest [source] (disco-proposed) [0.4.17.1+repack-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted persistent-cache-cpp [source] (disco-proposed) [1.0.4+16.10.20160823-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted stenographer [source] (disco-proposed) [0.0~git20180422.0.73ce5dd-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted caffe [source] (disco-proposed) [1.0.0+git20180821.99bd997-2build2]
-queuebot:#ubuntu-release- Unapproved: accepted node-leveldown [source] (disco-proposed) [1.5.0+dfsg-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted librime [source] (disco-proposed) [1.4.0+dfsg1-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted python-leveldb [source] (disco-proposed) [0~svn68-3build6]
<infinity> seb128: Do you have a good testing plan for this gnome-initial-setup (ie: ways to abuse it and make sure you love it)?  The changes are a bit too long for a useful code review other than "yeah, that looks like code that does kinda what you say".
-queuebot:#ubuntu-release- New: accepted linux-meta-snapdragon [sync] (disco-proposed) [5.0.0.1010.3]
<infinity> seb128: (not looking for a written test plan or anything, just a "yeah, we have an idea of how it might break and different ways to exercise it to make sure it's good", or even a "yes, jibel is involved" :P)
<seb128> infinity, the test case it's basically "go through the wizard steps after install and make sure the apps page is not empty"
<seb128> we can also test on a normal system but there snapd is in an happy/stable state so there should be no issue
<infinity> seb128: Right, I guess it was more of a "put snappy in sketchy states, test every possible way of clicking on wizard, win". :P
<infinity> seb128: Anyhow, if you're on top of it, I'm accepting.
<seb128> but from our first round of testing and code review it looks fine (also the regression potential is low, and it's only the last page of the wizard, even if it crashes it's not much different from being empty today)
<seb128> we are
<seb128> thx
-queuebot:#ubuntu-release- Unapproved: accepted gnome-initial-setup [source] (disco-proposed) [3.32.1-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: libnanomsg-raw-perl (disco-proposed/universe) [0.10-1build2 => 0.10-1build3] (no packageset)
<infinity> vorlon: I need to run to vote and pick up my travel laptop from my dad and a few other things, so leaving the queue to you.
<vorlon> infinity: ok
<infinity> vorlon: Timing-wise, I intend to britney block and spin RCs either before bed or when I wake up (depending on how quickly we can migrate the current lot), so do mental math on long builds for seeded stuff.
<vorlon> infinity: was linux-kvm intentionally skipped?
<infinity> systemd migration is probably the one we're waiting on.
<infinity> vorlon: It was skipped because I thought Andy was taking care of his rebase kernels, but maybe he missed that one and walked away. :P
-queuebot:#ubuntu-release- Unapproved: accepted libnanomsg-raw-perl [source] (disco-proposed) [0.10-1build3]
<infinity> vorlon: Feel free.
<infinity> (or feel free to poke apw about why it was missed)
<vorlon> accepted it
-queuebot:#ubuntu-release- Unapproved: accepted linux-kvm [sync] (disco-proposed) [5.0.0-1003.3]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-kvm [sync] (disco-proposed) [5.0.0.1003.3]
<infinity> I'll do a final (hopefully) d-i upload to migrate the kernel before said block-and-RC dance.
-queuebot:#ubuntu-release- Unapproved: leiningen-clojure (disco-proposed/universe) [2.8.1-9 => 2.9.0-1] (no packageset) (sync)
<infinity> apw: linux-restricted-modules appears to need a version bump.
-queuebot:#ubuntu-release- Unapproved: accepted leiningen-clojure [sync] (disco-proposed) [2.9.0-1]
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (disco-proposed/main) [0.131ubuntu18 => 0.131ubuntu19] (core)
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (disco-proposed) [0.131ubuntu19]
<apw> infinity: again? sigh, thanks
-queuebot:#ubuntu-release- Unapproved: munin (disco-proposed/universe) [2.0.37-1ubuntu1 => 2.0.47-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted munin [source] (disco-proposed) [2.0.47-1ubuntu1]
<xnox> infinity, about that crashy apt esm hook
<xnox> infinity, still crashy on s390x.... with 18.03, and now crashy on line 184
<xnox> infinity, yes access R_OK guard is true, and yes we still crash.
-queuebot:#ubuntu-release- Unapproved: pomegranate-clojure (disco-proposed/universe) [1.1.0-1 => 1.1.0+really-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pomegranate-clojure [sync] (disco-proposed) [1.1.0+really-1]
-queuebot:#ubuntu-release- Unapproved: mariadb-10.1 (bionic-proposed/universe) [1:10.1.38-0ubuntu0.18.04.1 => 1:10.1.38-0ubuntu0.18.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mariadb-10.1 (cosmic-proposed/universe) [1:10.1.29-6ubuntu2 => 1:10.1.38-0ubuntu0.18.10.1] (no packageset)
<xnox> reopened https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/1824523
<ubot5`> Ubuntu bug 1824523 in ubuntu-advantage-tools (Ubuntu) "Assertion error during iso build" [Critical,Confirmed]
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (disco-proposed/main) [2.576 => 2.577] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (disco-proposed) [2.577]
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (disco-proposed/main) [2.576 => 2.577] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (disco-proposed) [2.577]
-queuebot:#ubuntu-release- Unapproved: unity-greeter (disco-proposed/universe) [18.04.0+18.10.20180926-0ubuntu2 => 18.04.0+19.04.20190410-0ubuntu1] (mythbuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: unity-scope-home (disco-proposed/universe) [6.8.2+16.04.20160212.1-0ubuntu3 => 6.8.2+19.04.20190412-0ubuntu1] (no packageset) (sync)
<vorlon> xnox: I've merged https://code.launchpad.net/~vorlon/ubuntu-cdimage/no-hard-coded-style/+merge/365882 now, if you could rebase your vanilla on that
<xnox> vorlon, i also wonder if that breaks all of ubuntu.
<xnox> vorlon, cause i thought our <style> block there is overrides to vanilla, hence should come after it is included.
<xnox> vorlon, or are they all /suplemental/ styles.
<vorlon> well we can try it and see
<xnox> vorlon, is there a css parser to like generate the end computed styles, to compare that changing this doesn't change the assembled result?
<xnox> something like that.
<vorlon> xnox: old: http://cdimage.ubuntu.com/daily-live/20190411.2/ new: http://cdimage.ubuntu.com/daily-live/20190412/ spot the difference
<vorlon> css parser> not my department
<vorlon> anyway, they both look the same to me
<vorlon> which is what I would expect - I would not expect us to be overriding any styles declared in vanilla, only supplementing them
<xnox> vorlon, looks all wrong to me.
<xnox> vorlon, the criss-cross on the banner logo is in a different place.
<xnox> unless banner logo is like dynamically generated on per page view.
<vorlon> xnox: oh. that's because the original code had a bug, and declared 'background-position: 75% 50%' except this was done in a wrong context that caused it to be interpreted as a special character
<xnox> vorlon, the fold is at the bottom of the logo, versus center of the logo.
<xnox> sigh
<xnox> sigh
<xnox> sigh
<vorlon> so instead of 'background-position: 75% 50%', you got 'background-position: 75                                               %'
<vorlon> ;D ;D
<vorlon> so I can revert that if it causes it to display incorrectly
<xnox> vorlon, i'll check with the webteam as to where the fold should be next week
<vorlon> xnox: in the meantime I will make it bug-compatible with the previous
<xnox> vorlon, both of these urls will stay live? well i can just take a screenshot on my system.
<vorlon> xnox: at least the first one will age out
<vorlon> xnox: better? http://cdimage.ubuntu.com/daily-live/20190412/
<xnox> vorlon, it's the same as the old 0412, and still different to the 11.2
<xnox> vorlon, if you think that <style> block and inline style="" behave the same, good luck! =)
<xnox> vorlon, i can edit this live in my browser, let me experiment like that
<xnox> easier with ctrl+shit+c thing
<xnox> c+s+I obviously
<xnox> hm
<xnox> no idea
<xnox> vorlon, just delete background-position at all
<xnox> vorlon, as google chrome helpfully tells me is that 'background-position: 75 %' is invalid property value
<xnox> hence old one had no background-position at all.
<vorlon> xnox: k, pushed again
<xnox> great! looks nice.
-queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (disco-proposed/main) [19.3 => 19.4] (core)
<ahasenack> xnox: vorlon: ^
<ahasenack> powersj: ^
<powersj> ahasenack, thank you
-queuebot:#ubuntu-release- Unapproved: accepted unity-greeter [sync] (disco-proposed) [18.04.0+19.04.20190410-0ubuntu1]
<vorlon> ahasenack, xnox, powersj: accepted
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-advantage-tools [source] (disco-proposed) [19.4]
-queuebot:#ubuntu-release- Unapproved: munin (disco-proposed/universe) [2.0.47-1ubuntu1 => 2.0.47-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted unity-scope-home [sync] (disco-proposed) [6.8.2+19.04.20190412-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted munin [source] (disco-proposed) [2.0.47-1ubuntu2]
-queuebot:#ubuntu-release- New: rejected intel-opencl-clang [source] (disco-proposed) [8.0.0-0ubuntu1]
<xnox> vorlon, multipath-tools is a valid candidate now.
 * vorlon braces for impact
<xnox> oh and it migrated too.
<xnox> oh well, i thought we are in such a freeze that requires manual unblocks.
<xnox> vorlon, systemd passes all tests, bug ppc64le which is still https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1814373 i believe. I wonder if i should simply mark the test cases as "meh" when on ppc64le
<ubot5`> Ubuntu bug 1814373 in linux (Ubuntu) "storage / luks / dmsetup regressed (or got better) on ppc64le" [Undecided,Confirmed]
<xnox> still waiting on systemd/i386, and everything else passed or it's linux -> which with kernel in proposed should be passing fine actually. I wonder if i should retrigger those with -proposed.
<vorlon> xnox: I thought failure to remove scsi_debug module was to be made nonfatal?
<vorlon> oh, or is that not the bit that failed
<vorlon> right
<xnox> vorlon, the bit that failed is "luks cryptsetup from a previous test case is still clogged up, cannot test something else"
<xnox> vorlon, i guess i can work around this by using unique names for devmapper names, but i don't think i can have multiple scsi debug volumes.... which is what is actually clogged up. and we know i can't just remove the module, as that fails.....
<xnox> and well peppers over the issue, that stopping / unmounting things / udevadm settle => doesn't give us back a known state, for some reason.
<wxl> maybe using luks1 would help
 * wxl ducks
<vorlon> have you tried reproducing this on ppc64el?
<vorlon> (did you ever create a linear reproducer that wasn't dependent on python unittest decorations and destructors?)
#ubuntu-release 2019-04-13
-queuebot:#ubuntu-release- Unapproved: munin (disco-proposed/universe) [2.0.47-1ubuntu2 => 2.0.47-1ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted munin [source] (disco-proposed) [2.0.47-1ubuntu3]
<vorlon> xnox: http://cdimage.ubuntu.com/ubuntu-server/daily-live/20190412.4/ ought to have the u-a-t fix
-queuebot:#ubuntu-release- New: accepted intel-opencl-clang [source] (disco-proposed) [8.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: intel-opencl-clang [i386] (disco-proposed/universe) [8.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: intel-opencl-clang [amd64] (disco-proposed/universe) [8.0.0-0ubuntu1] (no packageset)
<vorlon> tjaalton: I: intel-graphics-compiler source: wildcard-matches-nothing-in-dep5-copyright third_party/opencl_headers (paragraph at line 10)
-queuebot:#ubuntu-release- New: accepted intel-graphics-compiler [source] (disco-proposed) [1.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted intel-opencl-clang [amd64] (disco-proposed) [8.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted intel-opencl-clang [i386] (disco-proposed) [8.0.0-0ubuntu1]
<tjaalton> vorlon: oh, a typo there..
<tjaalton> vorlon: thanks for the reviews!
-queuebot:#ubuntu-release- New sync: smrtanalysis (disco-proposed/primary) [0~20180814]
-queuebot:#ubuntu-release- New sync: node-cosmiconfig (disco-proposed/primary) [3.1.0-2]
<tjaalton> same bugs with compute-runtime it seems
-queuebot:#ubuntu-release- New: rejected node-cosmiconfig [sync] (disco-proposed) [3.1.0-2]
-queuebot:#ubuntu-release- New: rejected smrtanalysis [sync] (disco-proposed) [0~20180814]
-queuebot:#ubuntu-release- Unapproved: debian-installer (disco-proposed/main) [20101020ubuntu568 => 20101020ubuntu569] (core)
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (disco-proposed) [20101020ubuntu569]
-queuebot:#ubuntu-release- Unapproved: caffe (disco-proposed/universe) [1.0.0+git20180821.99bd997-2build2 => 1.0.0+git20180821.99bd997-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted caffe [source] (disco-proposed) [1.0.0+git20180821.99bd997-2ubuntu1]
<ginggs> infinity: i've just filed #926985 ^
<ginggs> debian bug #926985
<ubot5`> Debian bug 926985 in src:caffe "caffe: FTBFS, no output PDF file produced!" [Serious,Open] http://bugs.debian.org/926985
<ginggs> ubot5`: thanks
<ubot5`> You're welcome! But keep in mind I'm just a bot ;-)
<infinity> ginggs: It's a texlive-extra bug, already open.
<infinity> ginggs: The one I referenced in the changelog. :P
<infinity> ginggs: So go forth and merge.
<ginggs> infinity: yeah, i saw, but if texlive-extra doesn't get fixed, cafe should workaround
<infinity> ginggs: Well, sure.  Feel free to suggest my workaround for now.  It only skips building the refman.pdf, everything else remains intact, so not world-ending.
<ginggs> infinity: ack, i'll add your workaround to the bug
<ginggs> infinity: if you have a minute, would you look at gpustat in disco NEW please?
-queuebot:#ubuntu-release- New: accepted gpustat [sync] (disco-proposed) [0.5.0-2]
-queuebot:#ubuntu-release- New binary: gpustat [amd64] (disco-proposed/multiverse) [0.5.0-2] (no packageset)
<ginggs> infinity: thanks!
-queuebot:#ubuntu-release- New binary: intel-graphics-compiler [amd64] (disco-proposed/universe) [1.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gpustat [amd64] (disco-proposed) [0.5.0-2]
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (disco-proposed/main) [2.577 => 2.578] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (disco-proposed) [2.578]
-queuebot:#ubuntu-release- New: accepted intel-graphics-compiler [amd64] (disco-proposed) [1.0.0-0ubuntu1]
<LocutusOfBorg> infinity, is it possible to try to move puma autopkgtests to a more capable machine?
<LocutusOfBorg> also please somebody decruft knot-resolver? old binaries left on amd64: libkres-dev, libkres9 (from 3.2.1-1)
<LocutusOfBorg> NBS in proposed
<infinity> LocutusOfBorg: What would you like the machines to be more capable of doing?
<infinity> The regressions don't look in any way load-related.
<LocutusOfBorg> infinity, I remember some days ago x no x saying he wasn't able to reproduce on his machine
<LocutusOfBorg> in any case, I'm doing a no change test rebuild here http://debomatic-amd64.debian.net/distribution#disco/puma/3.12.0-2build1/autopkgtest
<LocutusOfBorg> also, ceres-solver is now not built anymore on arm64 and ppc64el... please kick binaries out? Debian did that months ago IIRC
<LocutusOfBorg> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919786
<ubot5`> Debian bug 919786 in ftp.debian.org "RM: ceres-solver [arm64 ppc64el] -- ROM; newer release FTBFS on arm64 and ppc64el" [Normal,Open]
<LocutusOfBorg> infinity, it works on debomatic, so I presume some misconfiguration somewhere? not a real bug I would say
<infinity> How did that prove anything?
<LocutusOfBorg> mmm why shouldn't it, it is an autopkgtest ran on the same disco baseline...
<infinity> And a different binary.
<LocutusOfBorg> so you mean a no-change rebuild might fix that?
<infinity> No idea.
<infinity> Probably not.
<LocutusOfBorg> mmm so I don't get what is your opinion :)
<infinity> But "it works when I change a bunch of variables, so please ignore the failures" isn't a helpful analysis.
<LocutusOfBorg> I'm not saying "ignore the failures", but please try to move to a more capable machine
<LocutusOfBorg> :)
<LocutusOfBorg> if it is possible to do a "one shot test against big packages"
<LocutusOfBorg> that is the request
<infinity> The point of CI tests are to establish a baseline and track regressions.  "I guess it'll just always fail" isn't a good baseline.
<LocutusOfBorg> in the meanwhile I'm uploading in my ppa
<infinity> Define "more capable machine".
<infinity> The tests are running in under 10 minutes.  Nothing's timing out.
<infinity> What do you think is wrong with "the machine".
<infinity> All 6 arches, no less.
<infinity> Is our mainframe too slow for you?
<LocutusOfBorg> for me its ok :D maybe it isn't for the package :p
<infinity> ...
<LocutusOfBorg> anyway, lets wait a no-change rebuild in my ppa, some testing run and I'll be back
<LocutusOfBorg> in any case, is it possible to move knot-resolver and ceres-solver a little bit further?
<infinity> knot-resolver is done.
<infinity> I'm looking at ceres.  It has an rdep.  Looking to see what Debian did there.
<infinity> But, seriously, think before you say "your machine is too slow" or whatever. :P
<infinity> It's clearly not a speed issue.
<infinity> s390x executes the tests in 39s.  Same as your debomatic run.
<infinity> Fails the same as all other 5 arches.
<LocutusOfBorg> infinity, I never said the machine was slow, did I?
<LocutusOfBorg> I said "more capable", and with that I think wrt more ram or similar
<LocutusOfBorg> that would explain why debian did not have this failure
<LocutusOfBorg> I agree that "slow" might be not the case
<infinity> ...
<infinity> It's not RAM either.
<LocutusOfBorg> so maybe some iptables or network configuration? dns?
<infinity> "more capable" might mean "a different network setup" or something esoteric like that, but that would require actually looking at the code failing instead of lobbing darts in the dark.
<LocutusOfBorg> I'm trying to see by looking at failures, I already looked at the code but I speak zero ruby
<LocutusOfBorg> also, another guess is that something is badly parsing some system parameter, maybe because its a container or similar
<infinity> It's not a container (except on armhf)
<infinity> The other 5 arches are kvm.
<LocutusOfBorg> network might be the culprit, the failing test does:
<LocutusOfBorg>       hit(["http://0.0.0.0:#{ launcher.connected_port }/test"])
<LocutusOfBorg> not sure what it means
-queuebot:#ubuntu-release- Unapproved: update-notifier (disco-proposed/main) [3.192.17 => 3.192.18] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (disco-proposed) [3.192.18]
<LocutusOfBorg> infinity, does knot-resolver need a bigger hammer on arm64?
<LocutusOfBorg> missing build on arm64: libkres-dev, libkres9 (from 3.2.0-1)
<LocutusOfBorg> it is not built anymore on arm64 due to lua
<infinity> LocutusOfBorg: Hammered before you asked.  Next britney after the next publisher should have more interesting things to say.
<infinity> LocutusOfBorg: Also retried knot/knot-resolver tests as a proposed pair to see if that works.
<infinity> Gonna nap for a bit and then probably declare the rest of proposed a lost cause when I wake up and britney block and spin some images.
<LocutusOfBorg> thanks, that was my ongoing activity, so I can now go back to puma :D
-queuebot:#ubuntu-release- Unapproved: hypre (disco-proposed/universe) [2.15.1-4 => 2.15.1-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: sip4 (disco-proposed/universe) [4.19.15+dfsg-1 => 4.19.15+dfsg-1ubuntu1] (kubuntu)
<tsimonq2> I realized Lubuntu hadn't done a seed update since the cycle opened. Updated and uploaded.
-queuebot:#ubuntu-release- Unapproved: lubuntu-meta (disco-proposed/universe) [1.16 => 19.04.1] (lubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted lubuntu-meta [source] (disco-proposed) [19.04.1]
<wxl> infinity: i found a rather weird regression in the current disco relative to beta: we seem to have english (uk) set as the default keyboard layout
<wxl> infinity: we've had only one change to our default settings and that's not it.. we've had no change in upstream lxqt-config which is used to manage the  keyboard layouts.. so is there some goofiness going on with ubuntu?
<wxl> infinity: nevermind. i don't like flukes but it seems i had one.
<infinity> wxl: "default" keyboard layout should be based on geoip.
<infinity> wxl: As in, it'll attempt to pick the right timezone, language, and keyboard.
<wxl> maybe geoip hiccuped. i dunno.
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Disco Final] (20101020ubuntu569) has been added
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Disco Final] (20101020ubuntu569) has been added
-queuebot:#ubuntu-release- Builds: Netboot armhf [Disco Final] (20101020ubuntu569) has been added
-queuebot:#ubuntu-release- Builds: Netboot i386 [Disco Final] (20101020ubuntu569) has been added
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Disco Final] (20101020ubuntu569) has been added
-queuebot:#ubuntu-release- Builds: Netboot s390x [Disco Final] (20101020ubuntu569) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Disco Final] (20190413.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Disco Final] (20190413.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Disco Final] (20190413.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Disco Final] (20190413.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Disco Final] (20190413.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Disco Final] (20190413.1) has been added
<infinity> ^ Same as the last few release cycles, these images don't have base-files or the ISO label updated, but please test, test, test, so I can spin "real" RCs on Monday with any fixes people commit between now and then.
<infinity> tsimonq2: Can you send out a call for testing?  I'm running a bit late to the airport.
<valorie> so this is the alpha RC?
<valorie> lol
<infinity> The "test it and fix stuff now, FFS" pre-RC. :P
<infinity> Cause testing later is too late.
<Bashing-om> tsimonq2: https://discourse.ubuntu.com/t/disco-disco-19-04-release-candidate-testing/10570 .
<infinity> Yay jibel.
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Disco Final] (20190413.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Disco Final] (20190413.1) has been added
<bluesabre> woohoo
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Disco Final] (20190413.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Disco Final] (20190413.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Disco Final] (20190413.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Disco Final] (20190413.1) has been added
<teward> infinity: FWIW I don't think you'll hear anything from tsimonq2 for the next 5 hours
<teward> or more
<teward> Bashing-om: ^
<teward> (he's at his prom)
<teward> so if it's more urgent you'll want to hand it off to someone else
<Bashing-om> teward: ack
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Disco Final] (20190413.2) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Disco Final] (20190413.1) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Disco Final] (20190413.2) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Disco Final] (20190413.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Disco Final] (20190413.3) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Disco Final] (20190413) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi3 [Disco Final] (20190413.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Disco Final] (20190413.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi3 [Disco Final] (20190413.1) has been added
<tsimonq2> infinity: I have some spare time right now.
<tsimonq2> Sure.
<valorie> okey-dokey
<valorie> tweeting as soon as tsimonq2 has a link to share
 * Eickmeyer just emailed his -devel list
<tsimonq2> infinity: Here, have a ready-to-go base-files.\
<valorie> Eickmeyer: me too
-queuebot:#ubuntu-release- Unapproved: base-files (disco-proposed/main) [10.1ubuntu8 => 10.1ubuntu9] (core)
<valorie> but I need a good link for the tweeteroo
<tsimonq2> infinity: (Saves you work, so when it's ready, you can accept.)
-queuebot:#ubuntu-release- Unapproved: rejected base-files [source] (disco-proposed) [10.1ubuntu9]
-queuebot:#ubuntu-release- Unapproved: rejected sip4 [source] (disco-proposed) [4.19.15+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted hypre [sync] (disco-proposed) [2.15.1-5]
<Eickmeyer> https://lists.ubuntu.com/archives/ubuntu-release/2019-April/004748.html
<valorie> and we're off!
<valorie> https://twitter.com/kubuntu/status/1117206913156993024
<infinity> Huzzah.
<infinity> I expect to check in to my hotel to either a barrage of new bugs or a bunch of people telling me everything's perfect.
<infinity> (the latter would be a nice change)
<stgraber> :)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Disco Final] (20190413.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Disco Final] (20190413.1) has been added
<Eickmeyer> https://twitter.com/ubuntustudio/status/1117207629468553216
* tsimonq2 changed the topic of #ubuntu-release to: Released: Bionic 18.04.2, Cosmic 18.10, Disco Beta | Archive: FF, DIF, Final Freeze | Disco Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melius malum quod cognoscis
#ubuntu-release 2019-04-14
<The_LoudSpeaker> Hey! We at #lubuntu-devel were considering making changes to grub commands during installation of lubuntu so that the nvram entry and the menu entry of grub read "Lubuntu" instead of current "ubuntu". We wanted to know your thoughts on it. TIA
<flocculant> infinity: I'm not about much anymore - but still in Xubuntu Release team till the end of the week - just rebooted into new kernel and bug 1824677
<ubot5`> bug 1824677 in xserver-xorg-video-nouveau (Ubuntu) "Display only has 640x480" [Undecided,New] https://launchpad.net/bugs/1824677
-queuebot:#ubuntu-release- Unapproved: python-django-mptt (disco-proposed/universe) [0.8.5-0.1ubuntu1 => 0.8.7-1] (no packageset) (sync)
<mparillo> I am sure it has been discussed, but I like the idea of having flavour-specific grub menu items, for those of us who dual-boot two different flavours.
<infinity> tjaalton: Care to poke at LP: #1824677?
<ubot5`> Launchpad bug 1824677 in xserver-xorg-video-nouveau (Ubuntu) "Display only has 640x480" [Undecided,Confirmed] https://launchpad.net/bugs/1824677
<infinity> mparillo: How does update-grub decide which flavour you have installed when you have kubuntu-desktop, ubuntu-desktop, and lubuntu-desktop all installed?
<infinity> mparillo: Which is probably about as common as people who install them in side-by-side partitions.
<infinity> (Which is to say, not very common in either case)
<tjaalton> infinity: nouveau modeset is now disabled by default, I'll tell him how to enable it..
<mparillo> Fair enough. I always dual-booted rather than picking a desktop through SDDM, but as you say, neither is a common use case.
<mparillo> I see in my current ISO testing lsb_release -a still says (development branch). I assume that gets removed just before the release is marked, correct?
<infinity> mparillo: That will go away with Monday's builds.  But I want weekend testing so maybe we have some things to fix on Monday. :P
<infinity> tjaalton: Being thrust back into 1992 suddenly is a bit jarring.  Is that how it's going to go for all nouveau users, or just some small subset of PCI IDs?
<tjaalton> infinity: for everyone who haven't installed nvidia blob
<infinity> :/
<tjaalton> nouveau.modeset=1 re-enables it
<infinity> That... Suboptimal.
<infinity> s/That/That's/
<infinity> What was the motivation for that?
<tjaalton> bug 1821820
<ubot5`> bug 1821820 in xorg-server (Ubuntu) "Cannot boot or install - have to use nomodeset" [Low,Fix committed] https://launchpad.net/bugs/1821820
<mparillo> Thanks infinity. So I will mark my test case as passed for now, expecting a Monday re-spin.
<infinity> tjaalton: But that was an Intel bug..
<tjaalton> no
<tjaalton> someone hijacked it
<tjaalton> that bug is what I mentioned on the kernel channe..
<tjaalton> l
<tjaalton> https://patchwork.freedesktop.org/patch/296411/ needed for some intel
<tjaalton> with buggy panels
<tjaalton> I discussed the nouveau thing with upstream, and they said the firmware is buggy, and it frequently is
<infinity> (someone hijacked what?)
<infinity> 1821820 is very much all i915 all the time.
<tjaalton> no it isn't, the original reporter has a hybrid machine and nouveau is messing it up
<tjaalton> and reported that the new kernel works
<infinity> lspci disagrees with you.
<tjaalton> haha
<tjaalton> ok, wrong bug
<tjaalton> hang on
<tjaalton> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1822026
<ubot5`> Ubuntu bug 1822026 in linux (Ubuntu Disco) "[Dell Precision 7530/5530 with Nvidia Quadro P1000] Live USB freezes or cannot complete install when nouveau driver is loaded (crashing in GP100 code)" [Undecided,Fix released]
<infinity> Anyhow, I'm not super happy with a solution that forces everyone down to 640x480.  I don't know what per centage of our install base is nvidia, and what per centage of those use the free driver, but I assume it's a non trivial number of people.
<tjaalton> maybe would be better to disable only on "new enough" hw
<tjaalton> which require buggy fw
<infinity> More problematic, for my inner hippie, is that I feel this is just going to force people to install the non-free driver when they don't need to, since there's no obvious way in the GUI to re-enable modeset.
<infinity> Plus, for old GPUs, the non-free driver is a mess.
<infinity> I mean, it's not great for new ones either, but at least it's maintained. :P
<infinity> I wonder if we could fudge a nouveau modeset "driver" in ubuntu-drivers that just installs a modprobe.d snippet and warns about the potential dangers.
<infinity> So users have a choice in the driver panel between free (but maybe buggy) and non-free (but differently buggy).
<tjaalton> perhaps
<tjaalton> I'll think of how to make this a smaller gun
<tjaalton> and limit it to "fresh" hw
<flocculant> tjaalton: ta :)
<tjaalton> flocculant: for what?
<tjaalton> flocculant: oh, got it
-queuebot:#ubuntu-release- Unapproved: latte-dock (disco-proposed/universe) [0.8.7-0ubuntu1 => 0.8.8-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: blis (disco-proposed/universe) [0.5.1-11 => 0.5.2-6] (no packageset) (sync)
<xnox> Laney, infinity, do we need more noawait triggers somewhere? Look for "cycle found while processing triggers"
<xnox> http://paste.ubuntu.com/p/GPTn3d2Dr4/
#ubuntu-release 2020-04-06
-queuebot:#ubuntu-release- Unapproved: flatpak (focal-proposed/universe) [1.6.2-1 => 1.6.3-1] (ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted flatpak [sync] (focal-proposed) [1.6.3-1]
-queuebot:#ubuntu-release- Unapproved: libarchive (focal-proposed/main) [3.4.0-1ubuntu2 => 3.4.0-2ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: gtk+3.0 (focal-proposed/main) [3.24.14-1ubuntu1 => 3.24.14-1ubuntu2] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: xubuntu-community-artwork (focal-proposed/universe) [18.04.0 => 20.04.0] (ubuntustudio, xubuntu)
<bluesabre> Hello release team! Please accept the above xubuntu-community-artwork package. It includes the new wallpapers from our wallpaper contest (https://xubuntu.org/news/xubuntu-20-04-community-wallpaper-contest-winners/) and does not affect documentation, screenshots, or translations in any way.
<vorlon> RikMills: what source package names specifically are you looking for wrt plasma?
<vorlon> RikMills: and I've re-added my cowboy hack to let britney pass again :/
-queuebot:#ubuntu-release- Unapproved: wireguard-linux-compat (eoan-proposed/universe) [0.0.20200205-1ubuntu1~19.10.1 => 1.0.20200401-1ubuntu1~19.10.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: wireguard (eoan-proposed/universe) [1.0.20200206-1ubuntu1~19.10.1 => 1.0.20200319-1ubuntu1~19.10.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: kwallet-kf5 (focal-proposed/universe) [5.68.0-0ubuntu1 => 5.68.0-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: qtwebkit-opensource-src (focal-proposed/universe) [5.212.0~alpha4-1 => 5.212.0~alpha4-1ubuntu1] (i386-whitelist, kubuntu, qt5)
-queuebot:#ubuntu-release- Unapproved: ftgl (focal-proposed/universe) [2.4.0-2build1 => 2.4.0-2ubuntu1] (edubuntu, ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: accepted fwupd-signed [source] (focal-proposed) [1.27]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [sync] (focal-proposed) [1.3.9-4]
-queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.9-4 => 1.3.9-4] (core)
-queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.9-4 => 1.3.9-4] (core)
-queuebot:#ubuntu-release- Unapproved: accepted ftgl [source] (focal-proposed) [2.4.0-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtwebkit-opensource-src [source] (focal-proposed) [5.212.0~alpha4-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: jemalloc (focal-proposed/universe) [5.2.1-1build1 => 5.2.1-1ubuntu1] (i386-whitelist, ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.9-4 => 1.3.9-4] (core)
-queuebot:#ubuntu-release- Unapproved: accepted kwallet-kf5 [source] (focal-proposed) [5.68.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: jemalloc (focal-proposed/universe) [5.2.1-1build1 => 5.2.1-1ubuntu1] (i386-whitelist, ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: accepted gtk+3.0 [source] (focal-proposed) [3.24.14-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: libvncserver (focal-proposed/main) [0.9.12+dfsg-8 => 0.9.12+dfsg-9] (i386-whitelist, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted qtlocation-opensource-src [source] (focal-proposed) [5.12.5+dfsg-5ubuntu1]
-queuebot:#ubuntu-release- Unapproved: session-migration (focal-proposed/main) [0.3.4 => 0.3.5] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [amd64] (focal-proposed) [1.3.9-4]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [armhf] (focal-proposed) [1.3.9-4]
-queuebot:#ubuntu-release- Unapproved: python-pysnmp4 (focal-proposed/main) [4.4.6+repack1-1build1 => 4.4.6+repack1-2] (ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [arm64] (focal-proposed) [1.3.9-4]
-queuebot:#ubuntu-release- Unapproved: python-seamicroclient (focal-proposed/universe) [0.4.0+2016.05.20.git.40ee44c664-2ubuntu1 => 0.4.0+2016.05.20.git.40ee44c664-3ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: libarchive (focal-proposed/main) [3.4.0-1ubuntu2 => 3.4.0-2ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: libdbusmenu (focal-proposed/main) [16.04.1+18.10.20180917-0ubuntu5 => 16.04.1+18.10.20180917-0ubuntu6] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: mesa (focal-proposed/main) [20.0.2-1ubuntu1 => 20.0.4-1ubuntu1] (core, i386-whitelist, xorg)
-queuebot:#ubuntu-release- Unapproved: datefudge (focal-proposed/universe) [1.23 => 1.23ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: chrony (focal-proposed/main) [3.5-6ubuntu2 => 3.5-6ubuntu3] (core)
-queuebot:#ubuntu-release- New source: pop-icon-theme (focal-proposed/primary) [2.1.0~1571158475~19.10~6bf9347]
-queuebot:#ubuntu-release- Unapproved: nss-wrapper (focal-proposed/universe) [1.1.3-1 => 1.1.11-1] (i386-whitelist) (sync)
<RikMills> vorlon: thanks. doko took care of plasma
-queuebot:#ubuntu-release- Unapproved: faketime (focal-proposed/universe) [0.9.7-3 => 0.9.7-3ubuntu1] (edubuntu, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: libva (focal-proposed/universe) [2.6.1-1 => 2.7.0-1] (i386-whitelist, kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: intel-gpu-tools (focal-proposed/universe) [1.25-1 => 1.25-2] (i386-whitelist, ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted datefudge [source] (focal-proposed) [1.23ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (focal-proposed/main) [20.2.1~0ubuntu1 => 20.3] (core)
-queuebot:#ubuntu-release- Unapproved: accepted faketime [source] (focal-proposed) [0.9.7-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-meta (focal-proposed/universe) [1.261 => 1.262] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: accepted chrony [source] (focal-proposed) [3.5-6ubuntu3]
-queuebot:#ubuntu-release- Unapproved: jemalloc (focal-proposed/universe) [5.2.1-1build1 => 5.2.1-1ubuntu1] (i386-whitelist, ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: accepted libdbusmenu [source] (focal-proposed) [16.04.1+18.10.20180917-0ubuntu6]
-queuebot:#ubuntu-release- Unapproved: gnat (focal-proposed/universe) [9ubuntu1 => 9ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gnat [source] (focal-proposed) [9ubuntu2]
-queuebot:#ubuntu-release- Unapproved: libvncserver (focal-proposed/main) [0.9.12+dfsg-8 => 0.9.12+dfsg-9] (i386-whitelist, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: shadow (focal-proposed/main) [1:4.8.1-1ubuntu3 => 1:4.8.1-1ubuntu4] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: mate-terminal (focal-proposed/universe) [1.24.0-1 => 1.24.0-2ubuntu1] (ubuntu-mate, ubuntukylin)
<Laney> vorlon: how come you went for cowboying rather than committing? you must have had to disable the automatic 'git pull' too?
-queuebot:#ubuntu-release- Unapproved: apt (focal-proposed/main) [2.0.1 => 2.0.1ubuntu1] (core, i386-whitelist)
<juliank> ^ please accept
<juliank> sil2100: ^
<juliank> doko: ^^ fix for gnutls28 regression
<juliank> I'll do 2.0.2 end of week or so, gathering some minor doc fixes and translation updates, but this is more urgent :)
<sil2100> Looking
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (focal-proposed) [2.0.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-meta (focal-proposed/universe) [1.261 => 1.262] (ubuntu-mate)
<juliank> thanks sil2100
-queuebot:#ubuntu-release- Unapproved: accepted python-seamicroclient [source] (focal-proposed) [0.4.0+2016.05.20.git.40ee44c664-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libappindicator (focal-proposed/main) [12.10.1+18.04.20180322.1-0ubuntu5 => 12.10.1+18.04.20180322.1-0ubuntu6] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: multipath-tools (focal-proposed/main) [0.8.3-1ubuntu1 => 0.8.3-1ubuntu2] (core, i386-whitelist)
<jibel> could someone review and approve grub2 ?
<jibel> and grub2-signed
-queuebot:#ubuntu-release- Unapproved: gnome-tweaks (focal-proposed/universe) [3.34.0-2 => 3.34.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-tweaks [source] (focal-proposed) [3.34.0-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libappindicator [source] (focal-proposed) [12.10.1+18.04.20180322.1-0ubuntu6]
<juliank> ugh
<juliank> that grub2 upload breaks my grub2 branch
<juliank> And I have no idea how to get this fixed sensibly
-queuebot:#ubuntu-release- Unapproved: accepted multipath-tools [source] (focal-proposed) [0.8.3-1ubuntu2]
<juliank> because of git-dpm merges in there, I need to rebase two branches basically
<didrocks> juliank: the git branch is updated in master though with latest upload, right? (on Friday)
<didrocks> but yeah git dpm with parallel workâ¦ Not enough experience with this :/
<juliank> didrocks: Well, yes, but how do I rebase my changes on top of that, that is the question :)
<didrocks> right
<didrocks> the other time this happened, I just rebase and restarted, was the easiest
<didrocks> not done that enough times to invest in looking in a more sensible solution
<cjwatson> Hm, are unsatisfiable dependencies on riscv64 meant to be blocking migration at the moment?  That seems like an odd approch
<cjwatson> *approach
<cjwatson> Looking at https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#putty
<cjwatson> Feels like it should be in NEW_ARCHES
<cjwatson> (I mean, I know that a gtk+3.0 fix is building at the moment, that's not the point)
<doko> vor lon mentioned that he deployed a kludge for that
<xnox> or it should look at bootstrap archive?!
<doko> I also noticed that glibc migrated despite autopkg tests not completely run, and having an autopkg test failure in glibc itself
<cjwatson> xnox: ugh, no
<xnox> ok
<xnox> jbicha:  do you have an upload for software-center-aptdaemon-plugins too? or should that package be removed? as it currently depends on python-piston-mini-client (which depends on python-oauthlib)
<cjwatson> There is a kludge in place which I don't understand why it wasn't a config file change
<Laney> I only see mention of that kludge or whatever it is being for a crash fix
<Laney> in the backlog here
<cjwatson> -                if (false_negatives or false_positives) and arch not in self.options.break_arches:
<xnox> jbicha:  (and in unapproved you try to drop both python-oauthlib & python-piston-mini-client)
<cjwatson> +                # vorlon 20200405 riscv64 cowboying, we don't want britney to break every time packages become installable
<cjwatson> +                if (false_negatives or false_positives) and arch not in self.options.break_arches and arch != 'riscv64':
<cjwatson> If that had been in BREAK_ARCHES in the config file instead then I think things would work better?
<Laney> I can't speak for what vorlo_n was intending to achieve there since I can only find references to fixing a crash (https://paste.ubuntu.com/p/CS8YfDCXYX/)
<Laney> Putting it in one of those config items makes sense to *me* though
<Laney> wgrant: ^- any opinion?
<wgrant> My assumption was that britney would be configured to not block on this sort of thing, yeah...
<wgrant> NEW_ARCHES and possibly FUCKED_ARCHES
<wgrant> But last time I touched britney was before Ubuntu used it...
<wgrant> apparently these things have been renamed now
<doko> but then it wouldn't wait for transitions to be completed on riscv64?
<cjwatson> It's been called OUTOFSYNC_ARCHES for a while :)
<wgrant> 2017 apparently, indeed.
<cjwatson> 2016
<cjwatson> Or 2013 in the Ubuntu branch
<cjwatson> I have forgotten the exact relative semantics of OUTOFSYNC_ARCHES / BREAK_ARCHES / NEW_ARCHES
<cjwatson> IIRC BREAK_ARCHES is the most brutal
<cjwatson> But also the particular thing blocking putty is guarded by BREAK_ARCHES, so ...
-queuebot:#ubuntu-release- Unapproved: libqapt (focal-proposed/universe) [3.0.4-1ubuntu5 => 3.0.5-1ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (focal-proposed) [2.657]
-queuebot:#ubuntu-release- Unapproved: accepted casper [source] (focal-proposed) [1.443]
-queuebot:#ubuntu-release- Unapproved: jemalloc (focal-proposed/universe) [5.2.1-1build1 => 5.2.1-1ubuntu1] (i386-whitelist, ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (focal-proposed) [0.136ubuntu4]
-queuebot:#ubuntu-release- Unapproved: libvncserver (focal-proposed/main) [0.9.12+dfsg-8 => 0.9.12+dfsg-9] (i386-whitelist, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: libnftnl (focal-proposed/main) [1.1.5-1 => 1.1.6-1] (i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libarchive [source] (focal-proposed) [3.4.0-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted jemalloc [source] (focal-proposed) [5.2.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-meta [source] (focal-proposed) [1.262]
-queuebot:#ubuntu-release- Unapproved: accepted session-migration [source] (focal-proposed) [0.3.5]
-queuebot:#ubuntu-release- Unapproved: accepted bluez [source] (focal-proposed) [5.53-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: harfbuzz (focal-proposed/main) [2.6.4-1ubuntu3 => 2.6.4-1ubuntu4] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-advantage-tools [source] (focal-proposed) [20.3]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-wallpapers [source] (focal-proposed) [20.04.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ruby2.7 (focal-proposed/main) [2.7.0-4 => 2.7.0-4ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: xorg-server (focal-proposed/main) [2:1.20.7-2ubuntu2 => 2:1.20.8-2ubuntu2] (desktop-core, i386-whitelist, xorg)
-queuebot:#ubuntu-release- Unapproved: accepted ruby2.7 [source] (focal-proposed) [2.7.0-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted harfbuzz [source] (focal-proposed) [2.6.4-1ubuntu4]
 * sil2100 hates reviewing syncs
-queuebot:#ubuntu-release- Unapproved: accepted python-pysnmp4 [sync] (focal-proposed) [4.4.6+repack1-2]
-queuebot:#ubuntu-release- Unapproved: accepted chromium-browser [source] (focal-proposed) [80.0.3987.163-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted indicator-sound [source] (focal-proposed) [12.10.2+18.10.20180612-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: libdrm (focal-proposed/main) [2.4.100-4 => 2.4.101-1] (core, i386-whitelist, xorg) (sync)
<oSoMoN> can someone please reject firefox 75.0+build2-0ubuntu1 from the focal queue? There's a 75.0+build3-0ubuntu1 upload that supersedes it
<seb128> oSoMoN, done
-queuebot:#ubuntu-release- Unapproved: rejected firefox [source] (focal-proposed) [75.0+build2-0ubuntu1]
-queuebot:#ubuntu-release- New binary: ubuntu-wallpapers [amd64] (focal-proposed/main) [20.04.2-0ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: fontconfig (focal-proposed/main) [2.13.1-2ubuntu2 => 2.13.1-2ubuntu3] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: accepted libvncserver [sync] (focal-proposed) [0.9.12+dfsg-9]
-queuebot:#ubuntu-release- Unapproved: accepted simplegeneric [sync] (focal-proposed) [0.8.1-3]
-queuebot:#ubuntu-release- Unapproved: accepted corosync [source] (focal-proposed) [3.0.3-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted python-troveclient [source] (focal-proposed) [1:2.17.0-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted valgrind [source] (focal-proposed) [1:3.15.0-1ubuntu9]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-color-manager [sync] (focal-proposed) [3.36.0-1]
-queuebot:#ubuntu-release- Unapproved: duplicity (focal-proposed/main) [0.8.11.1596-1 => 0.8.11.1612-1] (ubuntu-budgie, ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-boxes [sync] (focal-proposed) [3.36.2-1]
-queuebot:#ubuntu-release- Unapproved: kdeclarative (focal-proposed/universe) [5.68.0-0ubuntu1 => 5.68.0-0ubuntu2] (kubuntu)
<RikMills> ^^ fix riscv64 build
<wgrant> RikMills: Ah, thanks. I'm already on knewstuff
<RikMills> np
<RikMills> wgrant: anyone looking at network-manager? that will block a reasonable amount of kde things I think
<wgrant> RikMills: I suspect that's a timeout, but nobody is looking at it AFAIK.
-queuebot:#ubuntu-release- Unapproved: nautilus (focal-proposed/main) [1:3.36.1-1ubuntu1 => 1:3.36.1.1-1ubuntu1] (ubuntu-desktop)
<wgrant> If you want to fiddle, https://people.ubuntu.com/~wgrant/chroot-ubuntu-focal-riscv64-20200404.tar.gz is a chroot with an appropriate sources.list (including the bootstrap archive). qemu-user generally works pretty well.
-queuebot:#ubuntu-release- Unapproved: accepted kdeclarative [source] (focal-proposed) [5.68.0-0ubuntu2]
<RikMills> wgrant: afraid I have other things pending, so can't get that much into this
<wgrant> No worries
<juliank> Do we have a need to run edos-distcheck against binaries packages too, or do we already have tools that check that binaries in release pocket are installable?
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (focal-proposed) [1.138]
-queuebot:#ubuntu-release- Unapproved: accepted kombu [source] (focal-proposed) [4.6.7-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (focal-proposed) [2.04-1ubuntu23]
-queuebot:#ubuntu-release- Unapproved: accepted edk2 [source] (focal-proposed) [0~20191122.bd85bf54-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: knewstuff (focal-proposed/universe) [5.68.0-0ubuntu1 => 5.68.0-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (focal-proposed) [2.20.11-0ubuntu23]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (focal-proposed) [1:20.04.17]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-getting-started-docs [source] (focal-proposed) [3.36.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-user-docs [source] (focal-proposed) [3.36.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (focal-proposed) [2.20.11-0ubuntu24]
-queuebot:#ubuntu-release- Unapproved: node-parse-ms (focal-proposed/universe) [1.0.1-2 => 2.1.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-parse-ms [sync] (focal-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (focal-proposed) [20.1-10-g71af48df-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted pop-icon-theme [source] (focal-proposed) [2.1.0~1571158475~19.10~6bf9347]
-queuebot:#ubuntu-release- New binary: gnome-user-docs [amd64] (focal-proposed/main) [3.36.1-0ubuntu1] (personal-gunnarhj, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-input-synaptics [source] (focal-proposed) [1.9.1-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu23 => 2.04-1ubuntu23] (core)
-queuebot:#ubuntu-release- Unapproved: accepted haproxy [sync] (focal-proposed) [2.0.13-2]
-queuebot:#ubuntu-release- Unapproved: accepted hplip [sync] (focal-proposed) [3.20.3+dfsg0-2]
-queuebot:#ubuntu-release- Unapproved: accepted gnustep-base [sync] (focal-proposed) [1.26.0-7]
<doko> vorlon: just saw your hint for glibc, however https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1870764
<ubot5> Ubuntu bug 1870764 in glibc (Ubuntu) "glibc tst-system test failure" [Undecided,New]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (focal-proposed) [2.04-1ubuntu23]
<oSoMoN> seb128, thanks!
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-input-synaptics (focal-proposed/universe) [1.9.1-1ubuntu2 => 1.9.1-1ubuntu3] (ubuntukylin, xorg, xubuntu)
-queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu23 => 2.04-1ubuntu23] (core)
-queuebot:#ubuntu-release- Unapproved: datalad-container (focal-proposed/universe) [0.5.0-1 => 1.0.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted datalad-container [sync] (focal-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- Unapproved: llvm-toolchain-9 (focal-proposed/main) [1:9.0.1-11 => 1:9.0.1-11ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: accepted ibus-libpinyin [sync] (focal-proposed) [1.11.1-3]
-queuebot:#ubuntu-release- Unapproved: accepted mypaint [sync] (focal-proposed) [2.0.0-2]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntukylin-meta [source] (focal-proposed) [0.41]
-queuebot:#ubuntu-release- Unapproved: last-align (focal-proposed/universe) [983-1ubuntu2 => 1060-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted last-align [sync] (focal-proposed) [1060-1]
-queuebot:#ubuntu-release- Unapproved: accepted librsvg [sync] (focal-proposed) [2.48.0-2]
-queuebot:#ubuntu-release- Unapproved: accepted libtool [sync] (focal-proposed) [2.4.6-14]
-queuebot:#ubuntu-release- Unapproved: accepted piston-mini-client [source] (focal-proposed) [0.7.5-0ubuntu7]
-queuebot:#ubuntu-release- Unapproved: accepted ufw [sync] (focal-proposed) [0.36-6]
-queuebot:#ubuntu-release- Unapproved: accepted libxmlb [sync] (focal-proposed) [0.1.15-2]
-queuebot:#ubuntu-release- Unapproved: accepted python-oauthlib [source] (focal-proposed) [3.1.0-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted mate-menu [source] (focal-proposed) [20.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gjs (focal-proposed/main) [1.64.0-1 => 1.64.1-1] (desktop-core, desktop-extra, i386-whitelist, mozilla) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-guide [source] (focal-proposed) [20.04.2-0ubuntu1]
-queuebot:#ubuntu-release- New binary: libxmlb [amd64] (focal-proposed/main) [0.1.15-2] (core)
-queuebot:#ubuntu-release- New binary: libxmlb [s390x] (focal-proposed/main) [0.1.15-2] (core)
-queuebot:#ubuntu-release- New binary: libxmlb [ppc64el] (focal-proposed/main) [0.1.15-2] (core)
-queuebot:#ubuntu-release- New binary: libxmlb [arm64] (focal-proposed/main) [0.1.15-2] (core)
-queuebot:#ubuntu-release- New binary: libxmlb [armhf] (focal-proposed/main) [0.1.15-2] (core)
-queuebot:#ubuntu-release- Unapproved: llvm-toolchain-10 (focal-proposed/main) [1:10.0.0-2ubuntu1 => 1:10.0.0-2ubuntu2] (i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: rejected mypaint [sync] (focal-proposed) [2.0.0-2]
-queuebot:#ubuntu-release- Unapproved: accepted appdirs [sync] (focal-proposed) [1.4.3-2.1]
-queuebot:#ubuntu-release- Unapproved: accepted pypy [sync] (focal-proposed) [7.3.0+dfsg-3]
<locutus_> wgrant, is your llvm-toolchain-* patch upstreamable?
<locutus_> I would like to undertand if it is usable in debian too
<wgrant> locutus_: I believe so, but I haven't had time to try yet.
<wgrant> It's basically making the riscv codepath look like the normal biarch one
<wgrant> It'll work fine in Debian, and I suspect upstream will accept it
-queuebot:#ubuntu-release- Unapproved: accepted cracklib2 [sync] (focal-proposed) [2.9.6-3.2]
-queuebot:#ubuntu-release- Unapproved: accepted tracker-miners [sync] (focal-proposed) [2.3.3-2]
-queuebot:#ubuntu-release- New binary: libxmlb [riscv64] (focal-proposed/main) [0.1.15-2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted libdvdread [sync] (focal-proposed) [6.1.0+really6.0.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (focal-proposed) [2.04-1ubuntu23]
 * sil2100 works through the queue
<sil2100> Guess it's starting to look better now
-queuebot:#ubuntu-release- Unapproved: accepted python-future [sync] (focal-proposed) [0.18.2-2]
-queuebot:#ubuntu-release- New: accepted gnome-user-docs [amd64] (focal-proposed) [3.36.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libxmlb [arm64] (focal-proposed) [0.1.15-2]
-queuebot:#ubuntu-release- New: accepted libxmlb [ppc64el] (focal-proposed) [0.1.15-2]
-queuebot:#ubuntu-release- New: accepted libxmlb [s390x] (focal-proposed) [0.1.15-2]
-queuebot:#ubuntu-release- New: accepted node-dtrace-provider [sync] (focal-proposed) [0.8.8-1]
-queuebot:#ubuntu-release- New: accepted node-eslint-plugin-node [sync] (focal-proposed) [6.0.1~dfsg-4]
-queuebot:#ubuntu-release- New: accepted node-eslint-scope [sync] (focal-proposed) [5.0.0-1]
-queuebot:#ubuntu-release- New: accepted node-proxyquire [sync] (focal-proposed) [2.1.3+~1.0.1+~1.0.2-9]
-queuebot:#ubuntu-release- New: accepted libxmlb [amd64] (focal-proposed) [0.1.15-2]
-queuebot:#ubuntu-release- New: accepted libxmlb [riscv64] (focal-proposed) [0.1.15-2]
-queuebot:#ubuntu-release- New: accepted node-eslint-plugin-eslint-plugin [sync] (focal-proposed) [2.2.1-1]
-queuebot:#ubuntu-release- New: accepted node-mqtt-connection [sync] (focal-proposed) [4.0.0-2]
-queuebot:#ubuntu-release- New: accepted libxmlb [armhf] (focal-proposed) [0.1.15-2]
-queuebot:#ubuntu-release- New: accepted node-eslint-plugin-requirejs [sync] (focal-proposed) [4.0.0-5]
-queuebot:#ubuntu-release- New: accepted node-debbundle-insert-module-globals [sync] (focal-proposed) [7.2.0+ds+~1.0.0+~1.2.0+~1.1.3-3]
-queuebot:#ubuntu-release- New: accepted ubuntu-wallpapers [amd64] (focal-proposed) [20.04.2-0ubuntu1]
-queuebot:#ubuntu-release- New binary: node-eslint-scope [amd64] (focal-proposed/universe) [5.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-debbundle-insert-module-globals [amd64] (focal-proposed/universe) [7.2.0+ds+~1.0.0+~1.2.0+~1.1.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: node-mqtt-connection [amd64] (focal-proposed/universe) [4.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-dtrace-provider [amd64] (focal-proposed/universe) [0.8.8-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-10 [source] (focal-proposed) [1:10.0.0-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-9 [source] (focal-proposed) [1:9.0.1-11ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted knewstuff [source] (focal-proposed) [5.68.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted node-debbundle-insert-module-globals [amd64] (focal-proposed) [7.2.0+ds+~1.0.0+~1.2.0+~1.1.3-3]
-queuebot:#ubuntu-release- New: accepted node-eslint-scope [amd64] (focal-proposed) [5.0.0-1]
-queuebot:#ubuntu-release- New: accepted node-dtrace-provider [amd64] (focal-proposed) [0.8.8-1]
-queuebot:#ubuntu-release- New: accepted node-mqtt-connection [amd64] (focal-proposed) [4.0.0-2]
<sil2100> Do we have some standing Gnome FFe by any chance?
-queuebot:#ubuntu-release- Unapproved: update-manager (focal-proposed/main) [1:20.04.1 => 1:20.04.2] (core)
<LocutusOfBorg> wgrant, I think this is just wrong?
<LocutusOfBorg> ++    findRISCVBareMetalMultilibs(D, TargetTriple, Path, Args, Result);
<LocutusOfBorg> ++    return true;
<LocutusOfBorg> it shouldn't have been changed?
<wgrant> LocutusOfBorg: I needed to change findRISCVMultilibs to return a bool, but findRISCVBareMetalMultilibs always succeeds
<wgrant> So I need to synthesise a successful return value (or make findRISCVBareMetalMultilibs non-void too)
<wgrant> It was returning a void result, which works because the function is itself void but is kinda misleading.
-queuebot:#ubuntu-release- Unapproved: accepted ruby-defaults [sync] (focal-proposed) [1:2.7+1]
-queuebot:#ubuntu-release- Unapproved: accepted budgie-desktop-environment [source] (focal-proposed) [0.13.7]
-queuebot:#ubuntu-release- Unapproved: rejected hplip [sync] (focal-proposed) [3.20.3+dfsg0-2]
-queuebot:#ubuntu-release- Unapproved: libwacom (focal-proposed/main) [1.3-1ubuntu1 => 1.3-2ubuntu1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: accepted libwacom [source] (focal-proposed) [1.3-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted pyjwt [source] (focal-proposed) [1.7.1-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (focal-proposed) [1:3.36.1-1ubuntu4]
<sil2100> Almost thought the g-c-c upload was reverting the fractional scaling UI, but then saw it was only renaming it
-queuebot:#ubuntu-release- Unapproved: accepted xubuntu-community-artwork [source] (focal-proposed) [20.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted shadow [source] (focal-proposed) [1:4.8.1-1ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted mate-terminal [source] (focal-proposed) [1.24.0-2ubuntu1]
-queuebot:#ubuntu-release- New binary: pop-icon-theme [amd64] (focal-proposed/universe) [2.1.0~1571158475~19.10~6bf9347] (no packageset)
<sil2100> RikMills: hey! Do you have a list of changes introduced by the libqapt merge?
-queuebot:#ubuntu-release- New binary: xubuntu-community-artwork [amd64] (focal-proposed/universe) [20.04.0] (ubuntustudio, xubuntu)
-queuebot:#ubuntu-release- Unapproved: rejected libnftnl [sync] (focal-proposed) [1.1.6-1]
<bluesabre> Thanks sil2100 !
-queuebot:#ubuntu-release- Unapproved: accepted fontconfig [source] (focal-proposed) [2.13.1-2ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted nautilus [source] (focal-proposed) [1:3.36.1.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted duplicity [sync] (focal-proposed) [0.8.11.1612-1]
-queuebot:#ubuntu-release- Unapproved: accepted gjs [sync] (focal-proposed) [1.64.1-1]
<locutus_> wgrant, I got what you mean, loool
<locutus_> return a void function is no-sense
<locutus_> I don't get why sparcv64 multilib directory is different between debian and ubuntu, but meh
<wgrant> locutus_: riscv64 you mean?
<wgrant> locutus_: The Debian build happened to have libgcc-10-dev installed for some reason, whereas on Ubuntu it just has gcc-10-base, so it has an empty dir
<locutus_> yep
<locutus_> thanks
<wgrant> This affects all archs, but most use the biarch codepath which already does the check for Default too
<locutus_> I'll forward this to the debian irc chan
<locutus_> ok so it is a bug also in debian, maybe something like apt installing recommends or so
<locutus_> nice, it makes sense+
<locutus_> wgrant, if llvm-toolchain-9 fails to build, please ping me, because you need an additional patch
<locutus_> I already know where it is
<wgrant> locutus_: Oh, which?
<locutus_> Cherry-pick upstream patch D74453 to fix atomic compare-and-swap on
<wgrant> I have a recent build of it which worked fine
<locutus_>     riscv64.
<locutus_> it might be a runtime break
<wgrant> Based on  1:9.0.1-10
<wgrant> Ah
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (focal-proposed) [1:20.04.2]
<RikMills> sil2100: https://cgit.kde.org/libqapt.git/log/
<RikMills> that vast amount of it is including julian's apt abi changes
<sil2100> I think I won't be able to review it today, I got through the most of the queue already - now I will only finish openssl and then someone else will have to pick it up
<sil2100> At least we got down to 23 packages in the queue for now!
<RikMills> sil2100: other stuff is mostly compatibility with newer Qt #ifdef for that etc
<doko> \o/
<RikMills> sil2100: good job. thanks :)
-queuebot:#ubuntu-release- Unapproved: mkvtoolnix (focal-proposed/universe) [44.0.0-1ubuntu1 => 45.0.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted mkvtoolnix [source] (focal-proposed) [45.0.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: lintian-brush (focal-proposed/universe) [0.59ubuntu1 => 0.60ubuntu1] (no packageset)
<locutus_> sil2100, can you please also have a look at libnftnl in queue?
-queuebot:#ubuntu-release- Unapproved: accepted lintian-brush [source] (focal-proposed) [0.60ubuntu1]
<locutus_> it should fix some bad crashes in nftables
<locutus_> lots of new examples, autoconf foo, and new tests, but the real code diff is quite minimal
-queuebot:#ubuntu-release- Unapproved: ruby-rchardet (focal-proposed/universe) [1.6.1-1 => 1.8.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ruby-mini-magick (focal-proposed/universe) [4.9.2-1.1 => 4.9.5-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ruby-redis (focal-proposed/universe) [3.3.5-1 => 4.1.2-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ruby-mini-magick [sync] (focal-proposed) [4.9.5-2]
-queuebot:#ubuntu-release- Unapproved: accepted ruby-redis [sync] (focal-proposed) [4.1.2-4]
-queuebot:#ubuntu-release- Unapproved: accepted ruby-rchardet [sync] (focal-proposed) [1.8.0-1]
<Laney> everything's going to get looked at
<LocutusOfBorg> thanks, I mentioned nftnl, because that library fixes bugs in nftables, not in the library itself (sad story when libraries are deocupled from source packages, such as filezilla/libfilezilla)
-queuebot:#ubuntu-release- Unapproved: r-cran-gwidgetstcltk (focal-proposed/universe) [0.0-55-1 => 0.0-55-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-gwidgetstcltk [sync] (focal-proposed) [0.0-55-2]
-queuebot:#ubuntu-release- Unapproved: r-cran-gwidgetsrgtk2 (focal-proposed/universe) [0.0-86-1 => 0.0-86-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-gwidgetsrgtk2 [sync] (focal-proposed) [0.0-86-2]
-queuebot:#ubuntu-release- New binary: r-cran-gwidgetstcltk [amd64] (focal-proposed/universe) [0.0-55-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: intel-gpu-tools (focal-proposed/universe) [1.25-1 => 1.25-2] (i386-whitelist, ubuntukylin) (sync)
-queuebot:#ubuntu-release- New binary: r-cran-gwidgetsrgtk2 [amd64] (focal-proposed/universe) [0.0-86-2] (no packageset)
<Odd_Bloke> Are we too late in the cycle for me to request a sync of neomutt (a leaf package in universe) from Debian?  They have a slightly more recent version than we do (and there's an outside chance it'll fix a segfault I've been seeing).
-queuebot:#ubuntu-release- Unapproved: kactivities-kf5 (focal-proposed/universe) [5.68.0-0ubuntu1 => 5.68.0-0ubuntu2] (kubuntu)
<xnox> Odd_Bloke:  version numbers?
<xnox> Odd_Bloke:  it has ftbfs fix, which we do want
<xnox> Odd_Bloke:  sync requested
<Laney> No it's not too late, but ideally it would be tested rather then specu...
<Laney> right...
-queuebot:#ubuntu-release- Unapproved: neomutt (focal-proposed/universe) [20191111+dfsg.1-1 => 20191207+dfsg.1-1.1] (no packageset) (sync)
<xnox> most changes are in testsuite & FTBFS code
<Odd_Bloke> I don't have a reliable way of reproducing the crash, unfortunately.
<Odd_Bloke> It just Sometimes Happens when I'm purging an IMAP folder/inbox.
<Laney> Not necessarily that, but even test build it and make sure it basically works, check the diff and make sure it's sane
-queuebot:#ubuntu-release- Unapproved: accepted neomutt [sync] (focal-proposed) [20191207+dfsg.1-1.1]
<Laney> moot though, you got someone to bypass that for you
<xnox> Odd_Bloke:  note, it it still RC buggy in debian with backspace bug, is that what you are hitting?
<xnox> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945442
<ubot5> Debian bug 945442 in neomutt "Possible to backspace past beginning of string, which appears to be identical to having pressed Enter immediately, without any backspace" [Grave,Open]
<Odd_Bloke> https://bugs.launchpad.net/ubuntu/+source/neomutt/+bug/1853909 is my bug.  I've reported it upstream too, but as I can't reproduce it reliably, they haven't been able to help me nail down the root cause either.
<ubot5> Ubuntu bug 1853909 in neomutt (Ubuntu) "neomutt crashed with SIGSEGV in cmd_parse_expunge()" [Medium,New]
 * Laney appeals for people to please test the things they upload :/
-queuebot:#ubuntu-release- Unapproved: ubuntukylin-theme (focal-proposed/universe) [2.0.4 => 2.0.5] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: rejected openssl [source] (focal-proposed) [1.1.1f-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: kactivities-kf5 (focal-proposed/universe) [5.68.0-0ubuntu1 => 5.68.0-0ubuntu2] (kubuntu)
<RikMills> ^ fixing riscv64 build
<RikMills> kactivities
<sil2100> uh, I see two kactivities-kf5 in the queue, I assume the second is better?
<sil2100> Oh, one is from William
<wgrant> I just rejected mine
<wgrant> Rik's is indeed better
-queuebot:#ubuntu-release- Unapproved: rejected kactivities-kf5 [source] (focal-proposed) [5.68.0-0ubuntu2]
<RikMills> sil2100: probably much the same. mine was done with pkgkde-symbols-helper, so should be consistant with how symbols have been done for the rest of KDE things
-queuebot:#ubuntu-release- Unapproved: accepted ubuntukylin-theme [source] (focal-proposed) [2.0.5]
-queuebot:#ubuntu-release- Unapproved: wine-development (focal-proposed/universe) [5.5-2ubuntu1 => 5.5-3] (i386-whitelist) (sync)
<LocutusOfBorg> I would like wine-development to be accepted, just because that way the diff becomes minimal
<LocutusOfBorg> and I can forward the patch to debian
<LocutusOfBorg> while this one is the "fixed one"
-queuebot:#ubuntu-release- Unapproved: wine-development (focal-proposed/universe) [5.5-2ubuntu1 => 5.5-3ubuntu1] (i386-whitelist)
<vorlon> Laney: because the cowboying is not something I would want to commit :)
<vorlon> cjwatson, Laney: I couldn't remember what else BREAK_ARCHES impacted, and it was the weekend and I was trying to unblock britney.  I don't know why britney was getting upset every time an essential package became newly /installable/ in the release pocket on riscv64
<vorlon> so BREAK_ARCHES definitely sounded like the wrong hammer for this
<sil2100> wgrant, RikMills: thanks guys o/
-queuebot:#ubuntu-release- Unapproved: accepted kactivities-kf5 [source] (focal-proposed) [5.68.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: fonts-ebgaramond (focal-proposed/universe) [0.016-1 => 0.016-1ubuntu1] (personal-gunnarhj)
<doko> hmm, why is cwiid not migrating?
<tjaalton> so everything ends up in the queue, not just main?
-queuebot:#ubuntu-release- Unapproved: rapid-photo-downloader (focal-proposed/universe) [0.9.17-1 => 0.9.20-0ubuntu1] (ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: accepted snapd-glib [source] (focal-proposed) [1.57-0ubuntu1]
<tjaalton> ah, r-p-d is seeded
<apw> tjaalton, it all ends up in teh queue, unseeded gets picked out by a bot
<tjaalton> yup, got it
<tjaalton> how do I know if a package is seeded?
<tjaalton> I wonder if darktable is
<wgrant> tjaalton: wgrant@fallia:~$ seeded-in-ubuntu darktable
<wgrant> darktable (from darktable) is seeded in:
<wgrant>   ubuntustudio: dvd
-queuebot:#ubuntu-release- Unapproved: glance (eoan-proposed/main) [2:19.0.0-0ubuntu1 => 2:19.0.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron-fwaas (eoan-proposed/main) [1:15.0.0-0ubuntu1 => 1:15.0.1-0ubuntu1] (openstack, ubuntu-server)
<tjaalton> wgrant: thanks
-queuebot:#ubuntu-release- Unapproved: neutron (eoan-proposed/main) [2:15.0.1-0ubuntu1 => 2:15.0.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: horizon (eoan-proposed/main) [3:16.0.0-0ubuntu1.1 => 3:16.1.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: nova (eoan-proposed/main) [2:20.0.1-0ubuntu1 => 2:20.1.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ceilometer (eoan-proposed/main) [1:13.0.0-0ubuntu1.1 => 1:13.1.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cinder (eoan-proposed/main) [2:15.0.1-0ubuntu1 => 2:15.1.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ukui-power-manager (focal-proposed/universe) [2.0.1-1 => 2.0.2-1] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: node-rollup-pluginutils (focal-proposed/universe) [2.8.2-7 => 2.8.2-7build2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-rollup (focal-proposed/universe) [1.12.0-2 => 1.12.0-2build2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-rollup-pluginutils [sync] (focal-proposed) [2.8.2-7build2]
-queuebot:#ubuntu-release- Unapproved: accepted node-rollup [sync] (focal-proposed) [1.12.0-2build2]
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-96.97] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-96.97~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-96.97~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-96.97]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-96.97~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-96.97~16.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-96.97] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: subiquity (focal-proposed/universe) [19.12.2+git106g3d9374ad => 20.03.3+git107gb7ae4d06] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted subiquity [source] (focal-proposed) [20.03.3+git107gb7ae4d06]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-96.97]
-queuebot:#ubuntu-release- Unapproved: dkimpy (focal-proposed/universe) [1.0.3-1 => 1.0.4-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted dkimpy [sync] (focal-proposed) [1.0.4-1]
-queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (eoan-proposed) [3.9-1ubuntu0.19.10.2]
-queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (bionic-proposed) [3.9-1ubuntu0.18.04.2]
-queuebot:#ubuntu-release- Unapproved: libnet-server-perl (focal-proposed/main) [2.009-1 => 2.009-2] (ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted rabbitmq-server [source] (bionic-proposed) [3.6.10-1ubuntu0.1]
<RikMills> could someone review and sponsor the debdiff in LP: #1870316
<ubot5> Launchpad bug 1870316 in util-linux (Ubuntu) "'sudo hwclock -s' fails with 'settimeofday() failed: Invalid argument'" [High,In progress] https://launchpad.net/bugs/1870316
-queuebot:#ubuntu-release- Unapproved: node-rollup-plugin-json (focal-proposed/universe) [4.0.0-5 => 4.0.0-6] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-rollup-plugin-json [sync] (focal-proposed) [4.0.0-6]
<seb128> looks like https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html stopped updating?
-queuebot:#ubuntu-release- Unapproved: gnome-settings-daemon (focal-proposed/main) [3.35.91-1ubuntu1 => 3.36.0-1ubuntu1] (ubuntu-desktop)
<mwhudson> can i get a release team opinion on https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1863672 ?
<ubot5> Ubuntu bug 1863672 in casper (Ubuntu) "The 'new' persistent live method starting in 19.10 no longer works" [High,Confirmed]
-queuebot:#ubuntu-release- Unapproved: accepted libnet-server-perl [sync] (focal-proposed) [2.009-2]
-queuebot:#ubuntu-release- Unapproved: libinstpatch (focal-proposed/universe) [1.1.2-2 => 1.1.2-2build1] (i386-whitelist)
<vorlon> an opinion on whether it no longer works? :)
<mwhudson> opinion on shifting back to casper-rw for release
<mwhudson> but if another developer can reproduce the issue that would also be good...
-queuebot:#ubuntu-release- Packageset: Removed gcc-8 from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed libberkeleydb-perl from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed libclass-accessor-perl from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Removed libmldbm-perl from i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added libalgorithm-diff-perl to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added libinstpatch to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added libjson-maybexs-perl to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added libmojolicious-perl to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added libtest-deep-perl to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added libtest-differences-perl to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added libtest-longstring-perl to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added libtext-diff-perl to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added libtypes-serialiser-perl to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added libxml-writer-perl to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added prettify.js to i386-whitelist in focal
-queuebot:#ubuntu-release- Unapproved: ruby-crb-blast (focal-proposed/universe) [0.6.9-3 => 0.6.9-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ruby-crb-blast [sync] (focal-proposed) [0.6.9-4]
-queuebot:#ubuntu-release- Unapproved: accepted libinstpatch [source] (focal-proposed) [1.1.2-2build1]
-queuebot:#ubuntu-release- New sync: eslint (focal-proposed/primary) [5.0.1~dfsg-4]
-queuebot:#ubuntu-release- Unapproved: command-not-found (focal-proposed/main) [20.04.1 => 20.04.2] (core)
-queuebot:#ubuntu-release- Unapproved: lxc (focal-proposed/universe) [1:4.0.0-0ubuntu2 => 1:4.0.1-0ubuntu1] (ubuntu-server)
<vorlon> tjaalton: can you give any color to the xserver-xorg-video-qxl sync, and why we want to take this post-freeze?  as a sync there are no linked LP bugs etc, and I see that it takes care of python2->3 migration which is good, but there are also upstream changes
-queuebot:#ubuntu-release- Unapproved: linux-meta (focal-proposed/main) [5.4.0.22.27 => 5.4.0.23.28] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux (focal-proposed/main) [5.4.0-22.26 => 5.4.0-23.27] (core, i386-whitelist, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-restricted-modules (focal-proposed/restricted) [5.4.0-22.26 => 5.4.0-23.27] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed (focal-proposed/main) [5.4.0-22.26 => 5.4.0-23.27] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: apparmor (focal-proposed/main) [2.13.3-7ubuntu3 => 2.13.3-7ubuntu4] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (focal-proposed) [1:4.0.1-0ubuntu1]
<mwhudson> uh livecd-rootfs not migrating because snapd is not present on riscv?
<jdstrand> fyi, that apparmor upload fixes a critical issue that affects using snaps with root on zfs (and a handful of miscellaneous policy updates)
-queuebot:#ubuntu-release- Unapproved: linux-aws (focal-proposed/main) [5.4.0-1007.7 => 5.4.0-1008.8] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-aws (focal-proposed/main) [5.4.0.1007.8 => 5.4.0.1008.10] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-restricted-modules-aws (focal-proposed/restricted) [5.4.0-1007.7 => 5.4.0-1008.8] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: pacemaker (focal-proposed/main) [2.0.3-3ubuntu2 => 2.0.3-3ubuntu3] (i386-whitelist, ubuntu-desktop, ubuntu-server)
<seb128> hum, how is https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.yaml being generated?
<seb128> those new /riscv entries don't have a policy_info section
<seb128> which seems to make the by_team report script sad
-queuebot:#ubuntu-release- Unapproved: linux-azure (focal-proposed/main) [5.4.0-1008.8 => 5.4.0-1009.9] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-restricted-modules-azure (focal-proposed/restricted) [5.4.0-1008.8 => 5.4.0-1009.9] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-azure (focal-proposed/main) [5.4.0.1008.8 => 5.4.0.1009.10] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed-azure (focal-proposed/main) [5.4.0-1008.8 => 5.4.0-1009.9] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-gcp (focal-proposed/main) [5.4.0-1007.7 => 5.4.0-1008.8] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-restricted-modules-gcp (focal-proposed/restricted) [5.4.0-1007.7 => 5.4.0-1008.8] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-gcp (focal-proposed/main) [5.4.0.1007.7 => 5.4.0.1008.8] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed-gcp (focal-proposed/main) [5.4.0-1007.7 => 5.4.0-1008.8] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-oracle (focal-proposed/main) [5.4.0.1007.7 => 5.4.0.1008.8] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-restricted-modules-oracle (focal-proposed/restricted) [5.4.0-1007.7 => 5.4.0-1008.8] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-oracle (focal-proposed/main) [5.4.0-1007.7 => 5.4.0-1008.8] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed-oracle (focal-proposed/main) [5.4.0-1007.7 => 5.4.0-1008.8] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-kvm (focal-proposed/main) [5.4.0-1006.6 => 5.4.0-1007.7] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-kvm (focal-proposed/main) [5.4.0.1006.6 => 5.4.0.1007.7] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta [sync] (focal-proposed) [5.4.0.23.28]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed [sync] (focal-proposed) [5.4.0-23.27]
-queuebot:#ubuntu-release- Unapproved: accepted linux-restricted-modules [sync] (focal-proposed) [5.4.0-23.27]
-queuebot:#ubuntu-release- Unapproved: accepted linux [sync] (focal-proposed) [5.4.0-23.27]
-queuebot:#ubuntu-release- Unapproved: rejected libdrm [sync] (focal-proposed) [2.4.101-1]
-queuebot:#ubuntu-release- Unapproved: rejected xorg-server [source] (focal-proposed) [2:1.20.8-2ubuntu1]
<xnox> vorlon:  please migrate livecd-rootfs despite uninstallable on riscv64
-queuebot:#ubuntu-release- Unapproved: pacemaker (xenial-proposed/main) [1.1.14-2ubuntu1.6 => 1.1.14-2ubuntu1.7] (ubuntu-server)
<vorlon> xnox: hinted
-queuebot:#ubuntu-release- Unapproved: json-glib (focal-proposed/main) [1.4.4-2ubuntu1 => 1.4.4-2ubuntu2] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: json-glib (eoan-proposed/main) [1.4.4-2 => 1.4.4-2ubuntu0.19.10.1] (core)
-queuebot:#ubuntu-release- Unapproved: isc-dhcp (focal-proposed/main) [4.4.1-2.1ubuntu3 => 4.4.1-2.1ubuntu4] (core)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (focal-proposed) [3.36.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (focal-proposed) [20.0.4-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: json-glib (bionic-proposed/main) [1.4.2-3 => 1.4.2-3ubuntu0.18.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: engrampa (focal-proposed/universe) [1.24.0-1 => 1.24.0-2] (ubuntu-mate, ubuntukylin, xubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: update-manager (focal-proposed/main) [1:20.04.2 => 1:20.04.3] (core)
-queuebot:#ubuntu-release- Unapproved: libaccounts-glib (focal-proposed/universe) [1.23+17.04.20161104-0ubuntu2 => 1.23+17.04.20161104-0ubuntu3] (kubuntu)
#ubuntu-release 2020-04-07
<wgrant> libaccounts-glib fixes the FTBFS and unblocks most of the remaining desktop stacks
<wgrant> on riscv64
-queuebot:#ubuntu-release- Unapproved: neutron (focal-proposed/main) [2:16.0.0~b3~git2020032420.a0e1b5804e-0ubuntu3 => 2:16.0.0~b3~git2020032420.a0e1b5804e-0ubuntu4] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: nova (focal-proposed/main) [2:21.0.0~b3~git2020032515.35240b0d8c-0ubuntu1 => 2:21.0.0~b3~git2020032515.35240b0d8c-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: pcs (focal-proposed/universe) [0.10.4-2ubuntu1 => 0.10.4-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pcs [sync] (focal-proposed) [0.10.4-3]
-queuebot:#ubuntu-release- Unapproved: autoradio (focal-proposed/universe) [3.1-6 => 3.4-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted autoradio [sync] (focal-proposed) [3.4-2]
-queuebot:#ubuntu-release- Unapproved: backupchecker (focal-proposed/universe) [1.7-1 => 1.7-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted backupchecker [source] (focal-proposed) [1.7-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: brebis (focal-proposed/universe) [0.10-1build1 => 0.10-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted brebis [source] (focal-proposed) [0.10-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: c-icap-modules (focal-proposed/universe) [1:0.5.3-2 => 1:0.5.4-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted c-icap-modules [sync] (focal-proposed) [1:0.5.4-1]
-queuebot:#ubuntu-release- Unapproved: can-utils (focal-proposed/universe) [2018.02.0-1 => 2018.02.0-1ubuntu1] (no packageset)
<tjaalton> vorlon: right, there hadn't been a nee release since 2016 so i made that snapshot, it had three commits for py3 fixes etc. here's the git log https://pastebin.com/1Qh9Grx
-queuebot:#ubuntu-release- Unapproved: accepted can-utils [source] (focal-proposed) [2018.02.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: cloop (focal-proposed/universe) [3.14.1.2ubuntu2 => 3.14.1.2ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cloop [source] (focal-proposed) [3.14.1.2ubuntu3]
-queuebot:#ubuntu-release- Unapproved: cmark-gfm (focal-proposed/universe) [0.29.0.gfm.0-3 => 0.29.0.gfm.0-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted cmark-gfm [sync] (focal-proposed) [0.29.0.gfm.0-4]
-queuebot:#ubuntu-release- Unapproved: colord-kde (focal-proposed/universe) [0.5.0-3build1 => 0.5.0-4] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: construct (focal-proposed/universe) [2.8.16-0.3 => 2.8.16-0.3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted construct [source] (focal-proposed) [2.8.16-0.3ubuntu1]
<Eickmeyer[m]> tjaalton: I just formally approved bug 1871049 and renamed it if you want to use it as a FFe for darktable.
<ubot5> bug 1871049 in darktable (Ubuntu) "FFe: darktable 2.6.3 in focal needs update to 3.0.1" [Undecided,Confirmed] https://launchpad.net/bugs/1871049
<tjaalton> Eickmeyer[m]: ah, thanks!
-queuebot:#ubuntu-release- Unapproved: cutesdr (focal-proposed/universe) [1.20-3build2 => 1.20-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted cutesdr [sync] (focal-proposed) [1.20-4]
-queuebot:#ubuntu-release- Unapproved: debbugs (focal-proposed/universe) [2.6.0 => 2.6.0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted debbugs [source] (focal-proposed) [2.6.0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: dlz-ldap-enum (focal-proposed/universe) [1.1.0-1 => 1.1.0-1.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted dlz-ldap-enum [sync] (focal-proposed) [1.1.0-1.1]
-queuebot:#ubuntu-release- Unapproved: egl-wayland (focal-proposed/universe) [1:1.1.3-1 => 1:1.1.3-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted egl-wayland [source] (focal-proposed) [1:1.1.3-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: firmware-microbit-micropython (focal-proposed/universe) [1.0.1-1 => 1.0.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: flake8-polyfill (focal-proposed/universe) [1.0.2-1 => 1.0.2-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted firmware-microbit-micropython [source] (focal-proposed) [1.0.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted flake8-polyfill [sync] (focal-proposed) [1.0.2-2]
-queuebot:#ubuntu-release- Unapproved: gnome-software (bionic-proposed/main) [3.28.1-0ubuntu4.18.04.14 => 3.28.1-0ubuntu4.18.04.15] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: ukui-control-center (focal-proposed/universe) [2.0.1.1-2 => 2.0.3-1] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: ukui-panel (focal-proposed/universe) [2.0.3-1 => 2.0.5-1] (ubuntukylin) (sync)
<tjaalton> please ack intel-gpu-tools sync, fixes the build
-queuebot:#ubuntu-release- Unapproved: kylin-nm (focal-proposed/universe) [1.2.2.1-1 => 1.2.3-1] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: ukui-media (focal-proposed/universe) [2.0.1-1 => 2.0.3-1] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: peony (focal-proposed/universe) [2.1.0-1 => 2.1.2-1] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- New binary: dropwatch [riscv64] (focal-proposed/universe) [1.5.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (focal-proposed/main) [5.4.0-23.27] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (focal-proposed/main) [5.4.0-23.27] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (focal-proposed/main) [5.4.0-23.27] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (focal-proposed/main) [5.4.0-23.27] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (focal-proposed) [5.4.0-23.27]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (focal-proposed) [5.4.0-23.27]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (focal-proposed) [5.4.0-23.27]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (focal-proposed) [5.4.0-23.27]
-queuebot:#ubuntu-release- Unapproved: accepted libaccounts-glib [source] (focal-proposed) [1.23+17.04.20161104-0ubuntu3]
<seb128> hey there, did anyone see my question from yesterday evening? how is update_excuses.yaml generated? was the generation changed recently to special case the new riscv entries?
<seb128> those are missing a policyinfo and the by team proposed migration doesn't like it
<seb128> wgrant, ^ do you know?
<wgrant> seb128: I don't know much about proposed-migration, I'm afraid
<sil2100> Morning o/ Let me start with a quick browse through the queue
-queuebot:#ubuntu-release- Unapproved: rejected wine-development [sync] (focal-proposed) [5.5-3]
-queuebot:#ubuntu-release- Unapproved: accepted wine-development [source] (focal-proposed) [5.5-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted fonts-ebgaramond [source] (focal-proposed) [0.016-1ubuntu1]
<sil2100> tjaalton: hey! Looking at rapid-photo-downloader, the new upstream version of 0.9.20 seems to be adding at least one new feature - is that right? Is there an FFe for this?
<tjaalton> sil2100: nope
<tjaalton> no ffe I mean
<tjaalton> though I could write one I guess
-queuebot:#ubuntu-release- Unapproved: accepted gnome-settings-daemon [source] (focal-proposed) [3.36.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ukui-power-manager [sync] (focal-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted apparmor [source] (focal-proposed) [2.13.3-7ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted command-not-found [source] (focal-proposed) [20.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted isc-dhcp [source] (focal-proposed) [4.4.1-2.1ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted json-glib [source] (focal-proposed) [1.4.4-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted pacemaker [source] (focal-proposed) [2.0.3-3ubuntu3]
<seb128> sil2100, hey
<seb128> do you know how is update_excuses.yaml generated? was the generation changed recently to special case the new riscv entries?
<seb128> those are missing a policyinfo and the by team proposed migration doesn't like it, it fails to update for a day now
-queuebot:#ubuntu-release- Unapproved: accepted linux-aws [sync] (focal-proposed) [5.4.0-1008.8]
-queuebot:#ubuntu-release- Unapproved: accepted linux-gcp [sync] (focal-proposed) [5.4.0-1008.8]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-aws [sync] (focal-proposed) [5.4.0.1008.10]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-gcp [sync] (focal-proposed) [5.4.0.1008.8]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-oracle [sync] (focal-proposed) [5.4.0.1008.8]
-queuebot:#ubuntu-release- Unapproved: accepted linux-restricted-modules-aws [sync] (focal-proposed) [5.4.0-1008.8]
-queuebot:#ubuntu-release- Unapproved: accepted linux-restricted-modules-gcp [sync] (focal-proposed) [5.4.0-1008.8]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed-azure [sync] (focal-proposed) [5.4.0-1009.9]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed-oracle [sync] (focal-proposed) [5.4.0-1008.8]
-queuebot:#ubuntu-release- Unapproved: accepted linux-azure [sync] (focal-proposed) [5.4.0-1009.9]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-azure [sync] (focal-proposed) [5.4.0.1009.10]
-queuebot:#ubuntu-release- Unapproved: accepted linux-oracle [sync] (focal-proposed) [5.4.0-1008.8]
-queuebot:#ubuntu-release- Unapproved: accepted linux-restricted-modules-oracle [sync] (focal-proposed) [5.4.0-1008.8]
-queuebot:#ubuntu-release- Unapproved: accepted linux-kvm [sync] (focal-proposed) [5.4.0-1007.7]
-queuebot:#ubuntu-release- Unapproved: accepted linux-restricted-modules-azure [sync] (focal-proposed) [5.4.0-1009.9]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-kvm [sync] (focal-proposed) [5.4.0.1007.7]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed-gcp [sync] (focal-proposed) [5.4.0-1008.8]
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (focal-proposed) [1:20.04.3]
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (eoan-proposed/main) [5.3.0-47.39] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-178.208] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (eoan-proposed/main) [5.3.0-47.39] (core, kernel)
<RikMills> morning. I don't have anything urgent in the queue. howver, from the ubuntutestingweek chat, I think kylin are keen to have  ukui-control-center through so their setting app does not segfault on start and testers can properly test
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (eoan-proposed/main) [5.3.0-47.39] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: accepted engrampa [sync] (focal-proposed) [1.24.0-2]
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (eoan-proposed/main) [5.3.0-47.39] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-178.208]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (focal-proposed) [2:16.0.0~b3~git2020032420.a0e1b5804e-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (focal-proposed) [2:21.0.0~b3~git2020032515.35240b0d8c-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (eoan-proposed) [5.3.0-47.39]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (eoan-proposed) [5.3.0-47.39]
-queuebot:#ubuntu-release- Unapproved: accepted colord-kde [sync] (focal-proposed) [0.5.0-4]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (eoan-proposed) [5.3.0-47.39]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (eoan-proposed) [5.3.0-47.39]
-queuebot:#ubuntu-release- Unapproved: accepted ukui-control-center [sync] (focal-proposed) [2.0.3-1]
-queuebot:#ubuntu-release- Unapproved: accepted ukui-panel [sync] (focal-proposed) [2.0.5-1]
-queuebot:#ubuntu-release- Unapproved: accepted kylin-nm [sync] (focal-proposed) [1.2.3-1]
-queuebot:#ubuntu-release- Unapproved: accepted ukui-media [sync] (focal-proposed) [2.0.3-1]
-queuebot:#ubuntu-release- Unapproved: accepted peony [sync] (focal-proposed) [2.1.2-1]
<handsome_feng> RikMills and release team: Thanks! :)
<sil2100> yw o/
<RikMills> :)
<tjaalton> sil2100: filed bug 1871315 for r-p-d
<ubot5> bug 1871315 in rapid-photo-downloader (Ubuntu) "FFe: rapid-photo-downloader 0.9.20" [Undecided,New] https://launchpad.net/bugs/1871315
<doko> tjaalton: reading https://bugs.launchpad.net/ubuntu/+source/darktable/+bug/1871049, why is u-a subscribed?
<ubot5> Ubuntu bug 1871049 in darktable (Ubuntu) "FFe: darktable 2.6.3 in focal needs update to 3.0.1" [Undecided,New]
<tjaalton> doko: it's a FFe?
<tjaalton> ahh
<tjaalton> sorry :D
<tjaalton> fixed
<tjaalton> s/archive/release/, same for r-p-d
-queuebot:#ubuntu-release- Unapproved: gfxboot-theme-ubuntu (focal-proposed/main) [0.23.0 => 0.23.1] (core)
-queuebot:#ubuntu-release- Unapproved: ukui-sidebar (focal-proposed/universe) [1.1.0-1 => 1.1.2-1] (no packageset) (sync)
<Laney> seb128: it looks like those "/<arch>" items don't have to have an age for some reason
<seb128> Laney, so the by_team script needs to be fixed to handle that case?
<seb128> well the age is not the only issue, I made it return 0 for those without an age yesterday but had another error
<seb128> unsure if the items are buggy/shouldn't lack those info and that what needs to be fixed or if the tool needs to deal with those new records
-queuebot:#ubuntu-release- Unapproved: qt5-ukui-platformtheme (focal-proposed/universe) [1.0.2-0ubuntu1 => 1.0.3-0ubuntu1] (no packageset)
<Laney> It looks like binary only migrations don't have (all) the policies run for them
<Laney> I think assume the yaml is ok and make the script deal with it
<seb128> k
 * seb128 adds to the todo
<seb128> I will try to poke a bit later but if someone has the free cycles earlier and want to beat me please do
-queuebot:#ubuntu-release- Unapproved: util-linux (focal-proposed/main) [2.34-0.1ubuntu8 => 2.34-0.1ubuntu9] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: libdmx (focal-proposed/main) [1:1.1.4-1 => 1:1.1.4-2] (i386-whitelist, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted qt5-ukui-platformtheme [source] (focal-proposed) [1.0.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gfxboot-theme-ubuntu [source] (focal-proposed) [0.23.1]
<doko> Eickmeyer[m]: I need to remove displaycal, removed python2 dependencies
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (focal-proposed/main) [5.4.0-1009.9] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (focal-proposed/main) [5.4.0-1008.8] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (focal-proposed/main) [5.4.0-1008.8] (core, kernel)
<Laney> seb128: proposed a merge if you don't see the email, seems to work for me
<seb128> Laney, thanks! will look in a bit
<cking> hi there, a SRU for stress-ng in bionic is pending an upload, 'Not touching package due to block request by freeze', but a re-test on armhf has now passed and there are a few bugs (1858858, 1853832) waiting on this
<seb128> Laney, k, merged, pushed and updated the checkout on the server
<seb128> Laney, bah, looks like you (force?) pushed other changes to the same location while I was merging
<Laney> did not force
<Laney> you must have just been too quick for me
<seb128> ah, I guess the launchpad UI is just smart enough and removed the commit that got merge from the mp
<seb128> Laney, k, 272 as well now :)
<Laney> thanks!
<seb128> thank *you* :-)
-queuebot:#ubuntu-release- Unapproved: python2.7 (focal-proposed/universe) [2.7.17-1ubuntu6 => 2.7.18~rc1-1] (i386-whitelist, kubuntu)
<doko> RikMills: ^^^ apparently python2 is still in the kubuntu package set. can we fix that for final focal?
-queuebot:#ubuntu-release- Unapproved: accepted firefox [source] (focal-proposed) [75.0+build3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-qxl [sync] (focal-proposed) [0.1.5+git20200331-1]
<RikMills> doko: its not in the supported seed. must have been added by the packageset generation scripts at some point
-queuebot:#ubuntu-release- Unapproved: accepted util-linux [source] (focal-proposed) [2.34-0.1ubuntu9]
-queuebot:#ubuntu-release- New source: freeipa (focal-proposed/primary) [4.8.6-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted dropwatch [riscv64] (focal-proposed) [1.5.1-2]
-queuebot:#ubuntu-release- New: accepted freeipa [source] (focal-proposed) [4.8.6-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted r-cran-gwidgetsrgtk2 [amd64] (focal-proposed) [0.0-86-2]
-queuebot:#ubuntu-release- New: accepted xubuntu-community-artwork [amd64] (focal-proposed) [20.04.0]
-queuebot:#ubuntu-release- New: accepted eslint [sync] (focal-proposed) [5.0.1~dfsg-4]
-queuebot:#ubuntu-release- New: accepted r-cran-gwidgetstcltk [amd64] (focal-proposed) [0.0-55-2]
-queuebot:#ubuntu-release- New: accepted pop-icon-theme [amd64] (focal-proposed) [2.1.0~1571158475~19.10~6bf9347]
<bluesabre> Yay!
-queuebot:#ubuntu-release- New binary: freeipa [s390x] (focal-proposed/none) [4.8.6-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: freeipa [ppc64el] (focal-proposed/none) [4.8.6-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: freeipa [amd64] (focal-proposed/universe) [4.8.6-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: freeipa [arm64] (focal-proposed/universe) [4.8.6-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: freeipa [armhf] (focal-proposed/universe) [4.8.6-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xubuntu-artwork (focal-proposed/universe) [20.04 => 20.04.1] (ubuntustudio, xubuntu)
-queuebot:#ubuntu-release- Unapproved: artikulate (focal-proposed/universe) [4:19.12.3-0ubuntu1 => 4:19.12.3-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- New: accepted freeipa [amd64] (focal-proposed) [4.8.6-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted freeipa [armhf] (focal-proposed) [4.8.6-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted freeipa [s390x] (focal-proposed) [4.8.6-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted freeipa [arm64] (focal-proposed) [4.8.6-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted freeipa [ppc64el] (focal-proposed) [4.8.6-1ubuntu1]
<RikMills> ^^ artikulate fix to build for riscv64
-queuebot:#ubuntu-release- Unapproved: accepted artikulate [source] (focal-proposed) [4:19.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: binutils (focal-proposed/main) [2.34-5ubuntu1 => 2.34-6ubuntu1] (core, i386-whitelist)
<bluesabre> Hello release team! Please accept the xubuntu-artwork package above which includes our 20.04 wallpaper. In my excitement, I jumped ahead and uploaded it before the UIFe bug (lp #1871357) was reviewed... (in the past, we've been given the go ahead for our artwork since it doesn't affect any existing translations or documentation)
<ubot5> Launchpad bug 1871357 in xubuntu-artwork (Ubuntu) "[UIFe] New wallpaper for Xubuntu 20.04" [Undecided,New] https://launchpad.net/bugs/1871357
-queuebot:#ubuntu-release- Unapproved: accepted binutils [source] (focal-proposed) [2.34-6ubuntu1]
-queuebot:#ubuntu-release- Unapproved: glslang (focal-proposed/universe) [8.13.3559-3 => 8.13.3559-4] (i386-whitelist) (sync)
-queuebot:#ubuntu-release- New binary: r-cran-rsgcc [amd64] (focal-proposed/universe) [1.0.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rsgcc [ppc64el] (focal-proposed/universe) [1.0.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rsgcc [armhf] (focal-proposed/universe) [1.0.6-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: systemd (focal-proposed/main) [245.2-1ubuntu3 => 245.4-2ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: python-glanceclient (focal-proposed/main) [1:2.17.0-0ubuntu2 => 1:2.17.0-0ubuntu3] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New binary: r-cran-rsgcc [riscv64] (focal-proposed/universe) [1.0.6-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libaccounts-qt (focal-proposed/universe) [1.15+17.04.20161104.1-0ubuntu2 => 1.15+17.04.20161104.1-0ubuntu3] (kubuntu)
<mfo> seb128, thanks for the util-linux review/upload for focal.
<seb128> mfo, np!
<RikMills> seb128 mfo, thanks to you both!
<seb128> np :-)
-queuebot:#ubuntu-release- Unapproved: ukui-menu (focal-proposed/universe) [2.0.4-1 => 2.0.5-1] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: update-manager (focal-proposed/main) [1:20.04.3 => 1:20.04.4] (core)
-queuebot:#ubuntu-release- Unapproved: kylin-display-switch (focal-proposed/universe) [1.0.3-1 => 1.0.4-1] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- New: accepted r-cran-rsgcc [amd64] (focal-proposed) [1.0.6-2]
-queuebot:#ubuntu-release- New: accepted r-cran-rsgcc [ppc64el] (focal-proposed) [1.0.6-2]
-queuebot:#ubuntu-release- New: accepted r-cran-rsgcc [armhf] (focal-proposed) [1.0.6-2]
-queuebot:#ubuntu-release- New: accepted r-cran-rsgcc [riscv64] (focal-proposed) [1.0.6-2]
-queuebot:#ubuntu-release- Unapproved: ukui-greeter (focal-proposed/universe) [1.2.3-1 => 1.2.5-1] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: vala (focal-proposed/universe) [0.48.2-1 => 0.48.3-1] (i386-whitelist, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: libcmis (focal-proposed/main) [0.5.2-1build1 => 0.5.2-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rejected libcmis [source] (focal-proposed) [0.5.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libcmis (focal-proposed/main) [0.5.2-1build1 => 0.5.2-1ubuntu1] (ubuntu-desktop)
<RikMills> wgr@nt's libaccounts-qt in the queue should help more KDE/qt things build for riscv64. if anyone can let that in, would be great :)
<seb128> vorlon, did you remove the colord/i386 hint in 4724 on purpose or by mistake? it's still failing https://autopkgtest.ubuntu.com/packages/colord/focal/i386 and blocking other things now
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (focal-proposed) [5.4.0-1009.9]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (focal-proposed) [5.4.0-1008.8]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (focal-proposed) [5.4.0-1008.8]
<rbalint> sil2100, vorlon please check systemd in the focal queue
-queuebot:#ubuntu-release- Unapproved: ubuntustudio-live (focal-proposed/universe) [1.3 => 1.4] (ubuntustudio)
<Eickmeyer[m]> ^ Please accept/approve, fixes the package selection plugin bug (removes the plugin)
<Eickmeyer[m]> In Ubiquity
-queuebot:#ubuntu-release- Unapproved: freeipa (focal-proposed/universe) [4.8.6-1ubuntu1 => 4.8.6-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted freeipa [source] (focal-proposed) [4.8.6-1ubuntu2]
<rbalint> juliank, Laney what version of autodep8 is running on the autopkgtest infra? i suspect it does not have the latest 0.22ubuntu1 because dkms tests are failing
<rbalint> like broadcom-sta
<Laney> https://code.launchpad.net/~ubuntu-release/+git/autodep8/+ref/master that
<bdmurray> vorlon, Laney, sil2100: I've reviewed update-manager for focal and its good if you could accept it for me that'd be great.
<Laney> sure
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (focal-proposed) [1:20.04.4]
<bdmurray> Laney: xubuntu-artwork looks good too, I also checked the image
<sil2100> bdmurray: on it
-queuebot:#ubuntu-release- Unapproved: accepted xubuntu-artwork [source] (focal-proposed) [20.04.1]
<rbalint> Laney, please cherry-pick https://code.launchpad.net/~rbalint/+git/autodep8 to lp:~ubuntu-release/+git/autodep8  , lp does not allow opening a merge proposal
-queuebot:#ubuntu-release- Unapproved: libtomcrypt (focal-proposed/universe) [1.18.2-2 => 1.18.2-3] (kubuntu) (sync)
<RikMills> build fix. will let riscv64 build ^
<RikMills> and that is in build dep chain for plasma-nm
-queuebot:#ubuntu-release- Unapproved: lxcfs (focal-proposed/universe) [4.0.1-0ubuntu2 => 4.0.2-0ubuntu1] (edubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted lxcfs [source] (focal-proposed) [4.0.2-0ubuntu1]
<Eickmeyer[m]> Question: Is there a way to test an image built from a seed locally?
<rafaeldtinoco> Could I please get FFe feedback/approval for bugs LP: #1866385 (kronosnet) and LP: #1866383 (resource-agents) ?
<ubot5> Launchpad bug 1866385 in kronosnet (Ubuntu) "[FFe][focal] kronosnet need fixes from just released upstream version" [Medium,New] https://launchpad.net/bugs/1866385
<ubot5> Launchpad bug 1866383 in resource-agents (Ubuntu) "[FFe][Focal] resource-agents need fixes from recent release upstream version" [Undecided,New] https://launchpad.net/bugs/1866383
<rafaeldtinoco> I'm stabilizing HA stack and need those
-queuebot:#ubuntu-release- Unapproved: apport (focal-proposed/main) [2.20.11-0ubuntu24 => 2.20.11-0ubuntu25] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: accepted glance [source] (eoan-proposed) [2:19.0.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (eoan-proposed) [2:15.0.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron-fwaas [source] (eoan-proposed) [1:15.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: alsa-tools (focal-proposed/universe) [1.1.7-1build1 => 1.1.7-1ubuntu1] (ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (eoan-proposed) [3:16.1.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python2.7 (focal-proposed/universe) [2.7.17-1ubuntu6 => 2.7.18~rc1-2] (i386-whitelist, kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: rejected python2.7 [source] (focal-proposed) [2.7.18~rc1-1]
-queuebot:#ubuntu-release- Unapproved: xubuntu-artwork (focal-proposed/universe) [20.04.1 => 20.04.2] (ubuntustudio, xubuntu)
<bluesabre> Hello release team! Please accept the above xubuntu-artwork package. We uploaded the wrong version of our new wallpaper this morning... and now we're back with the correct one. :)
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (eoan-proposed) [2:20.1.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ceilometer [source] (eoan-proposed) [1:13.1.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (eoan-proposed) [2:15.1.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: node-rollup-pluginutils (focal-proposed/universe) [2.8.2-7build2 => 2.8.2-7build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: node-rollup (focal-proposed/universe) [1.12.0-2build2 => 1.12.0-2build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted node-rollup-pluginutils [source] (focal-proposed) [2.8.2-7build3]
-queuebot:#ubuntu-release- Unapproved: accepted node-rollup [source] (focal-proposed) [1.12.0-2build3]
-queuebot:#ubuntu-release- Unapproved: accepted json-glib [source] (eoan-proposed) [1.4.4-2ubuntu0.19.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted json-glib [source] (bionic-proposed) [1.4.2-3ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (bionic-proposed/main) [5.3.0-47.39~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (bionic-proposed/main) [5.3.0-47.39~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [arm64] (bionic-proposed/main) [5.3.0-47.39~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-97.98] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oem-5.6 [amd64] (focal-proposed/universe) [5.6.0-1007.7] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-97.98] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: node-os-locale (focal-proposed/universe) [2.0.0-1 => 4.0.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-file-entry-cache (focal-proposed/universe) [5.0.1+~2.0.1+~2.0.0+~1.0.0+~2.0.1-4 => 5.0.1+~2.0.1+~2.0.0+~1.0.0+~2.0.1-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-file-entry-cache [sync] (focal-proposed) [5.0.1+~2.0.1+~2.0.0+~1.0.0+~2.0.1-5]
-queuebot:#ubuntu-release- Unapproved: accepted node-os-locale [sync] (focal-proposed) [4.0.0-1]
-queuebot:#ubuntu-release- Unapproved: node-pump (focal-proposed/universe) [3.0.0-1 => 3.0.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-espree (focal-proposed/universe) [6.0.0+ds-2 => 6.0.0+ds-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-minimatch (focal-proposed/universe) [3.0.4-3 => 3.0.4-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-esrecurse (focal-proposed/universe) [4.2.0-1 => 4.2.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-espree [sync] (focal-proposed) [6.0.0+ds-3]
-queuebot:#ubuntu-release- Unapproved: accepted node-minimatch [sync] (focal-proposed) [3.0.4-4]
-queuebot:#ubuntu-release- Unapproved: node-p-limit (focal-proposed/universe) [1.1.0-1 => 2.2.2-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-esrecurse [sync] (focal-proposed) [4.2.1-1]
-queuebot:#ubuntu-release- Unapproved: node-resolve (focal-proposed/universe) [1.5.0-1 => 1.15.1-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-pump [sync] (focal-proposed) [3.0.0-2]
-queuebot:#ubuntu-release- Unapproved: accepted node-p-limit [sync] (focal-proposed) [2.2.2-1]
-queuebot:#ubuntu-release- Unapproved: node-esquery (focal-proposed/universe) [1.0.1-1 => 1.1.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-wordwrap (focal-proposed/universe) [1.0.0-1 => 1.0.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-resolve [sync] (focal-proposed) [1.15.1-3]
-queuebot:#ubuntu-release- Unapproved: should.js (focal-proposed/universe) [13.2.3~dfsg-2 => 13.2.3~dfsg-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-mkdirp (focal-proposed/universe) [0.5.1-1 => 0.5.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-esquery [sync] (focal-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted node-wordwrap [sync] (focal-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- Unapproved: accepted node-mkdirp [sync] (focal-proposed) [0.5.1-2]
-queuebot:#ubuntu-release- Unapproved: accepted should.js [sync] (focal-proposed) [13.2.3~dfsg-3]
-queuebot:#ubuntu-release- Unapproved: node-path-is-absolute (focal-proposed/universe) [1.0.0-1 => 2.0.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-has-flag (focal-proposed/universe) [4.0.0-1 => 4.0.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-inherits (focal-proposed/universe) [2.0.4-1 => 2.0.4-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-has-flag [sync] (focal-proposed) [4.0.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted node-path-is-absolute [sync] (focal-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- Unapproved: node-minimist (focal-proposed/universe) [1.2.0-1 => 1.2.5-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-inherits [sync] (focal-proposed) [2.0.4-1]
-queuebot:#ubuntu-release- Unapproved: node-function-bind (focal-proposed/universe) [1.1.1+repack-1 => 1.1.1+repack-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: rejected node-function-bind [sync] (focal-proposed) [1.1.1+repack-1]
-queuebot:#ubuntu-release- Unapproved: accepted node-minimist [sync] (focal-proposed) [1.2.5-1]
-queuebot:#ubuntu-release- Unapproved: ubuntustudio-icon-theme (focal-proposed/universe) [0.20 => 0.21] (ubuntustudio)
<Eickmeyer[m]> ^ Please approve/accept, fixes bug 1871508
<ubot5> bug 1871508 in ubuntustudio-icon-theme (Ubuntu) "Toolbar icons not properly following color scheme" [Undecided,Fix committed] https://launchpad.net/bugs/1871508
<mwhudson> if someone could accept apport, that would be grand
<vorlon> rbalint: systemd in the focal queue includes Debian changes to revert seccomp support on systemd, whereas the version in -proposed built fine on riscv64 with seccomp support, so nack, rejecting
-queuebot:#ubuntu-release- Unapproved: rejected systemd [source] (focal-proposed) [245.4-2ubuntu1]
#ubuntu-release 2020-04-08
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (bionic-proposed) [5.3.0-47.39~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (bionic-proposed) [5.3.0-47.39~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-97.98]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [arm64] (bionic-proposed) [5.3.0-47.39~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-97.98]
-queuebot:#ubuntu-release- Unapproved: eslint (focal-proposed/universe) [5.0.1~dfsg-4 => 5.0.1~dfsg-4build2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-eslint-plugin-eslint-plugin (focal-proposed/universe) [2.2.1-1 => 2.2.1-1build3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-eslint-plugin-node (focal-proposed/universe) [6.0.1~dfsg-4 => 6.0.1~dfsg-4build3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-proxyquire (focal-proposed/universe) [2.1.3+~1.0.1+~1.0.2-9 => 2.1.3+~1.0.1+~1.0.2-9build3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-file-entry-cache (focal-proposed/universe) [5.0.1+~2.0.1+~2.0.0+~1.0.0+~2.0.1-5 => 5.0.1+~2.0.1+~2.0.0+~1.0.0+~2.0.1-5build2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted eslint [sync] (focal-proposed) [5.0.1~dfsg-4build2]
-queuebot:#ubuntu-release- Unapproved: accepted node-eslint-plugin-node [sync] (focal-proposed) [6.0.1~dfsg-4build3]
-queuebot:#ubuntu-release- Unapproved: accepted node-proxyquire [sync] (focal-proposed) [2.1.3+~1.0.1+~1.0.2-9build3]
-queuebot:#ubuntu-release- Unapproved: accepted node-eslint-plugin-eslint-plugin [sync] (focal-proposed) [2.2.1-1build3]
-queuebot:#ubuntu-release- Unapproved: accepted node-file-entry-cache [sync] (focal-proposed) [5.0.1+~2.0.1+~2.0.0+~1.0.0+~2.0.1-5build2]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-5.6 [amd64] (focal-proposed) [5.6.0-1007.7]
-queuebot:#ubuntu-release- New binary: node-eslint-plugin-requirejs [amd64] (focal-proposed/universe) [4.0.0-5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gnome-software (eoan-proposed/main) [3.30.6-2ubuntu10.19.10.0 => 3.30.6-2ubuntu10.19.10.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: python-debian (focal-proposed/main) [0.1.36build1 => 0.1.36ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: thunderbird (focal-proposed/main) [1:68.6.0+build2-0ubuntu1 => 1:68.7.0+build1-0ubuntu1] (mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted ukui-menu [sync] (focal-proposed) [2.0.5-1]
-queuebot:#ubuntu-release- Unapproved: accepted ukui-sidebar [sync] (focal-proposed) [1.1.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted ukui-greeter [sync] (focal-proposed) [1.2.5-1]
-queuebot:#ubuntu-release- Unapproved: accepted kylin-display-switch [sync] (focal-proposed) [1.0.4-1]
-queuebot:#ubuntu-release- Unapproved: accepted libcmis [source] (focal-proposed) [0.5.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted rapid-photo-downloader [source] (focal-proposed) [0.9.20-0ubuntu1]
<sil2100> o/
-queuebot:#ubuntu-release- Unapproved: accepted libaccounts-qt [source] (focal-proposed) [1.15+17.04.20161104.1-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted python-glanceclient [source] (focal-proposed) [1:2.17.0-0ubuntu3]
<sil2100> juliank: hey! Didn't you also look into the crash with studio installation after deselecting packages?
<sil2100> Since I see an upload in the queue that removes the package selection plugin, I think?
<juliank> sil2100: Yes, that's correct, and yes, the plan was to remove the plugin, as it's conceptually broken
<juliank> sil2100: so yes please accept that
<sil2100> ACK o/
-queuebot:#ubuntu-release- Unapproved: accepted ubuntustudio-live [source] (focal-proposed) [1.4]
-queuebot:#ubuntu-release- Unapproved: casper (focal-proposed/main) [1.443 => 1.444] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted libtomcrypt [sync] (focal-proposed) [1.18.2-3]
-queuebot:#ubuntu-release- Unapproved: librsvg (focal-proposed/main) [2.48.0-2 => 2.48.2-1] (core, i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted alsa-tools [source] (focal-proposed) [1.1.7-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (focal-proposed) [2.20.11-0ubuntu25]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntustudio-icon-theme [source] (focal-proposed) [0.21]
-queuebot:#ubuntu-release- Unapproved: accepted xubuntu-artwork [source] (focal-proposed) [20.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted python-debian [source] (focal-proposed) [0.1.36ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python2.7 [sync] (focal-proposed) [2.7.18~rc1-2]
-queuebot:#ubuntu-release- Unapproved: accepted librsvg [sync] (focal-proposed) [2.48.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted casper [source] (focal-proposed) [1.444]
-queuebot:#ubuntu-release- Unapproved: python-stdlib-extensions (focal-proposed/universe) [2.7.17-2 => 2.7.18-1] (i386-whitelist, kubuntu) (sync)
<Laney> rbalint: Can we get that forwarded upstream please?
<mwhudson> will someone on the release team be looking at UNAPPROVED today?
<mwhudson> oh i was scrolled back, i see it's happening :)
<Laney> yes, as every day!
<mwhudson> sil2100: thanks :)
<mwhudson> Laney: can someone on the release team move to my timezone please?
<mwhudson> not very practical currently i guess :)
<mwhudson> maybe for 21.04
<apw> soz locked-down :)
<sil2100> Laney: what do we do with stuffs like thunderbirds and firefoxes? I guess we accept those animals, right?
<Laney> sil2100: Right, check the debian/ diff and close your eyes
<sil2100> ;)
<apw> sil2100, Laney, you left out "shed a few tears"
<Laney> they get in through -security for stable releases so ...
<Laney> apw: ah, that's my default state
<Laney> </angst>
 * Laney moves to .nz per the offer, perhaps that'll help
<rbalint> Laney, sure, will do soon
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (focal-proposed/main) [2.657 => 2.658] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: systemd (focal-proposed/main) [245.2-1ubuntu3 => 245.4-2ubuntu1] (core, i386-whitelist)
<xnox> mwhudson:  so i can't yaml, right?
<mwhudson> xnox: well
<mwhudson> xnox: it's yaml
<mwhudson> xnox: just not netplan config
<rbalint> Laney, done: https://salsa.debian.org/ci-team/autodep8/-/merge_requests/21
<mwhudson> xnox: can you test an lpar install with a customized initrd for me?
<mwhudson> people keel talking to jfh it seems
<xnox> mwhudson:  sure
<xnox> mwhudson:  give me all the things =)
<mwhudson> xnox: https://people.canonical.com/~mwh/s390x-initrd.lz4
<xnox> mwhudson:  got it.
<mwhudson> xnox: it's been de-uuidified so should work with whichever rootfs you like
<mwhudson> but it came from 20200407 i think
<jfh> yes - it was the yesterdays ISO ... 7th
<xnox> mwhudson:  le sigh, i see. But is it cloud-init failing to parse that, or netplan failing to parse that, or subiquity failing to parse it?
<mwhudson> xnox: cloud-init
<xnox> mwhudson:  twats.
<xnox> mwhudson:  ok.
<mwhudson> xnox: but if cloud-init succeeded, netplan would then choke on it
<xnox> right
<mwhudson> and then probably subiquity too, i haven't actually checked that far :)
<mwhudson> yeah subiquity would crash
<xnox> mwhudson:  i think your code is still broken, for non-vlan static ip address though.
<xnox> because it will have
<xnox> ethernets:
<xnox>    ens3:
<xnox> actually, no, it should be fine.
<mwhudson> yeah i hope so
<mwhudson> 	elif [ -n "$vname" ]; then
<mwhudson> 		echo "	    {}"
<mwhudson> 	fi
<mwhudson> 	if [ -n "$vname" ]; then
<xnox> indeed.
<mwhudson> looks mighty weird but i think it's correct
<jamespage> hi release team - I just testing a fix for bug 1869324
<ubot5> bug 1869324 in ceph (Ubuntu) "civetweb: 0x7f4763896580: cannot bind to 70: 13 (Permission denied)" [High,In progress] https://launchpad.net/bugs/1869324
<jamespage> which is a bit of a blocker for ceph deploys so would be good to get accepted once I upload :)
<rbalint> please accept systemd ^^, i've reenabled seccomp support per vorlon's request
<mwhudson> sigh is buildd-manager melting again
-queuebot:#ubuntu-release- New: accepted node-eslint-plugin-requirejs [amd64] (focal-proposed) [4.0.0-5]
-queuebot:#ubuntu-release- Unapproved: ipxe-qemu-256k-compat (focal-proposed/main) [1.0.0+git-20150424.a25a16d-0ubuntu3 => 1.0.0+git-20150424.a25a16d-0ubuntu4] (ubuntu-server)
<mwhudson> xnox: any luck testing that initrd yet?
-queuebot:#ubuntu-release- Unapproved: eslint (focal-proposed/universe) [5.0.1~dfsg-4build2 => 5.0.1~dfsg-4build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: node-eslint-plugin-node (focal-proposed/universe) [6.0.1~dfsg-4build3 => 6.0.1~dfsg-4build4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ceph (focal-proposed/main) [15.2.0-0ubuntu1 => 15.2.0-0ubuntu2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted eslint [source] (focal-proposed) [5.0.1~dfsg-4build3]
-queuebot:#ubuntu-release- Unapproved: node-eslint-plugin-eslint-plugin (focal-proposed/universe) [2.2.1-1build3 => 2.2.1-1build4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: node-proxyquire (focal-proposed/universe) [2.1.3+~1.0.1+~1.0.2-9build3 => 2.1.3+~1.0.1+~1.0.2-9build4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted node-eslint-plugin-node [source] (focal-proposed) [6.0.1~dfsg-4build4]
-queuebot:#ubuntu-release- Unapproved: node-file-entry-cache (focal-proposed/universe) [5.0.1+~2.0.1+~2.0.0+~1.0.0+~2.0.1-5build2 => 5.0.1+~2.0.1+~2.0.0+~1.0.0+~2.0.1-5build3] (no packageset)
<xnox> mwhudson:  i was in a hangout =)
<xnox> mwhudson:  do log-off, will test, if good, will upload.
<Laney> rbalint: it's done
<xnox> mwhudson:  or pastebin debdiff to me
<xnox> mwhudson:  it is unsocial hour for you already?
<mwhudson> xnox: https://paste.ubuntu.com/p/nrHjjYshsY/
-queuebot:#ubuntu-release- Unapproved: accepted node-eslint-plugin-eslint-plugin [source] (focal-proposed) [2.2.1-1build4]
-queuebot:#ubuntu-release- Unapproved: accepted node-proxyquire [source] (focal-proposed) [2.1.3+~1.0.1+~1.0.2-9build4]
-queuebot:#ubuntu-release- Unapproved: accepted node-file-entry-cache [source] (focal-proposed) [5.0.1+~2.0.1+~2.0.0+~1.0.0+~2.0.1-5build3]
<mwhudson> xnox: i started late but yes i'd like to stop now
<xnox> mwhudson:  have fun! =)
-queuebot:#ubuntu-release- Unapproved: mkvtoolnix (focal-proposed/universe) [45.0.0-1ubuntu1 => 45.0.0-2] (no packageset) (sync)
<mwhudson> i was hoping that images would be published and i could make a discourse post about autoinstalls
<mwhudson> i guess i'll do that in the morning
-queuebot:#ubuntu-release- Unapproved: ghdl (focal-proposed/universe) [0.35+git20181129+dfsg-4ubuntu1 => 0.37+dfsg-1] (no packageset) (sync)
<mwhudson> xnox: wrote a thing https://wiki.ubuntu.com/FoundationsTeam/AutomatedServerInstalls/QuickStart
-queuebot:#ubuntu-release- Unapproved: accepted ghdl [sync] (focal-proposed) [0.37+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: accepted mkvtoolnix [sync] (focal-proposed) [45.0.0-2]
<mwhudson> xnox: (possibly using a config drive would be better? this is how i've been testing though)
<rbalint> Laney, thanks, can i retrigger the tests now or there is a propagation delay?
<Laney> no delay
<Laney> but maybe just try one test to make sure it does what you want
<xnox> mwhudson:  we can add config-drive commands too, cloud-init ships a tool to create config drive these days.
<xnox> mwhudson:  not sure how to merge the two into a single usb stick though
<mwhudson> xnox: well for vm testing you don't need to do that
<xnox> right
<mwhudson> for a usb stick you somehow need to delete the "iso nature" from the stick so regular partitioning tools don't go cross eyed looking at the partition table
<mwhudson> oh and i guess overriding the command line is a touch harder
-queuebot:#ubuntu-release- Unapproved: node-ansi-font (focal-proposed/universe) [0.0.2-1 => 0.0.2-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-array-from (focal-proposed/universe) [2.1.1-1 => 2.1.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-astw (focal-proposed/universe) [2.2.0-3 => 2.2.0-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-babel (focal-proposed/universe) [6.26.0+repack-2 => 6.26.0+repack-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-autoprefixer (focal-proposed/universe) [8.6.5-2 => 8.6.5+repack-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-ansi-font [sync] (focal-proposed) [0.0.2-2]
-queuebot:#ubuntu-release- Unapproved: accepted node-astw [sync] (focal-proposed) [2.2.0-4]
-queuebot:#ubuntu-release- Unapproved: accepted node-babel [sync] (focal-proposed) [6.26.0+repack-3]
-queuebot:#ubuntu-release- Unapproved: node-boom (focal-proposed/universe) [7.4.3+~1.3.1-2 => 9.0.0+~2.0.0+ds-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-browser-pack (focal-proposed/universe) [6.1.0+ds-5 => 6.1.0+ds-6] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ruby-bio (focal-proposed/universe) [2.0.1-1 => 2.0.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-array-from [sync] (focal-proposed) [2.1.1-2]
-queuebot:#ubuntu-release- Unapproved: node-bluebird (focal-proposed/universe) [3.5.3+dfsg1-1 => 3.5.3+dfsg1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ruby-ahoy-matey (focal-proposed/universe) [3.0.0-2 => 3.0.2-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-autoprefixer [sync] (focal-proposed) [8.6.5+repack-1]
-queuebot:#ubuntu-release- Unapproved: node-boxen (focal-proposed/universe) [1.3.0-1 => 4.2.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-bluebird [sync] (focal-proposed) [3.5.3+dfsg1-2]
-queuebot:#ubuntu-release- Unapproved: accepted node-boxen [sync] (focal-proposed) [4.2.0-2]
-queuebot:#ubuntu-release- Unapproved: accepted ruby-ahoy-matey [sync] (focal-proposed) [3.0.2-1]
-queuebot:#ubuntu-release- Unapproved: node-chainsaw (focal-proposed/universe) [0.1.0-1 => 0.1.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ruby-delayer-deferred (focal-proposed/universe) [2.1.1-3 => 2.2.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-boom [sync] (focal-proposed) [9.0.0+~2.0.0+ds-1]
-queuebot:#ubuntu-release- Unapproved: accepted ruby-bio [sync] (focal-proposed) [2.0.1-2]
-queuebot:#ubuntu-release- Unapproved: ruby-delayer (focal-proposed/universe) [1.0.1-2 => 1.1.2-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-browser-pack [sync] (focal-proposed) [6.1.0+ds-6]
-queuebot:#ubuntu-release- Unapproved: node-ci-info (focal-proposed/universe) [1.1.2-1 => 2.0.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-ci-info [sync] (focal-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- Unapproved: node-d3 (focal-proposed/universe) [4.13.0-10 => 5.12.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-copy-webpack-plugin (focal-proposed/universe) [4.3.0-6 => 4.3.0-7] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-chainsaw [sync] (focal-proposed) [0.1.0-2]
-queuebot:#ubuntu-release- Unapproved: accepted ruby-delayer [sync] (focal-proposed) [1.1.2-1]
-queuebot:#ubuntu-release- Unapproved: node-d3-interpolate (focal-proposed/universe) [1.3.2-3 => 1.4.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ruby-delayer-deferred [sync] (focal-proposed) [2.2.0-1]
-queuebot:#ubuntu-release- Unapproved: node-d3-quadtree (focal-proposed/universe) [1.0.6-2 => 1.0.7-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-d3-drag (focal-proposed/universe) [1.2.3-2 => 1.2.5-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-copy-webpack-plugin [sync] (focal-proposed) [4.3.0-7]
-queuebot:#ubuntu-release- Unapproved: accepted node-d3-interpolate [sync] (focal-proposed) [1.4.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted node-d3 [sync] (focal-proposed) [5.12.0-2]
-queuebot:#ubuntu-release- Unapproved: node-d3-shape (focal-proposed/universe) [1.3.5-2 => 1.3.7-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-d3-drag [sync] (focal-proposed) [1.2.5-1]
-queuebot:#ubuntu-release- Unapproved: node-d3-scale-chromatic (focal-proposed/universe) [1.3.3-2 => 1.5.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-d3-quadtree [sync] (focal-proposed) [1.0.7-1]
-queuebot:#ubuntu-release- Unapproved: accepted node-d3-scale-chromatic [sync] (focal-proposed) [1.5.0-1]
-queuebot:#ubuntu-release- Unapproved: node-dagre-d3-renderer (focal-proposed/universe) [0.5.8+dfsg-2 => 0.6.4+dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-doctrine (focal-proposed/universe) [3.0.0-1 => 3.0.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-d3-shape [sync] (focal-proposed) [1.3.7-1]
-queuebot:#ubuntu-release- Unapproved: node-dot (focal-proposed/universe) [1.1.1-1 => 1.1.3+ds-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-dagre-layout (focal-proposed/universe) [0.8.8-6 => 0.8.8+really0.8.5+dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-dagre-d3-renderer [sync] (focal-proposed) [0.6.4+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: accepted node-doctrine [sync] (focal-proposed) [3.0.0-2]
-queuebot:#ubuntu-release- Unapproved: node-es6-weak-map (focal-proposed/universe) [2.0.2-1 => 2.0.3-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-dagre-layout [sync] (focal-proposed) [0.8.8+really0.8.5+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: node-eslint-plugin-html (focal-proposed/universe) [3.2.1-1 => 3.2.1-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-dot [sync] (focal-proposed) [1.1.3+ds-1]
-queuebot:#ubuntu-release- Unapproved: node-eslint-visitor-keys (focal-proposed/universe) [1.1.0-3 => 1.1.0-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-fbjs (focal-proposed/universe) [1.0.0-2 => 1.0.0-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-es6-weak-map [sync] (focal-proposed) [2.0.3-1]
-queuebot:#ubuntu-release- Unapproved: accepted node-eslint-visitor-keys [sync] (focal-proposed) [1.1.0-3]
-queuebot:#ubuntu-release- Unapproved: node-forever-agent (focal-proposed/universe) [0.6.1-1 => 0.6.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-eslint-plugin-html [sync] (focal-proposed) [3.2.1-3]
-queuebot:#ubuntu-release- Unapproved: node-fs-extra (focal-proposed/universe) [8.1.0-2 => 9.0.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-filesize (focal-proposed/universe) [3.5.11+dfsg-2 => 6.1.0+dfsg-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-fbjs [sync] (focal-proposed) [1.0.0-4]
-queuebot:#ubuntu-release- Unapproved: accepted node-forever-agent [sync] (focal-proposed) [0.6.1-2]
-queuebot:#ubuntu-release- Unapproved: node-get-stdin (focal-proposed/universe) [5.0.1-1 => 6.0.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-filesize [sync] (focal-proposed) [6.1.0+dfsg-2]
-queuebot:#ubuntu-release- Unapproved: node-get-stream (focal-proposed/universe) [3.0.0-1 => 4.1.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-fs-extra [sync] (focal-proposed) [9.0.0-1]
-queuebot:#ubuntu-release- Unapproved: node-glogg (focal-proposed/universe) [1.0.0-1 => 1.0.2-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-grunt-contrib-clean (focal-proposed/universe) [1.0.0-2 => 2.0.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-graphlibrary (focal-proposed/universe) [2.2.0+dfsg-2 => 2.2.0+really2.1.8+dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-get-stdin [sync] (focal-proposed) [6.0.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted node-glogg [sync] (focal-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted node-grunt-contrib-clean [sync] (focal-proposed) [2.0.0-2]
-queuebot:#ubuntu-release- Unapproved: node-gulp-concat (focal-proposed/universe) [2.6.1-1 => 2.6.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-get-stream [sync] (focal-proposed) [4.1.0-1]
-queuebot:#ubuntu-release- Unapproved: node-gulp-coffee (focal-proposed/universe) [2.3.4-1 => 2.3.4-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-graphlibrary [sync] (focal-proposed) [2.2.0+really2.1.8+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: node-gulp (focal-proposed/universe) [3.9.1-7 => 4.0.2-6] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-gulp-coffee [sync] (focal-proposed) [2.3.4-2]
-queuebot:#ubuntu-release- Unapproved: accepted node-gulp [sync] (focal-proposed) [4.0.2-6]
-queuebot:#ubuntu-release- Unapproved: node-gyp (focal-proposed/universe) [6.1.0-2 => 6.1.0-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-gulp-concat [sync] (focal-proposed) [2.6.1-2]
-queuebot:#ubuntu-release- Unapproved: node-gulp-util (focal-proposed/universe) [3.0.7-1 => 3.0.8-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-har-schema (focal-proposed/universe) [2.0.0-2 => 2.0.0-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-hooker (focal-proposed/universe) [0.2.3-1 => 0.2.3-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-has-binary (focal-proposed/universe) [0.1.7-1 => 0.1.7-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-gulp-util [sync] (focal-proposed) [3.0.8-1]
-queuebot:#ubuntu-release- Unapproved: accepted node-har-schema [sync] (focal-proposed) [2.0.0-3]
-queuebot:#ubuntu-release- Unapproved: accepted node-hooker [sync] (focal-proposed) [0.2.3-2]
-queuebot:#ubuntu-release- Unapproved: accepted node-gyp [sync] (focal-proposed) [6.1.0-3]
-queuebot:#ubuntu-release- Unapproved: accepted node-has-binary [sync] (focal-proposed) [0.1.7-2]
<LocutusOfBorg> I syncd lots of autopkgtests fixes in nodejs, it should be better now with new nodejs, eslint is finally bootstrapped, as well as rollup, my next goal is to make mocha migrate
<LocutusOfBorg> sorry for the spam
-queuebot:#ubuntu-release- Unapproved: node-vinyl-fs (focal-proposed/universe) [2.4.4-3 => 3.0.3-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-vinyl-fs [sync] (focal-proposed) [3.0.3-5]
-queuebot:#ubuntu-release- Unapproved: ghdl (focal-proposed/universe) [0.37+dfsg-1 => 0.37+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ghdl [source] (focal-proposed) [0.37+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ipxe-qemu-256k-compat [source] (focal-proposed) [1.0.0+git-20150424.a25a16d-0ubuntu4]
<doko> LocutusOfBorg: ghdl still ftbfs
-queuebot:#ubuntu-release- Unapproved: gtk+3.0 (focal-proposed/main) [3.24.14-1ubuntu2 => 3.24.17-3ubuntu1] (i386-whitelist, ubuntu-desktop)
<LocutusOfBorg> doko, nope
<LocutusOfBorg> ppc64el and riscv64 are failing also in release pocket, I tested in my ppa before uploading
-queuebot:#ubuntu-release- Unapproved: node-yn (focal-proposed/universe) [3.0.0-1 => 4.0.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-yn [sync] (focal-proposed) [4.0.0-1]
-queuebot:#ubuntu-release- Unapproved: node-rollup-plugin-buble (focal-proposed/universe) [0.19.4-3 => 0.19.8-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-rollup-plugin-buble [sync] (focal-proposed) [0.19.8-2]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-97.98~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-97.98~16.04.1] (kernel)
-queuebot:#ubuntu-release- Unapproved: node-hosted-git-info (focal-proposed/universe) [2.7.1-1 => 2.8.5-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-http-errors (focal-proposed/universe) [1.7.1-1 => 1.7.3-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-hosted-git-info [sync] (focal-proposed) [2.8.5-1]
-queuebot:#ubuntu-release- Unapproved: node-iconv-lite (focal-proposed/universe) [0.4.13-3 => 0.4.23-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-immutable-tuple (focal-proposed/universe) [0.4.10-5 => 0.4.10-6] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-http-errors [sync] (focal-proposed) [1.7.3-1]
-queuebot:#ubuntu-release- Unapproved: node-immediate (focal-proposed/universe) [3.2.3+dfsg-1 => 3.2.3+dfsg-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-immutable-tuple [sync] (focal-proposed) [0.4.10-6]
-queuebot:#ubuntu-release- Unapproved: node-isomorphic-fetch (focal-proposed/universe) [2.2.1-1 => 2.2.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-iconv-lite [sync] (focal-proposed) [0.4.23-1]
-queuebot:#ubuntu-release- Unapproved: node-jquery-textcomplete (focal-proposed/universe) [1.7.3+dfsg-2 => 1.8.5+dfsg-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-immediate [sync] (focal-proposed) [3.2.3+dfsg-2]
-queuebot:#ubuntu-release- Unapproved: accepted node-isomorphic-fetch [sync] (focal-proposed) [2.2.1-2]
-queuebot:#ubuntu-release- Unapproved: accepted node-jquery-textcomplete [sync] (focal-proposed) [1.8.5+dfsg-4]
-queuebot:#ubuntu-release- Unapproved: node-jquery.waitforimages (focal-proposed/universe) [2.4.0+ds-2 => 2.4.0+ds-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-json-buffer (focal-proposed/universe) [3.0.0-1 => 3.0.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-json2module (focal-proposed/universe) [0.0.3-1 => 0.0.3-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-json-stringify-safe (focal-proposed/universe) [5.0.1+repack-1 => 5.0.1+repack-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-jquery.waitforimages [sync] (focal-proposed) [2.4.0+ds-5]
-queuebot:#ubuntu-release- Unapproved: accepted node-json-stringify-safe [sync] (focal-proposed) [5.0.1+repack-2]
-queuebot:#ubuntu-release- Unapproved: node-jsonld (focal-proposed/universe) [1.6.2-2 => 1.6.2-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-jsprim (focal-proposed/universe) [1.4.0-1 => 1.4.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-json-buffer [sync] (focal-proposed) [3.0.1-1]
-queuebot:#ubuntu-release- Unapproved: node-jsonstream (focal-proposed/universe) [1.3.2-1 => 1.3.5-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-json2module [sync] (focal-proposed) [0.0.3-2]
-queuebot:#ubuntu-release- Unapproved: accepted node-jsonld [sync] (focal-proposed) [1.6.2-3]
-queuebot:#ubuntu-release- Unapproved: accepted node-jsprim [sync] (focal-proposed) [1.4.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted node-jsonstream [sync] (focal-proposed) [1.3.5-1]
-queuebot:#ubuntu-release- Unapproved: node-libnpx (focal-proposed/universe) [10.2.1-1 => 10.2.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-libnpx [sync] (focal-proposed) [10.2.1-2]
-queuebot:#ubuntu-release- Unapproved: node-loader-runner (focal-proposed/universe) [2.3.0-1 => 2.3.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-loader-runner [sync] (focal-proposed) [2.3.0-2]
<xnox> Laney:  sil2100: vorlon: i see that s390x subiquity image was built today, but the last modification time on cdimage is from yesterday. Is something stuck somewhere?
<xnox> http://cdimage.ubuntu.com/ubuntu-server/daily-live/20200408/ => 2020-04-07
<xnox> yet
<xnox> https://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/focal/daily-live-20200408.log
<xnox> buildtime: Wed, 08 Apr 2020 10:08:43 +0000
<xnox> release: focal
<xnox> output directory: /srv/cdimage.ubuntu.com/www/full/ubuntu-server/daily-live/20200408
<xnox> is all successful
<sil2100> xnox: uh, something clearly went wrong, it feels to me like cdimage didn't finish what it started
<sil2100> xnox: (even the .html bits are missing)
<sil2100> ...and it copied over old images for the files it was missing?! Need to look into the log
<sil2100> Yeah, so clearly something didn't finish - the first thing cdimage does is copy over previous binaries as a starting point and only then proceeds to publishing, which seems to have somehow hiccuped
<xnox> ok
<xnox> sil2100:  i requested rebuild some time ago anyway, hopefully that will finish fine
<sil2100> xnox: ah, ok, I checked on nusakan just now
<xnox> sil2100:  i hope it's not like out of disk space or some such.
<sil2100> xnox: so it's the mirror sync that probably uh, got done somehow inbetween
<xnox> cause copy-up is like hardlink, right?
<xnox> is mirror out of disk space, or no?
<sil2100> hm, good question
<sil2100> xnox: I think it's all good, I did a manual sync-mirrors and now it slowly kicked in
<sil2100> Not sure what happened really
<sil2100> http://cdimage.ubuntu.com/ubuntu-server/daily-live/20200408/
<sil2100> But now it looks correctly synced
-queuebot:#ubuntu-release- Unapproved: yelp (focal-proposed/main) [3.34.0-1 => 3.36.0-1] (ubuntu-desktop) (sync)
<xnox> sil2100:  thanks
<rbalint> ubuntu-archive, please promote LP: #1835114
<ubot5> Launchpad bug 1835114 in ec2-instance-connect (Ubuntu) "[MIR] ec2-instance-connect" [Undecided,Fix committed] https://launchpad.net/bugs/1835114
-queuebot:#ubuntu-release- Unapproved: npm (focal-proposed/universe) [6.13.7+ds-1 => 6.14.4+ds-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted npm [sync] (focal-proposed) [6.14.4+ds-1]
-queuebot:#ubuntu-release- Unapproved: node-loose-envify (focal-proposed/universe) [1.3.1+dfsg1-1 => 1.4.0+dfsg1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-lowercase-keys (focal-proposed/universe) [1.0.0-2 => 2.0.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-marked-man (focal-proposed/universe) [0.4.0-1 => 0.7.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-marked (focal-proposed/universe) [0.5.1+dfsg-1 => 0.8.0+ds-1] (lubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: node-memory-fs (focal-proposed/universe) [0.4.1-1 => 0.4.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-lowercase-keys [sync] (focal-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted node-memory-fs [sync] (focal-proposed) [0.4.1-2]
-queuebot:#ubuntu-release- Unapproved: accepted node-marked-man [sync] (focal-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- Unapproved: node-mqtt-packet (focal-proposed/universe) [6.3.0-1 => 6.3.2-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-loose-envify [sync] (focal-proposed) [1.4.0+dfsg1-1]
-queuebot:#ubuntu-release- Unapproved: node-neo-async (focal-proposed/universe) [2.6.1-2 => 2.6.1-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-mute-stream (focal-proposed/universe) [0.0.8-1 => 0.0.8-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-node-rest-client (focal-proposed/universe) [2.5.0-3 => 2.5.0-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-nodemailer (focal-proposed/universe) [6.4.2-1 => 6.4.5-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-mqtt-packet [sync] (focal-proposed) [6.3.2-2]
-queuebot:#ubuntu-release- Unapproved: accepted node-neo-async [sync] (focal-proposed) [2.6.1-3]
-queuebot:#ubuntu-release- Unapproved: accepted node-nodemailer [sync] (focal-proposed) [6.4.5-1]
-queuebot:#ubuntu-release- Unapproved: accepted node-mute-stream [sync] (focal-proposed) [0.0.8-2]
-queuebot:#ubuntu-release- Unapproved: accepted node-node-rest-client [sync] (focal-proposed) [2.5.0-4]
-queuebot:#ubuntu-release- Unapproved: node-marked (focal-proposed/universe) [0.5.1+dfsg-1 => 0.8.0+ds-1] (lubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: node-nodemailer (focal-proposed/universe) [6.4.2-1 => 6.4.5-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-nopt (focal-proposed/universe) [3.0.6-3 => 3.0.6-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-normalize-package-data (focal-proposed/universe) [2.4.0-1 => 2.5.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-npmlog (focal-proposed/universe) [4.1.2-1 => 4.1.2-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-npm-bundled (focal-proposed/universe) [1.0.3-1 => 1.1.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: rejected node-nodemailer [sync] (focal-proposed) [6.4.5-1]
-queuebot:#ubuntu-release- Unapproved: accepted node-normalize-package-data [sync] (focal-proposed) [2.5.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted node-npmlog [sync] (focal-proposed) [4.1.2-2]
-queuebot:#ubuntu-release- Unapproved: node-oauth-sign (focal-proposed/universe) [0.9.0-1 => 0.9.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-policyfile (focal-proposed/universe) [0.0.6+ds-1 => 0.0.6+ds-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-nopt [sync] (focal-proposed) [3.0.6-4]
-queuebot:#ubuntu-release- Unapproved: node-number-is-nan (focal-proposed/universe) [1.0.0-1 => 2.0.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ruby-ffi-yajl (focal-proposed/universe) [2.3.1-2build1 => 2.3.1-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-npm-bundled [sync] (focal-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- Unapproved: node-opener (focal-proposed/universe) [1.4.3-1 => 1.5.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-postcss (focal-proposed/universe) [6.0.23-1 => 6.0.23-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-policyfile [sync] (focal-proposed) [0.0.6+ds-2]
-queuebot:#ubuntu-release- Unapproved: node-prismjs (focal-proposed/universe) [1.11.0+dfsg-2 => 1.11.0+dfsg-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-postcss [sync] (focal-proposed) [6.0.23-3]
-queuebot:#ubuntu-release- Unapproved: accepted node-number-is-nan [sync] (focal-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted node-opener [sync] (focal-proposed) [1.5.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted node-oauth-sign [sync] (focal-proposed) [0.9.0-2]
-queuebot:#ubuntu-release- Unapproved: accepted ruby-ffi-yajl [sync] (focal-proposed) [2.3.1-3]
-queuebot:#ubuntu-release- Unapproved: accepted node-prismjs [sync] (focal-proposed) [1.11.0+dfsg-3]
<LocutusOfBorg> doko, can you please do the node-marked magic? it should make some autopkgtests happy for eslint integration fixes, as well as fix some other reverse-dependencies. It should finally match the nodejs in release pocket
<rafaeldtinoco> good morning. id like to have the following FFes reviewed/accepted please: LP: #1866385 and LP: #1866383. Part of HA stack stabilization. Thank you!
<ubot5> Launchpad bug 1866385 in kronosnet (Ubuntu) "[FFe][focal] kronosnet need fixes from just released upstream version" [Medium,New] https://launchpad.net/bugs/1866385
<ubot5> Launchpad bug 1866383 in resource-agents (Ubuntu) "[FFe][Focal] resource-agents need fixes from recent release upstream version" [Undecided,New] https://launchpad.net/bugs/1866383
<jamespage> hi release team - pls could ceph be reviewed for acceptance into focal to resolve bug 1869324
<ubot5> bug 1869324 in ceph (Ubuntu) "civetweb: 0x7f4763896580: cannot bind to 70: 13 (Permission denied)" [High,In progress] https://launchpad.net/bugs/1869324
<seb128> sil2100, hey, are we supposed to have weekly langpack updates atm or is that just launchpad export? could you kick another upload if that's something that need to be manually done still?
-queuebot:#ubuntu-release- Unapproved: glibc (focal-proposed/main) [2.31-0ubuntu7 => 2.31-0ubuntu8] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: accepted glibc [source] (focal-proposed) [2.31-0ubuntu8]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (focal-proposed) [245.4-2ubuntu1]
<tjaalton> could someone ack glslang, fixes build on s390x
<tjaalton> and thus also vulkan-validationlayers, and should let it migrate
-queuebot:#ubuntu-release- Unapproved: gnome-system-tools (focal-proposed/universe) [3.0.0-8ubuntu1 => 3.0.0-9ubuntu1] (ubuntu-mate, ubuntustudio, xubuntu)
<Eickmeyer> tjaalton: Looks like r-p-d was accepted? I see 0.9.20 in release.
<tjaalton> Eickmeyer: yes
<tjaalton> and then there was 0.9.21 released :P
<Eickmeyer> Lovely timing. :P
<Eickmeyer> Do you plan to keep that FFe open for 0.9.21?
<Eickmeyer> Also, looks like bug 1871049 hasn't received any love from the release team.
<ubot5> bug 1871049 in darktable (Ubuntu) "FFe: darktable 2.6.3 in focal needs update to 3.0.1" [Undecided,New] https://launchpad.net/bugs/1871049
<sil2100> seb128: hey! It's running right now, it wasn't before because I forgot to set the base pack on LP - but hopefully we should have a new batch of langpacks soon
<seb128> sil2100, hey, great, thanks!
<sil2100> Ah, actually they're here already, need to approve them from the queue
<Laney> yes, please do!
 * Laney screamed when loading the queue just now
<sil2100> Just sanity checking the command and they'll all be gone soon!
-queuebot:#ubuntu-release- New binary: systemd [i386] (focal-proposed/main) [245.4-2ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: font-manager (focal-proposed/universe) [0.7.3-1.1 => 0.7.7-0.3] (ubuntustudio) (sync)
-queuebot:#ubuntu-release- Unapproved: fonts-lohit-gujr (focal-proposed/main) [2.92.4-3ubuntu1 => 2.92.4-4] (desktop-core, personal-gunnarhj) (sync)
-queuebot:#ubuntu-release- Unapproved: fonts-lohit-deva (focal-proposed/main) [2.95.4-3ubuntu1 => 2.95.4-4] (desktop-core, personal-gunnarhj) (sync)
-queuebot:#ubuntu-release- Unapproved: fonttools (focal-proposed/universe) [4.4.1-1 => 4.5.0-1] (i386-whitelist) (sync)
-queuebot:#ubuntu-release- New binary: systemd [s390x] (focal-proposed/main) [245.4-2ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: ubuntustudio-meta (focal-proposed/universe) [0.208 => 0.209] (ubuntustudio)
<Eickmeyer> ^ Python2 removal stuff.
<Eickmeyer> Alas, 3 packages didn't make it. :(
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (focal-proposed/main) [2.657 => 2.658] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: python-stdlib-extensions (focal-proposed/universe) [2.7.17-2 => 2.7.18-1] (i386-whitelist, kubuntu) (sync)
-queuebot:#ubuntu-release- New binary: systemd [ppc64el] (focal-proposed/main) [245.4-2ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: accepted glslang [sync] (focal-proposed) [8.13.3559-4]
-queuebot:#ubuntu-release- Unapproved: node-prop-types (focal-proposed/universe) [15.6.0+ds-4 => 15.6.2-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-prosemirror-model (focal-proposed/universe) [1.9.0-2 => 1.9.0-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-rc (focal-proposed/universe) [1.1.6-2 => 1.2.8-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-q (focal-proposed/universe) [1.5.1-1 => 1.5.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-prop-types [sync] (focal-proposed) [15.6.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted node-q [sync] (focal-proposed) [1.5.1-2]
-queuebot:#ubuntu-release- Unapproved: node-read-package-json (focal-proposed/universe) [2.0.13-1 => 2.1.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-regenerate-unicode-properties (focal-proposed/universe) [8.1.0+ds-2 => 8.2.0+ds-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-prosemirror-model [sync] (focal-proposed) [1.9.0-3]
-queuebot:#ubuntu-release- Unapproved: node-read (focal-proposed/universe) [1.0.7-1 => 1.0.7-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-rc [sync] (focal-proposed) [1.2.8-1]
-queuebot:#ubuntu-release- Unapproved: accepted node-read-package-json [sync] (focal-proposed) [2.1.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted node-regenerate-unicode-properties [sync] (focal-proposed) [8.2.0+ds-1]
-queuebot:#ubuntu-release- Unapproved: node-request-promise (focal-proposed/universe) [4.2.5-1 => 4.2.5-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-read [sync] (focal-proposed) [1.0.7-2]
-queuebot:#ubuntu-release- Unapproved: node-request-promise-core (focal-proposed/universe) [1.1.3-1 => 1.1.3-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-request-promise-core [sync] (focal-proposed) [1.1.3-2]
-queuebot:#ubuntu-release- Unapproved: node-retry (focal-proposed/universe) [0.10.1-1 => 0.12.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-request-promise [sync] (focal-proposed) [4.2.5-2]
-queuebot:#ubuntu-release- New binary: systemd [armhf] (focal-proposed/main) [245.4-2ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: node-rollup-plugin-babel (focal-proposed/universe) [3.0.3-7 => 3.0.7-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-sellside-emitter (focal-proposed/universe) [1.2.1-2 => 1.2.1-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-safe-buffer (focal-proposed/universe) [5.1.2-1 => 5.2.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-sha (focal-proposed/universe) [2.0.1-1 => 3.0.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-retry [sync] (focal-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted node-safe-buffer [sync] (focal-proposed) [5.2.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted node-sha [sync] (focal-proposed) [3.0.0-1]
-queuebot:#ubuntu-release- Unapproved: node-sigmund (focal-proposed/universe) [1.0.0-1 => 1.0.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-spdx-correct (focal-proposed/universe) [1.0.2-1 => 3.1.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-rollup-plugin-babel [sync] (focal-proposed) [3.0.7-1]
-queuebot:#ubuntu-release- Unapproved: node-shasum (focal-proposed/universe) [1.0.2-2 => 1.0.2-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-sellside-emitter [sync] (focal-proposed) [1.2.1-3]
-queuebot:#ubuntu-release- Unapproved: node-sinon (focal-proposed/universe) [8.1.0+ds-2 => 9.0.1+ds-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-sinon [sync] (focal-proposed) [9.0.1+ds-1]
-queuebot:#ubuntu-release- Unapproved: node-spdx-license-ids (focal-proposed/universe) [1.2.2-1 => 3.0.5-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-spdx-correct [sync] (focal-proposed) [3.1.0-1]
-queuebot:#ubuntu-release- Unapproved: node-stats-webpack-plugin (focal-proposed/universe) [0.7.0-1 => 0.7.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-shasum [sync] (focal-proposed) [1.0.2-3]
-queuebot:#ubuntu-release- Unapproved: node-stream-array (focal-proposed/universe) [1.1.2-1 => 1.1.2-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-stream-http (focal-proposed/universe) [2.8.3+dfsg-1 => 3.1.0+dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-sigmund [sync] (focal-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- Unapproved: node-stream-each (focal-proposed/universe) [1.2.2-2 => 1.2.3-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-spdx-license-ids [sync] (focal-proposed) [3.0.5-1]
-queuebot:#ubuntu-release- Unapproved: accepted node-stream-array [sync] (focal-proposed) [1.1.2-2]
-queuebot:#ubuntu-release- Unapproved: accepted node-stream-http [sync] (focal-proposed) [3.1.0+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: node-tar-stream (focal-proposed/universe) [1.5.2-1 => 1.5.2-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-stats-webpack-plugin [sync] (focal-proposed) [0.7.0-2]
-queuebot:#ubuntu-release- Unapproved: node-tap-parser (focal-proposed/universe) [7.0.0+ds1-3 => 7.0.0+ds1-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-stream-each [sync] (focal-proposed) [1.2.3-1]
-queuebot:#ubuntu-release- Unapproved: node-timeago.js (focal-proposed/universe) [3.0.2+dfsg-5 => 4.0.2-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-tap-parser [sync] (focal-proposed) [7.0.0+ds1-5]
-queuebot:#ubuntu-release- Unapproved: accepted node-timeago.js [sync] (focal-proposed) [4.0.2-2]
-queuebot:#ubuntu-release- Unapproved: node-tty-browserify (focal-proposed/universe) [0.0.0-2 => 0.0.1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-tar-stream [sync] (focal-proposed) [1.5.2-2]
-queuebot:#ubuntu-release- Unapproved: node-traverse (focal-proposed/universe) [0.6.6-1.1 => 0.6.6-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-traverse [sync] (focal-proposed) [0.6.6-2]
-queuebot:#ubuntu-release- Unapproved: node-unicode-canonical-property-names-ecmascript (focal-proposed/universe) [1.0.4-1 => 1.0.4-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: pulseaudio (focal-proposed/main) [1:13.99.1-1ubuntu1 => 1:13.99.1-1ubuntu2] (desktop-core, i386-whitelist, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted node-tty-browserify [sync] (focal-proposed) [0.0.1-1]
-queuebot:#ubuntu-release- Unapproved: node-unicode-data (focal-proposed/universe) [0~20190709+git706d06c0-4 => 0~20200315+gitfc57d75a-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-unicode-match-property-value-ecmascript (focal-proposed/universe) [1.1.0+ds-2 => 1.2.0+ds-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-unicode-canonical-property-names-ecmascript [sync] (focal-proposed) [1.0.4-2]
-queuebot:#ubuntu-release- Unapproved: accepted node-unicode-match-property-value-ecmascript [sync] (focal-proposed) [1.2.0+ds-1]
-queuebot:#ubuntu-release- Unapproved: node-vinyl (focal-proposed/universe) [2.0.1-1 => 2.2.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-unicode-data [sync] (focal-proposed) [0~20200315+gitfc57d75a-2]
-queuebot:#ubuntu-release- Unapproved: node-validate-npm-package-license (focal-proposed/universe) [3.0.1-1 => 3.0.4-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-validate-npm-package-license [sync] (focal-proposed) [3.0.4-1]
-queuebot:#ubuntu-release- Unapproved: accepted node-vinyl [sync] (focal-proposed) [2.2.0-1]
-queuebot:#ubuntu-release- New binary: systemd [arm64] (focal-proposed/main) [245.4-2ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: node-vm-browserify (focal-proposed/universe) [0.0.4-1 => 1.1.2+ds-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-vm-browserify [sync] (focal-proposed) [1.1.2+ds-1]
-queuebot:#ubuntu-release- Unapproved: node-widest-line (focal-proposed/universe) [1.2.2-1 => 3.1.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-webpack (focal-proposed/universe) [4.30.0-7 => 4.30.0-9] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-write-file-atomic (focal-proposed/universe) [2.3.0-1 => 3.0.3-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-webpack [sync] (focal-proposed) [4.30.0-9]
-queuebot:#ubuntu-release- Unapproved: accepted node-write-file-atomic [sync] (focal-proposed) [3.0.3-1]
-queuebot:#ubuntu-release- Unapproved: node-yauzl (focal-proposed/universe) [2.10.0-1 => 2.10.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-widest-line [sync] (focal-proposed) [3.1.0-1]
-queuebot:#ubuntu-release- Unapproved: node-yarnpkg (focal-proposed/universe) [1.21.1-1 => 1.22.4-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: nodeenv (focal-proposed/universe) [0.13.4-1 => 0.13.4-1.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: nodeenv (focal-proposed/universe) [0.13.4-1 => 0.13.4-1.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-yarnpkg [sync] (focal-proposed) [1.22.4-2]
-queuebot:#ubuntu-release- Unapproved: rejected nodeenv [sync] (focal-proposed) [0.13.4-1.1]
-queuebot:#ubuntu-release- Unapproved: accepted node-yauzl [sync] (focal-proposed) [2.10.0-2]
-queuebot:#ubuntu-release- Unapproved: accepted nodeenv [sync] (focal-proposed) [0.13.4-1.1]
-queuebot:#ubuntu-release- New binary: node-unicode-data [amd64] (focal-proposed/universe) [0~20200315+gitfc57d75a-2] (no packageset)
-queuebot:#ubuntu-release- New binary: systemd [amd64] (focal-proposed/main) [245.4-2ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (focal-proposed/main) [1:20.04.17 => 1:20.04.18] (core)
-queuebot:#ubuntu-release- Unapproved: ubiquity (focal-proposed/main) [20.04.9 => 20.04.10] (core)
-queuebot:#ubuntu-release- Unapproved: create-resources (focal-proposed/universe) [0.1.3-5 => 0.1.3-6] (ubuntustudio) (sync)
<locutus_> node-unicode-data is now at version 13.0.0, matching unicode-data that is in focal
<locutus_> it should have been part of the unicode FFe I did early this month
<Laney> bdmurray: just uploaded an update-manager, fyi because I think you like to review that one
<Laney> crash fix
-queuebot:#ubuntu-release- Unapproved: sphinx (focal-proposed/main) [1.8.5-7ubuntu1 => 1.8.5-7ubuntu2] (edubuntu, i386-whitelist, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: update-manager (focal-proposed/main) [1:20.04.4 => 1:20.04.5] (core)
-queuebot:#ubuntu-release- Unapproved: accepted font-manager [sync] (focal-proposed) [0.7.7-0.3]
-queuebot:#ubuntu-release- Unapproved: accepted fonts-lohit-gujr [sync] (focal-proposed) [2.92.4-4]
-queuebot:#ubuntu-release- Unapproved: accepted fonts-lohit-deva [sync] (focal-proposed) [2.95.4-4]
-queuebot:#ubuntu-release- Unapproved: accepted fonttools [sync] (focal-proposed) [4.5.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntustudio-meta [source] (focal-proposed) [0.209]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (focal-proposed) [1:20.04.18]
-queuebot:#ubuntu-release- Unapproved: accepted python-stdlib-extensions [sync] (focal-proposed) [2.7.18-1]
-queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (focal-proposed) [15.2.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: ubuntustudio-meta (focal-proposed/universe) [0.208 => 0.210] (ubuntustudio)
<Eickmeyer> ^ Sorry about the noise on ubuntustudio-meta but we replaced an application that was lost with python2. FFe filed, bug 1871677
<ubot5> bug 1871677 in ubuntustudio-meta (Ubuntu) "FFe: Replace gmidimonitor with midisnoop" [Undecided,New] https://launchpad.net/bugs/1871677
-queuebot:#ubuntu-release- Unapproved: accepted gnome-system-tools [source] (focal-proposed) [3.0.0-9ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected node-marked [sync] (focal-proposed) [0.8.0+ds-1]
-queuebot:#ubuntu-release- Unapproved: rejected pycurl [sync] (focal-proposed) [7.43.0.2-3]
-queuebot:#ubuntu-release- Unapproved: accepted pulseaudio [source] (focal-proposed) [1:13.99.1-1ubuntu2]
<sil2100> Ok, since I'll be EODing soon, can someone take a look at my livecd-rootfs upload in the queue? It's a (hopefully) fix for the raspi images not booting right now
<Laney> sil2100: you say it makes the subarch use the raspi kernel flavour - where does that happen?
-queuebot:#ubuntu-release- New binary: font-manager [s390x] (focal-proposed/universe) [0.7.7-0.3] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: font-manager [ppc64el] (focal-proposed/universe) [0.7.7-0.3] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: font-manager [amd64] (focal-proposed/universe) [0.7.7-0.3] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: font-manager [armhf] (focal-proposed/universe) [0.7.7-0.3] (ubuntustudio)
<Laney> sorry, gotta go
-queuebot:#ubuntu-release- New binary: font-manager [arm64] (focal-proposed/universe) [0.7.7-0.3] (ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: accepted sphinx [source] (focal-proposed) [1.8.5-7ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted vala [sync] (focal-proposed) [0.48.3-1]
<bdmurray> Laney: thanks for the update
-queuebot:#ubuntu-release- New binary: font-manager [riscv64] (focal-proposed/universe) [0.7.7-0.3] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: systemd [riscv64] (focal-proposed/main) [245.4-2ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: npm (focal-proposed/universe) [6.14.4+ds-1 => 6.14.4+ds-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted npm [source] (focal-proposed) [6.14.4+ds-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-97.98~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-97.98~16.04.1]
<rafaeldtinoco> ubuntu-archive: I'd like to have the following FFes reviewed/accepted please: LP: #1866385 and LP: #1866383. Part of HA stack stabilization. Thanks!
<ubot5> Launchpad bug 1866385 in kronosnet (Ubuntu) "[FFe][focal] kronosnet need fixes from just released upstream version" [Medium,New] https://launchpad.net/bugs/1866385
<ubot5> Launchpad bug 1866383 in resource-agents (Ubuntu) "[FFe][Focal] resource-agents need fixes from recent release upstream version" [Undecided,New] https://launchpad.net/bugs/1866383
-queuebot:#ubuntu-release- New: accepted systemd [amd64] (focal-proposed) [245.4-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted systemd [armhf] (focal-proposed) [245.4-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted systemd [ppc64el] (focal-proposed) [245.4-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted systemd [arm64] (focal-proposed) [245.4-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted systemd [s390x] (focal-proposed) [245.4-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted systemd [i386] (focal-proposed) [245.4-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted systemd [riscv64] (focal-proposed) [245.4-2ubuntu1]
<doko> rafaeldtinoco: not an u-a issue
<xnox> vorlon:  Laney: sil2100:  it happened again https://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/focal/daily-live-20200408.1.log finished building for all arches, yet on the frontend it is only amd64 published, and everything else is gone: http://cdimage.ubuntu.com/daily-live/20200408.1/
<xnox> bah
<xnox> unping
<xnox> http://cdimage.ubuntu.com/ubuntu-server/daily-live/20200408.1/ is all good
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (focal-proposed/main) [0.136ubuntu4 => 0.136ubuntu5] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: npm (focal-proposed/universe) [6.14.4+ds-1ubuntu1 => 6.14.4+ds-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (focal-proposed/main) [0.136ubuntu4 => 0.136ubuntu5] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: accepted npm [source] (focal-proposed) [6.14.4+ds-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: node-fs-readdir-recursive (focal-proposed/universe) [1.0.0-1 => 1.1.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: sax.js (focal-proposed/universe) [1.2.4-2 => 1.2.4-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: netdata (focal-proposed/universe) [1.19.0-2 => 1.19.0-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: pegjs (focal-proposed/universe) [0.7.0-2 => 0.10.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted netdata [sync] (focal-proposed) [1.19.0-3]
-queuebot:#ubuntu-release- Unapproved: accepted pegjs [sync] (focal-proposed) [0.10.0-1]
-queuebot:#ubuntu-release- Unapproved: jsbundle-web-interfaces (focal-proposed/universe) [1.1.0+~2.0.1~ds+~5.0.0+~0~20180821-1 => 1.1.0+~2.0.1~ds+~6.0.0+~0~20180821-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-fs-readdir-recursive [sync] (focal-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- Unapproved: libjs-webrtc-adapter (focal-proposed/universe) [7.3.0~ds-1 => 7.5.1~ds-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted sax.js [sync] (focal-proposed) [1.2.4-3]
<xnox> mwhudson:  and now i have two of them
<xnox> accepted together
-queuebot:#ubuntu-release- Unapproved: accepted jsbundle-web-interfaces [sync] (focal-proposed) [1.1.0+~2.0.1~ds+~6.0.0+~0~20180821-1]
-queuebot:#ubuntu-release- Unapproved: ruby-diffy (focal-proposed/universe) [3.2.1-1 => 3.3.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libjs-webrtc-adapter [sync] (focal-proposed) [7.5.1~ds-1]
<xnox> vorlon:  the two initramfs-tools uploads are identical.
<mwhudson> xnox: yes just saw that
<xnox> but one of them need accept =)
-queuebot:#ubuntu-release- Unapproved: accepted ruby-diffy [sync] (focal-proposed) [3.3.0-1]
-queuebot:#ubuntu-release- Packageset: Removed python-typing from i386-whitelist in focal
-queuebot:#ubuntu-release- Unapproved: rejected initramfs-tools [source] (focal-proposed) [0.136ubuntu5]
<vorlon> xnox, mwhudson: accepted
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (focal-proposed) [0.136ubuntu5]
<mwhudson> vorlon: thanks
-queuebot:#ubuntu-release- Unapproved: gfxboot-theme-ubuntu (focal-proposed/main) [0.23.1 => 0.23.2] (core)
<seb128> ^ please review that upload, I screwed up the recent update this week that added the safe graphics variant to translations by using space in the string identifiers
<seb128> which has been leading to wrong strings translations to load
<seb128> like today's Ubuntu iso menu loads the Ubuntu Kylin string in french...
<vorlon> seb128: the debdiff appears to show a large number of added, untranslated strings; is that what you expect?  (I see that they are translated in French, but maybe only French?)
<seb128> vorlon, the script creates those empty strings for the the translations and past uploads included those so I decided to play safe and include them, I don't think it can hurt
<seb128> vorlon, and yes, I included french as a testcase to verify things are working and the new strings correctly translated
<vorlon> seb128: ok, so those strings were there previously, and were untranslated previously?
<seb128> I will do a full export with other locales once the new template is imported and that I've verified things work correctly
<seb128> yes, those have never been translated since they have been added a few cycles ago
<seb128> which I tried to fix in https://bugs.launchpad.net/ubuntu/+source/gfxboot-theme-ubuntu/0.23.1
<ubot5> Error: ubuntu bug 0 not found
-queuebot:#ubuntu-release- Unapproved: accepted gfxboot-theme-ubuntu [source] (focal-proposed) [0.23.2]
<seb128> I've been learning gfxboot-theme-ubuntu weirdness as I'm going :p
<vorlon> :)
<seb128> gettext is not used to load translations but some weird scripting that cares about the # comments rather than using the msgid
<seb128> anyway, hopefully the new upload works
<seb128> I saw the accepted, thanks!
-queuebot:#ubuntu-release- Unapproved: accepted libqapt [source] (focal-proposed) [3.0.5-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntustudio-meta [source] (focal-proposed) [0.210]
<mwhudson> xnox: going to upload https://paste.ubuntu.com/p/WWNCWryDs2/ unless you scream
-queuebot:#ubuntu-release- Unapproved: apport (focal-proposed/main) [2.20.11-0ubuntu25 => 2.20.11-0ubuntu26] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: casper (focal-proposed/main) [1.444 => 1.445] (desktop-core, ubuntu-server)
<xnox> mwhudson:  yes please
<xnox> turns out strcmp is not as good as g_strcmp0 and friends
#ubuntu-release 2020-04-09
-queuebot:#ubuntu-release- New binary: linux-signed-oracle-5.3 [amd64] (bionic-proposed/main) [5.3.0-1015.16~18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: doxygen (focal-proposed/universe) [1.8.17-0ubuntu1 => 1.8.17-0ubuntu2] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: libappindicator (bionic-proposed/main) [12.10.1+18.04.20180322.1-0ubuntu1 => 12.10.1+18.04.20200408.1-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: libappindicator (focal-proposed/main) [12.10.1+18.04.20180322.1-0ubuntu6 => 12.10.1+20.04.20200408.1-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: intel-gmmlib (focal-proposed/universe) [19.4.1+ds1-1build1 => 20.1.1+ds1-1] (i386-whitelist, kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: intel-opencl-clang (focal-proposed/universe) [9.0.0-1build1 => 10.0.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted intel-opencl-clang [sync] (focal-proposed) [10.0.0-2]
-queuebot:#ubuntu-release- Unapproved: lxc (focal-proposed/universe) [1:4.0.1-0ubuntu1 => 1:4.0.1-0ubuntu2] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: spirv-llvm-translator [amd64] (focal-proposed/universe) [10.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: spirv-llvm-translator [s390x] (focal-proposed/universe) [10.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: spirv-llvm-translator [ppc64el] (focal-proposed/universe) [10.0.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (focal-proposed) [1:4.0.1-0ubuntu2]
-queuebot:#ubuntu-release- New binary: spirv-llvm-translator [arm64] (focal-proposed/universe) [10.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: spirv-llvm-translator [armhf] (focal-proposed/universe) [10.0.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accounts-qml-module (focal-proposed/universe) [0.6+17.04.20170405-0ubuntu3 => 0.6+17.04.20170405-0ubuntu4] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: rejected accounts-qml-module [source] (focal-proposed) [0.6+17.04.20170405-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accounts-qml-module (focal-proposed/universe) [0.6+17.04.20170405-0ubuntu3 => 0.6+17.04.20170405-0ubuntu4] (kubuntu)
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle-5.3 [amd64] (bionic-proposed) [5.3.0-1015.16~18.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (eoan-proposed/main) [5.3.0-1015.16] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: deluge (focal-proposed/universe) [2.0.3-1.1 => 2.0.3-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted deluge [sync] (focal-proposed) [2.0.3-2]
<sil2100> Laney: hey, so looking at the ubiquity upload, it's dropping the whole d-i/source/ - is that intentional?
-queuebot:#ubuntu-release- Unapproved: rs (focal-proposed/universe) [20181225-1 => 20200313-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted rs [sync] (focal-proposed) [20200313-1]
-queuebot:#ubuntu-release- Unapproved: accepted create-resources [sync] (focal-proposed) [0.1.3-6]
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (focal-proposed) [1:20.04.5]
-queuebot:#ubuntu-release- Unapproved: intel-compute-runtime (focal-proposed/universe) [20.02.15268-1build1 => 20.13.16352-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted intel-compute-runtime [sync] (focal-proposed) [20.13.16352-1]
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (focal-proposed) [2.20.11-0ubuntu26]
-queuebot:#ubuntu-release- Unapproved: accepted casper [source] (focal-proposed) [1.445]
-queuebot:#ubuntu-release- Unapproved: accepted doxygen [source] (focal-proposed) [1.8.17-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: rejected node-marked [sync] (focal-proposed) [0.8.0+ds-1]
-queuebot:#ubuntu-release- Unapproved: accepted accounts-qml-module [source] (focal-proposed) [0.6+17.04.20170405-0ubuntu4]
-queuebot:#ubuntu-release- Unapproved: python-apt (focal-proposed/main) [1.9.10 => 2.0.0] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: accepted libappindicator [sync] (focal-proposed) [12.10.1+20.04.20200408.1-0ubuntu1]
<juliank> re fresh python-apt: I synced --no-lp (and keeping my original .dsc signature) to speed up things :)
<juliank> Don't want to wait until it appears in Debian archive, gets synced to LP, and then do a real sync
<juliank> but it's uploaded in both archives :)
<juliank> [apt 2.0.2 will be the same]
<Laney> sil2100: eek, no!
<juliank> Laney: this is super frustrating, right?
 * juliank had the same thing
<Laney> uploading ubiquity?
<Laney> yes
<Laney> gbp buildpackage -S
<Laney> cd ../build-area
<Laney> dpkg-source -x ...
<Laney> debian/rules update
<Laney> debuild -S -d
<Laney> that's my workflow but I probably forgot the last bit
<juliank> Do --git-prebuild=debian/rules update in the gbp buildpackage?
<juliank> with quotes?
<juliank> could set that in debian/gbp.conf
<Laney> could do
<Laney> gbp.conf-ing it would be most sensible
<juliank> Life should get easier once the d-i stuff is submodules instead of pulled from the archive
<Laney> ahahah submodules making life easier
<juliank> no wait, the other thing
<juliank> submodules friends that directly merges other trees into subdirectories
<juliank> I think that's what we want to do
-queuebot:#ubuntu-release- Unapproved: rejected ubiquity [source] (focal-proposed) [20.04.10]
<juliank> subtree?
<Laney> git subtree probably
<Laney> never used them, but people say it's easier
<juliank> Laney: It's basically just "git merge <random other tree> && mv its files into a subdirectory"
<juliank> So you get one full repo with one history with merges, instead of references to external repos
<juliank> and tools, you get tools to extract those changes in those subdirectories back for upstream
-queuebot:#ubuntu-release- Unapproved: eyes.js (focal-proposed/universe) [0.1.8-1 => 0.1.8-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ubiquity (focal-proposed/main) [20.04.9 => 20.04.10] (core)
-queuebot:#ubuntu-release- Unapproved: accepted eyes.js [sync] (focal-proposed) [0.1.8-2]
<Laney> that one should be better
-queuebot:#ubuntu-release- Unapproved: node-proper-lockfile (focal-proposed/universe) [2.0.1-1 => 2.0.1-1ubuntu1] (no packageset)
 * Laney takes a look at the queue
-queuebot:#ubuntu-release- Unapproved: accepted node-proper-lockfile [source] (focal-proposed) [2.0.1-1ubuntu1]
<Laney> sil2100: I asked Till if he could give me an opinion on foomatic-db btw, waiting to hear back
<Laney> did you see my q about livecd-rootfs last night?
<sil2100> Laney: ah, no, guess I missed it, let me look at teh logs
-queuebot:#ubuntu-release- Unapproved: mozjs52 (focal-proposed/universe) [52.9.1-1ubuntu1 => 52.9.1-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted mozjs52 [source] (focal-proposed) [52.9.1-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: scikit-learn (focal-proposed/universe) [0.20.3+dfsg-0ubuntu5 => 0.22.2.post1+dfsg-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted scikit-learn [sync] (focal-proposed) [0.22.2.post1+dfsg-5]
<sil2100> Laney: so by default KERNEL_FLAVOURS is set there to whatever SUBARCH is (see the earlier `KERNEL_FLAVOURS="${SUBARCH:-$KERNEL_FLAVOURS}"` line)
<sil2100> Laney: and since the SUBARCH is raspi, the kernel flavor will be as we expect - raspi
<Laney> ah ok, thanks, I just wanted some help tracking down where it came from
<Laney> there's still other raspi2 bits in the source, are they obsolete too?
<sil2100> Yeah, but some of it is from the old raspi2 ubuntu-core support, so I didn't want to rip out too much as the whole code needs to go one day
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (focal-proposed) [2.658]
-queuebot:#ubuntu-release- Unapproved: vaultlocker (bionic-backports/universe) [1.0.4-0ubuntu0.19.04.1~ubuntu18.04.1 => 1.0.6-0ubuntu1~ubuntu18.04.1] (no packageset)
<sil2100> Laney: thanks o/
<jamespage> back I think I backported that vaultlocker backport from the wrong source - needs to be from the eoan version for upgrades...
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (eoan-proposed) [5.3.0-1015.16]
-queuebot:#ubuntu-release- Unapproved: fail2ban (focal-proposed/universe) [0.10.2-2.1 => 0.11.1-1] (no packageset) (sync)
<jamespage> Laney: could you reject ^^ for me and I'll re-upload with the right versioning :)
<LocutusOfBorg> hello, can any archive-admin please remove node-run-sequence from the archive?  https://bugs.debian.org/954832
<ubot5> Debian bug 954832 in ftp.debian.org "RM: node-run-sequence -- ROM; Deprecated since node-gulp 4" [Normal,Open]
-queuebot:#ubuntu-release- Unapproved: accepted fail2ban [sync] (focal-proposed) [0.11.1-1]
<apw> jamespage, what are you asking to be rejected ?
<jamespage> apw: the vaultlocker upload I just made to bionic-backports
<jamespage> the versioning won't work with upgrades from bionic->eoan
<apw> jamespage, done
-queuebot:#ubuntu-release- Unapproved: vaultlocker (eoan-proposed/universe) [1.0.4-0ubuntu0.19.10.1 => 1.0.6-0ubuntu0.19.10.1] (no packageset)
<jamespage> apw: ta
-queuebot:#ubuntu-release- Unapproved: rejected vaultlocker [source] (bionic-backports) [1.0.6-0ubuntu1~ubuntu18.04.1]
<apw> jamespage, it is hard to see who did what in the queue view without opening all the changes files by hand; best to be explicit
<jamespage> apw: thanks
-queuebot:#ubuntu-release- Unapproved: vaultlocker (bionic-backports/universe) [1.0.4-0ubuntu0.19.04.1~ubuntu18.04.1 => 1.0.6-0ubuntu0.19.10.1~ubuntu18.04.1] (no packageset)
<jamespage> will do going forwards
<apw> jamespage, ta
-queuebot:#ubuntu-release- Unapproved: mikutter (focal-proposed/universe) [3.9.8+dfsg-1 => 3.9.8+dfsg-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mikutter [sync] (focal-proposed) [3.9.8+dfsg-2]
-queuebot:#ubuntu-release- Unapproved: shim-signed (focal-proposed/main) [1.40 => 1.40.1] (core)
-queuebot:#ubuntu-release- Unapproved: sundials (focal-proposed/universe) [3.1.2+dfsg-3ubuntu1 => 3.1.2+dfsg-3ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted sundials [source] (focal-proposed) [3.1.2+dfsg-3ubuntu2]
-queuebot:#ubuntu-release- Unapproved: netdata (focal-proposed/universe) [1.19.0-3 => 1.19.0-3ubuntu1] (no packageset)
<cjwatson> juliank: I agree, subtrees are generally much less confusing
-queuebot:#ubuntu-release- Unapproved: accepted netdata [source] (focal-proposed) [1.19.0-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rake (focal-proposed/main) [13.0.1-2 => 13.0.1-4] (i386-whitelist, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: ruby-test-unit (focal-proposed/main) [3.3.4-1 => 3.3.5-1] (i386-whitelist, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: liblxqt (focal-proposed/universe) [0.14.1-0ubuntu2 => 0.14.1-4ubuntu1] (lubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (focal-proposed) [1.40.1]
<sil2100> Laney: hey! I had a quick look at ubiquity - I know that basically the two new features are hidden by default right now, but is there an FFe for those somewhere already?
<Laney> sil2100: not yet, I was planning to do that when getting the enablement stuff back from the OEM guys
<Laney> we could use https://bugs.launchpad.net/ubuntu/+source/hw-detect/+bug/1864965 for one half of it
<ubot5> Ubuntu bug 1864965 in hw-detect (Ubuntu) "Add Intel RAID/RST detection with NVMe devices" [Wishlist,In progress]
-queuebot:#ubuntu-release- Unapproved: telepathy-ring (focal-proposed/universe) [2.3.24-1ubuntu1 => 2.3.24-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted telepathy-ring [source] (focal-proposed) [2.3.24-1ubuntu2]
<The_LoudSpeaker> Hey!  @infinity and @vorlon
<The_LoudSpeaker> regards from Lubuntu, especially from @tsimonq2
<The_LoudSpeaker> :P
<The_LoudSpeaker> can you please approve liblxqt (0.14.1-4ubuntu1) ?
<The_LoudSpeaker> I am trying to fix all the packages from lubuntu packageset that are stuck in Merge-o-matic. This is one of them.
<Laney> Everything will get reviewed, no need to ping us, especially not after 6 minutes
<Laney> It's maybe a bit late to be merging packages unless they contain fixes you actually need
<Laney> There's not much time to fix things if one of the merges breaks something
<The_LoudSpeaker> @tsimonq2 suggested I ping. thats why.
<The_LoudSpeaker> okay. I will check if there are important fixes that we need and will merge only them. Thanks Laney
<Laney> np!
<The_LoudSpeaker> actually, fixing merges was the task I had started a couple of months back. Didn't get enough time in the past month due to college exams and then the pandemic. And realised only untill I saw the beta release last week. Will review and upload important things now.
-queuebot:#ubuntu-release- New: accepted font-manager [amd64] (focal-proposed) [0.7.7-0.3]
-queuebot:#ubuntu-release- New: accepted font-manager [armhf] (focal-proposed) [0.7.7-0.3]
-queuebot:#ubuntu-release- New: accepted font-manager [riscv64] (focal-proposed) [0.7.7-0.3]
-queuebot:#ubuntu-release- New: accepted node-unicode-data [amd64] (focal-proposed) [0~20200315+gitfc57d75a-2]
-queuebot:#ubuntu-release- New: accepted spirv-llvm-translator [arm64] (focal-proposed) [10.0.0-1]
-queuebot:#ubuntu-release- New: accepted spirv-llvm-translator [ppc64el] (focal-proposed) [10.0.0-1]
-queuebot:#ubuntu-release- New: accepted font-manager [arm64] (focal-proposed) [0.7.7-0.3]
-queuebot:#ubuntu-release- New: accepted font-manager [s390x] (focal-proposed) [0.7.7-0.3]
-queuebot:#ubuntu-release- New: accepted spirv-llvm-translator [armhf] (focal-proposed) [10.0.0-1]
-queuebot:#ubuntu-release- New: accepted font-manager [ppc64el] (focal-proposed) [0.7.7-0.3]
-queuebot:#ubuntu-release- New: accepted spirv-llvm-translator [s390x] (focal-proposed) [10.0.0-1]
-queuebot:#ubuntu-release- New: accepted spirv-llvm-translator [amd64] (focal-proposed) [10.0.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted intel-gpu-tools [sync] (focal-proposed) [1.25-2]
-queuebot:#ubuntu-release- Unapproved: accepted nss-wrapper [sync] (focal-proposed) [1.1.11-1]
-queuebot:#ubuntu-release- Unapproved: accepted libva [sync] (focal-proposed) [2.7.0-1]
-queuebot:#ubuntu-release- Unapproved: rejected intel-gpu-tools [sync] (focal-proposed) [1.25-2]
-queuebot:#ubuntu-release- Unapproved: accepted xorg-server [source] (focal-proposed) [2:1.20.8-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted gtk+3.0 [source] (focal-proposed) [3.24.17-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libdmx [sync] (focal-proposed) [1:1.1.4-2]
-queuebot:#ubuntu-release- Unapproved: accepted python-apt [source] (focal-proposed) [2.0.0]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-input-synaptics [source] (focal-proposed) [1.9.1-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted intel-gmmlib [sync] (focal-proposed) [20.1.1+ds1-1]
-queuebot:#ubuntu-release- Unapproved: accepted thunderbird [source] (focal-proposed) [1:68.7.0+build1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libdrm [sync] (focal-proposed) [2.4.101-1]
-queuebot:#ubuntu-release- Unapproved: accepted yelp [sync] (focal-proposed) [3.36.0-1]
-queuebot:#ubuntu-release- New binary: intel-opencl-clang [amd64] (focal-proposed/universe) [10.0.0-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu23 => 2.04-1ubuntu24] (core)
-queuebot:#ubuntu-release- Unapproved: xubuntu-default-settings (focal-proposed/universe) [20.04 => 20.04.1] (xubuntu)
-queuebot:#ubuntu-release- Unapproved: libiberty (focal-proposed/main) [20190907-1 => 20200409-1] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: mozjs52 (focal-proposed/universe) [52.9.1-1ubuntu2 => 52.9.1-1ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted mozjs52 [source] (focal-proposed) [52.9.1-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: shim-signed (focal-proposed/main) [1.40.1 => 1.40.2] (core)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (focal-proposed/main) [1.138 => 1.139] (core)
-queuebot:#ubuntu-release- Unapproved: gcc-9 (focal-proposed/main) [9.3.0-10ubuntu1 => 9.3.0-10ubuntu2] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: indicator-applet (focal-proposed/universe) [12.10.2+20.04.20200329-0ubuntu1 => 12.10.2+20.04.20200409-0ubuntu1] (edubuntu, ubuntu-budgie) (sync)
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (focal-proposed/main) [0.136ubuntu5 => 0.136ubuntu6] (core, i386-whitelist)
<xnox> vorlon:  initramfs-tools => fixes testsuite ftbfs, and also adds tests to run all the netplan.yamls through netplan generate to insure they are valid.
<xnox> tested in bileto including autopkgtests including i386
-queuebot:#ubuntu-release- Unapproved: python-skbio (focal-proposed/universe) [0.5.5-5 => 0.5.6-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-skbio [sync] (focal-proposed) [0.5.6-1]
-queuebot:#ubuntu-release- New: accepted intel-opencl-clang [amd64] (focal-proposed) [10.0.0-2]
-queuebot:#ubuntu-release- Unapproved: mutter (focal-proposed/main) [3.36.0-2ubuntu1 => 3.36.1-3ubuntu1] (desktop-core, desktop-extra)
<xnox> sil2100:  fixedup openssl is up, once launchpad processes it
-queuebot:#ubuntu-release- Unapproved: gnome-shell (focal-proposed/main) [3.36.0-2ubuntu2 => 3.36.1-4ubuntu1] (desktop-extra, mozilla, ubuntu-desktop)
<sil2100> xnox: ok o/
-queuebot:#ubuntu-release- Unapproved: openssl (focal-proposed/main) [1.1.1d-2ubuntu6 => 1.1.1f-1ubuntu1] (core, i386-whitelist)
<xnox> sil2100:  there it is
 * xnox reuploaded with -sa
-queuebot:#ubuntu-release- Unapproved: libssh (focal-proposed/main) [0.9.3-2ubuntu1 => 0.9.3-2ubuntu2] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: subiquity (focal-proposed/universe) [20.03.3+git107gb7ae4d06 => 20.03.3+git147gb34aeda0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted subiquity [source] (focal-proposed) [20.03.3+git147gb34aeda0]
-queuebot:#ubuntu-release- Unapproved: ubuntustudio-default-settings (focal-proposed/universe) [20.04.1 => 20.04.2] (ubuntustudio)
<stgraber> can someone help me decipher the britney output for lxc? AFAICT it's a valid candidate for promotion but is getting stuck because of something around lxc-utils an riscv64?
-queuebot:#ubuntu-release- Unapproved: rejected matplotlib [sync] (focal-proposed) [3.2.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntustudio-default-settings [source] (focal-proposed) [20.04.2]
<Laney> Eickmeyer: whoopsie, ignore that first rejection, I ticked too many boxes
<Eickmeyer> Yikes! :D
<Laney> stgraber: Looks like it'll go through with systemd
<Laney> https://paste.ubuntu.com/p/9kRp8tvS3B/
-queuebot:#ubuntu-release- Unapproved: darktable (focal-proposed/universe) [2.6.3-1build2 => 3.0.1-0ubuntu1] (ubuntustudio)
<Eickmeyer> ^ There's a FFe for that.
<Eickmeyer> from tjaalton
-queuebot:#ubuntu-release- Unapproved: accepted gcc-9 [source] (focal-proposed) [9.3.0-10ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted foomatic-db [sync] (focal-proposed) [20200401-1]
-queuebot:#ubuntu-release- Unapproved: net-snmp (focal-proposed/main) [5.8+dfsg-2ubuntu1 => 5.8+dfsg-2ubuntu2] (desktop-core, i386-whitelist, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (focal-proposed) [2.04-1ubuntu24]
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (focal-proposed) [1.139]
<rafaeldtinoco> I'd like to have the following FFes reviewed/accepted please: LP: #1866385 and LP: #1866383. Part of HA stack stabilization. Should I continue asking in here ? Is there any other place I could highlight this need ?
<ubot5> Launchpad bug 1866385 in kronosnet (Ubuntu) "[FFe][focal] kronosnet need fixes from just released upstream version" [Medium,New] https://launchpad.net/bugs/1866385
<ubot5> Launchpad bug 1866383 in resource-agents (Ubuntu) "[FFe][Focal] resource-agents need fixes from recent release upstream version" [Undecided,New] https://launchpad.net/bugs/1866383
<rafaeldtinoco> mailing list ? specific person ?
-queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (focal-proposed) [1.40.2]
<sil2100> hmm, I see that my livecd-rootfs upload is stuck on unsatisfiable depends for riscv64 - can I hint it in anyway? It's unrelated to the upload
-queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu24 => 2.04-1ubuntu24] (core)
<Laney> I guess we should probably figure out which of NEW_ARCHES BREAK_ARCHES OUTOFSYNC_ARCHES to add riscv64 to
<Laney> if we're saying we want to allow uninstallables on this arch anyway
-queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu24 => 2.04-1ubuntu24] (core)
<Laney> looking like BREAK_ARCHES
<Laney> perhaps we put that on for a period, and then at some later point we look to remove it and drive the uninsts back down?
<xnox> vorlon:  ^^^^
<vorlon> we don't want to allow uninstallables
<vorlon> but we're in a transitional period now when there are uninstallables
-queuebot:#ubuntu-release- Unapproved: kronosnet (focal-proposed/main) [1.14-1ubuntu2 => 1.15-1ubuntu1] (i386-whitelist)
<vorlon> allowing uninstallables would improve the short-term pain and increase the long-term pain
<Laney> I would probably agree more if it wasn't 2 weeks until the release
<vorlon> xnox: isn't Test-Command: ./tests/run-tests redundant?
<vorlon> Laney: I am aggressively hinting specific packages through when it's a non-regression in installability that britney failed to wrap its brain around
<vorlon> however, the bad is that the force hint also skips the autopkgtest
<vorlon> s
<vorlon> Laney: we've had a Foundations discussion that the right thing is to fix britney to trigger autopkgtests and start looking at results without waiting for riscv64 to be built, because it's a non-autopkgtest arch
<vorlon> but that's a code change we need to work out
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (focal-proposed) [0.136ubuntu6]
<Laney> Can you please strive to have such discussions in places where non-foundations people can participate?
<xnox> vorlon:  it will be triggered as autopkgtest, when netplan moves, but initramfs-tools does not move.
<xnox> vorlon:  unless i missed where that is already run
<xnox> vorlon:  if there was "needs build" restriction, then it would be redundant.
<xnox> Laney:  well, it was audio side-channel during our #ubuntu-meeting meeting that is finishing right now.
<Laney> xnox: Don't think the particular venue affects my request
-queuebot:#ubuntu-release- Unapproved: resource-agents (focal-proposed/main) [1:4.4.0-3ubuntu1 => 1:4.5.0-2ubuntu1] (ubuntu-server)
<Laney> sil2100: So I guess no
<Laney> Sorry, I've not been included in the loop on riscv64 bring-up discussions so I didn't get a chance to raise this kind of concern
<Laney> Looks like in-progress builds, if they succeed, might make this particular one go through though
<sil2100> Laney: oh, hm, so no hinting of the livecd-rootfs package?
<sil2100> hmmm
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [source] (focal-proposed) [3.36.1-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libiberty [source] (focal-proposed) [20200409-1]
-queuebot:#ubuntu-release- Unapproved: accepted libssh [source] (focal-proposed) [0.9.3-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted rake [sync] (focal-proposed) [13.0.1-4]
-queuebot:#ubuntu-release- Unapproved: accepted xubuntu-default-settings [source] (focal-proposed) [20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted indicator-applet [sync] (focal-proposed) [12.10.2+20.04.20200409-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mutter [source] (focal-proposed) [3.36.1-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted liblxqt [source] (focal-proposed) [0.14.1-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ruby-test-unit [sync] (focal-proposed) [3.3.5-1]
-queuebot:#ubuntu-release- Unapproved: budgie-extras (focal-proposed/universe) [1.0.0-1 => 1.0.1-1] (personal-fossfreedom, ubuntu-budgie) (sync)
-queuebot:#ubuntu-release- Unapproved: lptools (focal-proposed/universe) [0.2.0-5ubuntu1 => 0.2.0-5ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted lptools [source] (focal-proposed) [0.2.0-5ubuntu2]
<doko> missing build on arm64: libopencl-clang-dev (from 9.0.0-1build1)
<doko> missing build on armhf: libopencl-clang-dev (from 9.0.0-1build1)
<doko> missing build on i386: libopencl-clang-dev (from 9.0.0-1build1)
<doko> missing build on ppc64el: libopencl-clang-dev (from 9.0.0-1build1)
<doko> missing build on riscv64: libopencl-clang-dev (from 9.0.0-1build1)
<doko> missing build on s390x: libopencl-clang-dev (from 9.0.0-1build1)
<doko> why do I see this? that's only built on amd64 in both the proposed and release pocket
<xnox> doko:  because -dev used to be _all.deb and not it is _amd64.deb
<xnox> doko:  and _all.deb obviously used to be available on all those other arches.
<xnox> doko:  because -dev used to be _all.deb and now it is _amd64.deb
<xnox> i don't know how to resolve that.
<xnox> doko:  libopencl-clang-dev needs to be "removed" on those arches? but that's not possible
<xnox> vorlon:  ^^^ ?
<doko> well, you can remove that on the archs, doing that now in the release pocket
-queuebot:#ubuntu-release- Unapproved: python-barbicanclient (focal-proposed/main) [4.8.1-0ubuntu2 => 4.10.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-castellan (focal-proposed/main) [2.0.0-0ubuntu1 => 3.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-cliff (focal-proposed/main) [2.18.0-0ubuntu1 => 3.1.0-0ubuntu1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-diskimage-builder (focal-proposed/universe) [2.33.0-0ubuntu1 => 2.35.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-diskimage-builder [source] (focal-proposed) [2.35.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: kdeplasma-addons (focal-proposed/universe) [4:5.18.4.1-0ubuntu1 => 4:5.18.4.1-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: python-glanceclient (focal-proposed/main) [1:2.17.0-0ubuntu3 => 1:3.1.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-glance-store (focal-proposed/main) [1.1.0-0ubuntu3 => 2.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-ironic-lib (focal-proposed/universe) [4.0.0-0ubuntu1 => 4.2.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-keystoneauth1 (focal-proposed/main) [3.18.0-0ubuntu1 => 4.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted python-ironic-lib [source] (focal-proposed) [4.2.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-keystonemiddleware (focal-proposed/main) [8.0.0-0ubuntu1 => 9.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-mistral-lib (focal-proposed/universe) [1.4.0-0ubuntu1 => 2.1.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-mistral-lib [source] (focal-proposed) [2.1.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: glance (focal-proposed/main) [2:20.0.0~b3~git2020032414.30ece7aa-0ubuntu2 => 2:20.0.0~b3~git2020032414.30ece7aa-0ubuntu3] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-octavia-lib (focal-proposed/universe) [1.5.0-0ubuntu1 => 2.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-openstackdocstheme (focal-proposed/universe) [2.0.0-0ubuntu1 => 2.0.1-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: accepted python-octavia-lib [source] (focal-proposed) [2.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-neutron-lib (focal-proposed/main) [2.2.0-0ubuntu1 => 2.3.0-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-neutronclient (focal-proposed/main) [1:7.1.0-0ubuntu1 => 1:7.1.1-0ubuntu1] (openstack, ubuntu-server)
<vorlon> Laney: so upon reflection, I think it is ok to relax britney to not care about installability on riscv64, because we're in final freeze which means we shouldn't be having any more transitions that would *increase* uninstallability... and the things that are equally uninstallable in both release and -proposed either shake out or they don't.  If one of the buttons lets us do just that, I'm ok with
<vorlon> this
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (focal-proposed) [2.04-1ubuntu24]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (focal-proposed) [2.04-1ubuntu24]
<rbalint> please merge https://code.launchpad.net/~rbalint/britney/hints-ubuntu/+merge/382031 for debhelper
-queuebot:#ubuntu-release- Unapproved: python-os-brick (focal-proposed/main) [3.0.0-0ubuntu1 => 3.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-os-traits (focal-proposed/main) [2.2.0-0ubuntu1 => 2.3.0-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-os-resource-classes (focal-proposed/main) [0.5.0-0ubuntu1 => 1.0.0-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-os-win (focal-proposed/main) [5.0.0-0ubuntu1 => 5.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-os-api-ref (focal-proposed/universe) [2.0.0-0ubuntu1 => 2.0.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-os-api-ref [source] (focal-proposed) [2.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-openstacksdk (focal-proposed/main) [0.45.0-0ubuntu2 => 0.46.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: shim-signed (focal-proposed/main) [1.40.2 => 1.40.3] (core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-keyring (focal-proposed/main) [2020.02.11.1 => 2020.02.11.2] (core)
<vorlon> Laney, xnox: so I'm going to go ahead and add riscv64 to NEW_ARCHES and see if that doesn't make things easier
-queuebot:#ubuntu-release- Unapproved: spirv-headers (focal-proposed/universe) [1.5.1-4 => 1.5.1+git20200409-1] (i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: spirv-tools (focal-proposed/universe) [2020.1-2 => 2020.2-1] (i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (focal-proposed) [1.40.3]
<doko> vorlon, Laney: could you also add riscv64 to the transition tracker?
-queuebot:#ubuntu-release- Unapproved: debian-installer (focal-proposed/main) [20101020ubuntu609 => 20101020ubuntu610] (core)
-queuebot:#ubuntu-release- Unapproved: python-oslo.reports (focal-proposed/main) [2.0.0-0ubuntu1 => 2.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-oslo.serialization (focal-proposed/main) [3.0.0-0ubuntu1 => 3.1.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-oslo.rootwrap (focal-proposed/main) [6.0.0-0ubuntu1 => 6.0.2-0ubuntu1] (openstack, ubuntu-server)
<vorlon> doko: patches welcome; otherwise not a priority for me since the transition tracker is trash and I hate it
-queuebot:#ubuntu-release- Unapproved: python-oslo.privsep (focal-proposed/main) [2.0.0-0ubuntu1 => 2.1.1-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-oslo.log (focal-proposed/main) [4.0.0-0ubuntu1 => 4.1.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-oslo.middleware (focal-proposed/main) [4.0.0-0ubuntu1 => 4.0.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-oslo.messaging (focal-proposed/main) [11.0.0-0ubuntu1 => 12.1.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-oslo.policy (focal-proposed/main) [2.4.1-0ubuntu1 => 3.0.3-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-oslo.i18n (focal-proposed/main) [4.0.0-0ubuntu1 => 4.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-oslo.concurrency (focal-proposed/main) [4.0.0-0ubuntu2 => 4.0.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-oslo.context (focal-proposed/main) [1:3.0.0-0ubuntu1 => 1:3.0.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-oslo.config (focal-proposed/main) [1:8.0.0-0ubuntu1 => 1:8.0.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-oslo.db (focal-proposed/main) [7.0.0-0ubuntu1 => 8.1.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-oslo.cache (focal-proposed/main) [2.0.0-0ubuntu1 => 2.3.0-0ubuntu1] (openstack, ubuntu-server)
<Laney> vorlon: Alright, thanks for your consideration. I'll try to peek in over the 4 day holiday we're having and see how that's going. (I suspect it might be BREAK_ARCHES from reading the source.)
<Laney> doko: Will do next week (remind me if I forget)
<vorlon> yeah I thought BREAK_ARCHES was much more violent though
<vorlon> might still be ok right now; we'll see
<Laney> it is, but I think it's what guards this particular condition
<Laney> worth trying the other one first
<Laney> ok, away for the night :-)
-queuebot:#ubuntu-release- Unapproved: python-zunclient (focal-proposed/universe) [3.6.0-0ubuntu1 => 4.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-zunclient [source] (focal-proposed) [4.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libcgi-application-plugin-messagestack-perl (focal-proposed/universe) [0.34-4ubuntu2 => 0.34-4ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted libcgi-application-plugin-messagestack-perl [source] (focal-proposed) [0.34-4ubuntu3]
-queuebot:#ubuntu-release- Unapproved: python-oslo.service (focal-proposed/main) [2.0.0-0ubuntu1 => 2.1.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-oslo.upgradecheck (focal-proposed/main) [1.0.0-0ubuntu1 => 1.0.1-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-oslo.utils (focal-proposed/main) [4.0.0-0ubuntu1 => 4.1.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-oslo.vmware (focal-proposed/main) [3.0.0-0ubuntu1 => 3.3.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-oslo.versionedobjects (focal-proposed/main) [2.0.0-0ubuntu1 => 2.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-osprofiler (focal-proposed/main) [3.0.0-0ubuntu1 => 3.1.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-ovsdbapp (focal-proposed/main) [1.0.0-0ubuntu1 => 1.1.0-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-vitrageclient (focal-proposed/universe) [4.0.0-0ubuntu1 => 4.0.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-senlinclient (focal-proposed/main) [2.0.0-0ubuntu1 => 2.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted python-vitrageclient [source] (focal-proposed) [4.0.1-0ubuntu1]
<vorlon> oh hey, only 2,964 uninstallables now on riscv64 in the release pocket, that's quite the improvement ;)
-queuebot:#ubuntu-release- Unapproved: python-oslotest (focal-proposed/universe) [1:3.9.0-0ubuntu1 => 1:4.2.0-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: python-pbr (focal-proposed/main) [5.4.4-0ubuntu1 => 5.4.5-0ubuntu1] (i386-whitelist, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: node-proper-lockfile (focal-proposed/universe) [2.0.1-1ubuntu1 => 2.0.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-proper-lockfile [sync] (focal-proposed) [2.0.1-2]
<vorlon> plasma-discover/riscv64 (5.18.4.1-0ubuntu1 to 5.18.4.1-0ubuntu1)
<vorlon> plasma-discover-backend-snap/riscv64 unsatisfiable Depends: snapd
<vorlon> Valid candidate
<vorlon> Laney: ^^ I think it worked
<vorlon> Laney: oops, but it only worked for binary-only migrations, and e.g. livecd-rootfs is still stuck
<vorlon> so yeah, looking for a bigger stick
-queuebot:#ubuntu-release- Unapproved: update-manager (bionic-proposed/main) [1:18.04.11.10 => 1:18.04.11.11] (core)
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (focal-proposed) [20101020ubuntu610]
-queuebot:#ubuntu-release- Unapproved: vte2.91 (focal-proposed/main) [0.60.0-2ubuntu2 => 0.60.1-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rejected update-manager [source] (bionic-proposed) [1:18.04.11.11]
-queuebot:#ubuntu-release- Unapproved: update-manager (bionic-proposed/main) [1:18.04.11.10 => 1:18.04.11.11] (core)
-queuebot:#ubuntu-release- New sync: rheolef (focal-proposed/primary) [7.1-1]
-queuebot:#ubuntu-release- Unapproved: grub2-signed (focal-proposed/main) [1.139 => 1.140] (core)
<xnox> juliank:  vorlon: ^ not sure if that's the right fix for the typpo
<xnox> i think that's what should happen
-queuebot:#ubuntu-release- Unapproved: rasdaemon (focal-proposed/universe) [0.6.5-1 => 0.6.5-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted rasdaemon [source] (focal-proposed) [0.6.5-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: grub2-signed (focal-proposed/main) [1.139 => 1.140] (core)
<vorlon> xnox: yeah, same thing I just uploaded, mod whitespace; accepting yours
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (focal-proposed) [1.140]
-queuebot:#ubuntu-release- Unapproved: rejected grub2-signed [source] (focal-proposed) [1.140]
-queuebot:#ubuntu-release- New binary: grub2-signed [arm64] (focal-proposed/none) [1.140] (core)
-queuebot:#ubuntu-release- New binary: linux-signed-gke-4.15 [amd64] (bionic-proposed/main) [4.15.0-1058.61] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-gke-5.0 [amd64] (bionic-proposed/universe) [5.0.0-1034.35] (kernel)
#ubuntu-release 2020-04-10
-queuebot:#ubuntu-release- Unapproved: fonts-noto-color-emoji (focal-proposed/main) [0~20191119-1 => 0~20200408-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (focal-proposed/main) [2.1 => 2.2] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: pango1.0 (focal-proposed/main) [1.44.7-2ubuntu2 => 1.44.7-2ubuntu3] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: goobox (focal-proposed/universe) [3.6.0-1 => 3.6.0-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted goobox [sync] (focal-proposed) [3.6.0-2]
-queuebot:#ubuntu-release- Unapproved: ukui-window-switch (focal-proposed/universe) [2.0.1-1 => 2.0.2-1] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: ukui-panel (focal-proposed/universe) [2.0.5-1 => 2.0.6-1] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-4.15 [amd64] (bionic-proposed) [4.15.0-1058.61]
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.0 [amd64] (bionic-proposed) [5.0.0-1034.35]
-queuebot:#ubuntu-release- Unapproved: gjs (focal-proposed/main) [1.64.1-1 => 1.64.1-2] (desktop-core, desktop-extra, i386-whitelist, mozilla) (sync)
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-autohidetopbar (focal-proposed/universe) [20190913-1 => 20200322-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gscan2pdf (focal-proposed/universe) [2.6.4-1 => 2.6.7-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-autohidetopbar [sync] (focal-proposed) [20200322-1]
-queuebot:#ubuntu-release- Unapproved: accepted gscan2pdf [sync] (focal-proposed) [2.6.7-1]
-queuebot:#ubuntu-release- Unapproved: tigervnc (focal-proposed/universe) [1.10.1+dfsg-2 => 1.10.1+dfsg-3] (edubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted tigervnc [sync] (focal-proposed) [1.10.1+dfsg-3]
-queuebot:#ubuntu-release- Unapproved: vulkan-loader (focal-proposed/main) [1.2.131.2-1 => 1.2.135.0-2] (desktop-core, i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: glslang (focal-proposed/universe) [8.13.3559-4 => 8.13.3559+git3727-1] (i386-whitelist) (sync)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (bionic-proposed/main) [4.15.0-1038.42] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1038.42]
-queuebot:#ubuntu-release- Unapproved: haskell-skylighting-core (focal-proposed/universe) [0.7.7-1build3 => 0.7.7-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted haskell-skylighting-core [source] (focal-proposed) [0.7.7-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libhdf4 (focal-proposed/universe) [4.2.14-1build1 => 4.2.14-1ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: wlcs (focal-proposed/universe) [1.1.0+dfsg-4ubuntu1 => 1.1.0+dfsg-4ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted wlcs [source] (focal-proposed) [1.1.0+dfsg-4ubuntu2]
-queuebot:#ubuntu-release- New: accepted grub2-signed [arm64] (focal-proposed) [1.140]
-queuebot:#ubuntu-release- Unapproved: intel-media-driver (focal-proposed/universe) [19.4.0r+dfsg1-1 => 20.1.1+dfsg1-1] (i386-whitelist, kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: intel-media-driver-non-free (focal-proposed/multiverse) [19.4.0+ds1-1build1 => 20.1.1+ds1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted intel-media-driver-non-free [sync] (focal-proposed) [20.1.1+ds1-1]
-queuebot:#ubuntu-release- Unapproved: intel-mediasdk (focal-proposed/universe) [19.4.0-1build1 => 20.1.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted intel-mediasdk [source] (focal-proposed) [20.1.0-0ubuntu1]
<vorlon> fwiw I'm getting the disco NBS kernel binaries removed now from disco-updates; so if anyone hears anything from users of disco having gone awry (not that there should be users of it at this point, but...), please poke me
<vorlon> also I've just realized I haven't been removing from disco-security, so yay, I'm going to have to figure out how to redo some of this
<rbalint> ^^ please accept unattended-upgrades, it has importand fixes
-queuebot:#ubuntu-release- Unapproved: mir (focal-proposed/main) [1.7.1-0ubuntu1 => 1.7.1-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (eoan-proposed/main) [5.3.0-1018.19] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (xenial-proposed/main) [4.15.0-1038.42~16.04.1] (kernel)
<juliank> huh
-queuebot:#ubuntu-release- Unapproved: apt (focal-proposed/main) [2.0.1ubuntu1 => 2.0.2] (core, i386-whitelist) (sync)
<juliank> ^ Seems I forgot to actually upload apt 2.0.2 yesterday, I woke up very confused.
-queuebot:#ubuntu-release- Unapproved: llvm-toolchain-10 (focal-proposed/main) [1:10.0.0-2ubuntu2 => 1:10.0.0-3] (i386-whitelist) (sync)
<wgrant> Hm, probably best not to accept llvm-toolchain-10 just yet. Really want the current one to finish on riscv64, and if -3 migrates before that it'll be rejected.
<wgrant> locutus__: Mind if I reject that for now?
<locutus__> wgrant, I would prefer if nobody touches it from the queue :D
<locutus__> and accept once the old one migrates
<locutus__> but as you wish, you know why I syncd it, so I can ping you later?
-queuebot:#ubuntu-release- Unapproved: libhttp-message-perl (focal-proposed/main) [6.18-1 => 6.22-1] (core, i386-whitelist) (sync)
<wgrant> locutus__: I just don't want some excellent release team member to accept the obviously good change and delay things by three days...
<wgrant> Anyway, thanks a lot for pushing that back to Debian.
-queuebot:#ubuntu-release- Unapproved: accepted kronosnet [source] (focal-proposed) [1.15-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted net-snmp [source] (focal-proposed) [5.8+dfsg-2ubuntu2]
<sil2100> o/
-queuebot:#ubuntu-release- Unapproved: accepted budgie-extras [sync] (focal-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted vte2.91 [source] (focal-proposed) [0.60.1-1ubuntu1]
<wgrant> sil2100: If you could hold off accepting the llvm-toolchain-10 it would be appreciated.
<wgrant> Want to wait for the existing riscv64 build to finish
<sil2100> I'll do a few queue reviews - I see many pkgs for OpenStack Ussuri, but I don't know if I'll have time to look through those
<sil2100> wgrant: ok, ACK
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [sync] (focal-proposed) [2.2]
<sil2100> handsome_feng: hey! Looking at ukui-window-switch right now - I see the whole UkwsStackBlur class has been added which feels like a new feature (for blurring the background image?), is that part of a particular fix?
-queuebot:#ubuntu-release- Unapproved: accepted ukui-panel [sync] (focal-proposed) [2.0.6-1]
<locutus__> wgrant, you can reject and then accept from rejected queue IIRC?
<wgrant> Very true.
-queuebot:#ubuntu-release- Unapproved: accepted libhdf4 [source] (focal-proposed) [4.2.14-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mir [source] (focal-proposed) [1.7.1-0ubuntu2]
<wgrant> sil2100: Thanks
<sil2100> Well, I don't think it's that easy, you can't accept syncs from the Rejected queue IIRC
<sil2100> But a sync is easy
<cjwatson> I thought that worked fine, but it's been a while
-queuebot:#ubuntu-release- Unapproved: rejected llvm-toolchain-10 [sync] (focal-proposed) [1:10.0.0-3]
<wgrant> The whole suspended PackageCopyJob thing is super weird.
<wgrant> I really don't remember.
<cjwatson> Yeah
<sil2100> Last time I accidentally rejected a sync and tried accepting, I got an error about it
<cjwatson> My brain is being eaten by trying to backport twisted to xenial anyway so nobody should trust anything I say
<wgrant> Interesting.
<sil2100> haha
<wgrant>         if self.status == PackageUploadStatus.REJECTED:
<wgrant>             raise QueueInconsistentStateError(
<wgrant>                 "Can't resurrect rejected syncs")
<wgrant> I guess rejection fails the job, and then we refuse to revive it.
<cjwatson> I suppose there was a reason for that.  It may even have been a good one
-queuebot:#ubuntu-release- Unapproved: strip-nondeterminism (focal-proposed/main) [1.6.3-2 => 1.7.0-1] (core, i386-whitelist) (sync)
<locutus__> I can do the sync once riscv64 is published
<wgrant> It would have been done already if I hadn't fat-fingered a manual ghc dispatch :(
-queuebot:#ubuntu-release- Unapproved: accepted apt [sync] (focal-proposed) [2.0.2]
-queuebot:#ubuntu-release- Unapproved: accepted gjs [sync] (focal-proposed) [1.64.1-2]
<handsome_feng> sil2100: emm, sorry, I missed this commit from the lots of fix stuff, and I just contact the upstream author, he said it is because there is a issue in github complained that all other components have blur effect other than ukui-window-switch under kwin. But, yes, I think it is a new feature, you can reject this and I will file an FFe now.
-queuebot:#ubuntu-release- Unapproved: accepted libhttp-message-perl [sync] (focal-proposed) [6.22-1]
<sil2100> handsome_feng: please file an FFe so we have this documented, but since this package is only used by your flavor I'll leave it up to you to decide if you still want to include this so late - if you are confident that this will not cause any issues for the release, I can approve the FFe and the upload
<handsome_feng> sil2100: We tested it carefully before uploaded, I think it's ok to let it got into the final, and I will file the FFe now.  Thanks!
<handsome_feng> LP: #1872042 :)
<ubot5> Launchpad bug 1872042 in ukui-window-switch (Ubuntu) "[FFe] Please sync ukui-window-switch 2.0.2-1 from Debian unstable" [Undecided,New] https://launchpad.net/bugs/1872042
-queuebot:#ubuntu-release- Unapproved: zsys (focal-proposed/main) [0.4.2 => 0.4.3] (no packageset)
<sil2100> handsome_feng: thanks! On it ;)
<sil2100> Ok, I'll go back to being on holiday, will check in on the queue later
-queuebot:#ubuntu-release- Unapproved: accepted ukui-window-switch [sync] (focal-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- Unapproved: golang-google-grpc (focal-proposed/universe) [1.22.1-1ubuntu1 => 1.27.1-1] (ubuntu-mate) (sync)
<locutus__> meh, please reject golang-google-grpc ^^ I'll fix post focal
<locutus__> I'll find another way to make protobuf stuff migrate
-queuebot:#ubuntu-release- Unapproved: golang-goprotobuf (focal-proposed/universe) [1.3.4-1 => 1.3.4-2] (edubuntu, ubuntu-mate) (sync)
<locutus__> this one is good ^^
<didrocks> locutus__: rejected
-queuebot:#ubuntu-release- Unapproved: rejected golang-google-grpc [sync] (focal-proposed) [1.27.1-1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (eoan-proposed) [5.3.0-1018.19]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (xenial-proposed) [4.15.0-1038.42~16.04.1]
-queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (focal-proposed/multiverse) [6.1.4-dfsg-2ubuntu20.04.1 => 6.1.4-dfsg-3ubuntu20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-hwe [source] (focal-proposed) [6.1.4-dfsg-3ubuntu20.04.1]
-queuebot:#ubuntu-release- Unapproved: node-buble (focal-proposed/universe) [0.19.8-7 => 0.19.8-7ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted node-buble [source] (focal-proposed) [0.19.8-7ubuntu1]
-queuebot:#ubuntu-release- Unapproved: node-buble (focal-proposed/universe) [0.19.8-7 => 0.19.8-7ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted node-buble [source] (focal-proposed) [0.19.8-7ubuntu2]
-queuebot:#ubuntu-release- Unapproved: node-address (focal-proposed/universe) [1.1.2-1 => 1.1.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted node-address [source] (focal-proposed) [1.1.2-1ubuntu1]
<locutus_> can any archive-admin please hint octave-communications on ppc64el? it is not built there...
-queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (focal-proposed/multiverse) [6.1.4-dfsg-3ubuntu20.04.1 => 6.1.4-dfsg-4ubuntu20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-hwe [source] (focal-proposed) [6.1.4-dfsg-4ubuntu20.04.1]
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (focal-proposed/main) [2.658 => 2.659] (desktop-core, i386-whitelist)
<locutus_> any archive-admin, please remove node-run-sequence from focal: https://bugs.debian.org/954832
<ubot5> Debian bug 954832 in ftp.debian.org "RM: node-run-sequence -- ROM; Deprecated since node-gulp 4" [Normal,Open]
<locutus_>  hello ubot5 the bug is closed, not open!
<locutus_> please read twice the report before saying wrong stuff
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1048.53] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1061.65] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1080.90] (kernel)
<coreycb> hello release team, we have several openstack packages in the focal unapproved queue that I'd like to see if we can get moving along so that we can continue testing.
-queuebot:#ubuntu-release- Unapproved: gnome-settings-daemon (focal-proposed/main) [3.36.0-1ubuntu1 => 3.36.0-1ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: avahi (focal-proposed/main) [0.7-4ubuntu6 => 0.7-4ubuntu7] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: pulseaudio (bionic-proposed/main) [1:11.1-1ubuntu7.5 => 1:11.1-1ubuntu7.6] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: indicator-china-weather (focal-proposed/universe) [3.0.3-0ubuntu2 => 3.0.4-0ubuntu1] (ubuntukylin)
<mitya57> FWIW, we are planning to publish Qt 5.12.8 in a couple of days: https://lists.ubuntu.com/archives/ubuntu-release/2020-April/004956.html
<mitya57> vorlon: â hope that's fine (and sorry for doing it so late, though that is mostly upstream's fault)
-queuebot:#ubuntu-release- Unapproved: nano (focal-proposed/main) [4.8-1 => 4.8-1ubuntu1] (core)
-queuebot:#ubuntu-release- New sync: node-ip-address (focal-proposed/primary) [6.3.0-1]
-queuebot:#ubuntu-release- New sync: node-stable (focal-proposed/primary) [0.1.8-2]
-queuebot:#ubuntu-release- Unapproved: node-request (focal-proposed/universe) [2.88.1-3 => 2.88.1-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted node-request [source] (focal-proposed) [2.88.1-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-cinderclient (focal-proposed/main) [1:6.0.0-0ubuntu1 => 1:7.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-taskflow (focal-proposed/main) [4.0.0-0ubuntu1 => 4.1.0-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-qinlingclient (focal-proposed/universe) [5.0.0-0ubuntu1 => 5.0.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-qinlingclient [source] (focal-proposed) [5.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-ironicclient (focal-proposed/universe) [4.0.0-0ubuntu1 => 4.1.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-saharaclient (focal-proposed/main) [3.0.0-0ubuntu1 => 3.1.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: nautilus (focal-proposed/main) [1:3.36.1.1-1ubuntu1 => 1:3.36.1.1-1ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: linux-meta (focal-proposed/main) [5.4.0.23.28 => 5.4.0.24.29] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux (focal-proposed/main) [5.4.0-23.27 => 5.4.0-24.28] (core, i386-whitelist, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-restricted-modules (focal-proposed/restricted) [5.4.0-23.27 => 5.4.0-24.28] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed (focal-proposed/main) [5.4.0-23.27 => 5.4.0-24.28] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: gfxboot-theme-ubuntu (focal-proposed/main) [0.23.2 => 0.23.3] (core)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1048.53]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1080.90]
-queuebot:#ubuntu-release- Unapproved: gnome-desktop3 (focal-proposed/main) [3.36.0-1ubuntu1 => 3.36.1-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta [sync] (focal-proposed) [5.4.0.24.29]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed [sync] (focal-proposed) [5.4.0-24.28]
-queuebot:#ubuntu-release- Unapproved: accepted linux-restricted-modules [sync] (focal-proposed) [5.4.0-24.28]
-queuebot:#ubuntu-release- Unapproved: accepted linux [sync] (focal-proposed) [5.4.0-24.28]
-queuebot:#ubuntu-release- Unapproved: python-octaviaclient (focal-proposed/main) [2.0.0-0ubuntu1 => 2.0.1-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New sync: ruby-enumerable-statistics (focal-proposed/primary) [2.0.1+dfsg-2]
-queuebot:#ubuntu-release- New sync: ruby-minitest-global-expectations (focal-proposed/primary) [1.0.1-2]
-queuebot:#ubuntu-release- New sync: ruby-http-parser (focal-proposed/primary) [1.2.1-2]
-queuebot:#ubuntu-release- New sync: ruby-ruby2-keywords (focal-proposed/primary) [0.0.2-1]
-queuebot:#ubuntu-release- New sync: ruby-slack-messenger (focal-proposed/primary) [2.3.3-2]
-queuebot:#ubuntu-release- Unapproved: lynx (focal-proposed/universe) [2.9.0dev.4-1 => 2.9.0dev.5-1] (i386-whitelist, ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: python-django (focal-proposed/main) [2:2.2.11-1 => 2:2.2.12-1] (ubuntu-server) (sync)
<locutus_> the new python-django release has a single bugfix on po files
<locutus_> ^^
<locutus_> for meson there are a few fixes, it works well, and it detects now system zlib natively, something that reverse-deps might be already doing (and failing), my opinion is to let this one into focal, and retry what failed in the archive...
-queuebot:#ubuntu-release- Unapproved: meson (focal-proposed/universe) [0.53.2-2ubuntu2 => 0.54.0-1] (i386-whitelist) (sync)
<locutus_> (meson probably needs a merge btw)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1061.65]
-queuebot:#ubuntu-release- Unapproved: gpsd (focal-proposed/main) [3.20-6 => 3.20-8] (kubuntu) (sync)
<vorlon> Reverse-Testsuite-Triggers
<vorlon> ooh when did we get support for that
-queuebot:#ubuntu-release- Unapproved: pyhamcrest (focal-proposed/main) [1.9.0-2 => 1.9.0-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.42.1 => 2.44.3] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (focal-proposed/main) [2.44.2+20.04 => 2.44.3+20.04] (core)
-queuebot:#ubuntu-release- Unapproved: snapd (eoan-proposed/main) [2.42.1+19.10 => 2.44.3+19.10] (core)
-queuebot:#ubuntu-release- Unapproved: snapd (disco-proposed/main) [2.42.1+19.04 => 2.44.3+19.04] (core)
-queuebot:#ubuntu-release- Unapproved: pam-ssh-agent-auth (focal-proposed/universe) [0.10.3-3build1 => 0.10.3-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pam-ssh-agent-auth [source] (focal-proposed) [0.10.3-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: snapd (bionic-proposed/main) [2.42.1+18.04 => 2.44.3+18.04] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: virtualbox (focal-proposed/multiverse) [6.1.4-dfsg-2 => 6.1.4-dfsg-4] (ubuntu-cloud) (sync)
-queuebot:#ubuntu-release- Unapproved: ufraw (bionic-proposed/universe) [0.22-3.1~build0.18.04.1 => 0.22-3.1ubuntu0.1] (ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: isc-dhcp (focal-proposed/main) [4.4.1-2.1ubuntu4 => 4.4.1-2.1ubuntu5] (core)
<Eickmeyer> ubuntu-archive: For anyone who approves that ufraw ^, can you let me know when you do? It'd be important to get that reseeded/in the metas.
<Eickmeyer> Additionally, where are we at with tjaalton's bug 1871049? Seems rather important to darktable users as there are database incompatibilities if anyone switches to us from a newer version in another distro.
<ubot5> bug 1871049 in darktable (Ubuntu) "FFe: darktable 2.6.3 in focal needs update to 3.0.1" [Undecided,New] https://launchpad.net/bugs/1871049
<Eickmeyer> This stuff didn't show up until after Beta because that's when more people started looking.
<Eickmeyer> bdmurray: Appreciate your help on ufraw.
<bdmurray> Eickmeyer: No problem. Reseeded where?
<Eickmeyer> bdmurray: ubuntustudio. It's gone from the metas since ufraw was removed from the repos.
<bdmurray> Eickmeyer: So then how would an sru of the package to bionic require a change to the metas?
<Eickmeyer> bdmurray: It wouldn't. I'm talking about Focal.
<bdmurray> And what would you do to Focal?
<Eickmeyer> I'd rebuild the ubuntustudio-meta packages.
<bdmurray> Because of a package change in Bionic?
<Eickmeyer> Wait... you only uploaded to bionic? Oh shoot, didn't read the whole thing. my bad.
<Eickmeyer> bdmurray: So, disragard that. :)
<Laney> why ever is BREAK_ARCHES not working
-queuebot:#ubuntu-release- Unapproved: qgis (focal-proposed/universe) [3.10.3+dfsg-1ubuntu1 => 3.10.4+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted qgis [source] (focal-proposed) [3.10.4+dfsg-1ubuntu1]
<LocutusOfBorg> can you please accept virtualbox? trivial fix for kernel 5.6 dkms build
-queuebot:#ubuntu-release- Unapproved: gnome-weather (focal-proposed/universe) [3.34.0-1 => 3.36.1-0ubuntu1] (desktop-extra, ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: accepted nautilus [source] (focal-proposed) [1:3.36.1.1-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: python-cliff (focal-proposed/main) [2.18.0-0ubuntu1 => 3.1.0-0ubuntu1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: qgis [s390x] (focal-proposed/universe) [3.10.4+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.525.43]
-queuebot:#ubuntu-release- New binary: qgis [ppc64el] (focal-proposed/universe) [3.10.4+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: brisk-menu (focal-proposed/universe) [0.6.0-1 => 0.6.0-1ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: mate-tweak (focal-proposed/universe) [20.04.0-1 => 20.04.0-1ubuntu1] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: mate-tweak (focal-proposed/universe) [20.04.0-1 => 20.04.0-1ubuntu2] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: sabnzbdplus (focal-proposed/multiverse) [2.3.6+dfsg-1ubuntu1 => 3.0.0~0git20200408+dfsg-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted sabnzbdplus [sync] (focal-proposed) [3.0.0~0git20200408+dfsg-1]
-queuebot:#ubuntu-release- New binary: qgis [amd64] (focal-proposed/universe) [3.10.4+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: sugar-toolkit-gtk3 (focal-proposed/universe) [0.116-5ubuntu1 => 0.116-6] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted sugar-toolkit-gtk3 [sync] (focal-proposed) [0.116-6]
-queuebot:#ubuntu-release- Unapproved: python-glanceclient (focal-proposed/main) [1:2.17.0-0ubuntu3 => 1:3.1.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-caffeine (focal-proposed/universe) [33-1 => 35-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-caffeine [sync] (focal-proposed) [35-2]
-queuebot:#ubuntu-release- Unapproved: jupp (focal-proposed/universe) [3.1.38-1build1 => 3.1.39-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted jupp [sync] (focal-proposed) [3.1.39-1]
-queuebot:#ubuntu-release- Unapproved: mksh (focal-proposed/universe) [57-7 => 58-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mksh [sync] (focal-proposed) [58-1]
-queuebot:#ubuntu-release- New sync: yubioath-desktop (focal-proposed/primary) [5.0.2-3]
#ubuntu-release 2020-04-11
-queuebot:#ubuntu-release- Unapproved: libvirt-php (focal-proposed/universe) [0.5.4-4ubuntu1 => 0.5.5-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libvirt-php [sync] (focal-proposed) [0.5.5-1]
-queuebot:#ubuntu-release- Unapproved: gnome-terminal (focal-proposed/main) [3.35.91-0ubuntu1 => 3.36.1.1-1ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-gnome-meta (focal-proposed/universe) [0.86 => 0.87] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-gnome-meta [source] (focal-proposed) [0.87]
-queuebot:#ubuntu-release- Unapproved: python-keystoneauth1 (focal-proposed/main) [3.18.0-0ubuntu1 => 4.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New binary: qgis [arm64] (focal-proposed/universe) [3.10.4+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (disco-proposed) [2.44.1+19.04]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (disco-proposed) [2.44.3+19.04]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (disco-proposed) [2.44.2+19.04]
-queuebot:#ubuntu-release- New binary: qgis [armhf] (focal-proposed/universe) [3.10.4+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ubuntu-gnome-default-settings (focal-proposed/universe) [20.04.1 => 20.04.1] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-gnome-default-settings [source] (focal-proposed) [20.04.1]
-queuebot:#ubuntu-release- Unapproved: python-keystoneauth1 (focal-proposed/main) [3.18.0-0ubuntu1 => 4.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cups-filters (focal-proposed/main) [1.27.3-1 => 1.27.4-1] (desktop-core, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: node-request (focal-proposed/universe) [2.88.1-3ubuntu1 => 2.88.1-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted node-request [sync] (focal-proposed) [2.88.1-4]
-queuebot:#ubuntu-release- Unapproved: gcc-3.3 (focal-proposed/universe) [1:3.3.6ds1-30ubuntu1 => 1:3.3.6ds1-30ubuntu2] (i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: python-httplib2 (focal-proposed/main) [0.14.0-1 => 0.14.0-1ubuntu1] (core)
<cjwatson> original problem that resulted in that python-httplib2 upload: finding that our advertised mechanism for running launchpadlib with HTTP debug tracing turned on was crashing on focal (at least on a non-IPv6-enabled network)
<LocutusOfBorg> wgrant, https://launchpad.net/ubuntu/+source/llvm-toolchain-10/1:10.0.0-2ubuntu2/+build/19128076 you sure the build is still ongoing? doesn't it need at least twice the space?
-queuebot:#ubuntu-release- Unapproved: python-sabyenc (focal-proposed/universe) [3.3.6-1 => 4.0.1-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-sabyenc [sync] (focal-proposed) [4.0.1-3]
-queuebot:#ubuntu-release- Unapproved: python-openstackdocstheme (focal-proposed/universe) [2.0.0-0ubuntu1 => 2.0.1-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- New binary: python-sabyenc [amd64] (focal-proposed/universe) [4.0.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: python-sabyenc [s390x] (focal-proposed/universe) [4.0.1-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: node-address (focal-proposed/universe) [1.1.2-1ubuntu1 => 1.1.2-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: node-buble (focal-proposed/universe) [0.19.8-7ubuntu2 => 0.19.8-8] (no packageset) (sync)
-queuebot:#ubuntu-release- New binary: python-sabyenc [ppc64el] (focal-proposed/universe) [4.0.1-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted node-address [sync] (focal-proposed) [1.1.2-2]
-queuebot:#ubuntu-release- Unapproved: accepted node-buble [sync] (focal-proposed) [0.19.8-8]
-queuebot:#ubuntu-release- New binary: python-sabyenc [arm64] (focal-proposed/universe) [4.0.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: python-sabyenc [armhf] (focal-proposed/universe) [4.0.1-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cyrus-imapd (focal-proposed/universe) [3.0.13-3ubuntu1 => 3.0.13-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cyrus-imapd [source] (focal-proposed) [3.0.13-4ubuntu1]
-queuebot:#ubuntu-release- New binary: python-sabyenc [riscv64] (focal-proposed/universe) [4.0.1-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-sabyenc [amd64] (focal-proposed) [4.0.1-3]
-queuebot:#ubuntu-release- New: accepted python-sabyenc [armhf] (focal-proposed) [4.0.1-3]
-queuebot:#ubuntu-release- New: accepted python-sabyenc [riscv64] (focal-proposed) [4.0.1-3]
-queuebot:#ubuntu-release- New: accepted yubioath-desktop [sync] (focal-proposed) [5.0.2-3]
-queuebot:#ubuntu-release- New: accepted python-sabyenc [arm64] (focal-proposed) [4.0.1-3]
-queuebot:#ubuntu-release- New: accepted python-sabyenc [s390x] (focal-proposed) [4.0.1-3]
-queuebot:#ubuntu-release- New: accepted python-sabyenc [ppc64el] (focal-proposed) [4.0.1-3]
-queuebot:#ubuntu-release- New: accepted qgis [amd64] (focal-proposed) [3.10.4+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted qgis [armhf] (focal-proposed) [3.10.4+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted qgis [s390x] (focal-proposed) [3.10.4+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted qgis [arm64] (focal-proposed) [3.10.4+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted qgis [ppc64el] (focal-proposed) [3.10.4+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted node-ip-address [sync] (focal-proposed) [6.3.0-1]
-queuebot:#ubuntu-release- New: accepted rheolef [sync] (focal-proposed) [7.1-1]
-queuebot:#ubuntu-release- New: accepted ruby-http-parser [sync] (focal-proposed) [1.2.1-2]
-queuebot:#ubuntu-release- New: accepted ruby-ruby2-keywords [sync] (focal-proposed) [0.0.2-1]
-queuebot:#ubuntu-release- New: accepted node-stable [sync] (focal-proposed) [0.1.8-2]
-queuebot:#ubuntu-release- New: accepted ruby-minitest-global-expectations [sync] (focal-proposed) [1.0.1-2]
-queuebot:#ubuntu-release- New: accepted ruby-enumerable-statistics [sync] (focal-proposed) [2.0.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted ruby-slack-messenger [sync] (focal-proposed) [2.3.3-2]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-3.3 [source] (focal-proposed) [1:3.3.6ds1-30ubuntu2]
-queuebot:#ubuntu-release- Unapproved: glance (focal-proposed/main) [2:20.0.0~b3~git2020032414.30ece7aa-0ubuntu2 => 2:20.0.0~b3~git2020032414.30ece7aa-0ubuntu3] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted gpsd [sync] (focal-proposed) [3.20-8]
-queuebot:#ubuntu-release- Unapproved: python-keystonemiddleware (focal-proposed/main) [8.0.0-0ubuntu1 => 9.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New binary: yubioath-desktop [s390x] (focal-proposed/none) [5.0.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: node-ip-address [amd64] (focal-proposed/universe) [6.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-enumerable-statistics [amd64] (focal-proposed/universe) [2.0.1+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-http-parser [amd64] (focal-proposed/universe) [1.2.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-minitest-global-expectations [amd64] (focal-proposed/universe) [1.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-slack-messenger [amd64] (focal-proposed/universe) [2.3.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: yubioath-desktop [ppc64el] (focal-proposed/universe) [5.0.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: node-stable [amd64] (focal-proposed/universe) [0.1.8-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-http-parser [ppc64el] (focal-proposed/universe) [1.2.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: yubioath-desktop [amd64] (focal-proposed/universe) [5.0.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-enumerable-statistics [s390x] (focal-proposed/universe) [2.0.1+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-ruby2-keywords [amd64] (focal-proposed/universe) [0.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-enumerable-statistics [ppc64el] (focal-proposed/universe) [2.0.1+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: yubioath-desktop [arm64] (focal-proposed/universe) [5.0.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: yubioath-desktop [armhf] (focal-proposed/universe) [5.0.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-http-parser [arm64] (focal-proposed/universe) [1.2.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-http-parser [armhf] (focal-proposed/universe) [1.2.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-enumerable-statistics [arm64] (focal-proposed/universe) [2.0.1+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-enumerable-statistics [armhf] (focal-proposed/universe) [2.0.1+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: yubioath-desktop [riscv64] (focal-proposed/universe) [5.0.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-enumerable-statistics [riscv64] (focal-proposed/universe) [2.0.1+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rheolef [s390x] (focal-proposed/universe) [7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rheolef [amd64] (focal-proposed/universe) [7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rheolef [ppc64el] (focal-proposed/universe) [7.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted yubioath-desktop [amd64] (focal-proposed) [5.0.2-3]
-queuebot:#ubuntu-release- New: accepted yubioath-desktop [armhf] (focal-proposed) [5.0.2-3]
-queuebot:#ubuntu-release- New: accepted yubioath-desktop [riscv64] (focal-proposed) [5.0.2-3]
-queuebot:#ubuntu-release- New: accepted yubioath-desktop [arm64] (focal-proposed) [5.0.2-3]
-queuebot:#ubuntu-release- New: accepted yubioath-desktop [s390x] (focal-proposed) [5.0.2-3]
-queuebot:#ubuntu-release- New: accepted yubioath-desktop [ppc64el] (focal-proposed) [5.0.2-3]
-queuebot:#ubuntu-release- New: accepted ruby-enumerable-statistics [amd64] (focal-proposed) [2.0.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted ruby-enumerable-statistics [armhf] (focal-proposed) [2.0.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted ruby-enumerable-statistics [riscv64] (focal-proposed) [2.0.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted ruby-enumerable-statistics [arm64] (focal-proposed) [2.0.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted ruby-enumerable-statistics [s390x] (focal-proposed) [2.0.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted ruby-enumerable-statistics [ppc64el] (focal-proposed) [2.0.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted node-ip-address [amd64] (focal-proposed) [6.3.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-http-parser [amd64] (focal-proposed) [1.2.1-2]
-queuebot:#ubuntu-release- New: accepted ruby-http-parser [armhf] (focal-proposed) [1.2.1-2]
-queuebot:#ubuntu-release- New: accepted ruby-minitest-global-expectations [amd64] (focal-proposed) [1.0.1-2]
-queuebot:#ubuntu-release- New: accepted ruby-slack-messenger [amd64] (focal-proposed) [2.3.3-2]
-queuebot:#ubuntu-release- New: accepted node-stable [amd64] (focal-proposed) [0.1.8-2]
-queuebot:#ubuntu-release- New: accepted ruby-http-parser [ppc64el] (focal-proposed) [1.2.1-2]
-queuebot:#ubuntu-release- New: accepted ruby-http-parser [arm64] (focal-proposed) [1.2.1-2]
-queuebot:#ubuntu-release- New: accepted ruby-ruby2-keywords [amd64] (focal-proposed) [0.0.2-1]
<locutus_> hello ubuntu-archive, can we please have the camitk hint converted into a "forget everywhere except amd64"? its NBS and also octave-communications/ppc64el, same reason, thanks
-queuebot:#ubuntu-release- Unapproved: uwsgi (focal-proposed/universe) [2.0.18-5ubuntu9 => 2.0.18-11ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted uwsgi [source] (focal-proposed) [2.0.18-11ubuntu1]
-queuebot:#ubuntu-release- Unapproved: xdmf (focal-proposed/universe) [3.0+git20190531-4ubuntu3 => 3.0+git20190531-6] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted xdmf [sync] (focal-proposed) [3.0+git20190531-6]
-queuebot:#ubuntu-release- Unapproved: python-keystonemiddleware (focal-proposed/main) [8.0.0-0ubuntu1 => 9.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: youtube-dl (focal-proposed/universe) [2020.03.24-0ubuntu1 => 2020.03.24-1] (ubuntu-budgie, ubuntukylin) (sync)
-queuebot:#ubuntu-release- New binary: rheolef [arm64] (focal-proposed/universe) [7.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rheolef [amd64] (focal-proposed) [7.1-1]
-queuebot:#ubuntu-release- New: accepted rheolef [ppc64el] (focal-proposed) [7.1-1]
-queuebot:#ubuntu-release- New: accepted rheolef [arm64] (focal-proposed) [7.1-1]
-queuebot:#ubuntu-release- New: accepted rheolef [s390x] (focal-proposed) [7.1-1]
-queuebot:#ubuntu-release- New sync: ogre-1.12 (focal-proposed/primary) [1.12.4+dfsg1-4]
-queuebot:#ubuntu-release- New binary: ruby-unicode-plot [amd64] (focal-proposed/universe) [0.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ruby-unicode-plot [amd64] (focal-proposed) [0.0.4-1]
-queuebot:#ubuntu-release- Unapproved: ruby-vips (focal-proposed/universe) [2.0.13-1 => 2.0.17-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ruby-vips [sync] (focal-proposed) [2.0.17-1]
-queuebot:#ubuntu-release- New sync: kxd (focal-proposed/primary) [0.14-2]
-queuebot:#ubuntu-release- New: accepted kxd [sync] (focal-proposed) [0.14-2]
-queuebot:#ubuntu-release- New: accepted ogre-1.12 [sync] (focal-proposed) [1.12.4+dfsg1-4]
-queuebot:#ubuntu-release- New sync: gnome-shell-extension-top-icons-plus (focal-proposed/primary) [22-5]
-queuebot:#ubuntu-release- New binary: kxd [amd64] (focal-proposed/universe) [0.14-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: kdeplasma-addons (focal-proposed/universe) [4:5.18.4.1-0ubuntu1 => 4:5.18.4.1-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: python-keystoneauth1 (focal-proposed/main) [3.18.0-0ubuntu1 => 4.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-glanceclient (focal-proposed/main) [1:2.17.0-0ubuntu3 => 1:3.1.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-keystonemiddleware (focal-proposed/main) [8.0.0-0ubuntu1 => 9.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New binary: kxd [ppc64el] (focal-proposed/universe) [0.14-2] (no packageset)
-queuebot:#ubuntu-release- New binary: kxd [s390x] (focal-proposed/universe) [0.14-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ogre-1.12 [s390x] (focal-proposed/universe) [1.12.4+dfsg1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: kxd [arm64] (focal-proposed/universe) [0.14-2] (no packageset)
-queuebot:#ubuntu-release- New binary: kxd [armhf] (focal-proposed/universe) [0.14-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ogre-1.12 [ppc64el] (focal-proposed/universe) [1.12.4+dfsg1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: ogre-1.12 [amd64] (focal-proposed/universe) [1.12.4+dfsg1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: ogre-1.12 [arm64] (focal-proposed/universe) [1.12.4+dfsg1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-image-processing [amd64] (focal-proposed/universe) [1.10.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ogre-1.12 [armhf] (focal-proposed/universe) [1.12.4+dfsg1-4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: configobj (focal-proposed/main) [5.0.6-3build1 => 5.0.6-4] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: spice-gtk (focal-proposed/universe) [0.37-0ubuntu2 => 0.37-2fakesync1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted spice-gtk [source] (focal-proposed) [0.37-2fakesync1]
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (focal-proposed/main) [5.4.0-24.28] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (focal-proposed/main) [5.4.0-24.28] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (focal-proposed/main) [5.4.0-24.28] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (focal-proposed/main) [5.4.0-24.28] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: linux-azure (focal-proposed/main) [5.4.0-1009.9 => 5.4.0-1010.10] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-restricted-modules-azure (focal-proposed/restricted) [5.4.0-1009.9 => 5.4.0-1010.10] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-azure (focal-proposed/main) [5.4.0.1009.10 => 5.4.0.1010.11] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed-azure (focal-proposed/main) [5.4.0-1009.9 => 5.4.0-1010.10] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-gcp (focal-proposed/main) [5.4.0-1008.8 => 5.4.0-1009.9] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-restricted-modules-gcp (focal-proposed/restricted) [5.4.0-1008.8 => 5.4.0-1009.9] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-gcp (focal-proposed/main) [5.4.0.1008.8 => 5.4.0.1009.9] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed-gcp (focal-proposed/main) [5.4.0-1008.8 => 5.4.0-1009.9] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-oracle (focal-proposed/main) [5.4.0.1008.8 => 5.4.0.1009.9] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-restricted-modules-oracle (focal-proposed/restricted) [5.4.0-1008.8 => 5.4.0-1009.9] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-oracle (focal-proposed/main) [5.4.0-1008.8 => 5.4.0-1009.9] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed-oracle (focal-proposed/main) [5.4.0-1008.8 => 5.4.0-1009.9] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-kvm (focal-proposed/main) [5.4.0-1007.7 => 5.4.0-1008.8] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-kvm (focal-proposed/main) [5.4.0.1007.7 => 5.4.0.1008.8] (core, kernel) (sync)
<Eickmeyer> Could someone _please_ take a look at bug 1871049 for darktable? tjaalton did an upload for this, just needs approved/accepted.
<ubot5> bug 1871049 in darktable (Ubuntu) "FFe: darktable 2.6.3 in focal needs update to 3.0.1" [Undecided,New] https://launchpad.net/bugs/1871049
-queuebot:#ubuntu-release- Unapproved: libxml2 (focal-proposed/main) [2.9.10+dfsg-4build1 => 2.9.10+dfsg-5] (core, i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: edk2 (focal-proposed/main) [0~20191122.bd85bf54-2ubuntu2 => 0~20191122.bd85bf54-2ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New binary: ogre-1.12 [riscv64] (focal-proposed/universe) [1.12.4+dfsg1-4] (no packageset)
-queuebot:#ubuntu-release- New: accepted ogre-1.12 [amd64] (focal-proposed) [1.12.4+dfsg1-4]
-queuebot:#ubuntu-release- New: accepted ogre-1.12 [armhf] (focal-proposed) [1.12.4+dfsg1-4]
-queuebot:#ubuntu-release- New: accepted ogre-1.12 [riscv64] (focal-proposed) [1.12.4+dfsg1-4]
-queuebot:#ubuntu-release- New: accepted ogre-1.12 [arm64] (focal-proposed) [1.12.4+dfsg1-4]
-queuebot:#ubuntu-release- New: accepted ogre-1.12 [s390x] (focal-proposed) [1.12.4+dfsg1-4]
-queuebot:#ubuntu-release- New: accepted ogre-1.12 [ppc64el] (focal-proposed) [1.12.4+dfsg1-4]
-queuebot:#ubuntu-release- New: accepted gnome-shell-extension-top-icons-plus [sync] (focal-proposed) [22-5]
-queuebot:#ubuntu-release- New: accepted kxd [arm64] (focal-proposed) [0.14-2]
-queuebot:#ubuntu-release- New: accepted kxd [ppc64el] (focal-proposed) [0.14-2]
-queuebot:#ubuntu-release- New: accepted ruby-image-processing [amd64] (focal-proposed) [1.10.3-1]
-queuebot:#ubuntu-release- New: accepted kxd [amd64] (focal-proposed) [0.14-2]
-queuebot:#ubuntu-release- New: accepted kxd [s390x] (focal-proposed) [0.14-2]
-queuebot:#ubuntu-release- New: accepted kxd [armhf] (focal-proposed) [0.14-2]
-queuebot:#ubuntu-release- New binary: gnome-shell-extension-top-icons-plus [amd64] (focal-proposed/universe) [22-5] (no packageset)
-queuebot:#ubuntu-release- New: accepted gnome-shell-extension-top-icons-plus [amd64] (focal-proposed) [22-5]
-queuebot:#ubuntu-release- Unapproved: nvidia-cuda-toolkit (focal-proposed/multiverse) [10.1.243-2 => 10.1.243-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-cuda-toolkit [sync] (focal-proposed) [10.1.243-3]
-queuebot:#ubuntu-release- Unapproved: python-oslo.rootwrap (focal-proposed/main) [6.0.0-0ubuntu1 => 6.0.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted edk2 [source] (focal-proposed) [0~20191122.bd85bf54-2ubuntu3]
-queuebot:#ubuntu-release- Unapproved: python-oslo.serialization (focal-proposed/main) [3.0.0-0ubuntu1 => 3.1.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (focal-proposed) [2.44.3+20.04]
-queuebot:#ubuntu-release- Unapproved: accepted python-httplib2 [source] (focal-proposed) [0.14.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: spirv-headers (focal-proposed/universe) [1.5.1-4 => 1.5.1+git20200409-1] (i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: rejected mate-tweak [source] (focal-proposed) [20.04.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-keyring (focal-proposed/main) [2020.02.11.1 => 2020.02.11.2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted mate-tweak [source] (focal-proposed) [20.04.0-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted brisk-menu [source] (focal-proposed) [0.6.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-os-win (focal-proposed/main) [5.0.0-0ubuntu1 => 5.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted isc-dhcp [source] (focal-proposed) [4.4.1-2.1ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted gfxboot-theme-ubuntu [source] (focal-proposed) [0.23.3]
 * RikMills watches bot
-queuebot:#ubuntu-release- Unapproved: akonadi (focal-proposed/universe) [4:19.04.3-0ubuntu5 => 4:19.04.3-0ubuntu6] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: calibre (focal-proposed/universe) [4.99.4+dfsg+really4.12.0-1 => 4.99.4+dfsg+really4.12.0-1build1] (edubuntu, ubuntustudio) (sync)
-queuebot:#ubuntu-release- Unapproved: dde-qt5integration (focal-proposed/universe) [5.0.0-1build2 => 5.0.0-1build3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: deepin-qt5dxcb-plugin (focal-proposed/universe) [5.0.1-3build1 => 5.0.1-3ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: dtkwidget (focal-proposed/universe) [2.1.1-1build1 => 2.1.1-1build2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gammaray (focal-proposed/universe) [2.11.0-2 => 2.11.0-2ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: hime (focal-proposed/universe) [0.9.10+git20170427+dfsg1-3build7 => 0.9.10+git20170427+dfsg1-3build8] (input-methods) (sync)
-queuebot:#ubuntu-release- Unapproved: kwin (focal-proposed/universe) [4:5.18.4.1-0ubuntu1 => 4:5.18.4.1-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: analitza (focal-proposed/universe) [4:19.12.3-0ubuntu1 => 4:19.12.3-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: fcitx-qt5 (focal-proposed/universe) [1.2.4-1build1 => 1.2.4-1build2] (input-methods, kubuntu, ubuntu-qt-packages) (sync)
-queuebot:#ubuntu-release- Unapproved: gcin (focal-proposed/universe) [2.8.8+dfsg1-1ubuntu3 => 2.8.8+dfsg1-1ubuntu4] (input-methods) (sync)
-queuebot:#ubuntu-release- Unapproved: kxmlgui (focal-proposed/universe) [5.68.0-0ubuntu1 => 5.68.0-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: fcitx5-qt (focal-proposed/universe) [0.0~git20200118.2e38c95-1build1 => 0.0~git20200118.2e38c95-1build2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: kmymoney (focal-proposed/universe) [5.0.8-1build1 => 5.0.8-1build2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted dde-qt5integration [sync] (focal-proposed) [5.0.0-1build3]
-queuebot:#ubuntu-release- Unapproved: accepted deepin-qt5dxcb-plugin [sync] (focal-proposed) [5.0.1-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted dtkwidget [sync] (focal-proposed) [2.1.1-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted gammaray [sync] (focal-proposed) [2.11.0-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: lxqt-qtplugin (focal-proposed/universe) [0.14.0-3ubuntu3 => 0.14.0-3ubuntu4] (lubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: maliit-framework (focal-proposed/universe) [0.99.1+git20151118+62bd54b-0ubuntu25 => 0.99.1+git20151118+62bd54b-0ubuntu26] (ubuntu-qt-packages) (sync)
-queuebot:#ubuntu-release- Unapproved: plasma-integration (focal-proposed/universe) [5.18.4.1-0ubuntu1 => 5.18.4.1-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted fcitx5-qt [sync] (focal-proposed) [0.0~git20200118.2e38c95-1build2]
-queuebot:#ubuntu-release- Unapproved: libqtxdg (focal-proposed/universe) [3.4.0-1build1 => 3.4.0-1build2] (lubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: pyqt5 (focal-proposed/universe) [5.14.1+dfsg-3 => 5.14.1+dfsg-3build1] (i386-whitelist, kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qt3d-opensource-src (focal-proposed/universe) [5.12.5+dfsg-1build2 => 5.12.8+dfsg-0ubuntu1] (kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qt5-ukui-platformtheme (focal-proposed/universe) [1.0.3-0ubuntu1 => 1.0.3-0ubuntu2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: qt5ct (focal-proposed/universe) [0.39-1build2 => 0.39-1build3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: qtav (focal-proposed/universe) [1.13.0+ds-1build1 => 1.13.0+ds-1build2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: qtbase-opensource-src (focal-proposed/universe) [5.12.5+dfsg-9build1 => 5.12.8+dfsg-0ubuntu1] (i386-whitelist, kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: lmms (focal-proposed/universe) [1.2.1+dfsg1-4build1 => 1.2.1+dfsg1-4build2] (i386-whitelist, ubuntustudio) (sync)
-queuebot:#ubuntu-release- Unapproved: qgis (focal-proposed/universe) [3.10.4+dfsg-1ubuntu1 => 3.10.4+dfsg-1ubuntu2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: qtbase-opensource-src-gles (focal-proposed/universe) [5.12.5+dfsg-2 => 5.12.8+dfsg-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: qtcharts-opensource-src (focal-proposed/universe) [5.12.5-2build1 => 5.12.8-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: qtdatavis3d-everywhere-src (focal-proposed/universe) [5.12.5-1build1 => 5.12.8-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: qtdeclarative-opensource-src (focal-proposed/universe) [5.12.5-5build1 => 5.12.8-0ubuntu1] (i386-whitelist, kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: libfm-qt (focal-proposed/universe) [0.14.1-12ubuntu2 => 0.14.1-12ubuntu3] (lubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: qtcreator (focal-proposed/universe) [4.11.0-2build1 => 4.11.0-2build2] (qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qtdeclarative-opensource-src-gles (focal-proposed/universe) [5.12.5-2build1 => 5.12.8-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: qtdoc-opensource-src (focal-proposed/universe) [5.12.5-1 => 5.12.8-0ubuntu1] (kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qtgamepad-everywhere-src (focal-proposed/universe) [5.12.5-1build1 => 5.12.8-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: peony (focal-proposed/universe) [2.1.2-1 => 2.1.2-1build1] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: qtconnectivity-opensource-src (focal-proposed/universe) [5.12.5-1build1 => 5.12.8-0ubuntu1] (kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qtgraphicaleffects-opensource-src (focal-proposed/universe) [5.12.5-2 => 5.12.8-0ubuntu1] (kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qtlocation-opensource-src (focal-proposed/universe) [5.12.5+dfsg-5ubuntu1 => 5.12.8+dfsg-0ubuntu1] (i386-whitelist, kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qtcurve (focal-proposed/universe) [1.9-5 => 1.9-5build1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: qtimageformats-opensource-src (focal-proposed/universe) [5.12.5-1build1 => 5.12.8-0ubuntu1] (kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qtmultimedia-opensource-src (focal-proposed/universe) [5.12.5-1build1 => 5.12.8-0ubuntu1] (i386-whitelist, kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qtnetworkauth-everywhere-src (focal-proposed/universe) [5.12.5-1 => 5.12.8-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: qtremoteobjects-everywhere-src (focal-proposed/universe) [5.12.5-2 => 5.12.8-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: qtsensors-opensource-src (focal-proposed/universe) [5.12.5-2build1 => 5.12.8-0ubuntu1] (i386-whitelist, kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qtserialbus-everywhere-src (focal-proposed/universe) [5.12.5-1build1 => 5.12.8-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: qtstyleplugins-src (focal-proposed/universe) [5.0.0+git23.g335dbec-3ubuntu3 => 5.0.0+git23.g335dbec-3ubuntu4] (kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qtsvg-opensource-src (focal-proposed/universe) [5.12.5-2build1 => 5.12.8-0ubuntu1] (i386-whitelist, kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qtquickcontrols2-opensource-src (focal-proposed/universe) [5.12.5+dfsg-2build1 => 5.12.8+dfsg-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: qtscxml-everywhere-src (focal-proposed/universe) [5.12.5-2build1 => 5.12.8-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: qtserialport-opensource-src (focal-proposed/universe) [5.12.5-1build1 => 5.12.8-0ubuntu1] (i386-whitelist, kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qttools-opensource-src (focal-proposed/universe) [5.12.5-2build1 => 5.12.8-0ubuntu1] (i386-whitelist, kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qttranslations-opensource-src (focal-proposed/universe) [5.12.5-1 => 5.12.8-0ubuntu1] (kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qtvirtualkeyboard-opensource-src (focal-proposed/universe) [5.12.5+dfsg-2build1 => 5.12.8+dfsg-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: qtwebengine-opensource-src (focal-proposed/universe) [5.12.5+dfsg-7build1 => 5.12.8+dfsg-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: qtquickcontrols-opensource-src (focal-proposed/universe) [5.12.5-1build1 => 5.12.8-0ubuntu2] (kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qtwebchannel-opensource-src (focal-proposed/universe) [5.12.5-2build1 => 5.12.8-0ubuntu1] (i386-whitelist, kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: qtx11extras-opensource-src (focal-proposed/universe) [5.12.5-1 => 5.12.8-0ubuntu1] (i386-whitelist, kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qtxmlpatterns-opensource-src (focal-proposed/universe) [5.12.5-1build1 => 5.12.8-0ubuntu1] (i386-whitelist, kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: skrooge (focal-proposed/universe) [2.21.1-1build1 => 2.21.1-1build2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: qtscript-opensource-src (focal-proposed/universe) [5.12.5+dfsg-2build1 => 5.12.8+dfsg-0ubuntu1] (kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qtwebkit-opensource-src (focal-proposed/universe) [5.212.0~alpha4-1ubuntu1 => 5.212.0~alpha4-1ubuntu2] (i386-whitelist, kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: qtwebview-opensource-src (focal-proposed/universe) [5.12.5-1build1 => 5.12.8-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: xdg-desktop-portal-kde (focal-proposed/universe) [5.18.4.1-0ubuntu1 => 5.18.4.1-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: qtspeech-opensource-src (focal-proposed/universe) [5.12.5-1build1 => 5.12.8-0ubuntu1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: qtwebsockets-opensource-src (focal-proposed/universe) [5.12.5-2build1 => 5.12.8-0ubuntu1] (i386-whitelist, kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: telegram-desktop (focal-proposed/universe) [2.0.1+ds-1 => 2.0.1+ds-1build1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: qtwayland-opensource-src (focal-proposed/universe) [5.12.5-2build1 => 5.12.8-0ubuntu1] (kubuntu, qt5) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted qgis [sync] (focal-proposed) [3.10.4+dfsg-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted qtdeclarative-opensource-src-gles [sync] (focal-proposed) [5.12.8-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted telegram-desktop [sync] (focal-proposed) [2.0.1+ds-1build1]
-queuebot:#ubuntu-release- Unapproved: linux-azure (focal-proposed/main) [5.4.0-1009.9 => 5.4.0-1010.10] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-restricted-modules-azure (focal-proposed/restricted) [5.4.0-1009.9 => 5.4.0-1010.10] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted qtbase-opensource-src-gles [sync] (focal-proposed) [5.12.8+dfsg-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: configobj (focal-proposed/main) [5.0.6-3build1 => 5.0.6-4] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: ubiquity (focal-proposed/main) [20.04.9 => 20.04.10] (core)
-queuebot:#ubuntu-release- Unapproved: accepted qtremoteobjects-everywhere-src [sync] (focal-proposed) [5.12.8-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: linux-meta-azure (focal-proposed/main) [5.4.0.1009.10 => 5.4.0.1010.11] (core, kernel) (sync)
<sil2100> o/
<sil2100> I'm around for a bit to look at the queue
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (focal-proposed) [2.659]
-queuebot:#ubuntu-release- Unapproved: accepted zsys [source] (focal-proposed) [0.4.3]
<RikMills> sil2100: there is a Qt bugfix transition sitting there
 * RikMills hides
-queuebot:#ubuntu-release- Unapproved: accepted avahi [source] (focal-proposed) [0.7-4ubuntu7]
-queuebot:#ubuntu-release- Unapproved: accepted indicator-china-weather [source] (focal-proposed) [3.0.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-settings-daemon [source] (focal-proposed) [3.36.0-1ubuntu2]
<sil2100> RikMills: hey! Yeah, hm, can I somehow get an easy digestible list of new features between 5.12.5 and 5.12.8 ?
<sil2100> Since this is a huge thing to land so soooo sooooo late
<RikMills> mitya57: ?
<sil2100> Was there an FFe for that?
<RikMills> there are no new features
-queuebot:#ubuntu-release- Unapproved: accepted gnome-desktop3 [source] (focal-proposed) [3.36.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted nano [source] (focal-proposed) [4.8-1ubuntu1]
<sil2100> RikMills: I guess in that case it has to be trust based then - you checked for sure? If you did, then I guess that's fine
<mitya57> sil2100: see https://www.qt.io/blog/qt-5.12.5-released â it says âAfter the Qt 5.12.5 release was branched, the Qt 5.12 LTS has entered in 'strict' phase, so from now on it will receive only the selected important bug and security fixes.â
<sil2100> Ah! I saw that, but totally misread the version number
<sil2100> Somehow my brain though it was 5.12.8, so after this release
<sil2100> Ok, thanks o/
<RikMills> it is 5.12.8, but that is still only strict bugfixes over 5.12.5
<RikMills> reason we skipped is that we were trying to go for 5.14, but had to abandon that goal
<RikMills> https://lists.ubuntu.com/archives/ubuntu-release/2020-April/004956.html
<mitya57> sil2100: there is no complete list of changes, but here are for example qtbase news files (which had the most changes):
<mitya57> https://code.qt.io/cgit/qt/qtbase.git/tree/dist/changes-5.12.6?h=5.12.8
<mitya57> https://code.qt.io/cgit/qt/qtbase.git/tree/dist/changes-5.12.7?h=5.12.8
<mitya57> https://code.qt.io/cgit/qt/qtbase.git/tree/dist/changes-5.12.8?h=5.12.8
<mitya57> The bundled modules are not relevant to us, as we build with system libraries.
-queuebot:#ubuntu-release- Unapproved: accepted linux-azure [sync] (focal-proposed) [5.4.0-1010.10]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-azure [sync] (focal-proposed) [5.4.0.1010.11]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-oracle [sync] (focal-proposed) [5.4.0.1009.9]
-queuebot:#ubuntu-release- Unapproved: accepted linux-restricted-modules-azure [sync] (focal-proposed) [5.4.0-1010.10]
-queuebot:#ubuntu-release- Unapproved: accepted linux-restricted-modules-oracle [sync] (focal-proposed) [5.4.0-1009.9]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed-gcp [sync] (focal-proposed) [5.4.0-1009.9]
-queuebot:#ubuntu-release- Unapproved: accepted linux-gcp [sync] (focal-proposed) [5.4.0-1009.9]
-queuebot:#ubuntu-release- Unapproved: accepted linux-oracle [sync] (focal-proposed) [5.4.0-1009.9]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed-azure [sync] (focal-proposed) [5.4.0-1010.10]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-gcp [sync] (focal-proposed) [5.4.0.1009.9]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed-oracle [sync] (focal-proposed) [5.4.0-1009.9]
-queuebot:#ubuntu-release- Unapproved: accepted linux-restricted-modules-gcp [sync] (focal-proposed) [5.4.0-1009.9]
<mitya57> Many submodules had just version bump and nothing else (but we needed to update all of them, as versions should match).
<mitya57> Qt WebEngine had really lots of CVE backports from upstream Chromium, e.g. https://code.qt.io/cgit/qt/qtwebengine.git/tree/dist/changes-5.12.8?h=5.12.8
<sil2100> mitya57, RikMills: thanks guys, I'll try to get this reviewed now
<mitya57> Thank you very much!
<sil2100> I'll just do a sanity check
<RikMills> thanks. we know it is late. factors (including life/work) conspired to make it so
<RikMills> I also have a new KDE PIM release FFe, but that won't ready to land until after, so tomorrow or monday
<sil2100> Ok, um, here it goes
 * RikMills holds breath
-queuebot:#ubuntu-release- Unapproved: accepted qtwebengine-opensource-src [sync] (focal-proposed) [5.12.8+dfsg-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtwebsockets-opensource-src [sync] (focal-proposed) [5.12.8-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtx11extras-opensource-src [sync] (focal-proposed) [5.12.8-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted skrooge [sync] (focal-proposed) [2.21.1-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted qtwebkit-opensource-src [sync] (focal-proposed) [5.212.0~alpha4-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted qtxmlpatterns-opensource-src [sync] (focal-proposed) [5.12.8-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtwebview-opensource-src [sync] (focal-proposed) [5.12.8-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted xdg-desktop-portal-kde [sync] (focal-proposed) [5.18.4.1-0ubuntu2]
<sil2100> RikMills, mitya57: in case any issues pop up regarding this landing, I'll pop up tomorrow for another queue review round if anything
<RikMills> sil2100: thanks. appreciated
<sil2100> So just give me a sign on what things need to be reviewed to unblock stuff
-queuebot:#ubuntu-release- Unapproved: accepted qtnetworkauth-everywhere-src [sync] (focal-proposed) [5.12.8-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtquickcontrols2-opensource-src [sync] (focal-proposed) [5.12.8+dfsg-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtscxml-everywhere-src [sync] (focal-proposed) [5.12.8-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtserialbus-everywhere-src [sync] (focal-proposed) [5.12.8-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtspeech-opensource-src [sync] (focal-proposed) [5.12.8-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtsvg-opensource-src [sync] (focal-proposed) [5.12.8-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qttranslations-opensource-src [sync] (focal-proposed) [5.12.8-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtwayland-opensource-src [sync] (focal-proposed) [5.12.8-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: fonts-noto-color-emoji (focal-proposed/main) [0~20191119-1 => 0~20200408-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: python-oslotest (focal-proposed/universe) [1:3.9.0-0ubuntu1 => 1:4.2.0-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: accepted qtquickcontrols-opensource-src [sync] (focal-proposed) [5.12.8-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted qtsensors-opensource-src [sync] (focal-proposed) [5.12.8-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtstyleplugins-src [sync] (focal-proposed) [5.0.0+git23.g335dbec-3ubuntu4]
<RikMills> cool. I think we unbroke everything, but you never know
-queuebot:#ubuntu-release- Unapproved: accepted qtvirtualkeyboard-opensource-src [sync] (focal-proposed) [5.12.8+dfsg-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: pango1.0 (focal-proposed/main) [1.44.7-2ubuntu2 => 1.44.7-2ubuntu3] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: python-senlinclient (focal-proposed/main) [2.0.0-0ubuntu1 => 2.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted qtscript-opensource-src [sync] (focal-proposed) [5.12.8+dfsg-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qttools-opensource-src [sync] (focal-proposed) [5.12.8-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-pbr (focal-proposed/main) [5.4.4-0ubuntu1 => 5.4.5-0ubuntu1] (i386-whitelist, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted qtserialport-opensource-src [sync] (focal-proposed) [5.12.8-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: vulkan-loader (focal-proposed/main) [1.2.131.2-1 => 1.2.135.0-2] (desktop-core, i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted qtwebchannel-opensource-src [sync] (focal-proposed) [5.12.8-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted peony [sync] (focal-proposed) [2.1.2-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted pyqt5 [sync] (focal-proposed) [5.14.1+dfsg-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted qt3d-opensource-src [sync] (focal-proposed) [5.12.8+dfsg-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtbase-opensource-src [sync] (focal-proposed) [5.12.8+dfsg-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtconnectivity-opensource-src [sync] (focal-proposed) [5.12.8-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtcurve [sync] (focal-proposed) [1.9-5build1]
-queuebot:#ubuntu-release- Unapproved: accepted qtdeclarative-opensource-src [sync] (focal-proposed) [5.12.8-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtgamepad-everywhere-src [sync] (focal-proposed) [5.12.8-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-integration [sync] (focal-proposed) [5.18.4.1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted qt5-ukui-platformtheme [sync] (focal-proposed) [1.0.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted qtav [sync] (focal-proposed) [1.13.0+ds-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted qtcreator [sync] (focal-proposed) [4.11.0-2build2]
-queuebot:#ubuntu-release- Unapproved: accepted qtdoc-opensource-src [sync] (focal-proposed) [5.12.8-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtimageformats-opensource-src [sync] (focal-proposed) [5.12.8-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtmultimedia-opensource-src [sync] (focal-proposed) [5.12.8-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-oslo.db (focal-proposed/main) [7.0.0-0ubuntu1 => 8.1.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-oslo.log (focal-proposed/main) [4.0.0-0ubuntu1 => 4.1.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-oslo.middleware (focal-proposed/main) [4.0.0-0ubuntu1 => 4.0.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted qtcharts-opensource-src [sync] (focal-proposed) [5.12.8-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtgraphicaleffects-opensource-src [sync] (focal-proposed) [5.12.8-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-oslo.context (focal-proposed/main) [1:3.0.0-0ubuntu1 => 1:3.0.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-oslo.messaging (focal-proposed/main) [11.0.0-0ubuntu1 => 12.1.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted qt5ct [sync] (focal-proposed) [0.39-1build3]
-queuebot:#ubuntu-release- Unapproved: accepted qtlocation-opensource-src [sync] (focal-proposed) [5.12.8+dfsg-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtdatavis3d-everywhere-src [sync] (focal-proposed) [5.12.8-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-oslo.i18n (focal-proposed/main) [4.0.0-0ubuntu1 => 4.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted akonadi [sync] (focal-proposed) [4:19.04.3-0ubuntu6]
-queuebot:#ubuntu-release- Unapproved: accepted calibre [sync] (focal-proposed) [4.99.4+dfsg+really4.12.0-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted hime [sync] (focal-proposed) [0.9.10+git20170427+dfsg1-3build8]
-queuebot:#ubuntu-release- Unapproved: accepted kwin [sync] (focal-proposed) [4:5.18.4.1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted libfm-qt [sync] (focal-proposed) [0.14.1-12ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted lmms [sync] (focal-proposed) [1.2.1+dfsg1-4build2]
-queuebot:#ubuntu-release- Unapproved: accepted maliit-framework [sync] (focal-proposed) [0.99.1+git20151118+62bd54b-0ubuntu26]
-queuebot:#ubuntu-release- Unapproved: kdeplasma-addons (focal-proposed/universe) [4:5.18.4.1-0ubuntu1 => 4:5.18.4.1-0ubuntu2] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: python-keystoneauth1 (focal-proposed/main) [3.18.0-0ubuntu1 => 4.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted analitza [sync] (focal-proposed) [4:19.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted gcin [sync] (focal-proposed) [2.8.8+dfsg1-1ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted kxmlgui [sync] (focal-proposed) [5.68.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted lxqt-qtplugin [sync] (focal-proposed) [0.14.0-3ubuntu4]
-queuebot:#ubuntu-release- Unapproved: python-glanceclient (focal-proposed/main) [1:2.17.0-0ubuntu3 => 1:3.1.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-neutronclient (focal-proposed/main) [1:7.1.0-0ubuntu1 => 1:7.1.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted fcitx-qt5 [sync] (focal-proposed) [1.2.4-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted libqtxdg [sync] (focal-proposed) [3.4.0-1build2]
-queuebot:#ubuntu-release- Unapproved: python-keystonemiddleware (focal-proposed/main) [8.0.0-0ubuntu1 => 9.0.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted kmymoney [sync] (focal-proposed) [5.0.8-1build2]
-queuebot:#ubuntu-release- Unapproved: python-openstackdocstheme (focal-proposed/universe) [2.0.0-0ubuntu1 => 2.0.1-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: glance (focal-proposed/main) [2:20.0.0~b3~git2020032414.30ece7aa-0ubuntu2 => 2:20.0.0~b3~git2020032414.30ece7aa-0ubuntu3] (openstack, ubuntu-server)
<mitya57> sil2100: ok, and thanks again!
-queuebot:#ubuntu-release- Unapproved: accepted gnome-weather [source] (focal-proposed) [3.36.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-kvm [sync] (focal-proposed) [5.4.0.1008.8]
-queuebot:#ubuntu-release- Unapproved: accepted linux-kvm [sync] (focal-proposed) [5.4.0-1008.8]
<sil2100> yw!
<sil2100> Ok, I go back to weekend duties, see you tomorrow o/
-queuebot:#ubuntu-release- Unapproved: accepted cups-filters [sync] (focal-proposed) [1.27.4-1]
-queuebot:#ubuntu-release- Unapproved: accepted youtube-dl [sync] (focal-proposed) [2020.03.24-1]
<Eickmeyer> Could someone _please_ take a look at bug 1871049 for darktable? tjaalton did an upload for this, just needs approved/accepted.
<ubot5> bug 1871049 in darktable (Ubuntu) "FFe: darktable 2.6.3 in focal needs update to 3.0.1" [Undecided,New] https://launchpad.net/bugs/1871049
-queuebot:#ubuntu-release- Unapproved: accepted libxml2 [sync] (focal-proposed) [2.9.10+dfsg-5]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (focal-proposed/main) [5.4.0-1009.9] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (focal-proposed/main) [5.4.0-1009.9] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (focal-proposed/main) [5.4.0-1010.10] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: golang-1.14 (focal-proposed/universe) [1.14.1-1 => 1.14.2-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted golang-1.14 [sync] (focal-proposed) [1.14.2-1]
-queuebot:#ubuntu-release- Unapproved: hedgewars (focal-proposed/universe) [1.0.0-4build4 => 1.0.0-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted hedgewars [source] (focal-proposed) [1.0.0-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (focal-proposed) [5.4.0-1010.10]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (focal-proposed) [5.4.0-1009.9]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (focal-proposed) [5.4.0-24.28]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (focal-proposed) [5.4.0-24.28]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (focal-proposed) [5.4.0-1009.9]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (focal-proposed) [5.4.0-24.28]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (focal-proposed) [5.4.0-24.28]
-queuebot:#ubuntu-release- Unapproved: llvm-toolchain-10 (focal-proposed/main) [1:10.0.0-2ubuntu2 => 1:10.0.0-3] (i386-whitelist) (sync)
<LocutusOfBorg> wgrant, llvm failed, can you please accept this one then?
-queuebot:#ubuntu-release- Unapproved: llvm-toolchain-9 (focal-proposed/main) [1:9.0.1-11ubuntu1 => 1:9.0.1-12] (i386-whitelist) (sync)
<Eickmeyer> Could someone _please_ take a look at bug 1871049 for darktable? tjaalton did an upload for this, just needs approved/accepted.
<ubot5> bug 1871049 in darktable (Ubuntu) "FFe: darktable 2.6.3 in focal needs update to 3.0.1" [Undecided,New] https://launchpad.net/bugs/1871049
-queuebot:#ubuntu-release- Unapproved: gnome-weather (focal-proposed/universe) [3.36.1-0ubuntu1 => 3.36.1-1] (desktop-extra, ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: meson (focal-proposed/universe) [0.53.2-2ubuntu2 => 0.54.0-1ubuntu1] (i386-whitelist)
#ubuntu-release 2020-04-12
-queuebot:#ubuntu-release- Unapproved: mutagen (focal-proposed/universe) [1.43.0-0ubuntu3 => 1.44.0-1] (ubuntustudio) (sync)
<xnox> vorlon:  pushed merge proposals to rename server to classic-server in debian-cd & ubuntu-cdimage
<xnox> vorlon:  they work for me, but i had to hack-out most of the image building, cause i don't have a full mirror.
-queuebot:#ubuntu-release- Unapproved: vulkan-tools (focal-proposed/universe) [1.2.131.1+dfsg1-1 => 1.2.135.0+dfsg1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted vulkan-tools [sync] (focal-proposed) [1.2.135.0+dfsg1-1]
-queuebot:#ubuntu-release- Unapproved: vulkan-validationlayers (focal-proposed/universe) [1.2.131.2-1 => 1.2.135.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted vulkan-validationlayers [sync] (focal-proposed) [1.2.135.0-1]
-queuebot:#ubuntu-release- Unapproved: ciftilib (focal-proposed/universe) [1.5.3-3 => 1.5.3-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ciftilib [source] (focal-proposed) [1.5.3-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: mathic (focal-proposed/universe) [1.0~git20181123-1 => 1.0~git20181123-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted mathic [source] (focal-proposed) [1.0~git20181123-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: primesieve (focal-proposed/universe) [7.5+ds-3 => 7.5+ds-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted primesieve [source] (focal-proposed) [7.5+ds-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-10 [sync] (focal-proposed) [1:10.0.0-3]
-queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-9 [sync] (focal-proposed) [1:9.0.1-12]
-queuebot:#ubuntu-release- Unapproved: budgie-extras (focal-proposed/universe) [1.0.1-1 => 1.0.1-2] (personal-fossfreedom, ubuntu-budgie) (sync)
-queuebot:#ubuntu-release- Unapproved: cyrus-imapd (focal-proposed/universe) [3.0.13-4ubuntu1 => 3.0.13-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted cyrus-imapd [sync] (focal-proposed) [3.0.13-5]
-queuebot:#ubuntu-release- Unapproved: ruby-adsf (focal-proposed/universe) [1.4.3+dfsg1-1 => 1.4.3+dfsg1-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ruby-adsf [sync] (focal-proposed) [1.4.3+dfsg1-1]
-queuebot:#ubuntu-release- Unapproved: ruby-riddle (focal-proposed/universe) [2.3.1-2ubuntu2 => 2.3.1-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ruby-riddle [source] (focal-proposed) [2.3.1-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: remmina (focal-proposed/main) [1.4.1+dfsg-3ubuntu1 => 1.4.2+dfsg-1ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: xfce4-taskmanager (focal-proposed/universe) [1.2.2-1 => 1.2.3-0ubuntu1] (ubuntustudio, xubuntu)
-queuebot:#ubuntu-release- Unapproved: guile-2.2 (focal-proposed/main) [2.2.7+1-3 => 2.2.7+1-4] (i386-whitelist, ubuntu-desktop) (sync)
<LocutusOfBorg> guile happiness ^^
-queuebot:#ubuntu-release- Unapproved: guile-3.0 (focal-proposed/universe) [3.0.1+1-1 => 3.0.1+1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted guile-3.0 [sync] (focal-proposed) [3.0.1+1-2]
-queuebot:#ubuntu-release- Unapproved: libnftnl (focal-proposed/main) [1.1.5-1 => 1.1.6-1] (i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-meta (focal-proposed/universe) [1.262 => 1.263] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: mm-common (focal-proposed/universe) [0.9.12-1 => 1.0.0-1] (i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: bijiben (focal-proposed/universe) [3.36.0-1 => 3.36.1-1] (desktop-extra) (sync)
<mitya57> Hi! It would be nice if someone could look at https://code.launchpad.net/~mitya57/britney/hints-ubuntu-update-pinentry/+merge/382109 â itâs needed for Qt migration
-queuebot:#ubuntu-release- Unapproved: kdeconnect (focal-proposed/universe) [1.4-0ubuntu4 => 1.4-0ubuntu5] (kubuntu)
<RikMills> ^^^ Fix for LP: #1872075
<ubot5> Launchpad bug 1872075 in kdeconnect (Ubuntu) "Can't access phone filesystem with KDE Connect" [High,In progress] https://launchpad.net/bugs/1872075
-queuebot:#ubuntu-release- Unapproved: gcc-10 (focal-proposed/main) [10-20200405-0ubuntu1 => 10-20200411-0ubuntu1] (i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: julia (focal-proposed/universe) [1.3.1+dfsg-1build1 => 1.4.0+dfsg-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted julia [source] (focal-proposed) [1.4.0+dfsg-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gcc-10-cross (focal-proposed/main) [5ubuntu2 => 6ubuntu2] (i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (focal-proposed/main) [2.659 => 2.660] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (eoan-proposed/main) [5.3.0-48.41] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (eoan-proposed/main) [5.3.0-48.41] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (eoan-proposed/main) [5.3.0-48.41] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (eoan-proposed/main) [5.3.0-48.41] (core, kernel)
<Eickmeyer> Release Team: Could someone _please_ take a look at bug 1871049 for darktable? tjaalton did an upload for this, just needs approved/accepted.
<ubot5> bug 1871049 in darktable (Ubuntu) "FFe: darktable 2.6.3 in focal needs update to 3.0.1" [High,New] https://launchpad.net/bugs/1871049
<tjaalton> it's easter, I hope no-one of the release team is here atm :)
<Eickmeyer> tjaalton: True. :)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (eoan-proposed) [5.3.0-48.41]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (eoan-proposed) [5.3.0-48.41]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (eoan-proposed) [5.3.0-48.41]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (eoan-proposed) [5.3.0-48.41]
-queuebot:#ubuntu-release- Unapproved: youker-assistant (focal-proposed/universe) [3.0.1-0ubuntu3 => 3.0.2-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: xfce4-settings (focal-proposed/universe) [4.14.2-1ubuntu1 => 4.14.3-0ubuntu1] (ubuntustudio, xubuntu)
-queuebot:#ubuntu-release- Unapproved: xubuntu-default-settings (focal-proposed/universe) [20.04.1 => 20.04.2] (xubuntu)
<sil2100> o/
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (focal-proposed) [2.660]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-10-cross [sync] (focal-proposed) [6ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-10 [sync] (focal-proposed) [10-20200411-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-meta [source] (focal-proposed) [1.263]
-queuebot:#ubuntu-release- Unapproved: python-castellan (focal-proposed/main) [2.0.0-0ubuntu1 => 3.0.0-0ubuntu1] (openstack, ubuntu-server)
<sil2100> jbicha: the new mutagen sync - python-mutagen is a reverse-dependency of zomg, are there any plans to do something with that package?
-queuebot:#ubuntu-release- Unapproved: accepted budgie-extras [sync] (focal-proposed) [1.0.1-2]
-queuebot:#ubuntu-release- Unapproved: accepted xfce4-taskmanager [source] (focal-proposed) [1.2.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: resource-agents (focal-proposed/main) [1:4.4.0-3ubuntu1 => 1:4.5.0-2ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted remmina [source] (focal-proposed) [1.4.2+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-barbicanclient (focal-proposed/main) [4.8.1-0ubuntu2 => 4.10.0-0ubuntu1] (openstack, ubuntu-server)
<RikMills> sil2100: pleas accept https://code.launchpad.net/~mitya57/britney/hints-ubuntu-update-pinentry/+merge/382109
-queuebot:#ubuntu-release- Unapproved: accepted kdeconnect [source] (focal-proposed) [1.4-0ubuntu5]
-queuebot:#ubuntu-release- Unapproved: openssl (focal-proposed/main) [1.1.1d-2ubuntu6 => 1.1.1f-1ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: accepted xfce4-settings [source] (focal-proposed) [4.14.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ubiquity (focal-proposed/main) [20.04.9 => 20.04.10] (core)
-queuebot:#ubuntu-release- Unapproved: accepted bijiben [sync] (focal-proposed) [3.36.1-1]
<sil2100> RikMills: looking
<RikMills> thanks!
-queuebot:#ubuntu-release- Unapproved: accepted youker-assistant [source] (focal-proposed) [3.0.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted xubuntu-default-settings [source] (focal-proposed) [20.04.2]
<sil2100> Ok, today sadly that's all the time I have - I'll be back tomorrow o/
<RikMills> sil2100: thanks :)
-queuebot:#ubuntu-release- Unapproved: accepted python-django [sync] (focal-proposed) [2:2.2.12-1]
-queuebot:#ubuntu-release- Unapproved: apparmor (focal-proposed/main) [2.13.3-7ubuntu4 => 2.13.3-7ubuntu5] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: dtkwidget (focal-proposed/universe) [2.1.1-1build2 => 2.1.1-1build3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted dtkwidget [source] (focal-proposed) [2.1.1-1build3]
-queuebot:#ubuntu-release- Unapproved: ibus-unikey (focal-proposed/main) [0.6.1-1.1build1 => 0.6.1-1.1ubuntu1] (input-methods, ubuntu-desktop)
<Eickmeyer> Release Team: Could someone _please_ take a look at bug 1871049 for darktable? tjaalton did an upload for this, just needs approved/accepted.
<ubot5> bug 1871049 in darktable (Ubuntu) "FFe: darktable 2.6.3 in focal needs update to 3.0.1" [High,New] https://launchpad.net/bugs/1871049
-queuebot:#ubuntu-release- Unapproved: language-selector (focal-proposed/main) [0.203 => 0.204] (core, personal-gunnarhj)
