 The chair is mpt.
[19:05] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[19:05] <mpt> there we go
[19:06] <mpt> so, the agenda
[19:06] <stub> me (sorry - new kernel doesn't like my network stick)
[19:06] <mpt>  * Next meeting
[19:06] <mpt>  * Actions from last meeting
[19:06] <mpt>  * Oops report (Matsubara)
[19:06] <mpt>  * Critical Bugs (Rinchen)
[19:06] <mpt>  * Bug tags
[19:06] <mpt>  * Operations report (mthaddon/herb/spm)
[19:06] <mpt>  * DBA report (stub)
[19:06] <mpt>  * Sysadmin requests (Rinchen)
[19:06] <mpt>  * New packages required (salgado)
[19:06] <mpt>  * A top user-affecting issue (mrevell)
[19:06] <mpt>  * Doc Team report (mrevell)
[19:07] <mpt>  * New MOTU liaison
[19:07] <mpt>  * Oopses for unauthorized exceptions
[19:07] <mpt> [TOPIC] Next meeting
[19:07] <MootBot> New Topic:  Next meeting
[19:07] <mpt> Any problem with the same time next week?
[19:07] <sinzui> I may not be
[19:08] <BjornT> the bugs team will be sprinting, but should make it anyway
[19:08] <flacoste> barry and sinzui are away
[19:08] <sinzui> here ot there
[19:08]  * barry pre-apologizes
[19:08] <al-maisan> I'll be off on Thursday next week
[19:08] <mpt> We have an apology from allenap for this week
[19:08] <mpt> and from kiko and Rinchen who are famously at Oscon
[19:09] <mpt> ok, next meeting same time next week
[19:09] <mpt> [TOPIC] Actions from last meeting
[19:09] <MootBot> New Topic:  Actions from last meeting
[19:10] <mpt> There are no notes available from the last meeting, so no actions
[19:10] <mpt> [TOPIC] Oops report
[19:10] <MootBot> New Topic:  Oops report
[19:10] <matsubara> Hi everyone, say hello to Ursinha, she started this week and is the new QA person
[19:10] <matsubara> Ursinha, the stage is yours. Go ahead.
[19:10] <thumper> hi Ursinha
[19:10]  * Ursinha waves
[19:10] <mpt> welcome Ursinha
[19:10] <Ursinha> hi all
[19:10] <herb> hi Ursinha
[19:10] <stub> o/
[19:10] <rockstar> Hi Ursinha
[19:10] <barry> Ursinha: welcome!
[19:10] <mars> hi Ursinha
[19:10] <al-maisan> hello Ursinha
[19:10] <Ursinha> :)
[19:10] <sinzui> hi
[19:10] <adeuring> hi Ursinha
[19:11] <abentley> Hi.
[19:11] <flacoste> welcome Ursinha!
[19:11] <mrevell> welcome Ursinha
[19:11] <salgado> welcome aboard, Ursinha
[19:11] <Ursinha> thanks all
[19:11] <Ursinha> well, I have two bugs in here
[19:11] <Ursinha> one is a Unicode error, bug 251569
[19:12] <Ursinha> can anybody please take a look at it?
[19:12] <Ursinha> it's oopsing when trying to do a people search
[19:13] <Ursinha> the other is a timeout problem that is causing more oopses than normal
[19:13] <Ursinha> an old bug, 124205
[19:13] <thumper> hey ubotto, bug 124205
[19:13] <flacoste> salgado?
[19:13] <flacoste> could you look into 251569?
[19:14] <salgado> sure
[19:14] <Ursinha> thanks salgado
[19:14]  * flacoste kicks ubotto
[19:14] <matsubara> the second one is a bug on +specworkload. it's assigned to BjornT (why?) BjornT are you going to have a look on that one?
[19:14] <Ursinha> \o/
[19:14] <BjornT> matsubara: nope :) i've unassigned myself
[19:15] <Ursinha> this bug is old but is happening very often in the last days
[19:15] <matsubara> okie. so, I guess that's another one for Foundations
[19:15] <matsubara> flacoste: can you keep it under the radar?
[19:16] <flacoste> matsubara: sure
[19:16] <flacoste> Ursinha: bac is looking at it
[19:16] <Ursinha> thanks flacoste
[19:16] <Ursinha> guess that's all for today
[19:16] <matsubara> btw, thanks all for the effort on the fixes for yesterday's rollout. oops summary today's been very quiet.
[19:16] <mpt> thanks Ursinha and matsubara
[19:17] <Ursinha> indeed, kudos for you all :)
[19:17] <mpt> [TOPIC] Critical bugs
[19:17] <MootBot> New Topic:  Critical bugs
[19:17] <mpt> Rinchen is away
[19:17] <mpt> Ursinha, are there any?
[19:17] <matsubara> I'll take care of that one
[19:17] <mpt> (other than the ones you've already mentioned)
[19:18] <matsubara> there's only one not in progress which was re-opened by sinzui
[19:18]  * sinzui show fix that
[19:18] <matsubara> bug 247878
[19:18] <sinzui> s/show/should/
[19:18] <matsubara> sinzui: given your comment there, I guess you're going to take care of it, right? :-)
[19:18] <matsubara> thanks sinzui
[19:19] <sinzui> I'll fix it tonight.
[19:19] <matsubara> great
[19:19] <matsubara> back to you mpt. thanks
[19:19] <sinzui> I'll look to land it tomorrow
[19:19] <mpt> thanks
[19:19] <mpt> [TOPIC] Bug tags
[19:19] <MootBot> New Topic:  Bug tags
[19:19] <mpt> There are no proposed tags.
[19:19] <mpt> [TOPIC] Operations report
[19:19] <MootBot> New Topic:  Operations report
[19:19] <mpt> herb?
[19:20] <herb> Early Saturday (2008-07-19) did a cherry pick of r6726 to lpnet* and the script server.
[19:20] <herb> Yesterday rolled out r6753.
[19:20] <herb> On a couple of occasions in the past week we've had to restart codebrowse because it was unresponsive and using >40% of system RAM.
[19:20] <herb> On a couple of occasions in the past week we've had to restart lpnet processes (3x in prod, 1x in staging) that had died leaving stale PID files. These have been related to the bug filed a few weeks ago, bug 247227.
[19:20] <herb> That's it from the LOSAs unless there are any questions for me.
[19:20] <mpt> Thanks herb
[19:20] <mpt> [TOPIC] DBA report
[19:20] <MootBot> New Topic:  DBA report
[19:20] <stub> Its all been pretty static on the DBA front - no patches, no worries. Yay!
[19:20] <stub> Next stage of replication/read-only-launchpad should be up for review tomorrow. We will need more disk space on chokecherry to test this - it has been previously discussed and an rt ticket raised today in case it got forgotten.
[19:20] <stub> Out timeouts seem relatively good, so thanks everyone who has been opimizing the worst offenders!
[19:20] <stub> Nothing else.
[19:21] <mpt> ok, thank you
[19:21] <mpt> [TOPIC] Sysadmin requests
[19:21] <MootBot> New Topic:  Sysadmin requests
[19:21] <mpt> Was anyone tracking these in Rinchen's absence?
[19:22] <mrevell> Not me. You matsubara?
[19:22] <matsubara> not formally
[19:22] <mpt> Anyone have urgent RTs?
[19:22] <matsubara> but if there're any I can chase those
[19:22] <matsubara> anyone?
[19:22] <stub> I can't find my rt ticket :-(
[19:23] <stub> nm - looks like disk got added when I wasn't looking
[19:23] <mpt> okie dokie
[19:23] <mpt> [TOPIC] New packages required
[19:23] <MootBot> New Topic:  New packages required
[19:23] <mpt> salgado?
[19:24] <salgado> anything for me this week?
[19:24] <salgado> probably not, but anyway
[19:24] <mpt> [TOPIC] New user-affecting issue
[19:24] <MootBot> New Topic:  New user-affecting issue
[19:24] <mpt> None from mrevell this week
[19:25] <mrevell> Hi - sorry, been snowed under with the tour.
[19:25] <mpt> and so we go sprinting onward through the agenda
[19:25] <mpt> [TOPIC] Doc Team report
[19:25] <MootBot> New Topic:  Doc Team report
[19:26] <mpt> mrevell, anything on this this week?
[19:26] <mrevell> Not relaly, I'm afraid.
[19:26] <mrevell> Just full steam ahead for next week.
[19:26] <mpt> okay
[19:27] <mpt> [TOPIC] New MOTU liaison
[19:27] <MootBot> New Topic:  New MOTU liaison
[19:27] <mpt> Is this an old item that wasn't deleted?
[19:27] <mrevell> mpt:  I think it might have been, unless someone else raised it. Sorry, I should have deleted this but was on vacation after it was in the meeting.
[19:27] <mpt> ok, no problem
[19:27] <mpt> [TOPIC] Oopses for unauthorized exceptions
[19:27] <MootBot> New Topic:  Oopses for unauthorized exceptions
[19:27] <mpt> salgado, is this current?
[19:28] <salgado> mpt, it is
[19:28] <salgado> We sometimes present links to pages that the logged in user doesn't have the rights to see.  When users follow them they get the Forbidden page, but we don't record that (as an OOPS) like we do for 404s.  I think we should do that as we probably want to either hide these links or present them in a disabled form
[19:28] <salgado> these would be listed in a separate section of the OOPS report, just like the 404s
[19:28] <flacoste> +1
[19:28] <salgado> matsubara, can we do that?
[19:29] <thumper> +1
[19:29] <mpt> That seems like a good idea
[19:29] <flacoste> that would help debug permission problem as well
[19:29] <salgado> flacoste, exactly
[19:29] <flacoste> like those reported by hobsee
[19:29] <mpt> as long as the page has a referer
[19:29] <abentley> +1 for disabling, preferably with a "why" tooltip.
[19:29] <mpt> So, we've had a discussion a couple of weeks ago about how to present links that you don't have permission to visit
[19:29] <thumper> abentley: "disabled as you aren't l33t enough" :)
[19:30] <mpt> This is a related but separate issue, about finding the problems in the first place.
[19:30] <salgado> right, but that's not what we're discussing here
[19:30] <mpt> finding the problem links in the first place, I mean.
[19:30] <abentley> thumper: But then what will it say for me?
[19:30] <salgado> so, I'll file a bug to generate OOPSes for unauthorized exceptions
[19:30] <matsubara> salgado: yes, we can do that. sorry, got caught up in the phone
[19:30] <mpt> [ACTION] salgado to report a bug on generating oopses for unauthorized exceptions
[19:30] <MootBot> ACTION received:  salgado to report a bug on generating oopses for unauthorized exceptions
[19:31] <salgado> cool
[19:31] <salgado> guess we've finished, then?
[19:31] <mpt> That's about it
[19:31] <mpt> And so, as Launchpad's fluorescent green fades slowly into the cocktail of memory
[19:32] <mpt> It's time to bring this Launchpad developer meeting to a close.
[19:32] <mpt> #endmeeting
[19:32] <MootBot> Meeting finished at 13:34.
[19:32] <mpt> thanks everyone
[19:32] <mrevell> mpt: Nice one Humph. Thanks.
[19:32] <thumper> thanks mpt
[19:32] <flacoste> thanks mpt!
[19:32] <salgado> thanks mpt
[19:32] <matsubara> thanks mpt!
[19:32] <Ursinha> thanks mpt :)
[19:32] <rockstar> mpt, I LIKED the green1  :)
[19:32] <flacoste> so did others
[19:32] <flacoste> green is peaceful :-)
[19:32] <mrevell> that shade of green wasn't peaceful :)
[19:32] <abentley> Yep, me too.  At least there was some vibrancy there.
[19:32] <barry> it's not easy being green
[19:32] <sinzui> Soon we can make a new Launchpad that is even greener
[19:32] <mpt> rockstar, don't tell anyone, but I have a secret plan to bring it back
[19:33] <mpt> It will require a lot of tricky CSS though
[19:33] <abentley> sinzui: With hookers and blackjack?
[19:33] <rockstar> mpt, you're supposed to say that in the other channel!
[19:33] <mpt> ssssshhh
[19:33] <rockstar> +1 hookers and blackjack


