[00:08] <micahg> stokachu: not as much as I used to be, but if somethings needed, I can try to squeeze it in
[00:08] <stokachu> micahg: is there someone who took up that task?
[00:27] <micahg> stokachu: I think the 3 of us who are "active" do it as we have time
[04:09] <stevengottlieb> i have a question regarding my software update for 12.10
[04:09] <stevengottlieb> hello?
[04:36] <stokachu> can i get https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=gpoint approved?
[04:57] <mlankhorst> gday
[05:04] <RAOF> maaaaaaaate
[05:17] <mlankhorst> no!
[06:30] <pitti_> Good morning
[06:34] <zyga> good morning
[06:48] <mardy> kaleo: hi! I was asked to check if the SDK team had any opinion about this: https://lists.ubuntu.com/archives/ubuntu-devel/2013-March/036935.html
[06:54] <apachelogger> cjwatson: hey, if you get a chance today it would be cool if you could have a look at https://code.launchpad.net/~kubuntu-members/debian-cd/kubuntu-raring-artwork/+merge/157998
[07:06] <tjaalton> @pilot on
[07:06] <udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
[07:07] <tjaalton> pilot in
[07:07] <tjaalton> bah
[07:07] <tjaalton> @pilot in
[07:10] <dholbach> good morning
[08:19] <cjwatson> apachelogger: you definitely want to switch to HIDDEN_TIMEOUT=2 (i.e. the same desktop image boot workflow that Ubuntu uses)?  I don't object, just wanted to double-check that
[08:19] <cjwatson> apachelogger: that's also a UI-freeze-worthy change - are there any relevant docs?
[08:28] <apachelogger> cjwatson: yes on the hidden timeout, see bug 1164854 for freeze exception
[08:30] <cjwatson> gotcha, thanks
[08:33] <cjwatson> apachelogger: it'll probably take LP a while to notice, but it's merged and deployed now, thanks
[08:33] <apachelogger> cjwatson: thank you :)
[08:51] <ev> bdmurray, pitti: have you heard many reports of reporting to Launchpad still being enabled post-release in 12.10?
[08:51] <ev> trying to find the right google terms for that :)
[08:51] <pitti> ev: no, I didn't; that might happen for people who manually re-enable it?
[08:51] <ev> very doubtful in this case - a designer in the office has it enabled on 12.10
[08:52] <ev> I'll see what else I can find
[08:52] <seb128> ev, maybe they played with the control center privacy settings (does that change apport's status?)?
[08:53] <ev> seb128: that only toggles whoopsie running
[08:53] <seb128> ok
[08:53] <seb128> apport is enabled in the /etc config ?
[08:53] <ev> maybe they've pulled in some 13.04 bits
[08:53] <ev> yeah
[08:53] <ev> in /etc/default/apport
[08:54] <seb128> ok, weird
[08:54] <seb128> dunno either then
[08:54] <seb128> ev, is it possible that they reported a bug, got asked for details and copied/pasted the command from the stock reply that tell them the command to enable apport?
[08:59] <ev> seb128, pitti: she doesn't appear to have enabled it herself or taken instruction from anyone else to do so. She's also not running anything from raring as far as she's aware. It sounds like a fairly stock system.
[08:59] <ev> I've asked to have a look at her computer again later today
[09:00] <ev> I'll see what I can dig up then
[09:00] <seb128> ok
[09:00] <pitti> ev: the precise contents of /e/d/apport would be interesting; perhaps it was modified years ago already
[09:00] <seb128> look at when the /etc file got edited and the packages installed around this time in dpkg.log maybe
[09:00] <ev> will do to both :)
[09:37] <mpt> ev, remarkable how that most common error in R is much more common in weekdays than weekends ... pre-release, I would have expected the opposite.
[09:37] <ev> :D
[09:37] <ev> I'm always encouraged when it challenges our preconceptions
[09:38] <lifeless> mpt:, ev: o/
[09:38] <ev> hi!
[09:38] <mpt> o/`
[09:45] <maxb> I've been using R for my office workstation for weeks, I just have a dual boot to Q on standby in case it all goes horribly wrong
[09:52] <mpt> ev, if we were tracking hangs by now, I get the feeling we'd be seeing a lot in update-manager
[09:53] <seb128> right
[09:54] <seb128> the computation to sort depends from an app under the app icon seems to be quite slow
[10:00] <doko> seb128, what about allowing the deprecated glib functions for the final release of 13.04 again? would save a lot of effort to fix the ftbfs now
[10:01] <seb128> Laney, pitti: ^ opinions?
[10:02] <seb128> doko, do you have specific deprecations you would like to comment/drop?
[10:02] <seb128> we can't just turn any deprecations off
[10:02] <doko> meh :-/
[10:02] <pitti> FTBFS because of packages which disable deprecated symbols, but use them?
[10:02] <seb128> pitti, yes
[10:02] <seb128> in universe
[10:03] <seb128> doko, how many of those are left?
[10:03] <seb128> should be easy enough to drop the G_DISABLE_DEPRECATED flags, but I'm not sure how many sources we are talking about there
[10:03] <pitti> I don't like changing glib itself to not mark them as deprecated, because that would be a lie
[10:03] <seb128> same here
[10:03] <doko> I didn't count, but it's every third or fourth package I'm touching
[10:03] <doko> at least the g*'s
[10:03] <seb128> how many are left on the ftbfs list?
[10:03] <doko> 520
[10:04] <seb128> hum
[10:04] <seb128> crazy
[10:04] <pitti> for "dead" software we'll keep having this problem, so at some point we need to fix (or remove) those anyway
[10:04] <seb128> right
[10:05] <seb128> I would rather trying a bit harder to "clean" those and not change glib
[10:05] <pitti> so maybe we can find some five people and a day to go through them and drop G_DISABLE_DEPRECATED
[10:05] <seb128> I can help having a look through the list and fix some
[10:05] <pitti> or remove the software if it's not even working any more, etc.
[10:06] <Laney> right, I agree
[10:06] <seb128> doko, pitti: let me try to build a list of affected sources from the build logs
[10:06] <seb128> then we can try to call for help dealing with those
[10:06] <Laney> maybe someone from +1 would help out
[10:06] <Laney> also mail the motu list
[10:06] <seb128> the 5 a days would work for me
[10:06] <pitti> ack
[10:06] <seb128> ok, let's do that
[10:06] <pitti> I can help out there, too; it should be possible to get through some 20 FTBFSes on one day
[10:09] <seb128> doko, do you know why > q on that list only failed on armhf? most of those build issues don't seem armhf specific
[10:09] <doko> seb128, see https://launchpad.net/builders
[10:10] <seb128> doko, ok, other arches didn't get to those yet
[10:10] <doko> yes :-/
[10:25] <pitti> doko: http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20130329-raring.html is still the current one, right?
[10:29] <seb128> doko, Laney, pitti: ftbfs i386 due to glib deprecations: http://paste.ubuntu.com/5694973/
[10:29] <seb128> well those are the ones that match "grep "is deprecated " *.txt | grep glib"
[10:29] <seb128> in the 229 i386 ftbfses
[10:29] <seb128> doing the same for other arches
[10:29] <pitti> seb128: ah, I was looking at some 20 packages, and so far I didn't find a single one; many are due to missing -lm, or breakage which is specific to that pacakge
[10:29] <seb128> right
[10:30] <seb128> same here
[10:30] <seb128> pitti, I did some hackish, grep on the .html, wget of the logs and "grep "is deprecated " *.txt | grep glib" on the stack of lgos
[10:30] <seb128> logs
[10:30] <pitti> seb128: I'll just take the first 20?
[10:31] <seb128> pitti, if you want, please
[10:31] <pitti> seb128: for NM tests I'm kind of blocked on reaching Dan Williams anyway, and I'm not feeling too awake today anyway
[10:31] <pitti> so this seems like the perfect job for a day with just half a brain :)
[10:31]  * seb128 hugs pitti
[10:32]  * seb128 runs the loop of wget on the ~400 armhf build issues
[10:37] <ogra_`> 400 ?
[10:38] <ogra_`> where do you see these ?
[10:38] <ogra_`> the fstbfs list doesnt have as many
[10:38] <seb128> ogra_`, http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20130329-raring.html
[10:39] <seb128> ogra_`, universe is over 500
[10:39] <ogra_`> geez
[10:39] <ogra_`> there werent as many last week !
[10:39] <seb128> ogra_`, build was not done, there is still 3 days of build backlog on i386/amd64
[10:40] <ogra_`> yeah, who cares for these obsolete arches
[10:40] <seb128> lol
[10:41] <seb128> Laney, pitti, doko: that's the end of the list (using armhf): http://paste.ubuntu.com/5695016/
[10:41] <seb128> total is 59 glib related ftbfses
[10:41] <pitti> seb128: would you mind putting them into an etherpad?
[10:42] <pitti> easier for coordination
[10:42] <ogra_`> would be really nice if the ftbfs UI could filter builds that only fail on one arch
[10:42] <seb128> Laney, pitti: http://pad.ubuntu.com/glib-deprecated-ftbfs
[10:42] <seb128> that's the full list
[10:43] <Laney> thanks
[10:43] <Laney> i'll take some this afternoon
[10:44] <pitti> seb128: ^5s
[10:44] <seb128> thanks
[10:44] <seb128> pitti, ^5s ;-)
[10:46] <seb128> $ grep "try adding it to the linker command line" *.txt | sed 's#buildlog_ubuntu-raring-armhf.##' | sed 's#_FAILEDTOBUILD.*##' | sort | uniq  | wc -l
[10:46] <seb128> 113
[10:46] <seb128>
[10:46] <pitti> that's mostly -lm?
[10:46] <seb128> so twice as many due to missing -l
[10:47] <seb128> pitti, 40 due to libm
[10:48] <seb128> pitti, I've added the "missing -lm" to the bottom of the pad
[10:48] <seb128> http://paste.ubuntu.com/5695026/
[10:48] <seb128> rather
[10:48] <seb128> let's not mix stuff
[10:51] <pitti> seb128: you seem to have some false positives there; easyspice is due to -lm, not due to glib
[10:52] <pitti> as we have them in your last paste, I'll just drop it from the pad
[10:52] <seb128> pitti, ups
[10:53] <mpt> seb128, thanks for the hint, I reported bug 1167277 about it
[10:54] <pitti> seb128: and e. g. ecore also only has those as warnings, not failures
[10:54] <pitti> seb128: (it fails due to 'PRIO_PROCESS' undeclared, which I can't find anywhere)
[10:54] <seb128> pitti, Laney: ok, list down to 11 ...
[10:54] <pitti> ah, nice
[10:54] <seb128> pitti, sorry, I matched warnings only before
[10:55] <seb128> those have "error: ... is deprecated ... glib..."
[10:55] <pitti> ok, so for 11 FTBFSes we shouldn't change glib, but just fix them
[10:55] <pitti> I'm fine to do those this afternoon
[10:55] <seb128> pitti, thanks
[10:55] <seb128> doko, ^ doesn't help you much though :-(
[10:56] <Laney> how come doko thought there were loads due to that then?
[10:56] <pitti> seb128: is that the first block on the pad now?
[10:56] <seb128> Laney, he crossed a few while doing fixes
[10:56] <Laney> just seeing warnings due to glib which failed for some other reason
[10:56] <mpt> ev, end of an era -- the list of bugs in Errors no longer fits one on page of a default Launchpad listing
[10:56] <seb128> pitti, yes
[10:56]  * mpt wonders if we can persuade wgrant to increase the default batch size from 75 to 100
[10:56] <pitti> seb128: did you see buzztard and cutter-testing-framework in your updated grep?
[10:56] <pitti> seb128: these were due to glib (I just uploaded fixes for those two)
[10:57] <geser> seb128: instead of greping the .html file, you can also grep the .csv file (but it only lists one log if a package fails on several archs) (http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20130329-raring.csv)
[10:57] <seb128> pitti, hum, no, the error is no "deprecated" but "unknow type" ... will add that to my grep, one min
[10:58] <pitti> seb128: I'll just take your first block then
[10:58] <seb128> buzztard_0.6.0-1
[10:58] <seb128> cutter-testing-framework_1.1.7-1.2ubuntu1
[10:58] <seb128> gnome-pie_0.5.4-1build1
[10:58] <seb128> thoggen_0.7.1-1ubuntu1
[10:58] <seb128>
[10:59] <seb128> pitti, those are the only 4 in that case
[10:59] <pitti> ok, added those
[10:59] <seb128> pitti, danke
[11:00] <seb128> geser, thanks, I just used the file to have the list of logs to wget, that worked ... maybe next time ;-)
[11:00] <doko> pitti, language packs did arrive :-/
[11:01] <pitti> yeah, at some point we'll need an update; but they should build on i386 in about an hour, it's just updates
[11:02] <seb128> doko, those 5 had dpkg errors, you might want to retry them
[11:02] <seb128> arpack++_2.3-2
[11:02] <seb128> cairo-clock_0.3.4-2ubuntu2
[11:02] <seb128> haskell-regex-tdfa_1.1.8-2build2
[11:02] <seb128> krename_4.0.9-1build1
[11:02] <seb128> ncap_1.9.2-1build1
[11:03] <Laney> hmm, that's a release version of regex-tdfa
[11:03] <Laney> there's a newer version in proposed - did the rebuild not take that into account?
[11:03] <Laney> (not that I'm saying this version is fixed)
[11:06] <doko> Laney, no, rebuild is for the release pocket only. not interested in test rebuilds in things which we don't release. and not everything stays that long in -proposed like haskell ;p
[11:07] <seb128> Laney, could you look at the tomboy one? it seems something with the libappindicator sharp bindings, likely a libappindicator issue but you probably know better how the "find the dll" stuff works
[11:07] <zyga> barry: ping
[11:07] <Laney> seb128: yes - can you update the pad?
[11:08] <Laney> doko: well, we certainly intend to release everything in proposed ...
[11:08] <seb128> Laney, done
[11:08]  * zyga found a python3 bug?
[11:08] <ev> mpt: we can fix that :)
[11:10] <zyga> or python3/python2 bugs
[11:10] <zyga> wft
[11:12] <doko> zyga, ?
[11:13] <zyga> doko: eh, sorry, nothing
[11:13] <zyga> doko: I thought I found a python3 metaclass inhertiance regression
[11:13] <zyga> doko: but it was my fault for using type(...) vs type.__new__(mcls, ...)
[11:14] <zyga> doko: just quickly tested that on precise/raring and it works
[11:31] <ev> apw: I found the problem with getting kernel oops reports on https://errors.ubuntu.com. Fixing now.
[11:35] <Laney> seb128: I think that the problem is that libappindicator0.1-cil-dev is an arch:all package but has pkgconfig files in a multiarch directory
[11:35] <seb128> Laney, oh
[11:36] <apw> ev, nice thanks
[11:36] <Laney> ie packaging bug
[11:36] <seb128> Laney, thanks for investigating ;-)
[11:36] <Laney> should be easy to fix
[11:36] <seb128> Laney, let's make the binary arch any then?
[11:37] <cjwatson> is it architecture-dependent in any other way?  if not, better to move the .pc file to /usr/share/pkgconfig/
[11:37] <Laney> That would be weird because the library is arch:all
[11:37] <Laney> I'll move the pkgconfig file
[11:38] <seb128> that makes sense
[13:02] <barry> zyga: hi.  problem all sorted out?
[13:04] <zyga> barry: yes, my bad: type(...) != type.__new__()
[13:04] <zyga> barry: subclass did not seem to inherit metaclass
[13:04] <barry> zyga: ah.  fun stuff. :)
[13:05] <zyga> barry: not pythonic :)
[13:05] <zyga> barry: well, I learn every day
[13:08] <barry> zyga: if you ain't learnin' you ain't livin'! :)
[13:09] <zyga> barry: is that because type.__new__() somehow super-calls __new__ again while type() does not?
[13:14] <barry> zyga: well, hard to know exactly what's going on without looking at your code, but suffice to say, these are tricky corners of the language
[13:15] <zyga> barry: I have a few line example
[13:15] <barry> zyga: pastebin!
[13:16] <zyga> barry: https://gist.github.com/zyga/5354531
[13:17] <zyga> barry: basically, look at that, if you replace type.__new__() with type() - it fails
[13:31] <barry> zyga: py3 docs on __new__: http://docs.python.org/3/reference/datamodel.html?highlight=__new__#object.__new__
[13:31] <barry> but this makes sense, because three-arg type() is a constructor
[13:31]  * barry ->reboots
[14:04] <seb128> @pilot in
[14:09] <pitti> seb128: bah, I fixed two causes of FTBFS in thoggen, and now I see that it doesn't build against our current (i. e. already years old) hal, and against our current dbus
[14:09] <pitti> last build was in jaunty
[14:10] <pitti> at some point we must drop hal stuff anyway, so I'm really inclined to just remove that package; objections?
[14:10] <seb128> pitti, hal is on the ftbfs list btw ;-)
[14:10] <seb128> pitti, no objection from me
[14:11] <pitti> ah, it got removed from testing, too
[14:11] <xnox> pitti: do not remove hal !!!!
[14:11] <pitti> we should have removed it about 3 years ago, but some ancient and dead software still depends on it
[14:11] <mdeslaur> pitti: flash needs it
[14:11]  * xnox still wants Amazon Pay-to-view to work in US and Google Play Movies work in US/UK/other? and Adobe Flash DRM to work as well.
[14:12] <pitti> xnox: but for now I only want to remove thoggen
[14:12]  * mdeslaur misunderstood
[14:12]  * pitti congratulates xnox as our new hal maintainer :)
[14:12] <mdeslaur> xnox: congrats! :)
[14:13] <pitti> seriously, this stuff uses hal!?
[14:13] <pitti> does that even work still these days?
[14:13] <xnox> pitti: i'm on vacation today, so don't take me too seriously =)))))
[14:13] <mdeslaur> pitti: i think it uses hal to get the hard disk serial number for drm
[14:14] <xnox> pitti: yes, all of that $drm-crap works on top of flash which depends on hal.
[14:14] <pitti> flash certainly doesn't pull in hal
[14:14] <xnox> hmmm....
[14:14] <mdeslaur> pitti: it doesn't fail if hal isn't installed, but it disabled drm
[14:16] <tjaalton> slangasek: so, fixing lightdm isn't that easy after all, since plymouth-splash could be stopped already before lightdm is about to start (able to hit that here)
[14:17] <tjaalton> slangasek: and adding 'and (stopped plymouth or started plymouth-splash)' means the transition isn't as smooth anymore
[14:20] <pitti> doko: could you please retry gnome-pie on ARM? This error ("unknown type name 'GCancellab'
[14:20] <pitti> doko: ...) doesn't make any sense
[14:21] <pitti> sun rays/RAM corruption/etc ?
[14:21] <pitti> it builds fine on amd64, and "GCancellab" doesn't appear any where in the code
[14:21] <doko> pitti, done
[14:21] <pitti> thanks
[14:22] <pitti> doko: that's it then, all the rest of glib-induced failures uploaded
[14:22] <pitti> (and got accepted)
[14:22] <pitti> seb128: ^ FYI
[14:23] <seb128> pitti, danke
[14:23] <seb128> doko, pitti, I've fixed some of the -lm issues, will try to do some every day
[14:24] <doko> seb128, thanks!
[14:24] <seb128> yw ;-)
[14:25] <doko> tried to revert that one in binutils, but that seems to be tangled with other uploads, maybe glibc
[14:25] <seb128> doko, specifically libm or linking being pickier?
[14:27] <doko> seb128, there are other libs too, but libm and libpthread are the ones which are seen many times. there were some libgmodule-2.0 (or such) too
[14:29] <bdmurray> ev: no, but I haven't looked
[14:35]  * dholbach hugs seb128
[14:35]  * seb128 hugs dholbach back
[14:39] <slangasek> tjaalton: hmm, ok
[14:41] <Quintasan> ...
[14:42] <Quintasan> why on earth I can't login into cups admin panel with my username and password when I am in the lpadmin group?
[14:54] <ogra_> doko, looking at the ants buioldlog it seems to think it hits an ICE, do you think it makes sense to give it back at least once ?
[14:55] <doko> Please submit a full bug report,
[14:55] <doko> with preprocessed source if appropriate.
[14:55] <doko> See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.
[14:55] <doko> The bug is not reproducible, so it is likely a hardware or OS problem.
[14:55] <doko> it even tells you =)
[14:55] <ogra_> i know that it tells me :P
[14:56]  * ogra_ was there during that reading class back then :P
[14:56] <ogra_> doko, i'll do a local build later then to collect that
[14:57] <doko> ogra_, wait until the build finishes ...
[14:58] <ogra_> oh there is a build running ?
[14:58] <ogra_> i wish the ftbfs UI would reflect that
[14:58] <ogra_> bah, 2min old :P
[15:02] <ogra_> doko, bino looks like a rebuild candidate too (bus error while unpacking deps)
[15:02] <ogra_> doko, err, sorry that was brise
[15:03] <ogra_> (wrong row)
[15:03] <doko> given back
[15:35] <dholbach> can somebody moderate my mail on u-d-a?
[15:37] <cjwatson> dholbach: done
[15:37] <dholbach> thanks cjwatson
[15:52] <menace> are there dbg-packages for nautilus in ubuntu precise?
[15:53] <menace> if yes: in which package? there is no nautilus-dbg
[15:55] <Sarvatt> menace: https://wiki.ubuntu.com/DebuggingProgramCrash debug symbol section on there, its nautilus-dbgsym
[15:57] <seb128> @pilot out
[15:58] <seb128> menace, nautilus-dbgsym like for any other binary, you just need to enable the ddeb source
[15:58] <seb128> or Sarvatt already replied
[16:14] <menace> 1
[16:15] <Laney> 2
[16:15] <menace> sry, kvm-switch...
[16:15] <menace> :D
[16:28] <jim00234> hi
[16:32] <Laney> apachelogger: are your kdiff3 and im-config patches forwarded?
[17:41] <tjaalton> @pilot out
[18:16] <zyga> hi
[18:16] <zyga> I just got locked out of my laptop
[18:16] <zyga> raring desktop, I updated / rebooted
[18:16] <zyga> secure boot blocked my system
[18:16] <zyga> cjwatson: ^^ ?
[18:17] <zyga> I disabled secure boot, I'm now in 3.8.0-17
[18:23] <zyga> I've updated to <IP_ADDRESS>.33
[18:23] <zyga> let's see
[18:26] <zyga> same
[18:26] <zyga> hmm
[18:26] <zyga> pitti: do you know who would be the best person to debug this?
[18:37] <infinity> slangasek: Can you remind me where the Debian bug for that WUR issue was?  I lost context somewhere in the last few days.
[18:45] <slangasek> infinity: what's 'WUR'?
[18:45] <infinity> slangasek: warn-unused-result
[18:47] <infinity> slangasek: I thought it was a samba bug, but can't find it, and now I can't find context for our conversation either, leading me to wonder if I've gone (more) insane.
[18:48] <infinity> Oh, hah.  But the last "git show" in my bash history is for 7e66ee5142deda977163d0a858c3d2883cae3f07 which happens to be the commit with the liberal application of __wur.
[18:48] <slangasek> infinity: ah right - I think it was on cifs-utils?
[18:48] <infinity> So, I don't have the bug tracker context, but I have the code.
[18:49] <infinity> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701422
[18:49] <infinity> slangasek: That's it, thanks.
[18:57] <mlankhorst> slangasek: runlevel is set to 2 from telinit, can plymouth-stop run because of stopped rc RUNLEVEL=2, before rc RUNLEVEL=2 is started?
[18:58] <slangasek> mlankhorst: I'm confused by the question. Are you asking whether a 'stopped rc RUNLEVEL=2' event would be seen before a 'started rc RUNLEVEL=2' event would be emitted?
[18:58] <mlankhorst> yeah
[18:58] <slangasek> it cannot
[19:01] <mlankhorst> meh something weird is happening though
[19:28] <tjaalton> I can't get --verbose work with upstart on raring
[19:28] <tjaalton> initctl log-priority still shows info
[19:29] <tjaalton> after adding the option to cmdline
[19:30] <stokachu> could i get someone to approve nominations for bug 1069570
[19:40] <slangasek> tjaalton: the kernel commandline?
[19:40] <slangasek> tjaalton: it definitely WFM
[19:47] <tjaalton> slangasek: yeah, not here :)
[19:48] <slangasek> tjaalton: ah, in fact 'initctl log-priority' shows the same for me, but I'm definitely /getting/ logging
[19:49] <tjaalton> where does it log?
[19:50] <tjaalton> upstart cookbook says 'grep init: /var/log/syslog' but nothing there
[19:55] <slangasek> tjaalton: it logs to dmesg, effectively
[19:56] <slangasek> tjaalton: and there's a bug in recent releases that I haven't pinned down which prevents this from finding its way into syslog
[19:56] <slangasek> (presumably a kernel or rsyslog bug)
[19:57] <tjaalton> slangasek: ahh, yeah dmesg has them
[20:47] <zyga_> hi
[20:47] <zyga_> I need help figuring out why my raring system stopped booting in secure mode
[20:47] <zyga_> anyone interested?
[20:48] <slangasek> zyga_: "secure mode" meaning UEFI Secure Boot, or something else?
[20:48] <zyga_> slangasek: yes
[20:48] <zyga_> sorry
[20:48] <zyga_> a bit hectic over here (real life problems piling up, almost contained now)
[20:49] <slangasek> zyga_: where does it break down?  Can you still boot older kernels?
[20:49] <zyga_> slangasek: I was on 3.8.0-5, rebooted to -17 failed to boot in secure boot mode
[20:49] <zyga_> slangasek: I tried they all seem to have failed
[20:49] <slangasek> hmm
[20:49] <zyga_> I could not access grub easily though
[20:49] <zyga_> I can now reinstall -5 and other kernels (I have a local mirror with --no-cleanup)
[20:49] <zyga_> and retest anyway you like
[20:50] <zyga_> this is a lenovo g580 system
[20:50] <zyga_> it never had secure boot issues before
[20:50] <zyga_> it works since december last year
[20:50] <slangasek> how do you mean, "could not access grub easily"?  there's the problem that holding shift doesn't work to display the grub menu, but you should still get the grub menu after any failed boot
[20:50] <zyga_> slangasek: I didn't get either
[20:50] <zyga_> slangasek: I managed to get into normal boot and edit /etc/default/grub enough to access the menu
[20:51] <slangasek> well, there was an upload of grub2 just yesterday
[20:51] <slangasek> it's possible something regressed as a result of the rebuild :/
[20:51] <zyga_> slangasek: would it affect secure boot or are those unrelated?
[20:52] <slangasek> zyga_: well grub is the bootloader, so it's relevant to secure boot
[20:52] <zyga_> slangasek: ok, I can install -17 (current) and -16 only
[20:52] <zyga_> right
[20:52] <zyga_> silly me
[20:52] <zyga_> sorry
[20:53] <zyga_> I thought we used a shim
[20:53] <slangasek> that's the first stage bootloader only
[20:53] <slangasek> (and hasn't been changed)
[20:53] <zyga_> isn't that what is actually signed?
[20:53] <zyga_> ok
[20:53] <zyga_> I'm not sure if my messages were from bios, shim or grub though
[20:53] <zyga_> what would you advise checking?
[20:54] <slangasek> can you try downgrading to grub-efi-amd64-signed 1.11+2.00-12ubuntu1 and grub-efi-amd64 2.00-13ubuntu2 ?
[20:54] <zyga_> let's see if I have it already
[20:54] <slangasek> what messages?
[20:54] <zyga_> yes, I have that
[20:54] <zyga_> slangasek: failed secure boot messages
[20:55] <slangasek> well, if you can quote me the message I can probably tell you where it's from ;)
[20:55] <zyga_> I'd have to reboot, I'll write it down the next time
[20:56] <zyga_> slangasek: ok, let me install those packages
[20:57] <zyga_> slangasek: can I just dpkg -i the relevant debs?
[20:57] <slangasek> zyga_: yes; if you do it that way, you'll need to include the matching grub-efi-amd64-bin and grub2-common packages
[20:57] <zyga_> ok
[20:58] <zyga_> can I do it via apt somehow?
[20:59] <slangasek> zyga_: IFF those versions are still in your cache
[20:59] <slangasek> (your apt cache, not the physical cache on disk)
[20:59] <zyga_> slangasek: I have that in my mirror
[20:59] <zyga_> but it's probably not in Packages
[20:59] <zyga_> anyway
[20:59] <zyga_> let's do it manually
[20:59] <slangasek> anyway, it's probably not worth figuring out how to do it with apt, you might as well just dpkg -i the 4 packages
[20:59] <zyga_> right
[20:59] <zyga_> there are also -bin packages
[20:59] <zyga_> should I get them/
[21:02] <slangasek> zyga_: grub-efi-amd64-bin, grub-efi-amd64, grub-efi-amd64-signed, grub2-common, grub-common - AFAICS that's what you need
[21:02] <zyga_> ok, let me try
[21:02] <slangasek> (I overlooked grub-common the first time, sorry)
[21:02]  * zyga_ tries to munge that into shell
[21:04] <zyga_> $ sudo dpkg -i grub2/grub-common_2.00-13ubuntu2_amd64.deb grub2/grub2-common_2.00-13ubuntu2_amd64.deb grub2-signed/grub-ef
[21:04] <zyga_> i-amd64-signed_1.11+2.00-12ubuntu1_amd64.deb grub2/grub-efi-amd64_2.00-13ubuntu2_amd64.deb grub2/grub-efi-amd64-bin_2.00-13ubuntu2_amd64.deb
[21:05] <zyga_> trying
[21:05] <zyga_> ok, installed
[21:05]  * zyga_ *had* to install mirror just to get this recovery option ;)
[21:05] <zyga_> slangasek: shall I reboot and re-enable secure boot now?
[21:05] <slangasek> zyga_: that's the thing to try
[21:05] <zyga_> ok
[21:06] <zyga_> brb
[21:10] <zyga> slangasek: it failed the same way, I took a photo
[21:10] <zyga> slangasek: let me share it
[21:11] <zyga> slangasek: https://plus.google.com/116315264177593873442/posts/9UUGFQ2cphM
[21:12] <slangasek> zyga: mmm.  Do you have the shim and shim-signed packages installed?
[21:12] <slangasek> zyga: (the answer is that these messages are from firmware)
[21:14] <zyga> yes
[21:14] <doko> stgraber, python-cffi is the new way to write python bindings
[21:14] <zyga> oh
[21:14] <zyga> no
[21:14] <zyga> I don't?
[21:14] <zyga> I have shim-signed
[21:14] <zyga> slangasek: I don't have shim
[21:14] <slangasek> zyga: ok, that should be sufficient
[21:15] <zyga> slangasek: http://paste.ubuntu.com/5696609/
[21:15] <slangasek> zyga: what's the output of 'sudo efibootmgr -v'?
[21:15] <zyga> slangasek: dpkg --get-selections
[21:15] <zyga> http://paste.ubuntu.com/5696611/
[21:16] <slangasek> zyga: md5sum /boot/efi/EFI/ubuntu/grubx64.efi ?
[21:16] <zyga> bb8cea9bb89a83aa714bd175d61cf5bc  /boot/efi/EFI/ubuntu/grubx64.efi
[21:17] <slangasek> zyga: doesn't match the shim-signed binary
[21:18] <slangasek> zyga: so, we should figure out where it does come from
[21:18] <zyga> slangasek: how did you figure that out, from this line: ?
[21:18] <zyga> Boot0001* Ubuntu	HD(1,800,2f000,947c5c3f-fa10-495c-b18d-97a7c757148f)File(\EFI\ubuntu\grubx64.efi)RC
[21:19] <slangasek> zyga: well, I mostly figured it out because I helped implement it so know what's supposed to be where ;), but yes, that line shows the path that's being booted
[21:19] <slangasek> (I wanted the efibootmgr output to confirm that the boot options themselves were configured correctly)
[21:19] <zyga> right, I meant the actual checksum
[21:19] <slangasek> zyga: I checked the shim-signed package
[21:19] <zyga> ah
[21:19] <zyga> ok
[21:19] <slangasek> zyga: you could try reinstalling shim-signed
[21:19] <zyga> ok
[21:20] <slangasek> zyga: but before you do, please make a copy of grubx64.efi
[21:20] <zyga> ouch
[21:20] <zyga> too late :/
[21:20] <slangasek> ohwell ;)
[21:20] <slangasek> zyga: order of operations fail on my part
[21:20] <slangasek> zyga: so what's the md5sum of that file on disk /now/?
[21:21] <zyga> cde67f528af411dd8d8f1b4bc643b484
[21:21] <zyga> different
[21:21]  * slangasek scratches his head
[21:21] <slangasek> that's not the md5sum I expect either ;)
[21:21] <tjaalton> slangasek: turns out the upstart logs don't have any mention of plymouth-splash, so no wonder 'started plymouth-splash' didn't work
[21:21] <zyga> cde67f528af411dd8d8f1b4bc643b484  /boot/efi/EFI/ubuntu/grubx64.efi
[21:22] <zyga> slangasek: is that the right file?
[21:22] <tjaalton> problem is I don't know what would work, so that the smooth transition is preserved
[21:22] <tjaalton> something to play with tomorrow then
[21:22] <slangasek> tjaalton: do you have plymouth in the initramfs?
[21:22] <tjaalton> slangasek: probably, using cryptsetup
[21:23] <zyga> slangasek: I can probably find the older grubx64.efi from the mirror I use
[21:23] <slangasek> tjaalton: right, that explains - no 'started' event because the service is started before upstart is
[21:23] <zyga> slangasek: and if it has the right md5sum I've pasted here, give it to you
[21:23] <slangasek> zyga: actually, sorry, I was directing you to the wrong place
[21:23] <tjaalton> slangasek: ha, ok
[21:24] <tonyyarusso> Hey everybody, I've been doing some mucking about with a script shipped with update-notifier-common (/usr/lib/update-notifier/apt_check.py).  I discovered that while it appeared to be intended to be usable as a module, it was never tweaked to actually be so.  So, I made some changes and was wondering if anyone could take a glance to see if they seem sane.  Here's the original: http://pastebin.com/102RGrjK , the new version: ...
[21:24] <tonyyarusso> ... http://pastebin.com/j7ZNVdMg , the diff of the two: http://pastebin.com/4Rmy1Hjc , and an example script using it as a module: http://pastebin.com/p808Hp9T .
[21:24] <slangasek> zyga: because apparently the system I was referencing here is also not configured for SB currently :P  How about 'sudo grub-install --uefi-secure-boot', then check if the efibootmgr output shows a different boot path?
[21:24] <zyga> k
[21:25] <zyga> huuh
[21:25] <zyga> slangasek: it _removed_ ubuntu?
[21:25] <slangasek> errr
[21:25] <zyga> slangasek: http://paste.ubuntu.com/5696643/
[21:25] <slangasek> really?
[21:25] <zyga> slangasek: as you can see
[21:25] <slangasek> that's... special
[21:26] <zyga> tonyyarusso: hi, I think this is best addressed on the ubuntu-devel@ mailing list
[21:26] <zyga> tonyyarusso: alternatively as a merge request (to trigger discussion) to the relevant project on launchpad.net
[21:26] <zyga> slangasek: am I being hacked or is this 20*13* showing its teeth
[21:26] <zyga> slangasek: and we got a borked upload with some interesting bug
[21:27] <slangasek> zyga: man, I don't know - none of these pieces have been uploaded recently, except for grub and the change there is irrelevant!
[21:27] <tonyyarusso> zyga: All righty - care to point me to a primer on how to do a merge request?  I've opened bugs before, but haven't had a solution to offer.  :)
[21:27] <slangasek> zyga: so, ah... if you run grub-install again, does the missing boot entry come /back/?
[21:27] <zyga> tonyyarusso: sure, there's a full help page on launchpad about that
[21:27] <zyga> slangasek: checking
[21:28] <stgraber> doko: is that the actual upstream recommended way of doing bindings nowadays? my understanding was that ffi was indeed quite cool to generate minimal on the fly bindings as something a bit cleaner than ctypes, but it didn't look like something that should be used for a full upstream binding
[21:28] <zyga> no
[21:28] <lifeless> stgraber: upstream for what value of upstream
[21:28] <zyga> slangasek: do I get it right that I should _not_ reboot now ;)
[21:28] <slangasek> tonyyarusso: http://developer.ubuntu.com/packaging/html/udd-intro.html + http://developer.ubuntu.com/packaging/html/fixing-a-bug.html
[21:28] <slangasek> zyga: yes, probably don't do that ;)
[21:28] <lifeless> stgraber: upstream has never recommended ctypes for bindings
[21:28] <zyga> right ;)
[21:28]  * zyga has been in such a situation once before ;)
[21:29] <slangasek> zyga: in theory you could still browse manually in the firmware and ask it to boot the Ubuntu botloader by name, but that doesn't sound fun
[21:29] <zyga> slangasek: ah
[21:29] <zyga> slangasek: so uefi shell is always around?
[21:29] <zyga> slangasek: I thought that's only in the reference impl
[21:29] <stgraber> lifeless: doko was essentially saying I should be using cffi for the LXC binding instead of my current native C extension
[21:29] <zyga> slangasek: been there, done that, should be okay if I have to
[21:29] <slangasek> zyga: not shell; it's incompatible with Win8 cert reqs to ship the shell
[21:29] <zyga> heh
[21:30] <slangasek> zyga: but your firmware menu *probably* has an option to boot a specific EFI executable by path
[21:30] <zyga> ok
[21:30] <slangasek> (this only works under Secure Boot if the binary is signed)
[21:30] <zyga> hmm, I don't recall such a menu
[21:30] <stgraber> lifeless: I know ctypes haven't been recommended by upstream and for very good reason, that's why to me cffi looked like something a bit cleaner than ctypes but not something that upstream python would recommend for a real-world binding
[21:30] <lifeless> stgraber: cffi should be equivalent, because it still invokes the compiler
[21:30] <zyga> ok
[21:30] <zyga> what shall we try next?
[21:31] <slangasek> zyga: I'm reading grub-install code right now to figure that out
[21:31] <zyga> slangasek: if the next UDS wasn't virtual I'd get you a beer for helping me :)
[21:32] <slangasek> zyga: what the heck... how about sending me the output of 'sh -x /usr/sbin/grub-install --uefi-secure-boot'?
[21:33] <zyga> slangasek: I'll set LANG= so that you can read it
[21:33] <slangasek> if you wish ;)
[21:33] <tjaalton> slangasek: a horrible hack I guess but works: 'and (started cryptdisks-enable or started plymouth-splash)' :)
[21:34] <slangasek> tjaalton: truly horrible; I think we should fix upstart instead to synthesize 'started' events for jobs started from initramfs
[21:34] <zyga> slangasek: http://pastebin.ubuntu.com/5696669/
[21:34] <slangasek> tjaalton: (there's no guarantee that plymouth in the initramfs is caused by use of cryptsetup, for one thing)
[21:34] <tjaalton> slangasek: heh, yeah. I was wondering if there was some more generic event to abuse here
[21:36] <slangasek> tjaalton: not really, we need to create one - either by fixing it in upstart, or by adding a secondary job that's 'start on startup or started plymouth-splash', checks for plymouth-splash running already, and emits an appropriate common event
[21:36] <tjaalton> slangasek: right, that could work
[21:37] <tjaalton> as an interim solution
[21:37] <slangasek> tjaalton: and by 'checks for plymouth splash running', I mean checking the output of 'status plymouth-splash'
[21:38] <doko> bah, after every reboot after a unity update my system comes up in low graphics mode
[21:40] <tjaalton> doko: most likely not related to unity, but the lovely plymouth-splash/lightdm race we have
[21:40] <doko> ahh
[21:40] <tjaalton> which is finally understood, just needs some head-scratching to fix it properly :)
[21:40] <doko> but unity sees updates more often =)
[21:41] <slangasek> zyga: 'fs_module=ext2' (line 1453) - /boot/efi is a VFAT partition, right?
[21:41] <zyga> yes
[21:41] <tjaalton> doko: pastebin Xorg.0.log from the failing boot
[21:41] <slangasek> zyga: hmm, ok
[21:44] <slangasek> zyga: so what if you run this command by hand?: efibootmgr -c -d /dev/sda -p 1 -w -L ubuntu -l \EFI\ubuntu\shimx64.efi
[21:44] <slangasek> (with appropriate quoting)
[21:44] <zyga> appropriate quoting?
[21:44] <zyga> ah
[21:44] <zyga> \ ?
[21:44] <slangasek> yah
[21:44] <zyga> EFI uses windows style path separators?
[21:44] <zyga> omg
[21:45] <zyga> slangasek: nothing
[21:45] <doko> tjaalton, hmm, $ ls -l /var/log/Xorg.*
[21:45] <doko> -rw-r--r-- 1 root root 31919 Apr 10 23:37 /var/log/Xorg.0.log
[21:45] <doko> -rw-r--r-- 1 root root 31151 Apr 10 23:36 /var/log/Xorg.0.log.old
[21:45] <doko> -rw-r--r-- 1 root root 34547 Apr 10 23:35 /var/log/Xorg.failsafe.log
[21:45] <doko> -rw-r--r-- 1 root root 34547 Apr  7 22:36 /var/log/Xorg.failsafe.log.old
[21:45] <slangasek> zyga: successful exit?
[21:45] <zyga> slangasek: as in, efibootmgr -v does not list anything new
[21:45] <zyga> no
[21:45] <zyga> slangasek: 1
[21:46] <slangasek> zyga:  -v it
[21:46] <zyga> slangasek: it dind't print anything either way
[21:46] <slangasek> man
[21:46] <slangasek> what's up with that
[21:46] <tjaalton> doko: hmm, .old is probably not useful, guess you logged out soon?
[21:46] <slangasek> zyga: are you sure /bin/efibootmgr isn't corrupt/trojaned/
[21:47] <doko> tjaalton, yes
[21:47] <zyga> slangasek: if it was, that'd be interesting
[21:47] <barry> slangasek: just to verify, the patch to bug 1078697 needs to be backported to lucid-updates, right?  i ask because the patch in raring/precise does not apply cleanly, and i want to make sure i need to adapt it before i spend too much time on backporting (a lot has changed in the code since lucid ;)
[21:47] <doko> tjaalton, will keep it the next time
[21:47] <zyga> slangasek: since I'm not in secure mode I'd have to boot from a CD to check for sure
[21:47] <zyga> slangasek: I can give you the md5sum I currently see
[21:47] <tjaalton> doko: check /var/log/Xorg.0.log next time it happens, it's probably kinda short and shows something like 'no screens'
[21:47] <zyga> ea865d9082f8aa250fc9f749e6391dbb  /bin/efibootmgr
[21:47] <doko> ok, will do
[21:48] <tjaalton> doko: in which case it's bug 982889
[21:48] <zyga> slangasek: maybe we can strace it?
[21:48] <slangasek> zyga: checksum is correct.  strace it is!
[21:48] <zyga> http://paste.ubuntu.com/5696697/
[21:49] <zyga> write(3, "B\0o\0o\0t\0000\0000\0000\0001\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 2084) = -1 ENOSPC (No space left on device)
[21:49] <slangasek> barry: I'm confused, why would we need this for lucid-updates?
[21:49] <zyga> hmmm
[21:49] <zyga> that's _not_ good
[21:49] <slangasek> zyga: have you had any recent kernel panics?
[21:49] <zyga> slangasek: did I bork my EFI flash stuff
[21:49] <barry> slangasek: that's my question.  when this came up last, cjwatson said it did.  i didn't have a chance to ask him why last time ;)
[21:50] <zyga> slangasek: not that I recall but I had a few problems earlier with my wifi (bcm) module
[21:50] <slangasek> zyga: are you using the raring kernel?
[21:50] <zyga> slangasek: yes
[21:50] <zyga> Linux g580 3.8.0-17-generic #27-Ubuntu SMP Sun Apr 7 19:39:35 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
[21:50] <slangasek> zyga: hmmmm, not sure how to address this then; for some context, see http://mjg59.dreamwidth.org/23554.html
[21:51] <zyga> slangasek: can I purge that space somehow?
[21:51] <slangasek> zyga: you may be able to clean it manually from the efivars filesystem, *but*, the firmware may not recognize you've done this until after you've rebooted
[21:51] <slangasek> (maybe rebooted /twice/ according to that page)
[21:52] <zyga> slangasek: is that safe?
[21:52] <zyga> slangasek: and how do I erase it, just files?
[21:52] <slangasek> and of course the thing you're trying to write to firmware right now is your bootloader entry, so :P
[21:52] <zyga> ohh
[21:52] <zyga> right
[21:52] <zyga> I have a ton of things in /sys/firmware/efi/vars
[21:53] <zyga> http://paste.ubuntu.com/5696710/
[21:53] <slangasek> zyga: none of this is safe, here there be dragons, but if you can find the right variable it should be safe to remove it since that's basically the same thing efibootmgr itself does
[21:53] <zyga> can I remove dump- variables?
[21:54] <zyga> man, I want the old bios back
[21:54] <zyga> or uboot ;)
[21:54] <slangasek> zyga: I would /guess/ those are the kernel pstore variables, yes
[21:55] <zyga> slangasek: rm -rvf dump-*
[21:55] <zyga> ?
[21:55] <slangasek> zyga: not sure
[21:55] <slangasek> zyga: note that there's a 'del_var' interface there
[21:55] <slangasek> you might need to use that
[21:55] <zyga> OMG
[21:55] <zyga> I need to get a charger
[21:55] <slangasek> or you can use /sys/firmware/efi/efivars instead
[21:55] <zyga> this day is _interesting_
[21:55] <slangasek> which is more filesystem-like
[21:56] <slangasek> rm /sys/firmware/efi/efivars/dump* ?
[21:56] <zyga> one has files, other directories
[21:56] <zyga> well, efivars has files
[21:56] <slangasek> /sys/firmware/efi/efivars is the new hotness
[21:56] <zyga> yeah
[21:56] <zyga> each dump- is full of backtraces
[21:56] <zyga> I wonder if that's safe
[21:56] <zyga> I mean
[21:56] <zyga> it's flash
[21:56] <zyga> it's going to die
[21:56] <zyga> and people get tons of that (wifi, nfs, etc)
[21:57] <slangasek> zyga: that's a question for the kernel team after we get you booting again :)
[21:58] <slangasek> zyga: in the meantime, rm the dump*, and reboot to either recovery media or (preferably) to /efi/ubuntu/shimx64.efi directly, then recover your bootloader entry with efibootmgr
[21:58] <slangasek> well, you can try efibootmgr one last time /before/ rebooting, but no guarantee that'll work
[21:58] <zyga> slangasek: ok, I need to prep some stuff
[21:58] <zyga> slangasek: yeah
[22:00] <slangasek> zyga: the good news is, the variable names encode a unix timestamp and you've been accumulating these since at least December... so unlike some other implementations, yours seems to include a proper amount of variable space... :P
[22:00] <zyga> slangasek: ok, power up
[22:00] <zyga> hehe
[22:00] <zyga> thanks lenovo
[22:00] <zyga> slangasek: let me burn raring image on a CD before we continue
[22:01] <slangasek> zyga: but be aware that filling the efi nvram is known to brick laptops in some cases (Samsung's implementation most notably), so even if we get those vars removed there's still some risk that this is going to go south on reboot
[22:02] <zyga> slangasek: well, I was about to get my refresh anyway ;)
[22:02] <zyga> (thought this laptop is brand new)
[22:02] <zyga> I wonder if that's under warranty
[22:03]  * zyga wgets current raring image
[22:03] <zyga> I guess it sucks to have the full mirror and yet wget all the iso's
[22:03] <slangasek> zyga: did the 'rm' work?
[22:03] <zyga> I didn't try
[22:03] <slangasek> ah
[22:03] <zyga> I want to burn raring DVD before I continue
[22:03] <slangasek> that part's safe enough to try, but ok
[22:04] <zyga> actually
[22:04] <zyga> I can burn the older DVD I still have in my archive
[22:04] <zyga> and then rm
[22:04] <xnox> slangasek: barry: yes, we need it for lucid _or_ for lucid in cat-ppa to deploy it where the checksums are generated.
[22:06] <chiluk> slangasek, I was just trying to verify pad.lv/1057358 , and the fix is still not showing up in the final deb.  It looks like you still have the patch too far down 00list
[22:07] <chiluk> I haven't figured out what processes 00list, and why it's so touchy... but I know it to be true.
[22:08] <slangasek> chiluk: I didn't upload it; looks like that was stgraber's upload?
[22:08] <chiluk> I don't know.
[22:11] <chiluk> slangasek, I assume you have a script that goes through and auto marks packages for needing verification.
[22:11] <chiluk> that's why I got excited.
[22:12] <slangasek> chiluk: the script is run manually by the SRU team when the package is accepted into -proposed; in this case that got missed somehow and stokachu prodded me :)
[22:12] <slangasek> but anyway, if the fix isn't working, you'll want to take that up with stgraber
[22:12] <chiluk> yeah we'd really like to get this "simple" bug off our queue.
[22:13] <slangasek> chiluk: or simply following up to the bug with that info and marking it 'verification-failed' to nudge things along
[22:13] <chiluk> already marked verification-failed
[22:14] <stokachu> chiluk: what did you break
[22:14] <stokachu> ;P
[22:14] <chiluk> wasn't me this time.
[22:14] <chiluk> although I feared it was me.
[22:15] <zyga> slangasek: burning
[22:15] <stokachu> chiluk: are you using edit-patch to make sure the previous patches are applied before doing your work?
[22:15] <zyga> slangasek: I'll remove the dump-* variables after that
[22:15] <slangasek> zyga: ok
[22:15] <zyga> slangasek: I think it's really bad that we keep no bounds on the number of those
[22:15] <zyga> slangasek: I mean, keepin one or 5 is okay
[22:15] <zyga> slangasek: keeping them till we can is crazy
[22:15] <chiluk> stokachu... it's a gotcha with isc-dhcp... where it requires certain patches to be in a certain order or it will revert them halfway through the build.
[22:15] <chiluk> basically I fixed my deb-diff..
[22:15] <stokachu> chiluk: i did a build recently and didnt see that problem
[22:15] <chiluk> but my fix didn't get pulled in.
[22:16] <chiluk> stokachu, then you were doing it wrong!
[22:16] <chiluk> my debdiff works.
[22:16] <stokachu> apparently not if the verification-faild
[22:16] <chiluk> what's in the repo has the dhcpd-ldap-apparmor.dpatch  at the end of the file where it gets reverted
[22:16] <chiluk> my debdiff is not what has been applied.
[22:17] <slangasek> zyga: that's one of the problems here, yes.  another is using precious nvram for non-fatal kernel oopses
[22:17] <slangasek> zyga: once this is all over, do you mind filing a bug on the kernel package about this?
[22:17] <zyga> slangasek: absolutely
[22:17] <chiluk> man I was really excited to get this bug out of my queues ..
[22:18] <zyga> slangasek: better yet, on ubuntu-devel@ we have a million bugs anyway
[22:18] <stokachu> chiluk: https://launchpadlibrarian.net/136643012/isc-dhcp_4.1.ESV-R4-0ubuntu5.8.precise.debdiff
[22:18] <stokachu> it add the patch at the end of 00list
[22:18] <zyga> slangasek: bot not many of them may brick machines
[22:18] <stokachu> chiluk: if you used edit-patch within the source directory it would handle all this for you
[22:18] <chiluk> I did use edit-patch... that's what screwed up in the first place.
[22:19] <zyga> slangasek: I'll copy all the dumps from that nvram to my good old hdd
[22:20] <chiluk> stokachu, from 00list  #these get reverted during the build, so put non-ldap
[22:20] <chiluk>  #patches earlier
[22:20] <stokachu> chiluk: then i dont know b/c like i said i did the process for each distro using both dpatch and quilt
[22:20] <chiluk> stokachu, you should really verify your debdiff to make sure that your patch does not get reverted.
[22:23] <zyga_> slangasek: ehh
[22:23] <stokachu> chiluk: edit-patch applys all patches and the work i did on top of that would've already had whatever ldap gets reverted
[22:23] <zyga_> slangasek: I cannot understand anything
[22:23] <zyga_> slangasek: my kernel just crashed
[22:23] <zyga_> slangasek: I tried to rsync my efi vars just in case there's something I need to restore later
[22:23] <slangasek> stokachu: the build log shows what's up, with the patch being applied at build time for the 'patched-ldap' build, followed by it being unapplied for a different build. https://launchpadlibrarian.net/132443806/buildlog_ubuntu-precise-amd64.isc-dhcp_4.1.ESV-R4-0ubuntu5.7_UPLOADING.txt.gz
[22:23] <zyga_> slangasek: then it didn't fully crash, it was just one big overlay on the framebuffer
[22:23] <zyga_> slangasek: then I rebooted it thinking that's it, the CD didn't finish burning
[22:23] <zyga_> slangasek: then it _booted_ from disk
[22:24] <slangasek> zyga_: omgwhat
[22:24] <zyga_> slangasek: but now efibootmgr -v shows Ubuntu
[22:24] <zyga_> slangasek: I have the backtrace as a photo, coming up
[22:24] <zyga_> slangasek: if this makes any sense
[22:25] <zyga_> slangasek: maybe the firmware adds the stuff from disk somehow if there are no entries at all?
[22:25] <slangasek> stokachu, chiluk: however, this behavior seems consistent with chiluk's own debdiff on the bug, so...
[22:25] <zyga_> http://paste.ubuntu.com/5696799/
[22:25] <zyga_> that's my current efi
[22:25] <slangasek> zyga_: that would be an insane thing for the firmware to do
[22:25] <chiluk> yeah as I said the current version of code didn't use my debdiff
[22:25] <zyga_> slangasek: insane + firmware == daily? right
[22:25] <chiluk> the patch I wanted is still in the wron place for 00list
[22:25] <slangasek> zyga_: do you have nvram space *now* to update with efibootmgr?
[22:26] <zyga_> let's see
[22:26] <zyga_> slangasek: nope
[22:26] <zyga_> same strace result there
[22:26] <zyga_> I didn't remove anything though
[22:26] <zyga_> this is insane
[22:26] <slangasek> right
[22:26] <slangasek> *can* you remove anything?
[22:27] <slangasek> or does it all just crash?
[22:27] <zyga_> let's try
[22:27] <lifeless> is there UEFI support for 32-bit builds ?
[22:27] <zyga_> I just did
[22:27] <slangasek> lifeless: no
[22:27] <lifeless> slangasek: what would be involved, in principle ?
[22:28] <zyga_> http://pastebin.ubuntu.com/5696808/ that's what I removed (usunięty == removed)
[22:28] <zyga_> slangasek: reboot twice now?
[22:28] <slangasek> zyga_: yep
[22:28] <zyga_> cross your fingers
[22:29] <slangasek> lifeless: grub-efi-ia32 exists, so in theory you just need boot media
[22:30] <slangasek> lifeless: as this cannot sanely done on our existing i386 boot image without compromising bootability on *other* systems, this is not something I expect to see in Ubuntu; but you can try to persuade cjwatson otherwise
[22:30] <stokachu> slangasek: is it me or is isc-dhcp using bad patching practices
[22:30] <slangasek> lifeless: (oh, there's probably installer bits that need doing as well)
[22:30] <lifeless> slangasek: I have a tablet here for experimentation, its an atom w/64 bit extensions, but a 32-bit UEFI environment
[22:30] <slangasek> stokachu: ... possibly?
[22:30] <lifeless> slangasek: and no non-UEFI boot facility [it ships w/windows 8]
[22:31] <stokachu> its just weird having to put patches above other because other patches revert code
[22:31] <slangasek> lifeless: make someone give you a 64-bit UEFI upgrade for it? :)
[22:31] <lifeless> slangasek: so I'm pondering getting enough of Ubuntu onto it to poke at touchscreen and video support.
[22:31] <slangasek> stokachu: they don't revert code; the structure of the patch file is magic and used to represent different sets of patches that are applied for different builds
[22:31] <lifeless> slangasek: if only it was that easy. I will dig up the right contacts and email them
[22:32] <tuxskar> hello, I'm using ubuntu 12.10 and I have this problem using libpcre3-dev
[22:32] <tuxskar> ~/apertium/apertium-en-es ⮀ apt-cache policy libpcre3-dev
[22:32] <tuxskar> libpcre3-dev:
[22:32] <tuxskar>   Installed: 1:8.30-5ubuntu1
[22:32] <tuxskar>   Candidate: 1:8.30-5ubuntu1
[22:32] <tuxskar>   Version table:
[22:32] <tuxskar>  *** 1:8.30-5ubuntu1 0
[22:32] <tuxskar>         500 http://es.archive.ubuntu.com/ubuntu/ quantal/main amd64 Packages
[22:32] <tuxskar>         100 /var/lib/dpkg/status
[22:32] <zyga> slangasek: hmm
[22:32] <tuxskar> Error: pcre_compile missing )
[22:32] <zyga> slangasek: not good
[22:32] <zyga> slangasek: keyboard / mouse does not work
[22:32] <zyga> slangasek: I've plugged external usb
[22:33] <zyga> slangasek: I had this just before the issues began
[22:33] <slangasek> lifeless: so if it's for a tablet and what you really need is a preinstalled image on removable media... that's fairly doable by just creating a disk image with a properly configured vfat partition and the magic binary bits in the right directory (/efi/boot/bootia32.efi, IIRC)
[22:33] <tuxskar> any idea?
[22:33] <zyga> slangasek: also bladernr_ is experiencing that
[22:33] <zyga> bladernr_: canyou type?
[22:33] <slangasek> zyga: !
[22:33] <slangasek> zyga: at what point is it failing?
[22:33] <zyga> slangasek: it does not respond in any way
[22:33] <bladernr_> zyga: i'm fine, mine is an old issue and probably not even closely related to yours
[22:33] <zyga> bladernr_: no, it started the _same_ way
[22:33] <bladernr_> and it's very transient and re-occuring
[22:34] <bladernr_> interesting...
[22:34] <zyga> bladernr_: then I rebooted and it all went nuts
[22:34] <zyga> bladernr_: are you using efi
[22:34] <xnox> lifeless: you can use rEFIt builds of 32bit EFI, it works well enough on UEFI devices despite targetting Apple's EFI from that you can at least boot/chain boot into grub-32bit. The "install" process will be very manual though.
[22:34] <slangasek> zyga: so you get what, a firmware screen and no input?
[22:34] <lifeless> xnox: thanks
[22:34] <lifeless> slangasek: thanks
[22:34] <zyga> slangasek: no, I booted to ubuntu :)
[22:34] <slangasek> hah
[22:34] <xnox> lifeless: this is the most "current" way to bootstrap/boot into 32bit only UEFI.
[22:34] <zyga> slangasek: but keyboard / mouse is not operational
[22:34] <lifeless> I shall put some time aside in a couple weeks to give it a spin
[22:34] <bladernr_> zyga: nope... my system is too old for that
[22:34] <zyga> ok
[22:34] <slangasek> zyga: ok, I claim no responsibility for this ;)
[22:35] <zyga> slangasek: heh
[22:35] <zyga> slangasek: ok, so I don't see any efi vars
[22:35] <zyga> slangasek: shall I reboot again?
[22:35] <slangasek> if deleting efi variables broke your keyboard... then that's a whole new world of crazy
[22:35] <slangasek> zyga: you don't see *any* vars, at all?
[22:35] <slangasek> did the efivarfs fail to mount?
[22:35] <zyga> slangasek: no, I do see a few, just none of the dump-*
[22:35] <slangasek> ok
[22:36] <slangasek> zyga: I'd try running efibootmgr again
[22:36] <zyga> slangasek: they are mounted ok
[22:36] <zyga> as in -v or to add the record?
[22:36] <zyga> http://paste.ubuntu.com/5696825/
[22:36] <zyga> that -s
[22:36] <slangasek> zyga: add the record
[22:36] <zyga> I booted with partially burned raring disk
[22:36] <zyga> ok
[22:37] <zyga> slangasek: I think that worked
[22:37] <slangasek> hurray!
[22:37] <zyga> http://pastebin.ubuntu.com/5696827/
[22:38] <slangasek> two Ubuntus?
[22:38] <slangasek> -v?
[22:38] <zyga> http://paste.ubuntu.com/5696831/
[22:38] <zyga> odd
[22:39] <zyga> shim + grubx
[22:39] <zyga> is that expected?
[22:39] <slangasek> yeah, efibootmgr writes a new boot entry instead of overwriting the existing
[22:39] <slangasek> grub-install has code to handle this
[22:39] <slangasek> just wanted to see which one is which to make sure the ordering was correct - and it looks fine
[22:39] <slangasek> so I think you can reboot to SB mode now
[22:40] <zyga> ok
[22:40] <zyga> and hopefully keyboard will work ;)
[22:40] <zyga> rebooting
[22:42] <zyga> slangasek: yay, everything works
[22:42] <slangasek> zyga: so the real question is how you ended up with a wrong, non-SB boot entry in the first place
[22:42] <zyga> slangasek: so let's file a few bugs
[22:42] <slangasek> zyga: upgrade logs may or may not provide illumination on this
[22:42] <zyga> slangasek: that's interesting but unless there's a log that knows this I don't know how to find out
[22:42]  * zyga will write a $10 app that "checks if your laptop is about to brick" ;)
[22:43] <slangasek> zyga: /var/log/apt/term.log would be a start
[22:43] <zyga> it should not be translated, meh
[22:44] <zyga> http://paste.ubuntu.com/5696840/ http://paste.ubuntu.com/5696841/ and http://paste.ubuntu.com/5696842/
[22:45] <zyga> slangasek: from the second log:
[22:45] <zyga> slangasek: Rozpakowywanie pakietu systemd-shim (z .../systemd-shim_1-0ubuntu1_amd64.deb) ...
[22:45] <zyga> slangasek: should that be installed?
[22:46] <slangasek> yes, it's unrelated to the shim bootloader
[22:46] <zyga> is that a "shim systemd"?
[22:46] <zyga> ok
[22:46] <stokachu> slangasek: since isc-dhcp is already in proposed with the reverted patch issue, maybe we can use https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1069570/comments/41
[22:46] <slangasek> apparently grub-install isn't verbose enough about its EFI handling
[22:46] <stokachu> slangasek: to push on top of it
[22:46] <zyga> Przygotowywanie do zastąpienia pakietu shim-signed 1.1+0~20120906.bcd0a4e8-0ubuntu4 (wykorzystując .../shim-signed_1.2+0~20120906.bcd0a4e8-0ubuntu4_amd64.deb) ...
[22:46] <slangasek> ohwell
[22:46] <zyga> that's all I can see shim-related
[22:47] <stokachu> slangasek: it contains changes from previous changelog along with mine and the proper ordering of the patches
[22:47] <slangasek> zyga: oh, was shim-signed uninstalled at some point?  (since that's a new install, not an upgrade?)
[22:48] <zyga> slangasek: checking
[22:49] <zyga> slangasek: I dind't remove it myself if that's what you're asking
[22:49] <slangasek> stokachu: er, don't patch debian/ from within debian/patches
[22:49] <zyga> slangasek: what makes you think that shim-signed was uninstalled?
[22:50] <zyga> as in ever uninstalled
[22:50] <stokachu> slangasek: sorry not following what you mean
[22:50] <zyga> slangasek: I have history.log files they have timestamps and other info
[22:51] <slangasek> stokachu: the debian/patches/add-option-ignore-client-uids.dpatch there is definitely wrong, it shouldn't be patching other patches
[22:51] <slangasek> stokachu: debian/patches/add-option-ignore-client-uids.dpatch *contains* debian/patches/dhcpd-ldap-apparmor.dpatch... and patches to 00list and debian/changelog as well
[22:51] <slangasek> zyga: oh, sorry, this was a simple reinstall of the package, I was reading wrong
[22:51] <slangasek> zyga: so yeah, looks like we have nothing to explain the wrong boot entry
[22:52] <zyga> slangasek: yes, that appears to be the case
[22:52] <zyga> slangasek: so what about the entry was wrong?
[22:52] <zyga> slangasek: the checksum?
[22:52] <slangasek> zyga: it pointed to grubx64.efi instead of shimx64.efi
[22:52] <zyga> I see
[22:52] <zyga> hmm
[22:52] <slangasek> and only shimx64.efi is signed with Microsoft's key
[22:53] <chiluk> so slangasek word round town is that stgraber is awwl (with leave) who would be the next best person to talk to about getting this issue and  https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1069570 committed?
[22:53] <stokachu> slangasek: hah, how the..
[22:53] <slangasek> chiluk: it seems that stokachu is preparing the SRU patch
[22:53] <zyga> slangasek: so I see a few bugs: mysterious grubx64.efi installed, kernel oopses logged to precious efi nvram, no cap / rotation on debug data in nvram
[22:54] <slangasek> zyga: the grubx64.efi isn't mysterious; it's expected and required, it's the second-stage bootloader
[22:54] <zyga> slangasek: + maybe the keyboard bug but I have no way to explain that (maybe apart from efi fastboot not starting USB for some reason but without any evidence)
[22:54] <zyga> slangasek: mysterious as in in that efi config space
[22:54] <zyga> (I probably phrase that incorrectly)
[22:54] <slangasek> ah - yes, the efi boot entry was mysterious
[22:55] <zyga> slangasek: I'll write a short email to ubuntu-devel@, I'll follow up with bugs tomorrow
[22:55] <zyga> slangasek: I wonder if anyone else got affected by that
[22:55] <zyga> slangasek: and if the nvram depletion a factor
[22:58] <stokachu> chiluk: that apparmor patch why not just edit debian/apparmor-dhcpd directly?
[23:01] <chiluk> because I was still new when I wrote it at first, and I was curious about the patching system.
[23:02] <chiluk> curiousity killed the cat.'
[23:03] <YokoZar> cjwatson: I subscribed you to https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1166124  because I remember our conversation ~ the printed text on the CD sleeves being grossly unrealistic a year or two ago
[23:04] <YokoZar> cjwatson: I'm not sure if Canonical is printing CDs for 13.04 but if so please make sure they don't say 256 megs required :D
[23:04] <zyga> slangasek: I wonder if it's safe to upgrade grub2 now
[23:04] <stokachu> slangasek: https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1069570/comments/42
[23:05] <stokachu> slangasek: mind taking a peek now, i think ive addressed everything
[23:06] <stokachu> slangasek: that should cover the broken -proposed and squash another bug
[23:08] <zyga> slangasek: did we get two ubuntu entries after my crash/reboot?
[23:13] <zyga> slangasek: email sent


[00:43] <dobey> crap. now xmpp accounts seem to be crashing pidgin for me :(
[00:47] <dobey> yay, and there's an update to fix it
[01:47] <wgrant> jcastro: I forwarded most of that patch upstream, but left the rewritten touchpad parts in Ubuntu because I thought they were a bit crap.
[10:11] <huats> morning
[10:18] <didrocks> morning huats
[10:39] <chrisccoulson> it's fairly quiet in here this morning
[12:12] <Nafallo> meh
[12:12] <Nafallo> doesn't look like gajim is making use of the indicator-applet :-/
[13:21] <kenvandine_wk> Nafallo: does it show up in the indicator at all?  and just not get individual messages?
[13:22] <Nafallo> kenvandine_wk: if I left click the envelope it tells me "Gajim Instant Messenger", but that's about it.
[13:38] <kenvandine_wk> Nafallo: ok... that is what i saw the other day too
[13:38] <kenvandine_wk> Nafallo: but... when i first patched it, it would show you messages too
[13:38] <Nafallo> kenvandine_wk: I'm a bit confused about what's supposed to happen :-)
[13:38] <kenvandine_wk> Nafallo: is my patch in the package?  or the patch that got applied upstream?
[13:38] <kenvandine_wk> Nafallo: when a message appears from someone, you should get an entry for that chat
[13:39] <Nafallo> kenvandine_wk: both. I haven't pulled a new upstream, but it's in their SVN as well as the package.
[13:39] <kenvandine_wk> http://blogs.gnome.org/kenvandine/2009/03/06/pidgin-sucks-less-for-irc/
[13:39] <kenvandine_wk> for an example
[13:39] <Nafallo> hehe. looking.
[13:39] <kenvandine_wk> but now the chat would appear as a sub item under Pidgin
[13:39] <Nafallo> I read the patch and expected what you just said though :-)
[13:40] <kenvandine_wk> it was working :)
[13:40] <kenvandine_wk> so either the changes to libindicate 0.1.5 broke it... or the patch is wrong
[13:40] <kenvandine_wk> but
[13:40] <kenvandine_wk> i have tested the example IM python script with 0.1.5
[13:41] <kenvandine_wk> and it works
[13:41] <Nafallo> hehe. can we ammend the patch to make it work again then? :-D
[13:41] <kenvandine_wk> which uses the exact same methods
[13:41] <kenvandine_wk> yes
[13:41] <kenvandine_wk> Nafallo: can you file a bug and assign it to me?
[13:41] <Nafallo> kenvandine_wk: sure
[13:41] <kenvandine_wk> i have a few other things to do first :)
[13:42]  * Nafallo hears "few" ;-)
[13:46] <Nafallo> kenvandine_wk: bug 340213 re-opened
[13:48] <kenvandine_wk> Nafallo: thx
[13:48] <kenvandine_wk> Nafallo: try the version in my ppa and see if it behaves the same way
[13:48] <kenvandine_wk> just for comparison
[13:48] <kenvandine_wk> that is the version i tested
[13:52] <Nafallo> kenvandine_wk: nope. same thing.
[13:53] <kenvandine_wk> ok
[13:53] <kenvandine_wk> thx for testing
[14:20]  * tedg is kinda getting into using the "X" to close the buddy list.
[14:20] <tedg> :)
[14:25] <kenvandine_wk> tedg: :-D
[14:57] <rickspencer3> looks like lots of folks on holiday today
[14:57] <rickspencer3> that's nice
[14:59] <dobey> rickspencer3: yeah, i should have just taken holiday too
[14:59] <rickspencer3> heh
[15:32] <kenvandine_wk> rickspencer3: good day to get stuff done :)
[15:32] <rickspencer3> yeah
[15:32] <rickspencer3> I think I'm going to take the afternoon off if at all possible
[15:34] <tedg> rickspencer3: Off, I'm already behind on 9.10 stuff! :)
[16:18] <rickspencer3> today is the deadline to submit to desktop summit !!!
[16:20] <calc> for some reason over the past day or so evolution has started crashing on me often, it just vanishes in the middle of working
[16:26] <tedg> rickspencer3 and davidbarth: So what are we thinking about the FUSA bug?  Jaunty or not?
[16:26] <rickspencer3> calc: ditto
[16:26] <rickspencer3> tedg: what's the bug #?
[16:27] <rickspencer3> calc: I think yesterday's update fixed it for me though
[16:27] <rickspencer3> also evo crashing does not play nice with the messaging indicator
[16:27] <calc> ah i updated just now but evolution didn't update so maybe it was something else that helped
[16:27] <tedg> rickspencer3: bug 357455
[16:28] <rickspencer3> right
[16:28] <rickspencer3> can't we just remove the "..."?
[16:28] <calc> anyone know if lower level automake targets (eg distclean) are supposed to call higher level targets as well (eg clean) ?
[16:28] <calc> i'm seeing an issue in ooo-build where it has a clean target in the Makefile.am that doesn't get called when distclean is run
[16:29] <rickspencer3> tedg: I think detecting that another user is connected and programming a way to block the shutdown is out of scope for Jaunty
[16:29] <rickspencer3> that's mho
[16:29] <rickspencer3> remove the "..." and move on to other important things
[16:30] <rickspencer3> like position of applets :)
[16:30] <tedg> rickspencer3: It's not that simple.  It basically is that we're detecting the case as multi-user when someone has two logins as the same user.
[16:30] <tedg> rickspencer3: There should be a dialog, and we think there will be, and teh PolicyKit doesn't put up one.
[16:31] <tedg> I'm done with my part of the applet one :)
[16:31]  * tedg was quick to invalidate that on indicator-applet ;)
[16:33] <rickspencer3> tedg: okay
[16:33] <rickspencer3> understood better
[16:33] <rickspencer3> given that we're past Final Freeze, I would say that the fact that selecting "shutdown" or "restart" actually causes those actions to happen is unfortunate
[16:34] <rickspencer3> but I suspect that any bug fixes will cause a cascade of regressions
[16:34] <rickspencer3> my opinion is that this should be punted to Karmic
[16:34] <tedg> That's kinda how I feel, but I guess I'd like an official decision on the bug :)
[16:34] <rickspencer3> who is the decider?
[16:34] <kenvandine_wk> rickspencer3: yeah... the applet positioning is basically done... just needs to be uploaded with the new patch from tedg
[16:34] <rickspencer3> davidbarth: ^^^^^^
[16:35] <rickspencer3> kenvandine_wk: yeah, I was being kind of sarcastic
[16:35] <tedg> rickspencer3: If it's for release stuff, I'd guess the release team.  If not them, I'd say you :)
[16:35] <rickspencer3> before you submit the change, we need to clarify with the design team that there is actual consensus that it'st eh right change
[16:35] <kenvandine_wk> rickspencer3: i guess hard to get the "tone" via irc :-p
[16:35] <rickspencer3> tedg: I just gave you my guidance
[16:36] <rickspencer3> however, I prefer team deciscion making and consensus in issues like this
[16:36] <rickspencer3> can we get davidbarth to weigh in?
[16:36] <rickspencer3> kenvandine_wk: ack on the tone thing
[16:36] <rickspencer3> plus I'
[16:36] <rickspencer3> m a bit grumpy today :/
[16:36] <tedg> rickspencer3: Let's see...
[16:36] <tedg> So I hear that England could be France in football any day of the week.  :)
[16:37] <tedg> beat that is.
[16:37] <rickspencer3> hehe
[16:37] <rickspencer3> I think that California wine surpassed French wine years ago
[16:37] <rickspencer3> nothing?
[16:38] <rickspencer3> :)
[16:38] <rickspencer3> kenvandine_wk: in terms of moving the MI, it also breaks visual freeze
[16:38] <kenvandine_wk> rickspencer3: yup!
[16:38] <kenvandine_wk> not a good time to do it
[16:38] <rickspencer3> so we need to let the documentation team know that we might be invalidating all of their screen shots
[16:38] <rickspencer3> marketing may be impacted as well
[16:38] <rickspencer3> they may have screenshots and what not ready to go
[16:39] <kenvandine_wk> rickspencer3: have we gotten any word from design folks?
[16:39] <rickspencer3> kenvandine_wk: they seem to be all on holiday
[16:39] <tedg> I learned that French wine was saved by Texas grape roots.  I think that we should ship Bush over as our representative to France...
[16:39] <rickspencer3> lol
[16:40] <kenvandine_wk> rickspencer3: my wife is from the napa valley... she has very strong opinions on the subjet
[16:40] <kenvandine_wk> and always gets a bit pissed when i buy sonoma valley wine :)
[16:42] <kenvandine_wk> i think buying french wine would be terms for divorce
[16:43]  * tedg mails kenvandine_wk some Texas wine ;)
[16:43] <kenvandine_wk> hehe
[16:44] <kenvandine_wk> she wouldn't touch the NC wine i bought... but after drinking it i don't blame her
[16:48]  * kenvandine_wk hopes to have his plate cleared before lunch so he can spend some time on his submission for the desktop summit
[16:52] <tedg> rickspencer3: kenvandine_wk: Can you guys comment on these please?  http://paste.ubuntu.com/148415/  http://paste.ubuntu.com/148416/
[16:53] <kenvandine_wk> tedg: isn't there quite a bit of overlap in those too?
[16:53] <kenvandine_wk> two even
[16:54] <tedg> kenvandine_wk: I was thinking one would be panel focused, and one would be application focused.
[16:54] <tedg> I think I have an hour of material... ;)
[16:54] <kenvandine_wk> for each?
[16:55] <tedg> No, each talk is a half hour.
[16:55] <kenvandine_wk> tedg: btw... i am doing an article on the indicator for the gnome journal
[16:55] <kenvandine_wk> ok... are they 30m slots?
[16:55] <tedg> Yeah, 30m slots.
[16:55] <tedg> kenvandine_wk: Oh, cool, that'll be fun.
[16:55] <kenvandine_wk> specifically porting apps to use the indicator :)
[16:56] <kenvandine_wk> i wish there were mono bindings :-D
[16:56] <tedg> For both of the talks I want to use the messaging use case, but then talk about extending it beyond that a lot.
[16:56] <kenvandine_wk> tedg: ok, looks good to me
[16:56] <tedg> Is there mono gobject introspection?
[16:57] <kenvandine_wk> i think so
[16:57] <kenvandine_wk> firerabbit wrote a tool for doing part of that
[16:57] <tedg> You could try enabling that.  PyBank wasn't up to it, but the mono one might work.
[16:57] <tedg> We dropped the gobject-introspection from the package, but it's still in the tarball.
[16:58] <kenvandine_wk> yeah
[16:58] <kenvandine_wk> i played with it a little
[16:58] <kenvandine_wk> i know nothing about using it though
[16:58] <tedg> You shouldn't have to, it should just work ;)
[16:58] <kenvandine_wk> i really want to see more apps using the indicator
[16:58] <kenvandine_wk> well
[16:59] <kenvandine_wk> it creates some mapping right?
[16:59] <tedg> It creates a GIR file, and I think youhave to use a lib to load that file.
[16:59] <kenvandine_wk> oh...
[16:59] <kenvandine_wk> humm
[16:59] <kenvandine_wk> i might need to play with that... in my infinite spare time :)
[17:00] <tedg> Heh, or convince walters to write a GNOME Journal article on it that you can then read ;)
[17:00] <kenvandine_wk> hehe
[17:00] <kenvandine_wk> that would actually be a great article
[17:29] <chrisccoulson> hi tedg, has seb128 spoken to you this week about fusa changes (specifically, making session saving work when exiting via the fusa)?
[17:29] <tedg> chrisccoulson: No, but I noticed some comments on ubuntu-devel about it.
[17:30] <chrisccoulson> yeah, i made a change to gnome-session to expose 2 new dbus methods, as gnome-session has been fixed to work properly now
[17:30] <chrisccoulson> i've also done the corresponding fusa change as well, but it needs some review
[17:31] <tedg> chrisccoulson: Okay, is it in LP?
[17:31] <chrisccoulson> session saving is working quite nicely here now :)
[17:31] <chrisccoulson> it's not on lp yet, i'll do that in a moment
[19:00] <chrisccoulson> tedg - my fusa changes are on lp now
[19:00] <chrisccoulson> https://code.edge.launchpad.net/~chrisccoulson/fast-user-switch-applet/session_management
[19:01] <chrisccoulson> i also updated the packaging branch (i had to do this to be able to build and test the changes anyway): https://code.edge.launchpad.net/~chrisccoulson/fast-user-switch-applet/ubuntu-packaging-jaunty
[19:25] <tedg> chrisccoulson: Looking through the diff, and that looks pretty good.  Do you know if gnome-session does the policy-kit dialog if need be?
[19:25] <chrisccoulson> it does:)
[19:26] <chrisccoulson> it takes care of everything for us. the only PK support required in the FUSA still is to detect whether we need to authenticate, to decide on whether to display the confirmation dialog or not
[19:28] <tedg> That makes life easier.
[19:31] <chrisccoulson> thanks for reviewing it:)
[19:52] <chrisccoulson> tedg - i'm going to update the fusa change slightly. i just noticed an issue where if you cancel the log out dialog and then select shutdown or restart when other users are logged in, it displays the old logout dialog again instead of the policykit dialog
[19:52] <chrisccoulson> minor mistake ;)
[19:55] <tedg> chrisccoulson: Heh, ah yes.
[20:16] <chrisccoulson> tedg - i've corrected both bzr branches now to remove that problem
[20:18] <tedg> chrisccoulson: Cool.  Do you want me to build a package?  I don't see any reason that I need to make one as I'm sure you've got one :)
[20:22] <chrisccoulson> tedg - you don't need to build one unless you want to try it out too, as I've got one here already. thanks
[20:23] <tedg> chrisccoulson: Great, I will, I'm very excited about the fix.  I just wanted to ensure you weren't waiting on me :)
[20:31] <didrocks> \o/
[20:31] <chrisccoulson> hi didrocks
[20:31]  * didrocks has finally found where the error was in his LaTeX file :)
[20:31] <didrocks> hey chrisccoulson
[20:32] <didrocks> I'm eager to see your FUSA patch :)
[20:32] <chrisccoulson> i can put the package in my ppa if you like, for you to try out
[20:32] <didrocks> chrisccoulson: hum, I am quit busy, not sure to test before it goes to official repos
[20:33] <didrocks> quite*
[20:33] <chrisccoulson> if it gets there. we've got to convince the release team yet i think ;)
[20:33] <chrisccoulson> but i think that session saving is quite important
[20:34] <didrocks> chrisccoulson: I totally agree. ok, upload to your ppa. I will give a shot
[20:34] <didrocks> (how to find some time before 2.26.1 to package ? O_o)
[20:42] <chrisccoulson> didrocks - that's uploaded to my ppa now (just waiting for it to finish building)
[20:45] <didrocks> chrisccoulson: great, I will keep you in touch
[20:47] <chrisccoulson> thanks. i'm just off to make some dinner now
[21:20] <Nafallo> kenvandine_wk: a tad more open to an get a patch to hide the gajim trayicon in the advanced options and enable that by default on Ubuntu now.
[21:21] <Nafallo> kenvandine_wk: unless we can make the hiding dependant on python-indicate being installed...
[21:21] <kenvandine_wk> we should be able to do that
[21:21] <Nafallo> not sure if that will cover the use case though. can someone install python-indicate and not use the applet... ;-)
[21:22] <kenvandine_wk> true
[21:22] <kenvandine_wk> although
[21:22] <kenvandine_wk> tedg: did you guys add a way to determine if the applet is available?
[21:23] <Nafallo> ooh. and then make something in the python binding to allow applications to check for that... would be swell :-)
[21:26] <Yasumoto> heya guys, if anyone has a chance to peek at https://bugs.edge.launchpad.net/ubuntu/+source/totem/+bug/358690, that'd be epic. It seems the issue is a symlink wasn't updated to point to the new name of a plugin, but I'm wondering if it's better to have a discrepancy in the symlink vs. real-file name, or to change the name of the symlink (and update it in firefox)
[21:31] <tedg> kenvandine_wk: Yes.
[21:32] <tedg> kenvandine_wk: That's what the "interest_added" and "interest_removed" signals tell servers.
[21:32] <kenvandine_wk> tedg: awesome
[21:32] <kenvandine_wk> tedg: great
[21:32] <kenvandine_wk> Nafallo: so i can do that
[21:32] <kenvandine_wk> :)
[21:32] <kenvandine_wk> Nafallo: i should be able to work on that this weekend :)
[21:32] <Nafallo> kenvandine_wk: nice. can we still have the advanced option to override it though? :-)
[21:33] <Nafallo> kenvandine_wk: however, that could be done quite easily later :-)
[21:33] <Nafallo> let's see if we can get it in first
[21:41] <tedg> kenvandine_wk: I probably won't be around much this weekend, but if you mail me at home I should get the mail -- send any questions that come up.
[21:41]  * tedg needs to get his work e-mail setup on his phone...
[21:43] <kenvandine_wk> sure
[21:43] <kenvandine_wk> great
[21:43] <kenvandine_wk> thx
[21:43] <kenvandine_wk> have a great weekend all!
[21:43] <Nafallo> kenvandine_wk: see you soon :-)
[21:44] <tedg> kenvandine_wk: You too!
[23:29] <chrisccoulson> some users are so rude
[23:30] <mpt_> heh
[23:37] <chrisccoulson> hey didrocks
[23:37] <chrisccoulson> you still there? it's getting quite late ;)


[22:05] <IOhannes> i'm new to ppas so: is it possible to upload a package for e.g. focal, that depends on focal-backports?
[22:06] <IOhannes> my package depends on debhelper-compat=13, and i'd rather not go back to 12 (for focal) or 11 (for bionic)
[22:10] <sarnold> IOhannes: yeah, in the 'edit ppa depencies' thing you can select backports
[22:16] <IOhannes> sarnold: thx
[22:17]  * IOhannes is currently on a machine where i don't have the credentials for my launchpad account, so i couldn't check that myself.
[22:47] <sarnold> IOhannes: heh, yeah, this is one of those times when just checking is probably quicker / easier than looking for docs :)


[00:22] <mup> PR snapcraft#3175 closed: cli: restore --target-arch with warning for LXD and Multipass <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3175>
[02:32] <mup> PR snapcraft#3178 opened: extensions: add gcc to GNOME 3.28 extension part <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3178>
[03:47] <guiverc> chromium snap:  a post on askubu (https://askubuntu.com/questions/1184357/why-cant-chromium-suddenly-access-any-partition-except-for-home/1251289#1251289) claims they can bypass what I suspect is intended security; should it be reported, if so where?  snapcraft.io  (it maybe nothing; a quick look and I didn't re-create but didn't really try)
[03:48]  * guiverc adds it's the new added answer by Dan Dasc.
[04:07] <jamesh> guiverc: it's true that running random binaries from within a snap rather than the public entry points will not be sandboxed.  There's no guarantee that such an invocation will work though.
[04:08] <guiverc> so not an issue, or known issue... I'll ignore.  thanks jamesh
[05:27] <mborzecki> morning
[05:53] <mborzecki> hm weird failure in google:ubuntu-core-20-64:tests/core/snap-auto-mount
[05:53] <mborzecki> and debug section is buggy in that test too
[06:23] <mborzecki> mvo: hey
[06:23] <mvo> hey mborzecki
[06:41] <mup> PR snapd#8890 closed: seed: fix LoadEssentialMeta when gadget is not loaded <Bug> <UC20> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8890>
[06:59] <pstolowski> morning
[07:03] <mvo> good morning pstolowski
[07:06] <mup> PR snapd#8813 closed: gadget,cmd/snap-bootstrap: move partitioning to gadget <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8813>
[07:14] <zyga> Good morning
[07:14] <zyga> I’m back home
[07:14] <zyga> Tired but okay
[07:14] <zyga> I just dropped in to say hi
[07:15] <zyga> And tell you all I will take today and tomorrow off to rest
[07:15] <zyga> Surgery cannot be done yet, and I need to wait for a few weeks on new
[07:15] <zyga> Meds that decrease the problem
[07:15] <zyga> I will resume work next week
[07:16] <zyga> And will work mostly normally for the next two to four weeks
[07:17] <zyga> I may have the surgery after that, when my condition improves
[07:17] <zyga> So that is that
[07:17] <zyga> I’m really tired today, had a very painful and long day and night
[07:18] <zyga> mvo: I will file yesterday today and tomorrow into the system
[07:19] <mvo> zyga: thank you, get well
[07:20] <zyga> Thank you, good luck with apparmor and secure boot and everything :)
[07:24] <mvo> zyga: yeah, slowely working my way forward there, almost no progress yesterday because of other things but I'm somewhat hopeful for today :)
[07:25] <mvo> mborzecki, pedronis any concerns to merge 8675? it has two +1 now
[07:26] <pedronis> mvo: I think mborzecki should look at it again
[07:27] <mborzecki> pedronis: mvo: finishign with some tweaks to u-i, will that a look at that pr next
[07:29] <mvo> mborzecki: ta
[08:23] <mwhudson> does something in snapd set LC_ALL to C?
[08:24] <mwhudson> hm doesn't look like it
[08:28] <mvo> mwhudson: hey, I don't think so - thanks for updating go/edge !
[09:32] <mvo> pstolowski: I added an idea to your comment in https://github.com/snapcore/snapd/pull/8881/files#r441360886 - please let me know what you think, zyga is out so I want to push this forward a bit
[09:32] <mup> PR #8881: interfaces: optimize rules of multiple connected iio and spi plugs <Bug> <Needs security review> <Created by zyga> <https://github.com/snapcore/snapd/pull/8881>
[09:32] <pstolowski> looking
[09:33]  * zyga needs to disable phone notifications
[09:33] <zyga> mvo: I would not drift away from ###PARAM###, just handle it without panic
[09:33] <mvo> zyga: haha - sorry
[09:33] <zyga> as it makes use of map nicer
[09:33] <zyga> mvo: no worries, I really feel better already
[09:34] <mvo> zyga: if you want and feel good have a look at my comment, it still uses ###PARM### internally just make the interface for the caller slightly different
[09:34] <zyga> mvo: yeah I like the interface a lot
[09:34] <zyga> I misunderstood that it also changes the backend
[09:34] <zyga> if that's the same backend that's a brilliant way out
[09:34] <zyga> nice work!
[09:35] <mvo> zyga: no worries, just comment there if you prefer the []string or "prefix,postfix" either way is fine, you know more about this than me (I slightly prfer []string)
[09:35] <zyga> I prefer [] as it may be needed to insert this many times
[09:35] <mvo> zyga: +1
[09:35] <mvo> thank you zyga
[09:35] <zyga> really sweet way out of this :)
[09:35] <zyga> thank You :)
[09:35] <mvo> :) my pleasure
[09:36] <zyga> if you park it ping me on irc/tg and I will iterate some more and add tests/i2c support
[09:36] <zyga> my family is helping me to adjust the bed to a better workspace
[09:36] <zyga> with "floating" laptop so that I don't need to strain my neck
[09:37] <zyga> and a split keyboard so that my hands don't have to be in the air while typing
[09:37] <zyga> I just ordered https://ultimatehackingkeyboard.com/
[09:37] <mvo> zyga: I did some of the cosmetic changes that jamie asked for, 1.5 unit tests and can push the diff and then it's all yours if you want :) , I have code-review and meetings today
[09:37] <mvo> zyga: I wonder if a bed breakfast tray would help?
[09:38] <zyga> mvo: we tried but I really want something that's more less at 45 angle
[09:38] <zyga> above my head
[09:38]  * mvo nods
[09:38] <zyga> some wood and duck tape will work as a prototype
[09:39] <zyga> I'll send pics when it works :)
[09:40] <zyga> mvo: I'm afk again, ping me when you are done with the PR
[09:44] <mborzecki> pedronis_: https://github.com/snapcore/snapd/pull/8887#discussion_r442077693 i was wondering whether there should be any fallback, but i gues when you're generating an image with some version of snapd, the asset must exist
[09:44] <mup> PR #8887: bootloader: pull recovery grub config from internal assets <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8887>
[09:45] <pedronis> mvo: so it seems there was an almost fix of 8889 in the codebase
[09:46] <pedronis> mvo: there's probably more code to cleanup there
[09:50] <mvo> pedronis: yeah, it was 2 steps forward, one step back. I did not dig super deep but my feeling is the same, there is more hidding there
[09:51] <mvo> zyga: pushed the tweak to the signature, feel free to tweak further or change as needed, I'm done with the PR for a couple of hours now (meeting, code-review, lunch etc). keep me updated please and fwiw, really nice job there
[09:52] <zyga> thanks!
[09:55] <pedronis> mvo: I left comments there
[09:56] <pedronis> mvo: I think the issue with the original fix is that we didn't write an UpdateMany tests perhaps?
[09:56] <pedronis> if don't have many of those, or maybe we did but is not quite right?
[09:56] <pedronis> s/if don't/we don't/
[09:58] <pstolowski> mvo: i like your idea, i meant to comment under the PR but it seems this comment is gone
[09:59] <mvo> pedronis: thanks, I have a look
[09:59] <mvo> pedronis: but yeah, missing test(s) seems very likely
[09:59] <mvo> pstolowski: sorry, my fault probably, I resolved it (but it should still be there, just collapsed)
[09:59] <mvo> pstolowski: anyway, "like it" is enough :)
[10:01] <pstolowski> mvo: ah indeed it's there, i got confused, sorry
[10:08] <mborzecki> quick errand, back in a bit
[10:19] <zyga> mborzecki: woah
[10:19] <zyga> snap just broke a non-snap app fonts
[10:19] <zyga> that was *open*
[10:19] <zyga> surreal
[10:19] <zyga> I opened telegram
[10:19] <zyga> and the ebook reader app got messed up
[10:33] <mborzecki> re
[10:37] <pedronis> mvo: I made a remark in #8881 that that method needs a doc comment
[10:37] <mup> PR #8881: interfaces: optimize rules of multiple connected iio and spi plugs <Bug> <Needs security review> <Created by zyga> <https://github.com/snapcore/snapd/pull/8881>
[10:40] <mvo> pedronis: thank you!
[10:40] <mvo> pedronis: also thanks for your comment in 8889, I had no idea we look at flags in so many place, +100 for the unit test(s)
[10:41] <mvo> s/comment/comments/
[10:44] <clmsy> did anyone experience "no such device: ubuntu-boot" from trying to boot this: https://github.com/snapcore/pc-amd64-gadget (20 branch)
[10:52] <mvo> clmsy: I don't remember this but if you used qemu, did you boot it in UEFI mode?
[10:58] <clmsy> I will double check and comeback mvo, thx
[11:15] <mvo> ijohnson: I merged 8675 but there is a small suggestion for a followup that is worth checking
[11:16] <ijohnson> mvo: sure I will take a look in a bit, trying to wrap up my presentation this morning :-)
[11:17] <mup> PR snapd#8675 closed: osutil: add disks pkg for associating mountpoints with disks/partitions <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8675>
[11:17] <mvo> ijohnson: no worries
[11:17] <mvo> ijohnson: it's not urgent, just wanted to mention it :)
[11:18] <mvo> pstolowski: 8812 looks ready, if you get unrelated failures just ping me and I can sudo merge
[11:19] <pstolowski> mvo: yes i'm super keen to land it and have been monitoring it; failed on project- on core20 and i restarted the tests
[11:20] <mvo> pstolowski: ok
[11:20] <mvo> pstolowski: thanks for being on top of this!
[11:20] <pstolowski> mvo: let's wait a little bit for current run
[11:20] <mvo> sure
[11:20] <mvo> in related news: down to 50 PRs again!
[11:34] <pstolowski> mvo: failed on centos 8 only, on selinux-clean. cannot be related because this functionality is not yet hooked anywhere
[11:34] <pstolowski> mvo: so i'd say go ahead an merge
[11:46] <pstolowski> cachio: hi, #8558 still has unaddressed comments, do you plan to add the doc?
[11:46] <mup> PR #8558: tests: make the nested library usable independently of spread <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8558>
[11:46] <cachio> pstolowski, hi, yes, but still applying some improvements to that one
[11:47] <cachio> pstolowski, I'll push today the update
[11:47] <pstolowski> cachio: ah, sure
[11:48] <cachio> pstolowski, there were many changes in nested recently :)
[11:48] <pstolowski> cachio: yes.. btw, is the core20 early config still failing?
[11:58] <cachio> pschecking
[12:00] <cachio> pstolowski, today I see the nested/core20 suite failed with that error https://paste.ubuntu.com/p/fqVwCSZDGf/
[12:00] <cachio> seems to be a race I think
[12:27] <mup> PR snapd#8891 opened: o/servicestate: add updateSnapstateServices helper (5/6) <Needs Samuele review> <Services ⚙> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8891>
[12:27] <mborzecki> https://github.com/snapcore/snapd/pull/8455 could use some reviews
[12:27] <mup> PR #8455: tests/lib/cla_check: expect explicit commit range <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8455>
[12:30] <pedronis> pstolowski: should we merge #8812 ?
[12:30] <mup> PR #8812: o/snapstate: service-control task handler (4/N) <Needs Samuele review> <Services ⚙> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8812>
[12:30] <pstolowski> pedronis: yes, i pinged mvo earlier but he seems busy. unrelated failure on centos
[12:31] <cachio> pstolowski, added the sectino to HACKING file
[12:32] <pedronis> pstolowski: you can merge, centos is marked not required
[12:32] <cachio> still testing hte lib with different variables
[12:32] <pstolowski> cachio: would it be possible to add it as --help ?
[12:32] <pedronis> pstolowski: you don't need mvo
[12:32] <pstolowski> pedronis: ah, indeed
[12:33] <cachio> pstolowski, yes let me add that
[12:33] <pstolowski> the grey merge button is confusing
[12:33] <pstolowski> done
[12:33] <pstolowski> that's great. i pushing the last PR then
[12:37] <mup> PR snapd#8812 closed: o/snapstate: service-control task handler (4/N) <Needs Samuele review> <Services ⚙> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8812>
[12:42] <pedronis> pstolowski: yes, the button can be green, grey, or greyed out
[12:42] <pedronis> something like that afair
[12:44] <mvo> yeah, centos-8 is no longer required because it's a bit unstable right now
[12:46] <pedronis> pstolowski: great, not sure I'll get to them immediately though
[12:47] <mup> PR snapd#8892 opened: o/snapstate,servicestate: use service-control task for service actions (6/6) <Complex> <Needs Samuele review> <Services ⚙> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8892>
[12:48] <pstolowski> pedronis: np, i'll probably push some tests to #8892 still
[12:48] <mup> PR #8892: o/snapstate,servicestate: use service-control task for service actions (6/6) <Complex> <Needs Samuele review> <Services ⚙> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8892>
[12:48] <pedronis> pstolowski: is still fairly large?
[12:49] <pstolowski> pedronis: yes, the 5th one will reduce it a bit
[12:50] <pstolowski> pedronis: +1,082 −573
[12:51] <pstolowski> pedronis: maybe I can find some small bits to extract into separate PR(s), but it got really hard at this point
[12:52] <pedronis> pstolowski: we'll need to see it might get hard to get in one go
[12:52] <pedronis> it seems to touch a lot of places
[12:55] <pedronis> pstolowski: there might be things we can do
[12:57] <pedronis> some things are also inherited messiness
[12:57] <pstolowski> pedronis: i'll look at the entire diff again and try to find something to propose separately. the main problem was change in semantics of wrappers, it affects a lot
[12:57] <pedronis> pstolowski: yea, I think we should discuss a bit
[12:58] <pstolowski> pedronis: and at some point when i was trying to split this i was lost and managing conflicts was nightmare
[12:59] <pstolowski> because i was trying to do some things "dummy" in preparation for something upcoming, but that just diverged too much
[13:23] <pstolowski> pedronis: i see a few smaller things that i can extract and propose independently without extra work, so i can prep them to start with
[13:47] <cachio> mvo, this is the log https://paste.ubuntu.com/p/6jmQQRkpCD/
[13:47] <cachio> there is another similar
[13:47] <cachio> do you want it?
[13:53] <mvo> cachio: looking, one is probably fine for now
[13:59] <mvo> cachio: I noticed test-snapd-sh-coe20 is missing, building that now
[14:02] <cachio> mvo, yes, thnaks
[14:03] <cachio> in most cases we build it
[14:03] <cachio> in the test
[14:23] <pstolowski> pedronis: do you have a moment now?
[14:23] <pedronis> pstolowski: I'm available in the standup HO
[14:24] <pstolowski> coming
[15:15] <zyga> mvo: I'm less sleepy now, I will pick up that branch in an hour or two
[15:18] <mvo> zyga: \o/ thanks!
[15:24] <mup> PR snapcraft#3178 closed: extensions: add gcc to GNOME 3.28 extension part <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3178>
[15:47] <ogra> xnox, so we got  UC20 demo from ian today ... systemd in initrd is seriously shiny, you rock !!!
[15:52] <xnox> ogra:  it's held by duct-tape and lots of hacks from everyone ian maciej michael etc.
[15:52] <xnox> ogra:  i'm glad that it _appears_ rock solid =)
[15:53] <ogra> still super shiny and long overdue ... duct tape or not ... kudos !
[16:18] <abeato> jdstrand, hey, is primed-staged-packages already used to find CVEs for snaps in the store?
[16:29]  * cachio lunch
[17:34] <mup> PR snapcraft#3179 opened: Maven plugin: improve error message when target libs are not found <Created by edumucelli> <https://github.com/snapcore/snapcraft/pull/3179>
[17:49] <jdstrand> abeato: not yet. emitorino got assigned to do that but then some urgent stuff came up. it'll happen 'soonish'
[17:50] <jdstrand> 'ish' since I'm not quite sure when, but it is the first review-tools item she'll pick up when she gets back to the review-tools :)
[18:10] <emitorino> abeato, yes, it's on my list as jdstrand mentioned. I plan to work on that feature next week. Let me know if you need it earlier and we can coordinate
[18:16] <abeato> jdstrand, emitorino great, thanks for the update - no, not in a hurry, I was just wondering if it was already there
[18:16] <emitorino> abeato, cool, I will let you know as soon as it is ready
[18:16] <abeato> awesome, thanks
[18:57] <pstolowski> ijohnson: hey, i've updated services PR
[18:58] <pstolowski> ijohnson: and i think the loop is correct, please take a look
[18:58] <ijohnson> Okay, thanks pstolowski
[19:23] <mup> PR snapd#8893 opened: osutil/disks: refactor diskFromMountPointImpl a bit <Cleanup :broom:> <Simple 😃> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8893>
[21:25] <zyga> jdstrand: I've updated https://github.com/snapcore/snapd/pull/8881
[21:25] <mup> PR #8881: interfaces: optimize rules of multiple connected iio and spi plugs <Bug> <Needs security review> <Created by zyga> <https://github.com/snapcore/snapd/pull/8881>
[21:26] <zyga> jdstrand: I think everything is addressed now, with one important exception
[21:26] <zyga> jdstrand: if you review it today it can be cherry picked into the release branch by mvo tomorrow
[21:26] <zyga> jdstrand: I'm officially off today and tomorrow
[21:26] <zyga> but I may show up for a moment
[22:35] <mup> PR snapcraft#3177 closed: repo: consider virtual pkgs for cache invalidation <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3177>