[00:14] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (bionic-proposed) [2.02-2ubuntu8.12]
[00:37] -queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.12 => 2.02-2ubuntu8.12] (core)
[00:48] -queuebot:#ubuntu-release- Unapproved: grub2-signed (bionic-proposed/main) [1.93.12 => 1.93.13] (core)
[00:49] -queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.12 => 2.02-2ubuntu8.12] (core)
[01:04] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (bionic-proposed) [2.02-2ubuntu8.12]
[01:04] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (bionic-proposed) [2.02-2ubuntu8.12]
[01:05] -queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (bionic-proposed) [1.93.13]
[05:15] -queuebot:#ubuntu-release- New binary: libgpuarray [s390x] (disco-proposed/universe) [0.7.6-2] (no packageset)
[05:17] -queuebot:#ubuntu-release- New binary: libgpuarray [ppc64el] (disco-proposed/universe) [0.7.6-2] (no packageset)
[05:19] -queuebot:#ubuntu-release- New binary: libgpuarray [amd64] (disco-proposed/universe) [0.7.6-2] (no packageset)
[05:19] -queuebot:#ubuntu-release- New binary: libgpuarray [i386] (disco-proposed/universe) [0.7.6-2] (no packageset)
[05:36] -queuebot:#ubuntu-release- New binary: libgpuarray [arm64] (disco-proposed/universe) [0.7.6-2] (no packageset)
[05:37] -queuebot:#ubuntu-release- New binary: libgpuarray [armhf] (disco-proposed/universe) [0.7.6-2] (no packageset)
[06:13] <vorlon> cyphermox: sorry, I guess I failed to let you know I had accepted the fixed grub2 in bionic-proposed; were you still looking at verification today?
[06:54] <vorlon> cyphermox: if you can get grub2 verified first thing in the morning, I will still release it and (be on call for regressions this weekend)(
[07:03] -queuebot:#ubuntu-release- New: accepted libgpuarray [amd64] (disco-proposed) [0.7.6-2]
[07:03] -queuebot:#ubuntu-release- New: accepted libgpuarray [armhf] (disco-proposed) [0.7.6-2]
[07:03] -queuebot:#ubuntu-release- New: accepted libgpuarray [arm64] (disco-proposed) [0.7.6-2]
[07:03] -queuebot:#ubuntu-release- New: accepted libgpuarray [i386] (disco-proposed) [0.7.6-2]
[07:03] -queuebot:#ubuntu-release- New: accepted libgpuarray [s390x] (disco-proposed) [0.7.6-2]
[07:03] -queuebot:#ubuntu-release- New: accepted libgpuarray [ppc64el] (disco-proposed) [0.7.6-2]
[08:03] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (bionic-proposed/main) [4.18.0-15.16~18.04.1] (kernel)
[08:03] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (cosmic-proposed/main) [4.18.0-15.16] (core, kernel)
[08:04] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (bionic-proposed/main) [4.18.0-15.16~18.04.1] (kernel)
[08:04] -queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (cosmic-proposed/main) [4.18.0-15.16] (core, kernel)
[08:06] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (bionic-proposed) [4.18.0-15.16~18.04.1]
[08:06] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (cosmic-proposed) [4.18.0-15.16]
[08:06] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (bionic-proposed) [4.18.0-15.16~18.04.1]
[08:06] -queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (cosmic-proposed) [4.18.0-15.16]
[08:53] -queuebot:#ubuntu-release- New binary: gcc-9-cross-ports [ppc64el] (disco-proposed/universe) [0ubuntu2] (no packageset)
[10:15] <tjaalton> infinity: just fyi that I'm looking into bug 1815172 which seems a showstopper for MATE, though it was only filed today.. booting the 32bit image seems to fail on my hw too so I'll bisect it if nothing else..
[10:15] <tjaalton> upstream is on it too
[10:24] <apw> tjaalton, try the kernle in -proposed
[10:27] <tjaalton> apw: ok..
[10:28] <apw> tjaalton, i assuem we are talking linux-hwe here ... there is a quick respin in there, which will be going out RSN
[10:28] <tjaalton> apw: actually no.. stock bionic
[10:29] <apw> the bionic one is worth chceking your image is up to date
[10:29] <smb> tjaalton, could that have been the kernel with the DP MST issue which we had a follow-up already?
[10:30] <tjaalton> smb: no that was an issue with external monitors, in this case the xserver just fails with an error from the i965 dri driver
[10:30] <tjaalton> though with the live image it ends up trying to respawn the session, essentially killing it
[10:30] <tjaalton> only mate/lightdm seem affected so far
[10:30] <smb> tjaalton, live image would use the cosmic kernel which has the i915 crash, no?
[10:31] <tjaalton> ok if there's an actual crash then yes
[10:31] <tjaalton> I'll still install it with nomodeset and debug this other issue just in case :)
[10:31] -queuebot:#ubuntu-release- New: rejected gcc-9-cross-ports [ppc64el] (disco-proposed) [0ubuntu2]
[10:32] <tjaalton> the bugreport was with stock kernel
[10:32] <tjaalton> could be I'm not able to reproduce it after all, we'll see
[10:33] <smb> tjaalton, at least one of the reporter had enough info to show that without the revert there is an oops early on. So no inteldrmfb and no X
[10:33] <tjaalton> ah that gen4 thing? this is with kabylake..
[10:33] <tjaalton> so gen9
[10:35] <smb> tjaalton, ah ok... so maybe yet something different. Intel quality
[10:49] <tjaalton> oh well, 64bit mate image works fine on this
[11:40] -queuebot:#ubuntu-release- New binary: gcc-9-cross-ports [ppc64el] (disco-proposed/universe) [0ubuntu3] (no packageset)
[11:58] <tjaalton> and installing 32bit results in a broken grub/efi
[12:25] -queuebot:#ubuntu-release- New binary: gcc-9-cross [ppc64el] (disco-proposed/universe) [0ubuntu2] (no packageset)
[13:37] <cyphermox> vorlon: I did check it very very late last night; I'm going to retest now to be able to write it down in the bugs
[13:37] <cyphermox> tjaalton: what do you mean broken grub/efi on 32bit?
[13:55] <tjaalton> cyphermox: nevermind, fixed already. it's a bad idea to mix efi/legacy installs on the same disk :)
[13:57] <cyphermox> well, on the same install it's supposed to work... so we need to make sure it didn't get broken somehow
[13:59] <tjaalton> it drops to grub shell, until grub-install is run from an efi partition
[14:00] -queuebot:#ubuntu-release- New binary: gcc-9-cross-ports [arm64] (disco-proposed/universe) [0ubuntu3] (no packageset)
[14:12] <oSoMoN> doko, re https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921683 , when are you planning on syncing the new firebird3.0 ?
[14:12] <oSoMoN> this is preventing LO builds
[14:21] -queuebot:#ubuntu-release- New binary: gcc-9-cross [i386] (disco-proposed/universe) [0ubuntu2] (no packageset)
[14:27] <cyphermox> tjaalton: but it's a separate install?
[14:29] <tjaalton> cyphermox: two partitions, one that was installed with efi, the other with legacy booted 32bit image. after the 32bit install grub is confused
[14:35] <cyphermox> ok
[14:43] <doko> oSoMoN: I have nothing to do with that except for filing that bug report. autosyncs are still enabled
[14:43] -queuebot:#ubuntu-release- New: rejected gcc-9-cross-ports [arm64] (disco-proposed) [0ubuntu3]
[14:43] -queuebot:#ubuntu-release- New: rejected gcc-9-cross [i386] (disco-proposed) [0ubuntu2]
[14:43] -queuebot:#ubuntu-release- New: rejected gcc-9-cross-ports [ppc64el] (disco-proposed) [0ubuntu3]
[14:43] -queuebot:#ubuntu-release- New: rejected gcc-9-cross [ppc64el] (disco-proposed) [0ubuntu2]
[14:47] <oSoMoN> doko, right, do you happen to know when we can expect the auto-sync to happen?
[14:49] <cjwatson> $ ssh -t snakefruit sudo -iu ubuntu-archive crontab -l | grep auto-sync
[14:49] <cjwatson> 0 5,11,17,23 * * *      http_proxy=http://squid.internal:3128/ PYTHONPATH=/home/ubuntu-archive/python auto-sync --log-directory ~/public_html/auto-sync --batch
[14:56] <oSoMoN> cjwatson, thanks
[14:57] -queuebot:#ubuntu-release- Unapproved: cockpit (cosmic-backports/universe) [184-1~ubuntu18.10.1 => 187-1~ubuntu18.10.1] (no packageset)
[14:58] -queuebot:#ubuntu-release- Unapproved: cockpit (bionic-backports/universe) [184-1~ubuntu18.04.1 => 187-1~ubuntu18.04.1] (no packageset)
[14:59] -queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (cosmic-backports) [187-1~ubuntu18.10.1]
[14:59] -queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (bionic-backports) [187-1~ubuntu18.04.1]
[15:07] -queuebot:#ubuntu-release- Unapproved: courier-authlib (bionic-proposed/universe) [0.68.0-4build1 => 0.68.0-4ubuntu0.1] (no packageset)
[15:07] -queuebot:#ubuntu-release- Unapproved: libbpp-core (bionic-proposed/universe) [2.4.0-3 => 2.4.0-3ubuntu0.1] (no packageset)
[15:07] -queuebot:#ubuntu-release- Unapproved: libbpp-seq (bionic-proposed/universe) [2.4.0-2 => 2.4.0-2ubuntu0.1] (no packageset)
[15:07] -queuebot:#ubuntu-release- Unapproved: ucommon (bionic-proposed/universe) [7.0.0-12 => 7.0.0-16ubuntu0.1] (no packageset)
[15:07] -queuebot:#ubuntu-release- Unapproved: fswatch (bionic-proposed/universe) [1.11.2+repack-10 => 1.11.2+repack-10ubuntu0.1] (no packageset)
[15:07] -queuebot:#ubuntu-release- Unapproved: libcec (bionic-proposed/universe) [4.0.2+dfsg1-2ubuntu1 => 4.0.2+dfsg1-2ubuntu1.1] (no packageset)
[15:07] -queuebot:#ubuntu-release- Unapproved: libbpp-seq-omics (bionic-proposed/universe) [2.4.0-2 => 2.4.0-2ubuntu0.1] (no packageset)
[15:10] -queuebot:#ubuntu-release- Unapproved: libgda5 (bionic-proposed/universe) [5.2.4-9 => 5.2.4-9ubuntu0.1] (no packageset)
[15:12] -queuebot:#ubuntu-release- Unapproved: rejected courier-authlib [source] (bionic-proposed) [0.68.0-4ubuntu0.1]
[15:12] -queuebot:#ubuntu-release- Unapproved: rejected libbpp-core [source] (bionic-proposed) [2.4.0-3ubuntu0.1]
[15:12] -queuebot:#ubuntu-release- Unapproved: rejected libbpp-seq [source] (bionic-proposed) [2.4.0-2ubuntu0.1]
[15:12] -queuebot:#ubuntu-release- Unapproved: rejected ucommon [source] (bionic-proposed) [7.0.0-16ubuntu0.1]
[15:12] -queuebot:#ubuntu-release- Unapproved: rejected fswatch [source] (bionic-proposed) [1.11.2+repack-10ubuntu0.1]
[15:12] -queuebot:#ubuntu-release- Unapproved: rejected libcec [source] (bionic-proposed) [4.0.2+dfsg1-2ubuntu1.1]
[15:12] -queuebot:#ubuntu-release- Unapproved: rejected libbpp-seq-omics [source] (bionic-proposed) [2.4.0-2ubuntu0.1]
[15:15] -queuebot:#ubuntu-release- Unapproved: accepted libgda5 [source] (bionic-proposed) [5.2.4-9ubuntu0.1]
[15:31] -queuebot:#ubuntu-release- Unapproved: accepted courier-authlib [source] (bionic-proposed) [0.68.0-4ubuntu0.1]
[15:38] <slashd> tjaalton, vorlon or any SRU vanguard : A user is complaining the pci.ids list in pciutils need update (no LP bug created yet). A few device id he is using has been added after xenial. Would it be okay if I SRU an update of pci.ids base on upstream --> https://github.com/pciutils/pciutils/commit/701fdd1e
[15:38] <slashd> in Xenial ^ sorry
[15:39] -queuebot:#ubuntu-release- Unapproved: accepted fswatch [source] (bionic-proposed) [1.11.2+repack-10ubuntu0.1]
[15:44] -queuebot:#ubuntu-release- Unapproved: accepted libbpp-core [source] (bionic-proposed) [2.4.0-3ubuntu0.1]
[15:47] -queuebot:#ubuntu-release- Unapproved: accepted libbpp-seq [source] (bionic-proposed) [2.4.0-2ubuntu0.1]
[15:49] -queuebot:#ubuntu-release- New binary: gcc-9-cross-ports [ppc64el] (disco-proposed/universe) [0ubuntu4] (no packageset)
[15:54] -queuebot:#ubuntu-release- Unapproved: accepted libbpp-seq-omics [source] (bionic-proposed) [2.4.0-2ubuntu0.1]
[15:57] -queuebot:#ubuntu-release- Unapproved: accepted libcec [source] (bionic-proposed) [4.0.2+dfsg1-2ubuntu1.1]
[15:58] <slashd> tjaalton, vorlon : I have filed a bug to document the discussion in the right place : https://launchpad.net/bugs/1815212
[16:06] -queuebot:#ubuntu-release- Unapproved: apt (trusty-proposed/main) [1.0.1ubuntu2.19 => 1.0.1ubuntu2.20] (core)
[16:23] -queuebot:#ubuntu-release- Unapproved: ucommon (bionic-proposed/universe) [7.0.0-12 => 7.0.0-12ubuntu0.1] (no packageset)
[16:24] -queuebot:#ubuntu-release- Unapproved: rejected ucommon [source] (bionic-proposed) [7.0.0-16ubuntu0.1]
[16:25] -queuebot:#ubuntu-release- Unapproved: ucommon (bionic-proposed/universe) [7.0.0-12 => 7.0.0-12ubuntu0.1] (no packageset)
[16:40] -queuebot:#ubuntu-release- Unapproved: rejected ucommon [source] (bionic-proposed) [7.0.0-12ubuntu0.1]
[16:41] -queuebot:#ubuntu-release- Unapproved: accepted ucommon [source] (bionic-proposed) [7.0.0-12ubuntu0.1]
[17:02] <tjaalton> slashd: sorry, i've spent all day on the i915 regression triggered by mesa update
[17:02] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (disco-proposed/main) [4.19.0-13.14] (core, kernel)
[17:02] -queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (disco-proposed/main) [4.19.0-13.14] (core, kernel)
[17:03] <tjaalton> apw, smb, infinity: so, mesa enabled softpin for the intel dri driver, which should work on gen8+ gpu's on kernels 4.5 and up, but there are two patches on 4.20 that would be needed to fix issues when running a 32bit install on those. best to revert the mesa change for 18.04.2 image and pull the kernel commits later (for both 4.15 and 4.18)
[17:04] <tjaalton> it's a oneliner to revert
[17:04] <smb> tjaalton, I am in favour or anything that does not require another "quick" kernel spin
[17:05] <tjaalton> yeah :)
[17:05] -queuebot:#ubuntu-release- New binary: linux-signed [arm64] (disco-proposed/main) [4.19.0-13.14] (core, kernel)
[17:07] <slashd> tjaalton, no problem, if vorlon doesn't answer today, I'll ping sil2100 on Monday
[17:11] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (disco-proposed) [4.19.0-13.14]
[17:12] -queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (disco-proposed) [4.19.0-13.14]
[17:12] -queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (disco-proposed) [4.19.0-13.14]
[17:16] -queuebot:#ubuntu-release- Unapproved: sssd (xenial-proposed/main) [1.13.4-1ubuntu1.12 => 1.13.4-1ubuntu1.13] (kubuntu, ubuntu-desktop, ubuntu-server)
[17:16] -queuebot:#ubuntu-release- New binary: rust-sniffglue [amd64] (disco-proposed/universe) [0.8.2-4] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: rust-sniffglue [i386] (disco-proposed/universe) [0.8.2-4] (no packageset)
[17:54] -queuebot:#ubuntu-release- New: accepted rust-sniffglue [amd64] (disco-proposed) [0.8.2-4]
[17:54] -queuebot:#ubuntu-release- New: accepted rust-sniffglue [i386] (disco-proposed) [0.8.2-4]
[17:56] <infinity> tjaalton: So, I have a new mesa on the way?
[17:58] <tjaalton> infinity: yes, waiting for feedback if it fixes the issue..
[17:59]  * infinity nods.
[18:20] <tjaalton> infinity: I forget, should I include the current-proposed changelog for the new upload?
[18:20] <tjaalton> or does it spam all the bugs
[18:20] <infinity> tjaalton: No!  This should be an upload based on -updates.
[18:21] <infinity> tjaalton: Not based on -proposed.
[18:21] <tjaalton> ah
[18:21] <infinity> tjaalton: This is not a way to sneak in a new upstream. :P
[18:21] <tjaalton> where should I upload that then
[18:21] <tjaalton> proposed has 18.2.8 already
[18:21] <infinity> tjaalton: To the queue.  I'll just delete 18.2.8 and undelete it after this one's verified and promoted.
[18:21] <tjaalton> ok
[18:22] <tjaalton> 18.2.8 fixes regressions too
[18:22] <tjaalton> but anyway
[18:23] <tjaalton> I need a new branch :P
[18:23] <tjaalton> for cosmic I'll base it on the current one
[18:23] <infinity> tjaalton: It may well fix things, but does it have even remotely enough testing for us to just drop it in right before a point release?
[18:24] <tjaalton> dunno, cert folks are off
[18:24] <infinity> Yeah, I'll go with "no" then.
[18:24] <infinity> It can always land a week or three after, and that's fine.
[18:25] <tjaalton> sure
[18:25] <tjaalton> but the same question for cosmic then
[18:25] <tjaalton> full changelog or just this change
[18:25] <infinity> Just this change.  The previous one is already in updates.
[18:26] <tjaalton> so you'll delete 18.2.8 from there as well?
[18:26] <infinity> I'll delete 18.2.8 from proposed, accept 18.2.2+newfix, you verify, I promote, then I undelete 18.2.8.
[18:27] <tjaalton> but surely cosmic could be different?
[18:27] <infinity> Hrm.  Oh, I missed the "cosmic" thing up there.    I think?
[18:28] <tjaalton> so it's mostly about being on par with bionic
[18:28] <infinity> It's been a while since I reviewed that.
[18:29] <infinity>   * intel-whl-aml-cfl-ids.diff: Add missing i965 pci-id's (LP: #1789924)
[18:29] <infinity> Yeah, that was only in bionic.
[18:29] <tjaalton> yeah that one
[18:29] <infinity> Up to you what you do with cosmic, IMO.
[18:30] <tjaalton> I'll slap it on top of 18.2.8
[18:30] <infinity> Either base it on 18.2.8 in proposed, or on 18.2.2 in release, + the PCI ID thing.
[18:30] <infinity> I can adapt to either.
[18:30] <tjaalton> but then, -v"18.2.2" or not?-)
[18:30] <infinity> I have no intention of releasing the cosmis one the same day you upload it, so caution is less important.
[18:30] <tjaalton> right, it can wait
[18:31] <infinity> Oh, right.  Yeah, that would be v18.2.2 indeed.
[18:31] <tjaalton> :)
[18:31] <tjaalton> thanks
[18:32] -queuebot:#ubuntu-release- Unapproved: mesa (cosmic-proposed/main) [18.2.8-0ubuntu0~18.10.1 => 18.2.8-0ubuntu0~18.10.2] (core, xorg)
[18:36] <infinity> tjaalton: bionic-proposed one deleted, you can upload that now.
[18:36] <tjaalton> uploaded
[18:37] -queuebot:#ubuntu-release- Unapproved: mesa (bionic-proposed/main) [18.2.2-0ubuntu1~18.04.1 => 18.2.2-0ubuntu1~18.04.2] (core, xorg)
[18:37] <tjaalton> there
[18:40] <vorlon> slashd: I'm pretty sure we've historically done updates of the pci.ids data in pciutils, yes
[18:40] <vorlon> it might even be called out as an SRU exception?
[18:40] -queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (bionic-proposed) [18.2.2-0ubuntu1~18.04.2]
[18:40] <infinity> It is, I think?  Tim used to do those, not sure who's picked up that ball.
[18:40] <vorlon> slashd: as listed under https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases
[18:41] <slashd> vorlon, infinity tks will start working on it then
[18:41] <infinity> tjaalton: Both accepted.  If you can hunt down some way to verify bionic ASAP, that would be lovely.
[18:41] -queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (cosmic-proposed) [18.2.8-0ubuntu0~18.10.2]
[18:43] <tjaalton> infinity: tomorrow
[18:44] <tjaalton> I mean, it'll get verified tomorrow
[18:51] <slashd> vorlon, I also puzzle what would be the good practice, SRU the pci.ids or leave the user the decision to use update-pciids which does it automatically
[18:52] <infinity> slashd: That second option isn't a great one, for many reasons.
[18:52] <vorlon> slashd: ^^ I concur
[18:52] <slashd> infinity, vorlon I agree but prefered to ask ;) tks again
[18:52] <infinity> slashd: The two that come to mind is (a) it alters a dpkg-managed file in /usr/share and (b) it's an entirely unchecked random download over http.
[18:53] <infinity> In fact, I'm a bit shocked we even ship that script at all, or haven't at least neutered it in some way.
[18:54] <infinity> That's just begging for an injection attack where intentionally-corrupted pci.ids data exploits something goofy in a library that reads it.
[18:55] <slashd> infinity, good point
[18:56] <infinity> If we were to give that as an option, we'd need to alter the script (and things that read that data) to use a second user-writable location in /var, and we'd need upstream to provide a signed/verifiable source we can pull from.
[18:56] <infinity> But I think "stop shipping the script on the PATH" is a saner plan.
[18:57] <slashd> infinity, want me to take benefit of my xenial sru to get rid of it in stable release ?
[18:58] <infinity> slashd: Maybe get some input from someone like mdeslaur or sarnold to see if they think I'm being overly paranoid, but I think having a script on path that downloads random junk over http and slams it in a file in /usr/share that gets read by dozens of other binaries is pretty sketchy.
[18:58] <infinity> slashd: So I'd be +1 on just nuking it.
[18:59] <slashd> infinity, ack will try to have a ACK for security team as well, but sound like a good plan
[18:59] <infinity> slashd: Or moving it to /use/share/doc/pciutils/examples
[19:00] <slashd> infinity, vorlon ok thanks a lot for your help
[19:00] <mdeslaur> oh ew ew ew ew
[19:01] <mdeslaur> yeah, moving it to examples would be a good idea
[19:01] <slashd> mdeslaur, ack tks
[19:03] <infinity> I love when an innocent question leads down a "WTF, why is that a thing" rabbit hole.
[19:03] <infinity> I guess back when we trusted the internet to not be full of big meanie-pantses, it sort of made sense.
[19:04] <infinity> It does, at least, validate header and footer, to make sure the download completed.  It just makes no attempt to validate everything in between for malicious MITM badness. :)
[19:05] <infinity> (For the record, I miss that naive and trusting world a lot)
[19:06] <mdeslaur> I suspect if we went through the MIR process for everything currently in main, a lot of stuff wouldn't pass :)
[19:07] <infinity> mdeslaur: Well, the first step is identifying if we think something has an attack profile that warrants a security audit, and most things don't get that box ticket.
[19:07] <infinity> ticked, even.
[19:07] <infinity> mdeslaur: If we skipped that question and audited EVERYTHING, it would (a) take a few decades, but also (b) probably end in tears.
[19:08] <mdeslaur> If we start with the kernel, we wouldn't need to do any of the other packages ;)
[19:08] <infinity> *snort*
[19:09] <infinity> To be fair, at least from a static-analysis-can-fix-it code quality perspective, cking already kinda does that.
[19:09] <infinity> He's dedicated large portions of his adult life to cleaning up compiler and static analysis warnings in the kernel, with some success.
[19:10] <infinity> So, probably a lot of potential CVEs fixed before anyone found a way to exploit them.
[19:11] <mdeslaur> yeah
[19:11] -queuebot:#ubuntu-release- New binary: gcc-9-cross-ports [arm64] (disco-proposed/universe) [0ubuntu4] (no packageset)
[19:12] <vorlon> cyphermox: cosmic verification coming also?
[19:22] -queuebot:#ubuntu-release- New binary: gcc-9-cross [ppc64el] (disco-proposed/universe) [0ubuntu3] (no packageset)
[19:22] <cyphermox> yup
[19:27] <bdmurray> cjwatson: Your livecd-rootfs upload in the SRU queue for bionic doesn't have a bug reference. Could you add one so the update doesn't get stuck in -proposed?
[19:29] <cjwatson> Oh right.  Will do, not right now.
[19:29] <bdmurray> cjwatson: okay, in the meantime I'll reject it
[19:32] -queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (bionic-proposed) [2.525.17]
[19:34] -queuebot:#ubuntu-release- Unapproved: rejected snapd-glib [source] (cosmic-proposed) [1.45-0ubuntu<IP_ADDRESS>]
[19:58] -queuebot:#ubuntu-release- Unapproved: linux-firmware (cosmic-proposed/main) [1.175.1 => 1.175.2] (core, kernel)
[19:59] -queuebot:#ubuntu-release- Unapproved: python-networkx (bionic-proposed/main) [1.11-1ubuntu2 => 1.11-1ubuntu3] (ubuntu-server)
[20:05] -queuebot:#ubuntu-release- Unapproved: accepted gtk+3.0 [source] (cosmic-proposed) [3.24.4-0ubuntu1]
[20:07] -queuebot:#ubuntu-release- Unapproved: linux-firmware (bionic-proposed/main) [1.173.3 => 1.173.4] (core, kernel)
[20:13] <vorlon> tyhicks: I see initramfs-tools is still stalled in cosmic because it's unreviewable by most of the SRU team.  Did you still want to get apw to review, or should I reject this one and let you do a sourceful reupload?
[20:23] <infinity> Oh.
[20:23] <infinity> I can review that.
[20:24] <infinity> Not sure why it was built in a security PPA originally, though. :P
[20:27] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (cosmic-proposed) [2.37.2+18.10]
[20:33] -queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [sync] (cosmic-proposed) [0.131ubuntu15.1]
[21:14] <tjaalton> infinity: mesa verified on bionic
[21:16] -queuebot:#ubuntu-release- Unapproved: accepted u-boot [source] (cosmic-proposed) [2018.07~rc3+dfsg1-0ubuntu2~18.10.1]
[21:22] <vorlon> cpaelzer: libpam-mount, you appear to have added autopkgtests in SRU but these are still missing in devel
[21:25] -queuebot:#ubuntu-release- Unapproved: accepted chkrootkit [source] (cosmic-proposed) [0.52-2ubuntu<IP_ADDRESS>]
[21:47] <infinity> tjaalton: Excellent.  And 18.2.8 copied back in.
[21:48] <infinity> tjaalton: Oh, but I guess 18.2.8 also needs this patch, same as it did in cosmic.
[21:48] <infinity> s/patch/revert/
[21:48] <infinity> tjaalton: So, one of those would be nice at some point. :)
[21:52] -queuebot:#ubuntu-release- New binary: gcc-9-cross [i386] (disco-proposed/universe) [0ubuntu3] (no packageset)
[21:56] <tjaalton> infinity: should I bump the minor version for that (~18.04.2)
[21:58] <infinity> tjaalton: Given that's how you did cosmic, that seems like the path of least confusion.
[22:01] <tyhicks> infinity: thanks for the initramfs-tools review
[22:01] <tyhicks> infinity: it was built in a security PPA because it needs to go to cosmic-security after it receives SRU testing
[22:07] -queuebot:#ubuntu-release- Unapproved: mesa (bionic-proposed/main) [18.2.8-0ubuntu0~18.04.1 => 18.2.8-0ubuntu0~18.04.2] (core, xorg)
[22:08] -queuebot:#ubuntu-release- Unapproved: partman-efi (cosmic-proposed/main) [71ubuntu4 => 71ubuntu4.1] (core)
[22:09] <vorlon> tyhicks: would fit the workflow better if such things could be built in a public security ppa
[22:11] <tyhicks> vorlon: yes, I'll make sure of that next time
[22:12] <tjaalton> infinity: on the queue now, guess it'll spam that bug once more but so be it
[22:13] <tyhicks> vorlon: there's a lot of backstory here about how I did originally build it in a public security ppa, then had to respin it with a small change, and built it in a different (private) PPA just so that infinity doesn't get pissed at me for burning a version number... so I guess it is fitting that he ended up doing the review :)
[22:15] <vorlon> :)
[22:15] <tjaalton> infinity: there's also the libx11 update with a single cherry-pick
[22:26] <infinity> tyhicks: Eh, the kernel team goes through version numbers like toilet paper, I'm sure it would have been fine for initramfs-tools too. :P
[22:27] <infinity> tyhicks: But yeah, in future, for non-embargoed stuff, ubuntu-security-proposed or canonical-kernel-team would both have been less headache for people who aren't me.
[22:32] <tyhicks> huh, I didn't think about canonical-kernel-team being configured as a security ppa but it obviously is
[22:37] <cjwatson> rejecting my own xenial livecd-rootfs upload for the same reason as bdmurray rejected the bionic one
[22:37] -queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (xenial-proposed) [2.408.43]
[22:44] -queuebot:#ubuntu-release- Unapproved: accepted pkgbinarymangler [source] (bionic-proposed) [<IP_ADDRESS>]
[22:53] -queuebot:#ubuntu-release- New binary: rust-wasm-bindgen-backend [ppc64el] (disco-proposed/universe) [0.2.33-1] (no packageset)
[22:53] -queuebot:#ubuntu-release- New binary: rust-wasm-bindgen-backend [s390x] (disco-proposed/universe) [0.2.33-1] (no packageset)
[22:55] -queuebot:#ubuntu-release- Unapproved: accepted gtk+3.0 [source] (bionic-proposed) [3.22.30-1ubuntu2]
[22:55] -queuebot:#ubuntu-release- New binary: rust-wasm-bindgen-backend [amd64] (disco-proposed/universe) [0.2.33-1] (no packageset)
[22:55] -queuebot:#ubuntu-release- New binary: rust-wasm-bindgen-backend [armhf] (disco-proposed/universe) [0.2.33-1] (no packageset)
[22:55] -queuebot:#ubuntu-release- New binary: rust-wasm-bindgen-backend [arm64] (disco-proposed/universe) [0.2.33-1] (no packageset)
[22:55] -queuebot:#ubuntu-release- New binary: rust-wasm-bindgen-backend [i386] (disco-proposed/universe) [0.2.33-1] (no packageset)
[22:57] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.42 => 2.408.43] (desktop-core)
[22:58] -queuebot:#ubuntu-release- New: accepted rust-wasm-bindgen-backend [amd64] (disco-proposed) [0.2.33-1]
[22:58] -queuebot:#ubuntu-release- New: accepted rust-wasm-bindgen-backend [armhf] (disco-proposed) [0.2.33-1]
[22:58] -queuebot:#ubuntu-release- New: accepted rust-wasm-bindgen-backend [arm64] (disco-proposed) [0.2.33-1]
[22:58] -queuebot:#ubuntu-release- New: accepted rust-wasm-bindgen-backend [i386] (disco-proposed) [0.2.33-1]
[22:58] -queuebot:#ubuntu-release- New: accepted rust-wasm-bindgen-backend [s390x] (disco-proposed) [0.2.33-1]
[22:59] -queuebot:#ubuntu-release- New: accepted rust-wasm-bindgen-backend [ppc64el] (disco-proposed) [0.2.33-1]
[22:59] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.16 => 2.525.17] (desktop-core)
[22:59] <cjwatson> bdmurray: livecd-rootfs reuploaded for xenial and bionic; thanks for catching that
[23:03] -queuebot:#ubuntu-release- Unapproved: accepted busybox [source] (bionic-proposed) [1:1.27.2-2ubuntu3.1]
[23:07] -queuebot:#ubuntu-release- New binary: rust-wasm-bindgen-macro-support [s390x] (disco-proposed/universe) [0.2.33-1] (no packageset)
[23:08] -queuebot:#ubuntu-release- New binary: rust-wasm-bindgen-macro-support [amd64] (disco-proposed/universe) [0.2.33-1] (no packageset)
[23:10] -queuebot:#ubuntu-release- New binary: rust-wasm-bindgen-macro-support [i386] (disco-proposed/universe) [0.2.33-1] (no packageset)
[23:11] -queuebot:#ubuntu-release- New binary: rust-wasm-bindgen-macro-support [arm64] (disco-proposed/universe) [0.2.33-1] (no packageset)
[23:12] -queuebot:#ubuntu-release- New binary: rust-wasm-bindgen-macro-support [armhf] (disco-proposed/universe) [0.2.33-1] (no packageset)
[23:14] -queuebot:#ubuntu-release- New: accepted rust-wasm-bindgen-macro-support [armhf] (disco-proposed) [0.2.33-1]
[23:14] -queuebot:#ubuntu-release- New: accepted rust-wasm-bindgen-macro-support [amd64] (disco-proposed) [0.2.33-1]
[23:14] -queuebot:#ubuntu-release- New: accepted rust-wasm-bindgen-macro-support [i386] (disco-proposed) [0.2.33-1]
[23:14] -queuebot:#ubuntu-release- New: accepted rust-wasm-bindgen-macro-support [arm64] (disco-proposed) [0.2.33-1]
[23:14] -queuebot:#ubuntu-release- New: accepted rust-wasm-bindgen-macro-support [s390x] (disco-proposed) [0.2.33-1]
[23:17] -queuebot:#ubuntu-release- New binary: spatialindex [s390x] (disco-proposed/universe) [1.9.0-1] (no packageset)
[23:17] -queuebot:#ubuntu-release- Unapproved: accepted chkrootkit [source] (bionic-proposed) [0.52-1ubuntu0.1]
[23:20] -queuebot:#ubuntu-release- New binary: spatialindex [ppc64el] (disco-proposed/universe) [1.9.0-1] (no packageset)
[23:26] -queuebot:#ubuntu-release- New binary: spatialindex [amd64] (disco-proposed/universe) [1.9.0-1] (no packageset)
[23:28] -queuebot:#ubuntu-release- New binary: rust-wasm-bindgen-macro [s390x] (disco-proposed/universe) [0.2.33-1] (no packageset)
[23:28] -queuebot:#ubuntu-release- New binary: spatialindex [i386] (disco-proposed/universe) [1.9.0-1] (no packageset)
[23:29] -queuebot:#ubuntu-release- New binary: rust-wasm-bindgen-macro [amd64] (disco-proposed/universe) [0.2.33-1] (no packageset)
[23:33] -queuebot:#ubuntu-release- New binary: rust-wasm-bindgen-macro [i386] (disco-proposed/universe) [0.2.33-1] (no packageset)
[23:39] -queuebot:#ubuntu-release- New binary: gnss-sdr [amd64] (disco-proposed/universe) [0.0.10-3] (no packageset)
[23:55] -queuebot:#ubuntu-release- New binary: gnss-sdr [i386] (disco-proposed/universe) [0.0.10-3] (no packageset)


[08:44] <infinity> pitti: The new udev-udeb has a non-udeb dependency (libacl1).
[08:45] <infinity> pitti: Either need to build it in a way to drop that dep, or we need a libacl-udeb.
[10:21] <infinity> pitti: unping, re: udev/acl.  Uploaded a fix.
[12:07] <chrisccoulson> infinity, chromium finished building on arm overnight \o/
[12:08] <chrisccoulson> (i'll try to run it later)
[12:15] <infinity> chrisccoulson: Oh, that's good news.  I just finished force-hinting the broken stack into raring, so udev/systemd could migrate, but an upload that actually builds would be FAR better. :P
[12:19] <ogra_> chrisccoulson, !
[12:20] <infinity> ogra_: Don't get your hopes up, it still might not run. :P
[12:20] <ogra_> yeah
[12:20] <ogra_> but its at least one step forward
[12:21] <ogra_> i still dont get why though ... given that chromeos/chrome runs just fine so it *must* be possiblle to get it working
[12:21] <infinity> There seems to be some serious left-hand/right-hand lack of communication there.
[12:22] <ogra_> yes
[12:22] <infinity> I don't know if jbailey still works on that, but I should talk to him about WTF is up.
[12:22] <infinity> Though, that mostly just accounts for failures to build (the right/left thing).
[12:22] <infinity> The failures to RUN could be v8 having bugs with armhf register usage, etc.
[12:22] <ogra_> qwell, and there are Keybuk and kees too
[12:22] <infinity> Unless ChromOS is now armhf too?
[12:23] <ogra_> it is
[12:23] <infinity> Ahh, so even fewer excuses now.  Lovely.
[12:23] <ogra_> i'm using their flash plugin in my ubuntu chromium all day here
[12:23] <ogra_> and i can run the whhole chromeos desktop in a window under unity too :)
[12:24] <ogra_> by just firing it up from /opt
[12:25] <ogra_> not that unity would be very useful (doesnt get along with mali drivers to use HW accel it seem ... everything else does though) or that chromeos in a window would
[12:26] <ogra_> but for laughs and testing it is fine :)
[12:50] <jtaylor> slangasek: you m-a'ed tcl recently, will you also do tk for raring?
[12:54] <infinity> jtaylor: That was xnox, actually.
[12:55] <infinity> Or maybe wookey, sponsored by xnox, looking at the changelog.
[12:56] <xnox> that.
[12:56] <xnox> i guess everyone is pieced off about it, so i should multiarch tk & ship compat shell config script.
[12:57] <jtaylor> having tk and tcl in the same state would be good
[12:57] <infinity> There needs to be a compat script?  What broke?
[12:57] <jtaylor> as they are kind of related
[12:57] <jtaylor> just a bad configure check in a science package
[12:57] <xnox> infinity: TkConfig.sh script moved from /usr/lib/ to /usr/lib/$(multiarch)
[12:58] <xnox> (and tcl)
[12:58] <jtaylor> my concern is just if I fixx it for tcl now, do I need to revisit it for tk in a few days?
[12:58] <infinity> Oh.  That's arch-specific? :/
[12:58] <xnox> infinity: but those config scripts can totally be dpkg-architecture & call the right script.
[12:59] <xnox> not to break stuff that expects that config script to be there.
[12:59] <infinity> Yeahp, that would work.
[12:59] <xnox> jtaylor: well, you can totally test for tk m-a, and try that, if not try normal one, and then bail.
[13:00] <jtaylor> thats what the bad configure dos
[13:01] <infinity> I'm not sure there's any value in patching upstream sources to look for the M-A config script at all, if you're going to put the compat one in.
[13:01] <jtaylor> a enormous list of possible locations it checks :)
[13:01] <jtaylor> instead of just doing a try link
[13:01]  * infinity gets the kernels and d-i to migrate and calls it a night.
[13:02] <jtaylor> the simplest fix for thix package is just add --with-tcl-library=/usr/lib/$(DEB_HOST_ARCH)
[13:02] <jtaylor> but do I need to do that for tk too in a few days or not?
[13:02] <infinity> DEB_HOST_MULTIARCH even.
[13:02] <jtaylor> yes
[13:03] <infinity> But if xnox adds the compat scripts, you don't need to change anything.
[13:03] <infinity> And it'll all just work again.
[13:03] <infinity> Which seems like a whole lot less effort. :P
[13:03] <jtaylor> the configure does not sue the script
[13:03] <infinity> Oh.
[13:03] <infinity> It's looking for the .so?
[13:03] <jtaylor> yes
[13:03] <infinity> People who do that should be shot.
[13:04] <infinity> I'd switch to either the config script or a try link and forward it upstream, instead of adding to the brain damage.
[13:05] <jtaylor> the funny thing is they do that too
[13:05] <jtaylor> but only after checking for the so in the hardcoded locations
[13:05] <jtaylor> very weird :)
[13:05] <infinity> So, you could just delete the .so checks?
[13:05] <infinity> Also very valid.
[13:06] <infinity> The only argument for .so checks is if you're dlopening a hardcoded path.  Which is, in itself, wrong.
[13:06] <infinity> At least, it's wrong if the library is on the search path, since this isn't 1975, and dlopen() is smart.
[13:07] <jtaylor> afk 15 min
[13:24] <cjwatson> jtaylor: I'm in the process of multiarching it - was working on it end of last week
[13:24] <jtaylor> k so it will be done, thanks thats all I wanted to know
[13:24] <cjwatson> because it's just madness for one of tcl and tk to be multiarched and the other noe.t
[13:24] <cjwatson> *not
[13:25] <jtaylor> yes I though too
[13:25] <cjwatson> If anyone's really desperate, my current work is http://paste.ubuntu.com/5619256/
[13:25] <cjwatson> But I plan to get that uploaded early next week once I've prepared corresponding tcltk-defaults changes and done some testing with the ruby1.8 build
[17:09] <guest16950> hello
[17:09] <guest16950> question:
[17:09] <guest16950> ubuntu XX.04 usually gets released at the end of april
[17:10] <guest16950> but windows xp support will end at 8th of april 2014 (beginning of april)
[17:10] <guest16950> are you planning to release ubuntu 14.04 prior or on the the 8th of april ;p?
[17:11] <guest16950> probably would be a good move, wouldn't it ;)?
[17:11] <guest16950> just saying
[17:14] <ScottK> guest16950: The release date was set almost half a year ago.  It's a bit late to change it now.
[17:23] <ogra_> ScottK, really ?ho set it ?
[17:23] <ogra_> *who even
[17:23]  * ogra_ wasnt aware we had a 14.04 date
[17:23] <ScottK> ogra_: Oh.  Sorry, I misread his comment.
[17:23] <ogra_> :)
[17:24]  * ScottK was thinking 13.04.
[17:24] <ogra_> yeah, me too first, i had to read twice
[17:26] <ScottK> OTOH, 10.10.10 was so annoying, I'm sure I don't want to release at the start of the month.
[17:27] <ogra_> well, depends what the TB decides ... if there is actually a six month cycle before yeah ...
[17:27] <ogra_> in a rolling model two weeks dont really hurt
[17:32] <guest16950> just imagine how many users still are using windows xp ;)
[17:32] <guest16950> and on the 8th of april 2014 they have to look for a new os
[17:33] <guest16950> because ms won't provide any updates to xp any longer from that date on ;)
[17:33] <guest16950> (according to the current plan)
[17:33] <guest16950> having 14.04 ready until or on that date sounds like a good idea to me ;)
[17:35] <guest16950> btw: i really hope the following bug:
[17:35] <guest16950> https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/578045
[17:35] <guest16950> will be fixed until then ;)
[17:44] <ScottK> ogra_: I hope the discussion at the TB will coalesce around Mark's latest proposal.  It seemed generally reasonable to me.
[17:44] <ogra_> well, i dont know how much rick wants to still push his proposal ... so we'll see
[17:45] <ogra_> but yeah, marks is definitely sensible
[17:52] <slangasek> jtaylor: no, I didn't :)
[17:53] <jtaylor> slangasek: found the "culprit" already
[17:53] <jtaylor> but you are wookey on oftc or?
[18:00] <ScottK> jtaylor: He's vorlon on oftc.
[18:01] <jtaylor> oh
[18:01] <jtaylor> sorry, mixed that up
[18:01] <slangasek> yes, wookey is wookey everywhere
[18:16] <penguin42> it's the only name he has
[18:25] <jcastro> If there's a backport request that deals with a major bug in a package with a fix I need to ping .... ?
[18:25] <jcastro> can someone fill in the blank for me?
[18:27] <ScottK> jcastro: With a package that's already been backported?
[18:27] <jcastro> I don't think it's been backported yet
[18:27] <ScottK> jcastro: It kind of depends on the specifics.
[18:27] <jcastro> https://bugs.launchpad.net/precise-backports/+bug/1095056
[18:27] <jcastro> is the bug in question
[18:28] <jcastro> someone pinged me about it, seems like there's a fix available, I just need to know what the next step is
[18:28] <jcastro> getting people to test the backport?
[18:29] <ScottK> Someone needs to test unhide and unhide.rb with it.
[18:30] <ScottK> If those work, then it can be backported.  Feel free to ping me and I'll do it if no one else is around.  Laney or micahg could too.
[18:30] <jcastro> ok, I'll get the guy to post his findings on the bug
[18:30] <jcastro> thanks!
[18:31] <ScottK> You're welcome.


[04:03] <robert_ancell_> bye all
[04:48]  * Trevinho did it again...  How goes?
[06:23] <seb128> hey didrocks larsu desktopers
[06:23] <didrocks> larsu: still sneezing a little, but near the end, and you?
[06:23] <didrocks> re seb128
[06:23] <larsu> hello seb128! What's up?
[06:23] <larsu> didrocks: started to sneeze yesterday :/
[06:23] <larsu> but doesn't seem *that* bad
[06:24] <seb128> larsu, I need coffee, a bit tired this morning ... what about you, feeling better than yesterday?
[06:24] <larsu> seb128: a little bit better. Had a good night's sleep
[06:24] <larsu> I hope it doesn't get worse over the day
[06:24] <seb128> good
[06:24] <pitti> bonjour tout le monde !
[06:25] <larsu> bonjour pitti!
[06:25] <pitti> ça va seb128 et didrocks ! comment allez-vous ?
[06:25] <didrocks> hey pitti, et toi, comment vas-tu ?
[06:25] <seb128> salut pitti, comment ça va ?  You guys are both in sync :)
[08:03] <didrocks> evening darkxst
[08:03] <larsu> hi Laney, willcooke, darkxst
[08:03] <larsu> what's up
[08:03] <larsu> man I hate icons
[08:03]  * larsu puts another item to the sprint
[08:04] <darkxst> spent the weekend and a bit up in the mountains enjoying the last of the snow, before our first heatwave arrives this weekend ;(
[08:04] <larsu> darkxst: meanwhile, we are enjoying the last rays of sun over here
[08:05] <seb128> hey willcooke Laney darkxst
[08:05] <larsu> as usual, I'm glad launchpad sends me an email when I edit a blueprint
[08:05] <larsu> I had almost forgotten!
[08:09] <Laney> looking like it's going to be a nice day!
[08:11] <larsu> willcooke: BUD?
[08:11] <willcooke> Budapest
[08:12] <willcooke> Snappy sprint
[08:12] <didrocks> finally: http://s-jenkins.ubuntu-ci:8080/job/udtc-trusty-tests/1966/
[08:12] <larsu> willcooke: ah!
[08:12] <didrocks> hum, public url once synced to our jenkins mirror :)
[08:12] <larsu> willcooke: that will be an intersting discussion - will we have a snappy packagekit backend?
[08:12] <didrocks> and done! https://jenkins.qa.ubuntu.com/job/udtc-trusty-tests/1966/
[08:12] <willcooke> larsu, it's rather looking like.... "if we build it we will have"
[08:12] <didrocks> still have to have the distro fixed. /me looks at our python maintainers…
[08:13] <willcooke> larsu, but I will be having a meeting with those guys when they are back from Budapest to work out exactly what the requirements are
[08:13] <willcooke> larsu, right now it looks like we have a couple of options:
[08:13] <willcooke> 1) Add Snappy support to USC
[08:13] <willcooke> 2) Add Snappy, and paid-for-apps etc to G SC
[08:14] <larsu> usc is basically unmaintained, isn't it?
[08:14] <seb128> larsu, I guess I missed the start of the discussion, or is that backlog from yesterday?
[08:14] <seb128> "that will be an intersting discussion"
[08:14]  * seb128 tries to find what "that" is
[08:14] <larsu> seb128: no willcooke just moved and item around on the sprint planning blueprint and I wondered what BUD stands for
[08:14] <seb128> ah ok
[08:15] <darkxst> seb128, Laney ok to upload gsettings-desktop-schemas 3.18, its just one bug fix, on typo fix and lots of translation updates
[08:15] <larsu> (didn't have "cities" in mind, but "business units")
[08:15] <seb128> darkxst, no objection from me if that's what you described
[08:20] <Laney> indeed
[08:20] <Laney> will go to the queue for someone to double check anyway
[08:22] <larsu> Laney: https://code.launchpad.net/~larsu/humanity/eog-fullscreen-toolbar/+merge/272879 and https://code.launchpad.net/~larsu/ubuntu-themes/eog-overlay-buttons/+merge/269482 fix eog's theming
[08:22] <larsu> reviews/landing appreciated ;)
[08:24] <Laney> larsu: who is the person you asked for a review from?
[08:25] <larsu> you
[08:26] <Laney> LIES
[08:26] <larsu> ?
[08:26] <Laney> danrabbit
[08:26] <larsu> Laney: do you have approval chops for icons?
[08:26]  * Laney doesn't understand icon themes really either
[08:27] <Laney> apparently so
[08:27] <darkxst> seb128, Laney k, uploaded
[08:27] <larsu> Laney: ah thanks for the catch. I reassigned
[08:27] <larsu> I had accidentally proposed to merge into lp:humanity
[08:28] <larsu> this whole project is a mess
[08:28] <Laney> anyway, will look shortly
[08:28] <larsu> thanks
[08:28] <seb128> didrocks, could you have a look to https://bugs.launchpad.net/ubuntu/+source/oneconf/+bug/1421884? do you remember if oneconf use the apt cache without taking a lock? (can it take one if it's not root?)
[08:28] <ubot5`> Ubuntu bug 1421884 in oneconf (Ubuntu) "/usr/share/oneconf/oneconf-query:SystemError:/usr/bin/oneconf-query@245:async_update:update:update:compute_local_packagelist:__init__:open" [High,Confirmed]
[08:28] <Laney> did you give the toolbar a background?
[08:29] <Laney> (don't have the new theme on the laptop atm)
[08:29] <Laney> (so can't check right away)
[08:29] <larsu> Laney: yes, that's the 2nd mr I linked
[08:29] <larsu> Laney: actually it's missing that commit, let me push it
[08:29] <willcooke> oh boy - looks like today is fsck day
[08:30] <Laney> haha
[08:30] <larsu> willcooke: no ssd?
[08:30] <Laney> the theme branch is the one we already looked at
[08:31] <larsu> shall I do a new one?
[08:31] <didrocks> seb128: ah, I may not take a lock, let me look at the api
[08:31] <willcooke> larsu, yeah this has got an SSD, but suddenly errors.  This laptop has been telling me it's getting old for a few months now.
[08:31] <seb128> didrocks, thanks
[08:32] <Laney> nah
[08:32] <larsu> ok I'll push then
[08:32] <didrocks> https://apt.alioth.debian.org/python-apt-doc/library/apt.cache.html -> doesn't mention any lock, apart from a lockexception :p
[08:32]  * didrocks continues looking
[08:34] <didrocks> seb128: nothing on the doc about lock if I'm right
[08:34] <didrocks> seb128: it's doing on your behalf supposively
[08:34] <seb128> didrocks, let me comment reply to that email
[08:35] <didrocks>         lockfile = apt_pkg.config.find_dir("Dir::Cache::Archives") + "lock"
[08:35] <didrocks> thanks!
[08:35] <didrocks> it's done for you when you update the archive
[08:35] <didrocks> (which is where it's failing)
[08:35] <didrocks> seb128: wait
[08:35] <didrocks> I found it another class
[08:35]  * seb128 waits
[08:36] <didrocks> let me test that's possible as a user
[08:40] <didrocks> seb128: yeah, if you can ask how we can get a system lock as this is running during user's session…
[08:40] <didrocks> seb128: getting the exception due to this
[08:48] <larsu> what's the "quiet volume down" key?
[08:49] <larsu> u-s-d grabs XF86AudioLowerVolume twice because of it (and confuses unity in the process)
[08:49] <pitti> larsu: the one that doesn't rattle?
[08:49] <larsu> haha
[08:50] <larsu> oh got it: it changes the volume without making those plop sounds
[08:50] <larsu> (which we don't have anyway in unity, do we?)
[08:51] <pitti> larsu: I do get plopps when I press the vol up/down keys
[08:51] <larsu> I don't :/
[08:51]  * ogra_ too and i would be unhappy to not have them
[08:51] <Laney> haha
[08:51]  * Laney strokes ogra_
[08:51] <pitti> *PLOPP*
[08:51] <ogra_> :)
[08:51] <Laney> DON'T CHANGE MY DESKTOP
[08:52] <pitti> if you want quiet, use mouse scroll on the indicator
[08:52] <larsu> ah! I guess this is because of the same race in unity?
[08:52] <Laney> hey what is speech-dispatcher?
[08:52] <larsu> becasue the same key is bound to both actions
[08:52]  * darkxst make xomnad point to gnome-shell, just for Laney ;)
[08:52] <larsu> (volume up and quiet volume up)
[08:53] <Laney> how do you bind quiet volume up?
[08:54] <larsu> you don't
[08:54] <larsu> it's hardcoded
[08:54] <larsu> if you want quit volume up, set org.gnome.settings-daemon.plugins.media-keys volume-up to something other than XF86AudioRaiseVolume
[08:54] <larsu> and the press XF86AudioRaiseVolume
[08:55] <larsu> this is amazong
[08:55] <larsu> zooooong
[08:58] <larsu> Laney: ah, I was wrong: this is when pressing <alt> as well
[08:58] <larsu> (but hardcoded to that)
[08:58] <Laney> oh nice, that's a cool trick
[08:59]  * seb128 doesn't understand what's going on with those keybindings
[09:00] <seb128> not sure I want to though
[09:00] <larsu> Trevinho: are there any other duplicate key grabs? (the volume one turns out to have <alt> modifier)
[09:00] <Laney> I'm happy to let larsu deal with it :)
[09:00] <Laney> and Trevinho
[09:00] <larsu> seb128: what's the problem?
[09:01] <larsu> Laney: biggest issue right now is in unity, indeed
[09:01] <larsu> u-s-d code is convoluted, but seems to do the right thing
[09:01] <seb128> larsu, just trying to understand what you wrote about the double actions on the same key
[09:02] <larsu> seb128: if you ask unity to grab the same key twice, it only sends you a signal for one of those grabs
[09:02] <larsu> which is the bug we're seeing
[09:02] <seb128> can you bind the same key to 2 different actions?
[09:02] <larsu> there was some confusion about u-s-d doing that in normal operation
[09:02] <larsu> seb128: no
[09:02] <seb128> the u-c-c ui doesn't let me
[09:02] <seb128> k, what I though
[09:03] <seb128> so how did you end up there?
[09:03] <larsu> the problem happens when u-s-d restarts after a crash
[09:03] <larsu> it ask unity to grab the same keys again
[09:03] <larsu> and unity sends signals about the old grab
[09:03] <seb128> shouldn't unity ungrab the first one if asked for an already assigned one?
[09:03] <larsu> so u-s-d doesn't see them and does ... nothing
[09:03] <larsu> seb128: yes. that's the bug
[09:03] <seb128> also didrocks said in his case there was no u-s-d crash or restart
[09:04] <larsu> seb128: also it should ungrab anything that someone who just crashed had grabbed before
[09:04] <seb128> darkxst, do you know if anyone is working on bug #1432098? it's ranked high on e.u.c issues
[09:04] <ubot5`> bug 1418771 in gjs (Ubuntu) "duplicate for #1432098 gjs-console assert failure: *** Error in `/usr/bin/gjs-console': free(): invalid next size (fast): 0x00007f74a804b240 ***" [Low,Confirmed] https://launchpad.net/bugs/1418771
[09:04] <larsu> seb128: I'm hoping he's wrong on that. If he isn't, I'll need a dbus log of his session's startup
[09:05] <larsu> seb128: I spent quite some time trying to reprocduce
[09:05] <seb128> k
[09:05] <seb128> maybe u-s-d restarts for some reasons
[09:05] <didrocks> (and I told it multiple times :p)
[09:05]  * larsu changes location. bbiab
[09:05] <didrocks> so no, no crash, can restart for some reason
[09:05] <didrocks> but clearly no crash
[09:06] <seb128> let's fix the restart issue and see if that resolves it
[09:06] <larsu> didrocks: if that happens, Trevinho's fix will solve this issue for you
[09:06] <didrocks> yeah
[09:06] <didrocks> but still would be great to have a 100% understanding of the issue
[09:10] <seb128> didrocks, I guess having a bustle log of your login when getting the issue would help
[09:11] <didrocks> yep, how to get this already?
[09:11] <didrocks> the upstart ted's post?
[09:11] <seb128> right
[09:11] <seb128> didrocks, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800501#22 btw
[09:11] <ubot5`> Debian bug 800501 in python-apt "SystemError on missing files in /var/lib/apt/lists" [Normal,Open]
[09:12] <didrocks> seb128: thanks, so nothing I can do for now on the apt thing
[09:12] <didrocks> seb128: ok, will add that and relog later
[09:12] <seb128> right
[09:13] <seb128> didrocks, I reported bug #1323586 as well but that got wontfixed and should be handled in oneconf (or declared a buggy system)
[09:13] <ubot5`> bug 1323586 in oneconf (Ubuntu) "oneconf crashes if one apt list file is unreadable" [High,Confirmed] https://launchpad.net/bugs/1323586
[09:13] <seb128> I think that one is less common
[09:15] <didrocks> seb128: hum, yeah… I don't think that client should have to deal with it, but I'm happy to just ignore it
[09:15] <seb128> I think it's best
[09:15] <seb128> one user just commented saying it currently apport prompts every hour
[09:15] <didrocks> seb128: note that we need the lock fix first, and the crash is at the same place
[09:15] <seb128> so probably better to just catch it
[09:15] <didrocks> well, he decided to put into that state and knows that he did it
[09:16] <seb128> yeah, but I guess some people don't realize they added a file which is not world readable
[09:16] <seb128> like they copy from another disk with different uid or something
[09:16] <didrocks> seb128: can be… anyway, let's get the lock fix in, then, I can handle that one propertly
[09:16] <didrocks> properly*
[09:16] <seb128> or a backup from a vfat drive
[09:16] <seb128> right
[09:16] <didrocks> and I'll just catch this exception
[09:16] <seb128> thanks ;-)
[09:16] <didrocks> yw
[09:17] <didrocks> keep me posted if you are subscribed on the python-apt thingy
[09:17] <seb128> yeah, I reported those so I can do that
[09:17] <didrocks> thanks!
[09:18] <seb128> yw!
[09:24] <seb128> pitti, let me know when you are around and have a minute to discuss the recent apport changes
[09:44] <pitti> seb128: I'm on-and-off ; what's the issue?
[09:44] <pitti> seb128: apart from the dkms hook crash in bug 1500450
[09:44] <ubot5`> bug 1500450 in apport (Ubuntu) "/usr/share/apport/package_hook:FileExistsError:/usr/share/apport/package_hook@64:make_report_file" [High,Triaged] https://launchpad.net/bugs/1500450
[09:44] <seb128> pitti, you dropped make_file_path from apport.utils
[09:44] <pitti> seb128: ah
[09:45] <seb128> is that wanted?
[09:45] <seb128> wasn't there a way to keep it and make it at least write some warning?
[09:46] <pitti> seb128: ish; we need to fix all hooks for the recent security issue, so /usr/share/apport/package-hooks/dkms_packages.py needs to be adjusted too
[09:46] <seb128> pitti, I just uploaded a fix for bug #1499842 but I guess we need to do security update with that change as well?
[09:46] <ubot5`> bug 1499842 in dkms (Ubuntu) "dkms_packages.py crashed with AttributeError in __main__: 'module' object has no attribute 'make_report_path'" [High,Fix committed] https://launchpad.net/bugs/1499842
[09:46] <pitti> seb128: we can keep the old interface, but we'd then hide the vuln
[09:46] <pitti> seb128: oh, you already did? thanks!
[09:46] <seb128> pitti, k, it would have been nice to mention the api change in the changelog
[09:46] <seb128> it puzzled me a bit
[09:47] <seb128> pitti, I just did for wily, I guess we want to do that for other series but it should be done through -security since that's where apport went?
[09:47] <seb128> mdeslaur, ^
[09:47] <seb128> pitti, yw!
[09:47] <pitti> seb128: yes, I agree; that, or we need to put the old insecure API back
[09:47] <pitti> but as we need to upload the other hook users anyway, we might just as well use the new API
[09:48] <seb128> right
[09:48] <seb128> or replace it by a function that raise a error explaining the issue
[09:48] <seb128> like "is replaced by ... because of ..."
[09:49] <seb128> pitti, anyway, I handled dkms for wily and
[09:49] <seb128> it seems it was the only hook using that function
[09:49] <pitti> seb128: ah great -- I was about to ask to check other hooks
[09:49] <seb128> :-)
[09:50] <seb128> pitti, thanks for the reply
[09:52] <pitti> seb128: I'll release the current packages in -proposed to "clear the way"
[09:52] <seb128> pitti, danke
[10:03] <seb128> darkxst, could be worth raising with robert_ancell but https://errors.ubuntu.com/problem/27941445d596fb71be692b9008c0847d2ce6c428 (xorg abort issue) is ranked high on e.u.c for wily and the recent report all look like gdm ones
[10:12] <seb128> bug #1499508 seems similar
[10:12] <ubot5`> bug 1499508 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT in OsAbort()" [Undecided,New] https://launchpad.net/bugs/1499508
[10:12] <seb128> https://launchpadlibrarian.net/218756042/XorgLogOld.txt has
[10:12] <seb128> "(EE) Cannot establish any listening sockets - Make sure an X server isn't already running(EE) "
[10:45] <Laney> seb128: do you have a vcs version of your eds upload?
[10:47] <seb128> Laney, let me check
[10:47] <Laney> otherwise i can commit the diff
[10:50] <seb128> Laney, I don't understand, the 1ubuntu1 version from the archive has different content from the vcs
[10:51] <seb128> -#ifeq ($(DEB_HOST_ARCH_OS),linux)
[10:51] <seb128> -#      DEB_CONFIGURE_EXTRA_FLAGS += --with-phonenumber=/usr
[10:51] <seb128> -#endif
[10:51] <seb128> in the rules
[10:51] <seb128> and some .symbols difference
[10:52] <seb128> Laney, I forgot that eds was in a vcs so I don't have a stacked/ready to push change but I'm happy to fix it, unsure what to do with those divergences though?
[10:57] <seb128> Laney, if you do an upload can you include https://git.gnome.org/browse/evolution-data-server/commit/modules/ubuntu-online-accounts/e-signon-session-password.c?h=gnome-3-18&id=1765be5703f4e129ecc5c821dbffac4e18d26e68 ? (I can also commit to the vcs once it's sorted out)
[10:59] <Laney> I probably forgot to bzr bd -S again after merging some more stuff in from Debian
[10:59] <Laney> those changes make sense
[11:02] <seb128> so I let them in the vcs, commit 0ubuntu2 different from the archive and you build a 0ubuntu3 that includes them and reconsiliate archive and vcs?
[11:02] <Laney> ya
[11:03] <Laney> I would mention them in the changelog of ubuntu3
[11:04] <mdeslaur> seb128, pitti: I'll take care of the dkms update
[11:04] <seb128> mdeslaur, thanks, I did the wily one
[11:06] <seb128> Laney, ok, you can pull
[11:07] <Laney> thx
[11:08] <seb128> yw, sorry for forgetting the vcs in the previous upload
[11:16]  * larsu goes for lunch
[11:19] <seb128> Trevinho, andyrock, if any of you look at ups/menu things could you add bug #1501289 to your list as well while you are at it?
[11:19] <ubot5`> bug 1501289 in unity (Ubuntu) "unity-panel-service "Source ID was not found when attempting to remove it" warnings" [Undecided,New] https://launchpad.net/bugs/1501289
[11:22] <pitti> mdeslaur: thanks; sorry, not much time this week on the sprint
[11:26] <seb128> mdeslaur, pitti, there seems to be some regressions from the apport update btw, e.g bug #1500450
[11:26] <ubot5`> bug 1500450 in apport (Ubuntu) "/usr/share/apport/package_hook:FileExistsError:/usr/share/apport/package_hook@64:make_report_file" [High,Triaged] https://launchpad.net/bugs/1500450
[11:31] <pitti> yes, I'll handle this
[11:31] <Trevinho> seb128: mh, oh... Is that UPS? :o
[11:31] <seb128> Trevinho, yes
[11:32]  * Trevinho just up... Long night hacking again :P
[11:32] <Trevinho> that's weird, I mean couldn't be an indicator?
[11:34] <Trevinho> larsu: have you seen the branch I proposed?
[11:35] <Trevinho> although it crashes on CI, while testing (nothing should be related to the keys)... seb128 is there any way to get a core file from ci on jenkins?
[11:36] <didrocks> pitti: I would be really greatful if you get bored during one of the meetings if you can have a look at the jayatana vivid SRU (it's a one line change and the issue got quite some press yesterday…)
[11:37] <Trevinho> larsu: it should also address the issue you were saying this morning, but let's see :)
[11:38] <pitti> didrocks: sorry, I can't -- I misspelled jajatana like three times now :)
[11:39] <didrocks> pitti: ahah yeahatana :p
[11:39] <seb128> Trevinho, unsure core on jenkins, maybe jibel can help you?
[11:39] <Laney> don't those machines report to whoopsie?
[11:39] <seb128> or what team maintains those?
[11:39]  * Laney thought they did
[11:39] <Laney> but maybe not
[11:39] <pitti> didrocks: fait
[11:40] <Laney> accompli
[11:40] <didrocks> pitti: merci !
[11:40] <seb128> lunch, bbiab
[11:40] <didrocks> enjoy seb128
[11:41] <Trevinho> Laney: I'm not sure as they'd also report issues that are only on a proposed branch, wouldn't that be distracting?
[11:42] <Laney> maybe it's a different set of machines which does that
[11:42] <Laney> probably best to ask whoever runs the machines :P
[11:46] <Trevinho> I've no idea who... fginther is the process owner, I'll ask him when back.
[11:49] <jibel> seb128, Trevinho jenkins just attach any file the test gives it in a location defined in the job. I don't know these jobs but they must be configured to export the core or crash from the testing environment to a predefined location that jenkins has access to. fginther can surely help with that
[11:50] <Trevinho> jibel: ok thanks
[12:06] <qengho> good morning.
[12:11] <willcooke> hey qengho
[12:35] <larsu> Trevinho: no I haven't seen it (not subscribed to unity)
[12:40] <Laney> larsu: am I missing a fix for the fullscreen button?
[12:40] <Laney> "Leave fullscreen"
[12:40] <Laney> it has a black border on the lfeft
[12:41] <Laney> oh I think it's transparent
[12:41] <Laney> ah is it a separate button from the toolbar?
[12:50] <Trevinho> larsu: it's on https://code.launchpad.net/~3v1n0/unity/gnome-keygrabber-refactor, I'm trying to understand why the CI crashes, but it works fine here. Adding support for only sending the signal to who has requested it makes it a little more complicated, but should work
[12:56] <larsu> Trevinho: hm okay, I'll have a look
[13:12] <andyrock> good morning
[13:12] <larsu> hi andyrock
[13:17] <seb128> hey andyrock
[13:28] <seb128> pitti, thanks for fixing the apport issue, but I'm not sure to understand, does it means the new apport can't write crash file when one is existing?
[13:28] <seb128> or in which case do those trigger?
[13:34] <desrt> good morning #ubuntu-desktop
[13:35] <seb128> hey desrt
[13:35] <seb128> how are you today?
[13:35] <desrt> good
[13:35] <desrt> last day at the sprint
[13:35] <desrt> more file monitor fixing today, i think :)
[13:36] <seb128> good :-)
[13:37] <willcooke> hey desrt andyrock
[13:37] <desrt> hello willcooke
[13:39] <larsu> morning desrt!
[13:42] <desrt> hihi
[14:00] <pitti> seb128: right; that's what the main apport does for unseen crashes; we don't have this fine-grained logic right now for package failures
[14:00] <pitti> seb128: we probably need to refine that, like remove an old report if it was seen already
[14:01] <seb128> pitti, is there a reason we need to make an user visible error out in those cases?
[14:01] <larsu> Trevinho: cool, works for me :)
[14:01] <pitti> seb128: sorry, WDYM?
[14:01] <seb128> right, I was going to say, what is cleaning old reports and making room for new ones?
[14:01] <pitti> seb128: normally the daily cron job
[14:03] <seb128> pitti, sorry I think I misread your change, I was expection some .warning, I though what you did would stop trigger apport prompt
[14:03] <seb128> but I guess it just make apport exit?
[14:05] <pitti> seb128: yes, the fix in trunk will now just log an error, and don't produce a "follow up apport crash:
[14:05] <pitti> "
[14:05] <seb128> k, sounds good
[14:05] <seb128> pitti, thanks
[14:07] <seb128> attente, hey, could you have a look to bug #1494331? or to talk to happyaron about it
[14:07] <ubot5`> bug 1494331 in unity-settings-daemon (Ubuntu) "fcitx can't use extra trigger key to activate" [Undecided,New] https://launchpad.net/bugs/1494331
[14:07] <seb128> there is a suggested change (not using fcitx_input_method_activate)
[14:10] <attente> seb128: sure
[14:10] <seb128> attente, thanks
[14:11] <Trevinho> larsu: cool, sorry I was otp :)
[14:11] <Trevinho> larsu: it should allow also multiple sources to grab a key, but it's released once the last left...
[14:11] <larsu> right
[14:12] <Trevinho> larsu: also if you call Ungrab with gdbus you're not allowed to do that...
[14:12] <larsu> Trevinho: right, because only the grabber can ungrab
[14:12] <larsu> man, this interface is bad
[14:12] <larsu> (not sure if I mentioned that before :D )
[14:13] <Trevinho> yep
[14:13] <Trevinho> larsu: yeah, you didn't but it was quite obiouvs
[14:13] <larsu> hehe
[14:14] <Trevinho> I only need to have better names for variables (/me is so bad on that)
[14:14] <larsu> naming things *is* one of the biggest challanges
[14:16] <Trevinho> sometimes I'd like to be like vala....
[14:16] <Trevinho> tmp1, tmp2...
[14:16] <Trevinho> :D
[14:20] <seb128> mdeslaur, you might want to include changes similar to http://bazaar.launchpad.net/~apport-hackers/apport/trunk/revision/3013 to the dkms change
[14:21] <mdeslaur> seb128: hrm, ok, thanks
[14:21] <seb128> mdeslaur, yw! bonus point if you would do wily as well? ;-)
[14:22] <mdeslaur> seb128: grr :)
[14:22] <mdeslaur> sure, I'll do wily
[14:22]  * seb128 is going to pay back with fixing some other GNOME bug when he can
[14:22] <seb128> mdeslaur, 'ci
[14:43] <Laney> larsu: did you see my questions about the button?
[14:44] <larsu> Laney: no?
[14:44] <larsu> where?
[14:44] <Laney> 14:40
[14:44] <larsu> oh, it scrolled off screen and I only saw Trevinho's ping sorry
[14:45] <larsu> Laney: I think you're missing it, yes
[14:45] <Laney> which bit?
[14:45] <Laney> the toolbar has the right background now
[14:45] <Laney> icons are the right size
[14:45] <larsu> should be in the menubar branch of eog
[14:46]  * larsu checks
[14:47] <larsu> Laney: ah no sorry, it's here: https://code.launchpad.net/~larsu/eog/fullscreen-button
[14:48] <Laney> neat
[14:56] <Laney> the first two pictures in my ~/Pictures make me angry
[14:56] <Laney> screenshots of the destruction of loads of big old trees done by the council to build a new tram line
[14:56] <Laney> less eog testing
[14:56] <larsu> test with /usr/share/backgrounds
[14:57] <larsu> that's what I did because the first pic in ~/Pictures was my profile picture
[14:57]  * larsu was tired of seeing his own face all the time
[15:03] <Laney> https://launchpadlibrarian.net/208152879/me-64.jpg
[15:03] <larsu> ya
[15:05] <Laney> seb128: did you find out what's going on with the theme?
[15:05] <Laney> can we just slip this eog branch in before the dual landing maybe?
[15:05] <larsu> but the one I have here is 960²
[15:07] <seb128> Laney, the landing you mean?
[15:07] <Laney> ye
[15:07] <seb128> no, pete was not online yesterday, but I added the eog bugfix branch to the silo
[15:07] <Laney> can't upload it if it a dual though
[15:08] <seb128> upload where?
[15:08] <Laney> ubuntu?
[15:08] <seb128> I don't understand
[15:08] <seb128> you can publish the silo
[15:08] <Laney> which part?
[15:08] <seb128> which is equivalent to an upload?
[15:08] <Laney> you think I should upload to the stable phone overlay?
[15:09] <seb128> no, I think you should add mps that we want to land to the silo
[15:09] <seb128> and we should publish then
[15:09] <seb128> those eog changes are noop for the phone
[15:09] <seb128> no reason they refuse them in the vivid overlay
[15:09] <seb128> dual landing is fine
[15:09] <Laney> but the actual change they want in is waiting for QA there
[15:09] <Laney> so if you upload you bypass that
[15:10] <seb128> right, but I guess icon changes are easy to get QA verified
[15:10] <seb128> we can ping jibel if needed, I'm sure he can help us to get that reviewed this week
[15:10] <Laney> if you want
[15:11] <Laney> I don't really see the need for us to ask for something to be sped up when we can just upload the thing we want to wil
[15:11] <Laney> y
[15:11] <seb128> because if we do that we screw their silo
[15:11] <seb128> and then need to reconfigure it to be single landing
[15:11] <seb128> they*
[15:11] <Laney> why is that?
[15:12] <seb128> because upload is going to be rejected if it already exist in the archive
[15:12] <seb128> well maybe the CI handle that
[15:12] <Laney> rebuild, don't see how it is screwed
[15:12] <seb128> but feels like hackish to me to just land the thing
[15:12] <seb128> or easier
[15:12] <seb128> that needs to land in both series anyway
[15:12] <seb128> it feels like we are one button press away
[15:13] <seb128> and dput + rebuild silo is more work that it's worth
[15:13] <seb128> let me ask on the other ci-eng channel since pete is not there
[15:16] <seb128> kenvandine, hey, com.Gwibber.Service is not a thing anymore, right?
[15:16] <kenvandine> nope
[15:16] <kenvandine> been dead for a long time
[15:16] <seb128> like it's deprecated and no other replacement took over the service?
[15:16] <seb128> k
[15:16] <seb128> thanks
[15:16] <kenvandine> np
[15:16] <seb128> s-c still has code to try to use it
[15:16] <seb128> going to clean that out
[15:36] <mzanetti> ChrisTownsend, hey, last friday I tried to get legacy apps running in unity8 but I failed. how is the status of that? should it work?
[15:37] <mzanetti> on my laptop that is, not pocket-desktop
[15:37] <ChrisTownsend> mzanetti: It works fairly well.  What did you do and what was the failure?
[15:38] <mzanetti> ChrisTownsend, I was struggling to create a libertine container... only type chroot would succeed, lxc failed to start.
[15:38] <mzanetti> then I managed to install something in the chroot container but failed to start...
[15:38] <ChrisTownsend> mzanetti: On Wily or Vivid?
[15:38] <mzanetti> vivid + overlay
[15:39] <mzanetti> so the same as the pocket-desktop channel intheory
[15:39] <ChrisTownsend> mzanetti: It's probably easiest to run create_bespoke_container and install libertine-demo.
[15:40] <mzanetti> aha!
[15:40] <ChrisTownsend> mzanetti: I've had to ignore lxc for a bit to get the chroot stuff working, so it may be broken.
[15:41] <mzanetti> I don't really mind which container I'm using tbh... as long as it allows me to test if things work correctly in unity8 with legacy apps
[15:41] <mzanetti> particular things I wanted to test is window titles etc
[15:41] <mzanetti> so if you say chroot is fine, works for me
[15:41] <ChrisTownsend> mzanetti: Ok, create_bespoke_container will make the chroot, install Compiz in it along 5 apps.
[15:41] <mzanetti> where do I get that command from?
[15:41] <mzanetti> ah... from the demo
[15:41] <mzanetti> have it
[15:42] <ChrisTownsend> mzanetti: Right
[15:42] <mzanetti> cool, will try. thanks a lot!
[15:42] <ChrisTownsend> mzanetti: Sure, lemme know if you still have issues.
[15:42] <seb128> Laney, thanks for the u-s-d review
[15:42] <mzanetti> yep, I will
[15:42] <Laney> np, thx for the commit
[15:49] <seb128> grrr, can't build s-c on my wily machine
[15:51] <seb128>    dh_auto_build
[15:51] <seb128> 	python setup.py build --force
[15:51] <seb128> Failed to connect to Mir: Failed to connect to server socket: No such file or directory
[15:51] <seb128> why is it trying to connect to mir?!
[15:52] <seb128> k, dpkg-buildpackage doesn't have the issue, only debuild
[15:52] <seb128> I guess some env problem there
[15:56] <Laney> that's what it says when there's no DISPLAY
[15:59] <seb128> I guess fakeroot or something clean the env
[15:59] <Laney> still, it must be possible to build it on the builders so that's weird
[16:00] <seb128> yeah, dunno...
[16:00] <seb128> kenvandine, https://code.launchpad.net/~seb128/software-center/dont_use_gwibber/+merge/272941 if you fancy reviewing that one
[16:01] <didrocks> time for some rest, have a good evening guys
[16:01] <seb128> didrocks, have fun
[16:01] <didrocks> seb128: thanks, you too (and not too much tennis tonight :p)
[16:02] <seb128> dobey, mvo_, hey, asking in case but did one of you ever looked at those warnings
[16:02] <seb128>   File "/usr/share/software-center/softwarecenter/backend/reviews/__init__.py", line 377, in _dump_bsddbm_for_unity
[16:02] <seb128>     0600)
[16:02] <seb128> DBInvalidArgError: (22, 'Argument invalide -- BDB0054 illegal flag combination specified to DB_ENV->open')
[16:02] <seb128> just asking before spending some time on that
[16:15] <dobey> seb128: wasn't aware of any, so no i haven't. i didn't even know it was using a db
[16:16] <dobey> seb128: that removing gwibber branch looks ok to me. you've already uploaded a distropatch for it?
[16:36] <seb128> dobey, not yet, was going to wait for a review and I want to look at the db bug
[16:37] <seb128> but time for sport now so that's going to be for tomorrow
[16:37] <seb128> nice evening everyone
[16:37] <seb128> dobey, thanks for the review
[16:37] <dobey> have a good evening seb128
[16:44] <davmor2> Hey guys just noticed something odd if you open and close nautilus it never shows in the dash but it randomises the apps list on unity7 wily
[16:44] <Trevinho> :o
[16:58] <willcooke> dinner time, g'night all
[17:01]  * Laney gone too
[17:01] <Laney> climbing -> fun fair -> GBBO
[18:52] <qengho> Whoa! Click on a date in calendar in panel. 100% CPU on evolution-calen, unity-panel-ser, indicator-datet, and 20% for dbus.  Niiiice. I updated this morning, but haven't rebooted.
[19:51] <robert_ancell> hi all


 But I think I lack a root password. How do I make a root password?
[01:28] <krytarik> You don't.
[01:28] <krytarik> !root
[01:30] <weboh> that is just great, but if I can't make a root password; I can't use mysql. thank you
[01:31] <oerheks> 1st account created is that root administrator, so use 'sudo <command>'
[09:57] <BluesKaj> Hey folks
[11:18] <john85> hey :)
[11:19] <BluesKaj> hey john85
[11:19] <john85> hows u?
[11:19] <BluesKaj> fine here, and you?
[11:19] <john85> good thanks
[11:20] <BluesKaj> we don't use textspeak on irc support channels, it's discouraged
[11:21] <hay207> Hi guys, is there a program that detects network disconnections accurately?
[11:22] <john85> are you reffering to my use of "u"?
[11:23] <BluesKaj> hay207, you  can check in /var/log/syslog, but I'm not sure what you mean
[11:23] <BluesKaj> john85, yes
[11:23] <john85> soz
[11:24] <john85> couldnt resist..sorry
[11:24] <hay207> for ex, sometimes my net disconnects while playing a game, and no notification appears
[11:25] <BluesKaj> heh, dunno what soz means anyway
[11:26] <john85> soz = sorry, could be one I just made up though
[11:27] <BluesKaj> hay207, sometimes it's the server that disconnects ...happens to my wife on LOTRO quite often, but mostly it's the server's fault
[11:28] <hay207> No, if server dc'ed, all players get dc'ed
[11:29] <hay207> It's only me who's network disconnects
[11:30] <BluesKaj> are you sure ?
[11:30] <hay207> Yes
[11:31] <BluesKaj> then the logs should show what happebed
[11:31] <BluesKaj> happened
[11:32] <BluesKaj> scuse my phat phinger spelling
[11:33] <hay207> :)
[11:33] <hay207> Ok, i will monitor the logs then
[11:41] <john85> is there a way of aligning widgets on desktop without having to do it by eye?
[11:43] <hateball> manually editing your plasma config I guess
[11:47] <john85> sounds complicated
[11:48] <BluesKaj> john85, enable  desktop grid in system settings>desktop behaviour>desktop effects
[11:51] <john85> cant see it BluesKaj
[11:53] <BluesKaj> it's under window management in the path I posted
[12:02] <john85> if appears to be enabled
[12:02] <john85> it*
[12:03] <john85> i will have a play with it tonight when I have a bit more time
[12:03] <john85> got to go
[16:24] <Angus> hello
[16:25] <Angus> good morning!!!
[16:26] <BluesKaj> hi Angus
[16:27] <Angus> How are you BluesKaj?
[16:28] <BluesKaj> I'm fine thanks, Angus, and how are you?
[16:32] <Angus> I'm fine, thanks.
[16:35] <Angus> BluesKaj, I'm interested in learning about free software! do you can help me?
[16:39] <Angus> I'm actually investigating!! and I'm new in the space! BluesKaj
[16:46] <BluesKaj> https://en.wikipedia.org/wiki/Free_and_open-source_software
[16:54] <Angus> thanks BluesKaj!! I will read, any questions do you can helpe me?
[16:55] <BluesKaj> Angus, click here #kubuntu-offtopic
[18:07] <cipa> hi
[18:08] <cipa> i can't decide between kubuntu and kde neon... maybe you have some pro-advice or sth
[18:10] <BluesKaj> cipa, I found Kubuntu to be more stable than neon
[18:12] <cipa> that's something that matters to me
[18:15] <BluesKaj> cipa, depends a lot on your HW and drivers of course ...you should try both on live media, then decide
[18:18] <BluesKaj> BBL..errands