 Sounds nice :)
[08:48] <larsu> morning pitti and hikiko!
[08:48] <pitti> Laney: hah, sounds fun! we had a nice weekend too; there was rather strong wind, I tried my new kite
[08:49] <Laney> nice
[08:49] <Laney> is it a stunt kite?
[08:49] <hikiko> morning larsu Laney pitti all
[08:49] <pitti> Laney: yes, but I'm not good enough yet for lots of stunts :)
[08:50] <pitti> Laney: I have this one: http://www.lenkdrachenshop.com/hq-lenkdrachen-maestro-iii-r2f-drachen-kite-sport-freizeit-neu-2014.html
[08:50] <Laney> hey hikiko
[08:50] <Laney> good weekend (and larsu)?
[08:50] <pitti> hey larsu, hello hikiko!
[08:51] <Laney> pitti: fun! it was very windy here too, would have been interesting to fly a kite in it :P
[08:51] <Laney> we have one like this http://www.skyhighkites.co.uk/shop/product/2486/HQ-Symphony-Beach-III-2,2M-Power-Kite.html
[08:51] <larsu> Laney: yes! Fainas family and a friend were here. Loads of fun and *a lot* of vodka
[08:51] <Laney> know some people who have a bigger one with four lines (instead of two), which are pretty powerful
[08:53] <Laney> larsu: за ваше здоровье!
[08:55] <Laney> ask Faina if this is legit :P
[08:55]  * Laney doesn't trust the internet
[08:56] <pitti> Laney: normally you say "na" sdorowje, not "sa"
[08:56] <mitya57> no, за is legit for a toast :)
[08:56] <larsu> Laney: already waiting for her reply ;)
[08:56] <pitti> Laney: ah, they should be a lot more stable in the air and need less wind, but also slower, right?
[08:59] <Laney> pitti: I've not tried one like yours before
[08:59] <Laney> but you can float these box ones in place quite easily
[08:59] <Laney> thanks mitya57 ;-)
[09:01] <Laney> oh I also found a great sloe bush and got enough for 3l of gin :)
[09:01]  * Laney just got reminded by seeing them in the freezer
[09:05] <willcooke> mornign
[09:05] <willcooke> urg
[09:05] <willcooke> good start
[09:06] <Laney> hi willcooke
[09:06] <Laney> how's it going?
[09:06] <willcooke> morning Laney
[09:08] <larsu> happy Monday willcooke
[09:09] <seb128> hey desktopers
[09:09] <seb128> hey willcooke Laney larsu pitti
[09:09] <larsu> bonjour seb128!
[09:10] <larsu> how ws your weekend?
[09:10] <pitti> bonjour seb128 ! ça va ?
[09:10] <seb128> great! (out of the news/events in Paris)
[09:10] <pitti> seb128: et comment est ta famille ? vont-ils bons après Paris ?
[09:10] <seb128> pitti, oui, tout le monde que je connais pas bien, merci
[09:10] <Laney> hey seb128!
[09:11] <seb128> spent saturday afternoon at a friend, played some football table and had fun there
[09:11] <seb128> and spent a quiet sunday with familly
[09:11] <pitti> j'ai essayé demander didrocks, mais il n'a pas encore repondé
[09:11] <seb128> willcooke, is didrocks supposed to be off today?
[09:11] <pitti> yes, swap day
[09:12] <seb128> he didn't say anything on friday
[09:12] <pitti> as per calendar
[09:12] <willcooke> yeah, swap
[09:12] <seb128> k
[09:12] <willcooke> oh, sorry just caught up
[09:12] <seb128> pitti, where did you ping him? telegram?
[09:12] <pitti> oui
[09:17] <davidcalle> willcooke, scopes patches good to go
[09:17] <davidcalle> Well, good for review at least
[09:17] <davidcalle> Also, hi o/
[09:18] <willcooke> davidcalle, thanks!  I saw your commits yesterday, thanks for working on that.  I'll poke the security team
[09:25] <Trevinho> hi
[09:26] <willcooke> morning Trevinho
[09:27] <seb128> hey Trevinho
[09:27] <Trevinho> hey willcooke, seb128
[09:31] <larsu> hi Trevinho!
[09:31] <larsu> what's up?
[09:31] <Trevinho> hi larsu...
[09:33] <Trevinho> Whatttttt... There's a small bug in my LCD. In the space between the led light and the panel itself :o
[09:35] <larsu> haha cool
[09:36] <willcooke> Just got an SMS from didrocks
[09:42] <seb128> willcooke, good
[09:43] <willcooke> Trevinho, the curse of the moving comma
[09:43] <willcooke> honestly, when I used to do IT support I have to see someone with a comma they couldn't delete
[09:44] <willcooke> and it was a bug crawling around
[09:44] <Trevinho> :D
[09:48] <pitti> seb128: hah, il a repondé maintenant, lui et sa famille vont biens
[09:48] <seb128> pitti, super
[10:02] <Trevinho> seb128: I've got a private mail from a guy saying that in u-s-d / upower that we ship there's no support for the keyboard backlight... Or better, it doesn't remember the previous settings.
[10:03] <Trevinho> seb128: it seems the fix is in g-s-d 3.16, is there any plan to backport that?
[10:03] <Trevinho> I guess there's a bug for that but I didn't search yet
[10:06] <Laney> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1510344 ?
[10:06] <ubot5`> Ubuntu bug 1510344 in linux (Ubuntu) "Keyboard Backlight Turns on at boot" [Low,Confirmed]
[10:06] <seb128> Trevinho, no current plan afaik
[10:07] <seb128> but Laney seems to know more than me about that ;-)
[10:07] <Trevinho> :)
[10:07] <Laney> just saw the bug
[10:07] <Trevinho> Laney: that bug seems somewhat related more to the kernel though... The boot side, not the suspension one
[10:07] <seb128> I've no hardware to test on
[10:07] <seb128> so not going to be me that work on it
[10:07] <Laney> what does no support mean?
[10:07] <Laney> it clearly does have some support
[10:08] <Trevinho> So the thing is:
[10:08] <Trevinho> you change the brightness level of the keyboard to a lower value -> suspend -> resume -> keyboard backlight is back to the maximum level
[10:08] <Laney> if you know a fix then cherry pick it?
[10:09] <Trevinho> Yeah, that's the thing, I asked if anyone knew the fix :)
[10:09]  * Trevinho looks in git
[10:22] <Trevinho> Laney, seb128: from a quick look it seems it's not just a commit... We mostly need to backport the whole power plugin as it has been changed a lot to work with newest upower (which seems to support this thing)
[10:25] <Trevinho> the changes aren't small, but it would be worth trying IMHO... As being updated on power-related stuff is always nice
[10:31] <seb128> Trevinho, we did backport the new upower work
[10:31] <seb128> the api changed we couldn't stay on the old one
[10:32] <Trevinho> mh weird... I made a diff between the two, and I see huge changes
[10:32] <Trevinho> APIs are ok, I mean.. But there's no support for new features maybe?
[10:37] <seb128> there was quite some refactoring, unsure about features
[10:37] <seb128> https://git.gnome.org/browse/gnome-settings-daemon/log/?qt=grep&q=power
[10:39] <willcooke> seb128, Trevinho - any ideas why I don't see X here:  https://bugs.launchpad.net/unity/+bug/1477068/+nominate
[10:39] <ubot5`> Ubuntu bug 1477068 in unity (Ubuntu) "Activating an application through the indicators doesn't bring it to the foreground" [High,Triaged]
[10:40] <willcooke> Is it that Unity needs a special X branch set up>?
[10:40] <Trevinho> seb128: it might be related to the change to  backlight_iface_emit_changed, which in our case only supports screen interface, not also keyboard one
[10:40] <davmor2> willcooke: bluetooth does work out of the box on the xps 13, it kinda looks like it does but it seems to be missing some firmware who do I need to ping about that?
[10:41] <Trevinho> willcooke: that's an old issue, and... well, there's no real fix for that. Indicators have to be fixed to launch apps with the timestamp of the click event
[10:41] <Trevinho> willcooke: I fixed some of them in the past, but not everyone is feasible as it needs some X dependencies
[10:42] <seb128> willcooke, those are unity project targets
[10:42] <seb128> not Ubuntu ones
[10:42] <willcooke> ah, right, thanks
[10:43] <willcooke> davmor2, hrm.  Well, if it's firmware that we can get hold of an distribute I expect the foundations team will need to include it
[10:43] <Laney> change the URL to /ubuntu/+source/unity...
[10:44] <davmor2> willcooke: dell have a deb I think in the driver pack after a lot of digging, but I followed steps for converting the windows to an ubuntu compatible version
[10:45] <Trevinho> seb128: this might be a start... https://github.com/GNOME/gnome-settings-daemon/commit/5614e2c7a275a092e1fcf43450d7f0c5730c14bd
[10:45] <davmor2> willcooke: https://wiki.archlinux.org/index.php/Dell_XPS_13_(2015)
[10:46]  * Trevinho has not such keyboard to test with, though...
[10:46] <seb128> Trevinho, could be, but initial support was added in https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=ce295afb6dbd021d0375270bf2b4becacb9ef4db
[10:46] <seb128> which is in our codebase
[10:46] <seb128> so I guess it's mostly bugfixes
[10:46] <seb128> but I don't have a such keyboard either
[10:46] <seb128> so I can't test
[10:49]  * Trevinho would backport the whole thing :P
[10:50] <seb128> go for it
[10:50] <seb128> we didn't hold on backporting for any special reason
[10:50] <seb128> it's just that nobody put the work to do it
[10:51] <seb128> also keep in mind that sometime the g-s-d changes imply g-c-c matchups and we can't update the frontend as easily since they completly changed the design/look compared to what we have
[10:51] <willcooke> davmor2, Hrm.  Sounds to me like we'd need to get that firmware included in the linux-firmware package.
[10:52] <davmor2> willcooke: it works perfectly once it is in place :)
[10:52] <davmor2> willcooke: I'll file a bug for it then
[10:53] <willcooke> da thanks
[10:53] <willcooke> davmor2, TheMuso
[10:53] <willcooke> argh
[10:53] <willcooke> davmor2, thanks
[10:53] <davmor2> tab doesn't work on words honest :)
[10:54] <willcooke> :)  try telling my fingers that
[12:10] <davmor2> willcooke: https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1516580
[12:10] <ubot5`> Ubuntu bug 1516580 in linux-firmware (Ubuntu) "Bluetooth firmware for dell xps 13" [High,New]
[12:10] <willcooke> thx davmor2
[12:16] <Trevinho> hikiko: can you please review https://code.launchpad.net/~3v1n0/compiz/scale-multimonitor-workarea/+merge/277561 ?
[12:18] <hikiko> Trevinho: sure in a while
[12:23] <hikiko> Trevinho, approved :D
[13:02] <desrt> hello desktop world
[13:06] <hikiko> Hello desrt
[13:11] <desrt> happy monday, hikiko
[13:12] <hikiko> Happy Monday desrt
[13:12]  * desrt looks at g+ page for event she is planning tomorrow
[13:12] <desrt> 5 'yes', 11 'maybe'
[13:12] <desrt> gonna be fun making the restaurant reservation based on that...
[13:14] <hikiko> What's tomorrow ?
[13:14] <desrt> i'd prefer not to discuss it.  it's a secret meeting.
[13:15] <desrt> but here's a hint: it's something blue
[13:15] <larsu> she said, after bringing it up
[13:15] <larsu> morning desrt
[13:15] <desrt> morning :D
[14:06] <andyrock> "morning"
[14:06] <andyrock> :D
[14:06] <qengho> Oh Monday, thoust vex me.
[14:07] <larsu> hi andyrock and qengho
[14:35] <willcooke> hey qengho andyrock
[14:36] <willcooke> qengho, the icon issues have gone away.  But the "opening a URL from xchat" issue remains.  I will do more testing though to make sure it's not me
[14:39] <qengho> willcooke: Hrm. Thanks.
[15:18] <willcooke> popping out to collect my car from the garage - bbiab
[15:23] <attente> any way to suppress -Werror=unused-parameter when packaging a qmake project?
[15:24] <larsu> attente: add -Wnounused-parameter to CFLAGS?
[15:24] <larsu> QMAKE_CXXFLAGS even :(
[15:25] <larsu> bah, QMAKE_CFLAGS
[15:26] <qengho> willcooke: "2015-09-26 Per Olofsson<EMAIL_ADDRESS>* xdg-mime: Check ~/.config/mimeapps.list instead of ~/.[local/share]/applications/mimeapps.list when looking for default application."   Well! Okay then. Found your xchat/firefox bug.
[15:26] <attente> larsu: ah, ok, i'll try those, thanks
[15:27] <larsu> attente: you can also disable them with a pragma, but that's ugly I think
[15:28] <attente> larsu: yeah. it's coming from generated code (gdbus-codegen). i might try to fix that upstream
[15:39] <willcooke> qengho, \o/
[16:11] <larsu> Laney: I dug a bit deeper on the black flicker issue this afternoon. We need the revert, but slightly amended to also work for windows with client side decorations (this was the difference that caused me to see the bug in 3.16.0 as well)
[16:11] <larsu> Laney: but I doubt this will be accepted upstream - the function is deprecated because the frame sync protocol seems to be considered a dependency of gtk now
[16:15] <Laney> larsu: all of these https://git.gnome.org/browse/gtk+/log/?h=gtk-3-18&qt=grep&q=don't+call+gtk_style_context ?
[16:16] <larsu> Laney: I'm unsure, but the flickering should only be a problem on top-level windows
[16:16] <Laney> worth talking to cosimoc?
[16:16] <larsu> have you noticed any problems with the other widgets?
[16:17] <larsu> not unless we have a prolem
[16:17] <larsu> *problem
[16:17] <larsu> Trevinho: have you ever thought about implementing that frame sync thing in compiz? I guess it's quite hard because it touches lots of things?
[16:18] <Laney> I mean, presumably this commit was done for some reason
[16:18] <Laney> not that the commit message is clear
[16:18] <larsu> which commit?
[16:19] <Laney> the one you want to revert
[16:19] <larsu> yes, the function is deprecated
[16:19] <larsu> widgets are supposed to draw their own background
[16:20] <larsu> which happens too late on compiz, because it doesn't wait for the signal from gtk that the frame is done
[16:20] <larsu> calling set_background() sets the background color of the x window
[16:21] <larsu> so we see an incomplete frame, but because the color is the same as the background color, it's not as noticable
[16:24] <Laney> I see
[16:24] <Laney> thanks for the info
[16:24] <larsu> did you already upload the revert?
[16:24] <Laney> want to hear from Trevinho about the frame sync stuff, that would be nicer depending on how bad it would be to do
[16:24] <Laney> no
[16:24] <Laney> I'm not that fast anyway /o\
[16:25] <larsu> that's good - I'll propose a patch in a bit that makes it work for csd windows as well
[16:26] <Laney> not going to be for today at any rate
[16:26] <Laney> but still want to hear about fixing it properly
[16:26] <larsu> ya, of course
[16:27] <Laney> thanks for the investigation!
[16:27] <larsu> :)
[16:37] <larsu> Laney: proposed at https://code.launchpad.net/~larsu/gtk/remove-black-flicker/+merge/277595
[16:40] <Trevinho> larsu: mh, sorry I was otp...
[16:50] <Trevinho> larsu: I saw it at the time I was looking at the mir gdk backend, but I didn't know it was in X as well
[17:10] <larsu> Trevinho: it has been for a couple of years :)
[17:40] <seb128> back!
[17:48] <willcooke> calling it a day
[17:48] <willcooke> g'night all
[21:07]  * qengho afk.
[23:40] <n8s> hi all
[23:40] <n8s> this may be tricky... but i have to ask
[23:41] <n8s> i have a laptop fine-tuned with all the apps and settings to my liking. it has been a pita to set it up. Now im ready to make the move on my desktop to ubuntu and say byebye to windows 10, ¿is there any way to "clone" the settings and installed packages automagically?
[23:44] <sarnold> n8s: dpkg --get-selections and --set-selections may be able to do the packages for you, though actually getting apt to follow those directions may be more work; I'm just content to apt-get install the packages I need when I need them, though, to avoid installing and updating software I don't use often..
[23:45] <sarnold> n8s: you can copy your home directory over, that ought to be a good starting point for most user-facing programs; i'd cherry pick files from /etc/ as needed for the system-wide configurations
[23:45] <sarnold> n8s: many people store their /etc and dotfiles in git or something similar, see etckeeper for a quick intro there
[23:45] <n8s> thank for pointing me that, sounds interesting
[23:46] <n8s> however if there is nothing that "migrates" it automatically, i guess i will do what you said first and make it work as i need it
[23:48] <n8s> howewer... i find surprising that ubuntu lacks an utility for doing this. i understand that this can be perfectly done with CLI+patience combo, but some user friendly solution would be awe
[23:49] <n8s> anyway, thanks a lot sarnold
[23:49] <sarnold> n8s: if you're installing dozens to thousands of machines, there's options that are probably worth exploring :)
[23:50] <sarnold> n8s: but for two systems, there's not much pre-built


[14:52] <rbasak> I think lp:ubuntu/+source/chrony would benefit from a git repack please
[14:53] <tomwardill> rbasak: the whole of git.lp is slow atm, we're looking at it
[14:53] <tomwardill> load average is > 100 for no apparent reason
[14:53] <rbasak> Ah OK
[14:53] <tomwardill> in fact, I'll do a header update :)
[16:31] <ngaio> Greetings! Can Launchpad do continuous translations from a git branch hosted on Launchpad? In 2017, the answer was "not yet". And today? :-)
[16:36] <cjwatson> We landed one of the necessary pieces recently, but the overall answer is still "not yet".
[16:36] <cjwatson> rbasak: Possibly a bit better now?  Killing mlocate with fire seems to have helped
[16:54] <rbasak> cjwatson: if I retry the clone, it seems to take a long time before I even get any progress output (still waiting)
[16:54] <rbasak> No rush to fix
[16:54] <rbasak> (I'm not blocked or anything)


[07:54] <zyga> hello
[08:02] <dholbach> good morning
[08:50] <noizer> good morning
[09:32] <JamesTait> Good morning all!  Happy Tuesday, and happy Pancake Day! 🙌
[09:33] <diwic> JamesTait, good morning! What do I need to install to see that unicode character? It is not visible on OOTB Ubuntu 14.04, at least.
[09:34] <JamesTait> diwic, you're not the first person to ask, but I still don't know the answer.  I might have had to install a specific font for it, not sure.
[09:34] <dholbach> diwic, fonts-symbola?
[09:34] <dholbach> I searched for it in gucharmap and right-clicked on it
[09:35] <JamesTait> dholbach, that does sound familiar, actually.
[09:35] <dholbach> mh... then I don't know :)
[09:35] <diwic> dholbach, thanks, but I can't find fonts-symbola in the archive...?
[09:36] <dholbach> diwic, I'm on xenial
[09:36] <JamesTait> In fact I think someone on IRC told me to install that, let me check my logs.
[09:36] <dholbach> Description: symbolic font providing emoji characters from Unicode 7.0
[09:36] <JamesTait> ttf-ancient-fonts-symbola?
[09:37] <diwic> interesting, it appears on vivid and nothing below that
[09:37] <dholbach> that's what it provides in 16.04, yes
[09:37] <dholbach> 14.04 is pre-emoji times
[09:37] <diwic> heh
[09:38] <diwic> maybe I can just install the .deb from vivid and hope for the best :p
[09:41] <diwic> it worked! \o/ thanks dholbach and JamesTait
[09:42] <JamesTait> Woohoo!  🙌
[09:42] <dholbach> :)
[09:42] <diwic> or should I say 🙌
[09:43] <diwic> oh well, now on to figuring out how to make snapcraft generate correct security profiles
[09:46] <opny> Hello! After a bit of hassle, I've been able to get running Snapcraft 2.1 on Xenial. I've noticed however the jdk plugin fails now, is this a known issue?
[09:49] <dholbach> opny, fails how?
[09:51] <opny> dholbach, http://paste.ubuntu.com/15000971/
[09:52] <dholbach> opny, I can't find any bug report for it at https://bugs.launchpad.net/snapcraft
[09:53] <opny> dholbach, is it an implicit request?
[09:53] <dholbach> opny, you asked if it was a known issue :)
[09:53] <dholbach> I'm just playing around with the java related examples to see if I can reproduce anything
[09:54] <dholbach> so the java-hello-world example works for me too
[09:54] <dholbach> trying the tomcat example now
[09:54] <opny> dholbach, :) ok.. If you mind I have a github repository for that snap I'm looking to build
[09:55] <dholbach> cool - have a link?
[09:55] <opny> dholbach, https://github.com/muka/kura.snap (Let me a moment to push current status)
[09:57] <dholbach> cool, let me know once you're done
[09:58] <opny> dholbach, ok done
[10:00] <dholbach> taking a look now
[10:02] <dholbach> opny, I can't reproduce the problem
[10:04] <opny> dholbach, uhm ok thank you for checking. May be the case I'm using a mount in virtualbox, will try to move it out
[10:04] <dholbach> maybe you can run  snapcraft clean  and start over? it looks like an apt problem
[10:04] <dholbach> maybe... *shrug*
[10:04] <dholbach> first I thought "maybe a part can't have the name of a snapcraft plugin", but that seemed irrelevant
[10:05] <dholbach> then I saw that build-packages should probably be stage-packages
[10:05] <dholbach> (if you want to bundle things in your snap, as opposed to making sure that certain packages are installed on the machine where you're building the snap)
[10:06] <opny> dholbach, build vs stage packages is a recurring topic for me :) Yes, stage is the appropriate one!
[10:06] <dholbach> :)
[10:11] <opny> dholbach, moving out of shared folder worked.. thanks
[10:12] <dholbach> excellent :-D
[10:18] <asac> elopio: running unit snapcraft tests on master cant find the storeapi etc... i use ./runtests.sh unit
[10:26] <asac> ok seems thats xenial only
[10:54]  * zyga pushed https://github.com/ubuntu-core/snappy/pull/468
[11:03] <opny> Hi, in snapcraft can I specify a git branch to pull?
[11:04] <dholbach> opny, yes - take a look at examples/godd/snapcraft.yaml
[11:05] <opny> dholbach, thank you
[11:10] <opny> dholbach, I do not see any branch ref https://github.com/ubuntu-core/snapcraft/blob/master/examples/godd/snapcraft.yaml#L15
[11:10] <opny> dholbach, Is it like url#branch ?
[11:41] <dholbach> opny, use source-branch
[11:48] <dholbach> (type: snapcraft help sources)
[11:50]  * zyga pushed big security part of skills for review
[11:50] <zyga> https://github.com/ubuntu-core/snappy/pull/468
[11:51] <zyga> elopio: do you know why some integration tests fail on all the branches (3 out of 58)
[12:06] <fgimenez> zyga, that was fixed with https://github.com/ubuntu-core/snappy/pull/467, if you rebase to the tip of master all should be fine
[12:21] <zyga> fgimenez: ah, thanks
[12:21] <zyga> fgimenez: I should stop being lazy and use my VPN :)
[13:17] <kyrofa> Good morning
[13:17] <didrocks> hey kyrofa!
[13:17] <kyrofa> didrocks, hey there! Good day so far?
[13:18] <didrocks> kyrofa: so far, yeah :-)
[13:18] <didrocks> how are you?
[13:18] <kyrofa> I'm doing pretty well-- my son has been sleeping kinda bad, which means I have been too :P
[13:19] <didrocks> argh, yeah, coffee time I guess then! :-)
[13:20] <kyrofa> Oh yes ;)
[13:21] <ogra_> ppisati, hmm, is the "linux-snapdragon" you uploaded this morning usable on the dragonboard already ?
[13:22] <ppisati> ogra_: nope
[13:22] <ogra_> k, thx
[14:05] <opny> hi, snapcraft fails while doing its own apt-get update with a  "Hash Sum mismatch". I've edited the sources.list to point to other archives but snapcraft still tries to use the old one
[14:06] <kyrofa> opny, that's usually a temporary error with the archives
[14:06] <kyrofa> opny, just try again in a few minutes
[14:07] <opny> kyrofa, thanks, however, this is making me go crazy!
[14:07] <kyrofa> opny, yeah it kills our CI tests every once in a while too
[14:08] <opny> kyrofa, I have a sed thing to switch around countries and have it working. This work for apt-get but not for snapcraft
[14:12] <kyrofa> You know you're OCD when you realize you have a thousand tabs open and just close the browser completely to start over
[14:16] <ogra_> the bad thing is that over time you end up with all these "session restore" tabs that pile up :P
[14:17] <kyrofa> ogra_, hahaha
[14:17] <kyrofa> ogra_, but those only come up if it exits inappropriately, though
[14:18] <ogra_> well, depends if you actually want that (i have occasions where i just want to archive the tabs and start over to save ram... and kill -9 ...)
[14:20] <kyrofa> ogra_, ha!
[14:22] <JamesTait> So glad to know I'm not the only one who has that problem.
[14:23] <kyrofa> JamesTait, which one, slaughtering firefox to archive your tabs, or OCD?
[14:24] <JamesTait> kyrofa, just the "ZOMG, I have 7 Firefox windows with 54 tabs in each, how did this happen?" problem.
[14:25] <kyrofa> JamesTait, ah, yes exactly. "Kill them all! Go away! I don't care what I was in the middle of doing, I can't keep track of all this!"
[14:25] <JamesTait> And they're killing tab groups!
[14:26] <JamesTait> So instead I made an attempt to organise things into bookmark folders, and then "open all in tabs" when I want to work on something specific.
[14:26] <JamesTait> With varying degrees of success....
[14:26] <kyrofa> Interesting idea
[14:27] <JamesTait> I'm still trialling it.  It's taking some time to get used to and to be disciplined about.
[14:33] <kyrofa> elopio, I'm assuming you can't hear me :P
[14:35] <jdstrand> dholbach: hi! would you mind looking at my response to your comment to my MP?
[14:35] <kyrofa> elopio, if you have headphones in, and aren't hearing me... what you are listening to? Are you muted and just have headphones on?
[14:36] <dholbach> jdstrand, I'm in calls for the next hour, but could take a look later on
[14:36] <kyrofa> elopio, so this is creepy. I'll get out so I don't feel like I'm spying on you :P . Ping me when you're ready?
[14:37] <kyrofa> Ping timeout... that might explain some things
[14:40] <kyrofa> elopio, you there now?
[14:41] <JamesTait> jdstrand, I just re-merged that branch locally and get the same, but I didn't see it yesterday.  Not sure what changed since then.
[14:41] <elopio> kyrofa: I can't see you.
[14:41] <elopio> nor hear you.
[14:41] <kyrofa> elopio, yeah that was several minutes ago now. Let me hop back in
[14:42] <JamesTait> jdstrand, are there any plans (is it even possible) to split the MP into smaller chunks?  10k lines is a lot to review. ☺
[14:42] <elopio> several minutes ago it also appeared that I was alone.
[14:44] <kyrofa> Creepy
[14:45] <zyga> jdstrand: hey :)
[14:48] <plars> elopio: for the testconfig.json needed by the integration tests, what's the bare minimum we need to make it run?
[14:48] <plars> elopio: also, do the values in it really affect the tests that run?
[14:49] <jdstrand> JamesTait: well, I could remove some of the sr_ bits
[14:50] <jdstrand> JamesTait: but the problem is that it will be large because it is a refactor
[14:50] <jdstrand> well, in part
[14:50] <jdstrand> zyga: hi :)
[14:51] <jdstrand> I did write a ton of new tests for snap.yaml which are adding to the length
[14:52] <JamesTait> jdstrand, yeah, I noticed that, and I'm thankful. ☺
[14:53] <JamesTait> jdstrand, I've been looking at individual commits to try and make the diff smaller.  I just wondered if there was a neat way to split "this factors out the common stuff but maintains feature parity" from "this starts adding snappy 2.0 specific functionality".
[14:54] <elopio> plars: I think now it will just affect the update tests.
[14:54] <elopio> oh well, after a couple of my branches land, that simplify things.
[14:54] <elopio> I need to check in detail if we still need it.
[14:55] <JamesTait> jdstrand, fwiw I've been throwing lots of files at the refactored version and haven't noticed any obvious problems.
[14:55] <kyrofa> elopio, ... it's an invalid python syntax thing?!
[14:56] <jdstrand> JamesTait: well, I can probably do that if is do the refactor, then pull out the 16.04 tests from cr_*, then add the 16.04 sr_* tests. the problem is, that is going to take me a while to make those 3 commits committable since the refactor happened rather organically since I didn't know what needed refactoring until I got into it
[14:56] <jdstrand> JamesTait: but, if that is going to help with the review, I can take the time to do that
[14:56] <plars> elopio: these branches will make it so that all the tests don't try to need that json file?
[14:57] <elopio> plars: no, I think we'll still need it.
[14:57] <jdstrand> JamesTait: re lots of files-- yeah, as part of the testing I plan to run all the snaps through the tools in the old and new versions and do a compare (like I've done with other big changes)
[14:57] <elopio> I'm just not 100% sure why. It had like three functions. I removed one.
[14:58] <elopio> kyrofa: that's what it says, but it's valid syntax.
[14:58] <jdstrand> but as I've been going I've been doing various spot checks
[14:58] <jdstrand> JamesTait: thanks for the testing
[14:59] <elopio> kyrofa: ah, it could be missing the quotes.
[14:59] <plars> elopio: ok, we're trying to run these tests under checkbox, and it's complaining about not having that file. I'm trying to see if there's a way to just avoid it, or if we should just put a stub file there to make it happy, or if we need to generate the real thing
[14:59] <kyrofa> elopio, yeah running that command here doesn't work, though it exits with a shell error, not a python error
[14:59] <elopio> plars: you need to generate the real thing.
[14:59] <JamesTait> jdstrand, yeah, I understand. ☺   I've been there enough times myself!  On the one hand I'd like to do a thorough review of all the changes, on the other hand we'd like to get this landed sooner rather than later.
[15:00] <elopio> plars: I'm with you all morning today. Just give me a second to get ready.
[15:00] <plars> elopio: no rush, I am off to a standup anyway
[15:02] <jdstrand> JamesTait: ok, I will focus on finishing the TODO for this so at the very least, reviewers can run this branch locally on snaps that are flagged for manual review. that will make sure there isn't any more refactoring (it's possible I'll have more for the security bits). then I can look into breaking this up into review parts
[15:03] <jdstrand> dholbach, JamesTait: weird, if I bzr branch anew and the run-tests, it passes
[15:03] <jdstrand> dholbach, JamesTait: the new check_snappy_readme_md() just doesn't use is_squashfs anymore... not sure why it is that way for you guys
[15:04] <JamesTait> jdstrand, interesting - I just did that and it worked for me as well.
[15:04] <jdstrand> dholbach, JamesTait: do you guys need to do 'make clean'?
[15:04]  * JamesTait does that just to be sure.
[15:05] <JamesTait> Nope, that still failed. :-/
[15:06] <jdstrand> diff -Naur -x .bzr ./existing ./newcheckout
[15:06] <jdstrand> might be interesting
[15:06] <dholbach> jdstrand, still fails here - I checked 'bzr {diff,ignored,unknowns}' to have no output... not sure what else to do
[15:08] <jdstrand> it is a mystery, but if I am breaking this up into 3 different parts, then perhaps looking into why it is a problem now is probably not the best use of our time
[15:08] <JamesTait> Weird, this is the same branch that was passing for me last week.
[15:08] <jdstrand> dholbach, JamesTait: you you both on xenial? I am, though I haven't updated in a few days
[15:09] <JamesTait> I'm not - still on Wily.
[15:09] <dholbach> yes, on xenial, up to date
[15:09] <jdstrand> heh
[15:09] <dholbach> hah, a new checkout works
[15:09] <jdstrand> so, probably not xenial specific
[15:09] <dholbach> that'S bizarre
[15:09] <JamesTait> Yeah, odd.
[15:10] <jdstrand> ok, I'm not going to worry about this. I'll keep pushing to the big branch, then I'll break up into smaller branches later
[15:10] <jdstrand> if there is a problem then, we'll dive in
[15:11] <JamesTait> Thanks, jdstrand!
[15:11] <dholbach> jdstrand, I think I know what the problem is - maybe we have a backed-out change in lp:click-reviewers-tools?
[15:12] <dholbach> jdstrand, http://paste.ubuntu.com/15002261/
[15:14] <dholbach> or rather: http://paste.ubuntu.com/15002273/
[15:15] <JamesTait> dholbach, I see http://paste.ubuntu.com/15002276/
[15:16] <JamesTait> Aha!
[15:16] <JamesTait> Heh. ☺
[15:16] <dholbach> :-D
[15:16] <diwic> jdstrand, hi, want to chat about PulseAudio on snappy?
[15:17]  * tedg watches, he wants to define new skills too
[15:17]  * JamesTait defines the new skill Time Travel.
[15:18] <kyrofa> JamesTait, I didn't know Apple was bring Time Machine to Ubuntu Core!
[15:19] <jdstrand> dholbach, JamesTait: are your branches up to date with trunk?
[15:19] <JamesTait> kyrofa, you should see it - it's magical! 😝
[15:19] <dholbach> jdstrand, yes
[15:19] <jdstrand> diwic: give me just a minute
[15:19] <diwic> the "kill daemons" skill sounds like it could fit in an RPG style game
[15:19] <JamesTait> Seems to be.
[15:19] <tedg> Honestly, that would be a sweet snap. Have it come on a device with a HDD or put it on your server.
[15:19] <diwic> jdstrand, sure
[15:20] <jdstrand> cause, I'm at r572 in my trunk
[15:20] <dholbach> jdstrand, are there any previously backed-out changes that might confuse bzr during the merge?
[15:21] <jdstrand> I think I didn't merge 569 and later into the cleanup branch
[15:21]  * JamesTait wonders what on earth he did to have this working locally.
[15:21] <JamesTait> Probably not a make clean. :-/
[15:22] <JamesTait> Bah, school run time.
[15:22] <jdstrand> but I just tried to merge with trunk and it came back clean
[15:22] <jdstrand> ok, pulling in as cherrypicks
[15:23] <jdstrand> and I can reproduce
[15:23] <jdstrand> let me fix that and push
[15:23] <jdstrand> dholbach, JamesTait: ^. thanks for helping me figure that out
[15:24] <dholbach> glad it's going to be fixed soon :-)
[15:28] <jdstrand> dholbach, JamesTait: ok, pushed
[15:28] <jdstrand> diwic: ok
[15:29] <diwic> jdstrand, ok, so what's currently blocking me is access to /dev/snd/*
[15:29] <dholbach> jdstrand, confirming the fix :)
[15:29] <jdstrand> diwic: are you on 15.04 or 16.04?
[15:30] <diwic> jdstrand, 16.04, just upgraded to the latest skill-based images
[15:30] <jdstrand> diwic: ok, things may be a bit rough atm as the skills work is mid-implementation
[15:30] <jdstrand> diwic: let me check something
[15:31] <diwic> jdstrand, to the extent that you think I should defer the snappy work and go do something else and come back in a week or two?
[15:31] <kyrofa> elopio, I can't duplicate that ROS error locally
[15:31] <jdstrand> diwic: alright, since /dev/snd devices aren't implemented as skills yet, hw-assign is what you need to use, and it is still available on 16.04
[15:31] <kyrofa> elopio, I'm really not sure what's happening there
[15:31] <jdstrand> diwic: sudo snappy hw-assign foo.sideload /dev/snd/*
[15:32] <diwic> jdstrand, ok, let me see if that works
[15:32] <elopio> kyrofa: ok, I can try to debug in a docker that's the same as the slave.
[15:33] <jdstrand> diwic: well, we're going to need to understand what pulse needs in order to create the skills for it. I'm confident we can get you unblocked such that we have enough information for developing those skills
[15:33] <kyrofa> elopio, alright. That call happens via a subprocess.check_output, so there should be no problems with the quotes
[15:33] <kyrofa> elopio, I suspect the syntax error is a red herring
[15:33] <diwic> jdstrand, cool. Feel free to ping me if you have further questions about what pulse needs - the hwassign thing does seem to work.
[15:34] <diwic> jdstrand, how does hw-assign work internally, btw?
[15:34] <diwic> jdstrand, is it related to acls somehow?
[15:34] <jdstrand> diwic: great. really, if you have a working snap, I just need it or the link to the branch
[15:35] <jdstrand> diwic: yes. if the specified files are in /sys, then you get apparmor rules, if in /dev, the device gets added to an app-specific cgroup
[15:35] <jdstrand> diwic: https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement
[15:37] <diwic> jdstrand, cool, thanks. I'll need to work some more on the snap - now that I know how to deal with /dev/snd/ - to make sure the sound card loads correctly
[15:37]  * diwic unblocked
[15:38] <jdstrand> \o/
[15:49] <jdstrand> dholbach: did it work for you?
[15:50] <dholbach> jdstrand, yes
 jdstrand, confirming the fix :)
[15:50] <tedg> jdstrand: But won't diwic need to provide a skill for applications to use? I don't understand how he does that.
[15:50] <tedg> jdstrand: Seems he'll need to put some apparmor configuration inside his snap.
[15:50] <jdstrand> dholbach: ah, I took 'confirming' as you were in the process of confirming it and would get back to me. thanks!
[15:50] <dholbach> ah, sorry :)
[15:51] <dholbach> so, yes - fixed, all good! :-D
[15:51] <jdstrand> tedg: that part of the discussion has been deferred since he is unblocked
[15:51] <jdstrand> tedg: but the general idea is this
[15:52] <jdstrand> tedg: people have something that needs to use skills that aren't yet defined. in this case, he needed /dev/snd and mayve some udev stuff
[15:52] <jdstrand> tedg: comes to snappy team, decide if the skill is worthwhile. if it is, define a skill type and the security policy, and add to snappy
[15:52] <jdstrand> tedg: then the app can 'uses' the skill
[15:52] <tedg> jdstrand: That clearly doesn't scale.
[15:53] <JamesTait> jdstrand, dholbach - thanks!
[15:53] <diwic> pulseaudio clients don't need /dev/snd, only the pulseaudio server does.
[15:54] <tedg> jdstrand: And what you're saying is that snappy hardcodes the path to the pulse socket. When in reality, it should be pulse defining that. So if it is "foo" today and "foo1" tomorrow, that's defined in the relationship between the provider and the slot.
[15:54] <jdstrand> tedg: then if the app is going to provide skills, they use existing types to declare what it provides. so, in this case, a socket and a dbus interface. snappy understands these skill types (eventually) and will dynamically create security policy for apps that 'uses' them
[15:54] <tedg> jdstrand: It shouldn't be dependent on a specific version of snappy.
[15:54] <jdstrand> tedg: no, not what I'm saying
[15:54] <jdstrand> tedg: there were two parts
[15:55] <jdstrand> there is what pulse needs from the system that is different from what is already there
[15:55] <jdstrand> and there is what pulse can provide to other snaps
[15:55] <tedg> Sure, I'm worried about the second.
[15:55] <jdstrand> the first part will be a smallish set of skills
[15:55] <jdstrand> that is what I described
[15:55] <jdstrand> the second part is a smallish set of skill *types* that are configurable by the providing snap
[15:56] <jdstrand> eg, lets say for simplicity there is a dbus skill type
[15:56] <jdstrand> snappy knows about this skill type
[15:56] <jdstrand> pulse snap fills in attributes for this skills type so that snappy can do stuff on the fly
[15:57] <jdstrand> pulse provides a pulse skill to the system
[15:57] <jdstrand> apps 'uses' this pulse skill
[15:57] <tedg> Okay, I'm good with that, but then what does the app specify? All the parameters for dbus?
[15:58] <jdstrand> tedg: what attributes pulse can set in its snap skill declaration for dbus is TBD
[15:59] <jdstrand> tedg: bluez, pulse and nm are three snaps we can look at to help define what a dbus skill or set of skills will look like
[15:59] <tedg> Seems like a big TBD, as that's kinda the core of how they integrate with each other.
[15:59] <diwic> side note: pulseaudio uses unix sockets as primary IPC mechanism
[16:00] <tedg> Unfortunately none of those deal with things like AppIDs being part of the dbus path, which is important for us on the phone.
[16:00] <jdstrand> diwic: yes, we have 'socket' right now for that, but there will be some sort of transition to skills for that aiui (which is TBD)
[16:00] <tedg> It would be nice to add a case of that as well.
[16:01] <jdstrand> diwic: and the 'socket' options support both file and abstract sockets
[16:01] <diwic> jdstrand, in snapcraft terms, where should I add 'socket' ?
[16:01] <diwic> i e where in snapcraft.yaml
[16:02] <jdstrand> tedg: today on snappy there is only a singular 'bus-name' (eg, org.freedesktop.pulseaudio)
[16:02]  * ogra_ curses
[16:02] <jdstrand> diwic: alongside 'command' under 'apps'
[16:02] <ogra_> root@anubis:/# snappy build --squashfs snap/
[16:02] <ogra_> 2016/02/09 16:02:18.472075 main.go:40: WARNING: can not create syslog logger
[16:02] <ogra_> open snap/meta/snap.yaml: no such file or directory
[16:02] <jdstrand> diwic: see docs/meta.md in the snappy git tree
[16:02] <tedg> jdstrand: So, in general, I agree that this overall approach makes sense. But when I said that on the list, zyga said that is incorrect.
[16:03] <jdstrand> tedg: but this was far too limiting on two fronts: bluez listens on more than one bus-name and there was no way to define dbus bus policy
[16:03] <tedg> jdstrand: The problem is that is the "easy case" — where there is less interaction and negotiation that is needed. We need to tackle the hard cases too.
[16:04] <diwic> jdstrand, in 16.04 too?
[16:04] <jdstrand> tedg: so the skills work will need to accommodate that. note, I said for the simple case there is a skills type of 'dbus'-- I don't know if that will be more specific or not
[16:04] <jdstrand> diwic: yes
[16:05] <tedg> jdstrand: Before feature freeze next week? ;-)
[16:06] <jdstrand> tedg: now, in terms of APP_ID, that shouldn't be a hard problem. only 'trusted helpers' need to know about APP_ID's. app templated policy won't really have to change here and the trusted helper will only need security policy to allow looking at its own path, etc. it should basically work, but there might be some fine-tuning (possibly an additional skill for trusted helpers, but I doubt it). I don't see a big issue there
[16:06] <jdstrand> tedg: this is snappy, feature freeze isn't until May :P
[16:07] <noizer> hi, short question. is ASCII not support by a snap?
[16:07] <noizer> because i get the following error with my uwsgi LookupError: no codec search functions registered: can't find encoding
[16:08] <tedg> jdstrand: Sure, there could be another simple type, but we're startting to add a lot of simple types then.
[16:09] <tedg> jdstrand: I'm worried we're only covering the trivial cases and not specing out the complex ones early enough. The format doesn't seem like it can handle the complex cases and is becoming more and more difficult to chagne.
[16:10] <jdstrand> tedg: I personally worry about the number types exploding. on touch we tried to keep that low. in snappy 15.04 we did the same. in snappy 16.04 and skills, people said this wasn't a problem and that is the path forward
[16:10] <jdstrand> tedg: types are actually supposed to be pretty easy to add
[16:11] <tedg> jdstrand: I *think* the hooks are going to need richer communication with the security frameworks, which is harder to add. It's hard to see with the current state of things though.
[16:11] <jdstrand> and 16.04 is only supposed to have a smallish number of easily understood types so that we can learn from them to do more complex ones
[16:12] <jdstrand> tedg: mapping click hooks to snappy is not on anyone's 16.04 todo list afaik
[16:12] <tedg> I'm fine as long as "smallish" is "everything we need for phone" :-)
[16:12] <tedg> jdstrand: It is on my todo list, but I can't figure out enough info to make anything other than a shot in the dark.
[16:13] <jdstrand> tedg: I though 'Personal' work was not for 16.04. did that change?
[16:14] <jdstrand> also, while I am speaking rather authoritatively here, skills are Gustavo's and zyga's baby-- I'm only providing input for the security bits and bringing up other things as needed (ie, I'm thinking about touch too)
[16:15] <tedg> jdstrand: Getting snaps so they could be installed on desktop or phone is a desirable feature, and we'd want those snaps to work into the future. So "personal" is not, but getting apps that will work for personal is.
[16:18] <fgimenez> elopio, sorry, don't know how i ended in the internal channel :D
[16:20] <jdstrand> tedg: I think getting leaf desktop snaps will be fine. that is different from a trusted helper and different than a click with lots of hooks, both I interpreted in the realms of 'Personal'
[16:23] <tedg> jdstrand: Certainly desktop is easier than phone, but while no one has decided anything, phone apps are on the table still as well.
[16:24] <zyga> jdstrand: I refreshed bool-file skill, would love if you can have a 2nd look at the security side
[16:25] <elopio> fgimenez: I think this is ready: https://github.com/ubuntu-core/snappy-jenkins/pull/72
[16:27] <fgimenez> elopio, thx let's merge after travis finishes
[16:27] <jdstrand> zyga: ack-- saw it, haven't gotten out of irc questions yet :)
[16:31] <zyga> jdstrand: thanks, if you have any questions about it we can also talk on irc
[16:32] <jdstrand> ok
[16:37] <JamesTait> jdstrand, what gotchas would I need to look out for if I wanted to use click-reviewers-tools as a library in the Store, rather than shelling out to a subprocess?  Is there a stable public API?
[16:43] <jdstrand> JamesTait: I think to do that well, we'd want to break what is in click-review out into a library and have that be the api. then click-review and you could use that
[16:43]  * JamesTait nods
[16:43] <jdstrand> JamesTait: click-review itself has been very stable and not changed much (until this cleanup branch)
[16:44] <jdstrand> so I think breaking out those bits would provide a good api
[16:45] <JamesTait> It's not something I'm looking to do immediately, unless it turns out to be so trivial it'd just fit into existing work, but as a future path I think it'd be preferable.
[16:47] <plars> elopio: I think it looks like we won't need much (anything?) in that json file if we aren't using the update/rollback tests, but it will still error if it can't read the file. So we can stub one, but it seems to read from a hardcoded relative path, that picks up its base path from the GOPATH on the build system
[16:48] <plars> elopio: would a parameter for this testconfig path be ok to add?
[16:48] <plars> elopio: or do you have a better suggestion
[16:48] <JamesTait> jdstrand, also, this is totally work that I'd expect the Store team to take on - just to be clear. 😉
[16:49] <jdstrand> ack
[16:49] <elopio> plars: it's only used for update, rollback and the info_test.
[16:49] <elopio> I'm not sure if you want to run the info test.
[16:49] <elopio> if you don't want anything to do with it, I can catch the file not existent error, and put a default config.
[16:50] <JamesTait> We've got a Trello card open for it, I'm just going to add some thoughts to it for now and we'll see where it fits in.
[16:50] <plars> elopio: but all tests try to read it: Error reading config: open integration-tests/data/output/testconfig.json: no such file or directory
[16:50] <jdstrand> makes sense
[16:50] <elopio> plars: yes, because all tests check if they are in the middle of an update or rollback.
[16:51] <elopio> I can put a default false in there.
[16:51] <plars> elopio: or we could probably just generate a json file with "{}" in it right?
[16:52] <elopio> plars: I'm not sure what will happen in that case. Maybe json.Unmarshal sets default values, or maybe it fails because of the missing fields.
[16:52] <elopio> plars: but there's something more important to solve here.
[16:53] <elopio> that integration-tests/data/ path is important, not just for the config. All the test snaps are in there.
[16:53] <elopio> so it's not just the binary what you need. You also need the test data.
[16:53] <plars> elopio: oh, so it's not enough just to ship the test binary, there's other data there too it needs?
[16:53] <plars> got it
[16:54] <elopio> yes. The config is not too important now. But the others are.
[16:54] <elopio> plars: can you try creating that testconfig.json to see if the binary finds it?
[16:54] <plars> elopio: I see that now... elopio but those don't get built when I build the integration tests with go test -d
[16:55] <plars> err.. -c
[16:55] <elopio> nop. Just the code goes into the binary, no data files.
[16:56] <plars> elopio: yeah, we'll give that a try. What will I need to force it to build all those other snaps? and will they need to be in that exact directory structure?
[16:57] <olli_> ho
[16:57] <elopio> plars: you don't need to build the snaps, they are build during the tests. You can't include them in the binary, afaik. You'll have to copy them to the testbed, as we do here with adt-run.
[16:57] <olli_> I love xchat and how it moves keyboard input between channels when starting up
[16:57] <fgimenez> elopio, this is done https://hub.docker.com/r/ubuntucore/snappy-jenkins-slave-xenial/builds/ we can build the new base image now
[16:57] <elopio> fgimenez: let me first re-run the tests on my branch and merge it.
[16:58] <fgimenez> elopio, the error from travis should be fixed with the latest changes too, ok
[17:09] <kyrofa> olli_, so you don't actually know where you pinged unless you look through them all? Yeah I love that too
[17:49] <jerryG> Chipaca: have you done a coredump ?
[18:24] <jdstrand> beuno, matiasb: I just uploaded snappy-debug to the store for rolling only, and 'snap find snappy-debug' doesn't see it. is this because the device is not authenticated with the store?
[18:25] <jdstrand> beuno, matiasb: it is published afaics
[18:25] <plars> elopio: getting a log of errors, even if I put the testconfig.json and snaps data there: http://paste.ubuntu.com/15003786/
[18:25] <jdstrand> beuno, matiasb: in the logs: snapd[3217]: 2016/02/09 18:20:36.827803 response.go:118: method "GET" not allowed
[18:26] <jdstrand> beuno, matiasb: /usr/bin/snapd[3217]: daemon.go:153: DEBUG: uid=0;@ GET /2.0/snaps?q=snappy-debug&sources=store 630.821587ms 200
[18:27] <elopio> plars: is that an allsnaps image generated with mvo's latest udf?
[18:27] <matiasb> jdstrand, let me check
[18:28] <plars> elopio: no
[18:28] <plars> elopio: it needs to be in order to work?
[18:28] <elopio> plars: if you have a 1504 image, you have to run the tests from the 1504 branch. If you want to run tests in rollilng, you need to use mvo's allsnaps image.
[18:29] <elopio> https://people.canonical.com/~mvo/all-snaps/
[18:29] <jdstrand> matiasb: thanks
[18:30] <elopio> pindonga: how can I upload a snap to the edge channel?
[18:30] <plars> elopio: so, the test binary I built was from ubuntu-core/snappy trunk, with your patches to enable the parameters cherry-picked on top of it
[18:30] <pindonga> elopio, setting channels is not yet supported in the api, so I think you need to upload then go to the web ui and set the channels for the new verison
[18:31] <elopio> pindonga: do you know if that will be ready for 1604?
[18:31] <elopio> plars: yes, trunk needs allsnaps.
[18:31] <pindonga> elopio, depends on how strong you can make your case for beuno  :)
[18:31] <plars> elopio: ack, thanks
[18:31] <pindonga> elopio, I'd start by filing a bug for it
[18:31] <matiasb> jdstrand, afaict, the revno is published and it looks ok; we would need to confirm that the rolling snappy client is not sending a framework when hitting CPI <- mvo could you confirm?
[18:32] <pindonga> elopio, and possibly listing all bugs related to the upload api
[18:32] <jdstrand> mvo is out sick
[18:32] <pindonga> so that we can see what's really missing and consider the effort
[18:32] <elopio> pindonga: well, I need squashfs first autoreview first, so I won't push to much with the channel.
[18:32] <pindonga> elopio, as said, autoreview depends on click-reviewers tools
[18:32] <pindonga> so, not something we can change in the store itself
[18:32] <jdstrand> matiasb: perhaps Chipaca could help in mvo's absense?
[18:32] <elopio> pindonga: right, but is that beuno's team too?
[18:32] <pindonga> not really
[18:33] <pindonga> it's snappy team I think? (jdstrand, mvo, ...?)
[18:33] <matiasb> jdstrand, did you get any results when searching?  So I can make the two requests in parallel to two different teams :D
[18:33] <jdstrand> matiasb: no
[18:34] <jdstrand> pindonga: I wasn't following the conversation. I can say that snap.yaml changes for the review tools are in progress and squashfs in the store is after that
[18:34] <elopio> jdstrand: awesome!
[18:34] <jdstrand> matiasb: $ snap find snappy-debug
[18:34] <jdstrand> error: no snaps found for "snappy-debug"
[18:35] <jdstrand> $ snap find snappy-debug.canonical
[18:35] <jdstrand> error: no snaps found for "snappy-debug.canonical"
[18:35] <nessita> jdstrand, you need to be running this commit of snap command (or newer) https://github.com/ubuntu-core/snappy/commit/d18e35ef719a418332cd14eb61ec3841ff2a535f
[18:35] <matiasb> jdstrand, odd, everything looks ok, and hitting the index directly, the search seems to return the expected result
[18:36] <jdstrand> nessita: I'm on latest all snaps images from mvo...
[18:36] <jdstrand> let me see if I can determine if that is in it
[18:37] <nessita> jdstrand, if you could grab the raw http request is being done, it would be helpful
[18:37] <nessita> the headers being sent is key
[18:38] <jdstrand> ok... tcpdump not on the device...
[18:39] <nessita> jdstrand, as a summary, if your snap search is sending the framework ubuntu-core-15.04-dev1 only revnos with that framework will be returned, and revno 12 opf snappy-debug does not have any framework (which is correct)
[18:42] <jdstrand> nessita: hrmm, this is https so I don't seem to be able to see the headers
[18:43]  * jdstrand goes back at looking at changes in the ppa
[18:44] <nessita> jdstrand, I guess source inspection with go is not possible?
[18:45] <jdstrand> nessita: that is what I am doing. the current os snap has an earlier version than what is in the ppa so I'm just tracking it all down
[18:47] <jdstrand> nessita: based on the diff for 1.7.3ubuntu1-1+1108~ubuntu16.04.1 , which is what is on the image, the change should be on the image
[18:48] <jdstrand> nessita: could this have something to do with it not authenticating with the store, ala, that other thread?
[18:48] <nessita> jdstrand, nopes, since search is anonymous: https://search.apps.ubuntu.com/api/v1/package/snappy-debug.canonical
[18:48] <nessita> https://search.apps.ubuntu.com/api/v1/search?q=snappy-debug
[18:48] <nessita> jdstrand, not authenticating could be a 401 when downloading the package, but this is not the case
[18:49] <jdstrand> this is what I see in the log:
[18:49] <nessita> jdstrand, from those package index URLs, you can see a search (with no headers) returns your package
[18:49] <jdstrand> /usr/bin/snapd[3217]: response.go:118: method "GET" not allowed
[18:49] <jdstrand> /usr/bin/snapd[3217]: daemon.go:153: DEBUG: uid=1000;@ GET /2.0/snaps?q=snappy-debug&sources=store 1.059970664s 200
[18:49] <nessita> jdstrand, that URL is not store "server" side, may be something internal
[18:49] <jdstrand> hmm
[18:50] <jdstrand> I guess I'll file a bug
[18:50] <nessita> the URL for searching is https://search.apps.ubuntu.com/api/v1/search?<params>
[18:50] <nessita> plus headers
[18:57] <jdstrand> Chipaca, matiasb, nessita: fyi, https://bugs.launchpad.net/snappy/+bug/1543731
[18:59] <matiasb> ack
[19:00] <elopio> Chipaca: do you have the credentials of the canonical account in the store? I need it to get the spi tests working.
[19:00] <jerryG> any1 been able to create coredumps successfully?
[20:18] <wiggleworm> I am getting a java error when I try to start my snap - "nohup: failed to run java: no such file or directory
[20:18] <wiggleworm> any thoughts on how to fix this?
[20:19] <wiggleworm> Or better yet, Am i not dofing somthing correct in snapcraft?
[23:02] <jerryG> kgunn: are you there?
[23:11] <kgunn> jerryG: i'm literally needing to step away just now...feel free to leave query
[23:23] <jerryG> kgunn: kk lol.  ill wait till tomorrow :}


[19:56] <nzt48> OK, I finally figured out my problem, so instead of runing:
[19:57] <nzt48> debian/scripts/misc/getabis 5.4.0 67.75
[19:57] <nzt48> I should have run:
[19:57] <nzt48> debian/scripts/misc/getabis 5.4.0 67.75~18.04.1
[19:58] <nzt48> That solved all the problems
[19:59] <nzt48> Thanks arighi and klebers for your help, and have a nice weekend!
[20:50] <arighi> glad you solved the problem nzt48, thanks for the update!
[20:56] <nzt48> arighi :^D


[03:17] <cwillu> dtchen, interested in hearing about 100%cpu pulseaudio bugs in snd-intel-hda on karmic?
[03:18] <dtchen> sure
[03:18] <dtchen> it'll be somewhat more useful if you have a current bug filed with https://wiki.ubuntu.com/PulseAudio/Log attached
[03:18] <cwillu> does ubuntu-bug supply that?
[03:19] <dtchen> everything but the stuff referenced in the URL
[03:19] <cwillu> okay
[03:19] <dtchen> of course, a description of what you were doing to trigger it would be useful as well
[03:20] <dtchen> OTOH, if you're talking about something libsdl-based, don't even bother filing a bug.
[03:20] <cwillu> oh
[03:20] <cwillu> sdl is a known issue?
[03:20] <dtchen> sdl is a known issue. It's resolved in libsdl svn trunk.
[03:21] <cwillu> upstream's sdl trunk I take it?
[03:21] <dtchen> yes
[03:21] <dtchen> I'll roll some debs in the ubuntu-audio-dev PPA sometime this weekend
[03:22] <dtchen> you essentially need to lift src/audio/{alsa,pulse} from svn trunk
[03:23] <cwillu> dtchen, a tarball from oct27 is probably recent enough?, or should I do a full checkout?
[03:24] <TheMuso> dtchen: Interesting. I think we will need sed patches into lucid early.
[03:24] <dtchen> cwillu: oct27 will suffice
[03:26]  * cwillu ./configure's
[03:29] <dtchen> TheMuso: sed or sdl?
[03:30] <dtchen> (or sid? I'm a bit confused)
[03:30] <cwillu> dtchen, or said
[03:30] <cwillu> "I think we will need said patches"
[03:32] <dtchen> ah, yes
[03:33] <dtchen> well, with any luck, I won't be chained to my $work desk this weekend
[03:34] <TheMuso> dtchen: SDL
[03:34] <dtchen> TheMuso: ok, right
[03:35] <cwillu> once of those rare occurrences where almost all the possible completions rendered into the same meaning :p
[03:37] <panda|phenom> ericm-Zzzz, hi, still awake :) ?
[03:37] <ericm> panda|phenom, I'm awake :)
[03:37] <panda|phenom> ericm, morning, i have find a strange issue, which lead me suspect timer is not accurate on my board
[03:38] <panda|phenom> ericm, is there any quick and easy to check whether kernel have time shifting?
[03:38] <ericm> panda|phenom, which clock source are you using?
[03:38] <ericm> check your arch/arm/mach-xxx/time.c
[03:39] <ericm> I don't know any tool to check time drift - some ntp tool may help
[03:44] <panda|phenom> ericm, em, i see, i will check with LTP for timer test case
[03:46] <ericm> the most inaccurate clock source is normally the onchip PLL generated signals, which cannot simply be 10ms per jiffy, check that - or if you need absolute accuracy, use RTC or NTP (provided you have network connection)
[03:49] <panda|phenom> ericm, well, the streaming server running in my system use event mechnism to send out packets
[03:50] <panda|phenom> ericm, calculate the next packet expected send out time and then set to a timer chain
[03:51] <ericm> panda|phenom, OK I see
[03:51] <panda|phenom> ericm, those timer are all around 40~60 ms, so if there is a tiny time shift
[03:51] <panda|phenom> ericm, then client will complain about those delayed packets and ask server to re-post
[03:52] <panda|phenom> ericm, which may cause my system very chokeniess ...
[03:53] <ericm> panda|phenom, I know - any source of your time.c to check?
[09:36] <dholbach> hi guys
[09:36] <dholbach> can anybody try to shed some light on https://bugs.launchpad.net/ubuntu/+bug/464411 ?
[09:36] <ubot3`> Malone bug 464411 in linux "After upgrade to Karmic, root partition (sda1) is missing /dev/sda1 is missing from /dev/disk/by-uuid" [Undecided,New]
[09:47] <smb> dholbach, From what I read in the bug, not really much more than it sounds like a userspace problem
[09:47] <smb> as the partition shows up in proc/partitions and can be mounted manually
[09:47] <dholbach> smb: do you think you could pinpoint it to some package?
[09:47] <smb> Just getting the uuid fails
[09:48] <smb> whatever package blkid is in
[09:48] <smb> i believe that is udev but lemme check
[09:49] <smb> dholbach, ah, util-linux
[09:49] <dholbach> great
[09:50]  * dholbach updated the bug report
[09:50] <apw> dholbach, yeah it seems that udev saw the partition and made the device as they can mount it manually ... so i think its userspace after udev which has failed.  from the output in the bug i think blkid is bust
[09:51] <dholbach> what can they do to debug / fix it?
[09:51] <smb> dholbach, apw has added some comments
[09:52] <smb> basically check with dumpe2fs, to see what that returns
[09:52] <dholbach> thanks a bunch smb and apw
[09:52] <dholbach> it's a guy I know from the Berlin team
[09:52] <apw> dholbach, np.  who owns util-linux
[09:52] <dholbach> apw: somebody who touched it last :/
[09:53] <dholbach> or Keybuk maybe, I dunno?
[09:53] <apw> yeah keybuk is fingered
[09:57] <apw> dholbach, might be worth having it have a task on both that an linux till its confirmed either way, so we can continue to track it
[09:58] <dholbach> sure
[10:14] <MsMaco> smb: quite a bit of blkid fail it sounds like
[10:14] <MsMaco> was someone in #ubuntu-bugs earlier saying debian stable's blkid recognizes zfs & ufs, but karmic does not
[10:14] <MsMaco> said arch's worked right too. arch & karmic are both using 2.16
[10:16] <smb> MsMaco, Generally it should not be a complete fail, as at least mine does find my sda1. On the other hand I have ext4 here.
[10:17] <smb> Hopefully the e2fsdump shows what is in those headers to compare
[10:17] <MsMaco> oh im not saying it always fails :P just "wow, ive heard about 2 bugs in it in less than 12 hours!"
[10:18] <smb> If it is not more, then I am glad. :) Nevertheless quite shocking when you reboot and get told your partition went away
[10:34] <^arky^> Hi, Anyone seen these ALSA underrun and wake errors http://pastebin.ubuntu.com/304936/
[11:17] <apw> dholbach, ok thats pretty much confirmed as a bug in blkid, it seems there is a patch upstream for it now ... so we likely need to get scott on the case
[11:18] <dholbach> apw: nice
[11:18] <dholbach> that'll make the world a better place
[11:55] <bigon> hi, is it "normal" that there is no iwlagn driver on the alternate cd?
[14:58] <Keybuk> apw, cking_: http://people.canonical.com/~scott/new-open-sort.png
[14:59] <cking_> Keybuk, nice peak on the first second or so
[14:59] <apw> Keybuk, woh ... what sort order you using for open?
[15:00] <Keybuk> apw: an obvious one
[15:00] <cking_> how much improvement is that?
[15:00] <Keybuk> so obvious it never occurred to us
[15:00] <Keybuk> it's still "slow", but not as slow
[15:00] <Keybuk> takes about a second off the dead bit
[15:00] <apw> heh ... so tell telll
[15:00] <cking_> ..we want to know :-)
[15:02] <Keybuk> sorted the paths by e2fs inode group, and ino_t
[15:02] <apw> doh ... pretty obvious
[15:03] <apw> Keybuk, nice one
[15:03] <apw> Keybuk, why is there two sets?  dirs and then files ?
[15:04] <Keybuk> inode preloads, then opens
[15:04] <Keybuk> not sure what the third ghost set is
[15:04] <ghostcube> -_-
[15:05] <cking_> 3rd set @ ~5 secs/
[15:05] <cking_> ?
[15:07] <Keybuk> right
[15:07] <cking_> w/o further analysis it's hard to say from a graph
[15:09] <Keybuk> yeah
[18:39] <ricklerre1> Hey guys, I just fresh installed Karmic desktop. On Jaunty I had to install and then boot into the server kernel in order to run vmware player with a 64-bit guest.  that vm currently won't run in the karmic linux-generic kernel.  I installed the linux-server kernel, but it won't boot into it.  any suggestions on how to boot into the kernel OR how to make vmware player run?
[20:50] <ricklerre> Hey all, I tried to install linux-server kernel on a desktop install of karmic, but it didn't boot into that kernel and the option doesn't exist appear on the grub menu, is there soemthing further that I need to do?
[21:06] <MsMaco> ricklerre: run "sudo update-grub"? we're not sure why grub's not updating its list of kernels properly
[21:13] <ricklerre> I gave that a try
[21:14] <ricklerre> I also ran "os probe" and then "update-grub", both non-starters
[21:15] <ricklerre> is there a manual method?
[21:27] <joaopinto> ricklerre, /etc/grub.d/40_custom
[21:27] <joaopinto> ricklerre, but you should file a bug report
[21:27] <ricklerre> ok, will do
[21:28] <ricklerre> any particular project?
[21:33] <joaopinto> ricklerre, ubuntu-bug grub-common
[21:33] <joaopinto> erm wait
[21:33] <joaopinto> I guess the detection is a task from os-prober
[21:33] <joaopinto> for
[21:34] <ricklerre> so `ubuntu-bug os-prober` ?
[21:35] <joaopinto> yup
[21:35] <joaopinto> ricklerre, well, to be honest, is not clear for me
[21:36] <joaopinto> there is a /etc/grub.d/10_linux which does check on /boot
[21:36] <joaopinto> and that one belongs to the grub-common package


[04:14] <colonelqubit> Is it poor form for me to triage my own bugs?
[04:14] <colonelqubit> I've had hibernation problems for a while and had an open bug for a month (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/366264)
[04:14] <ubot4> Launchpad bug 366264 in linux "[Dell XPS m1530] Resume fails after hibernate/suspend" [Undecided,New]
[04:14] <micahg> colonelqubit: triage no, confirm yes
[04:15] <colonelqubit> What about marking importance?
[04:16] <colonelqubit> jtholmes was nice enough to tag the bug "hibernation", but there's no Importance level specified yet.
[04:17] <lifeless> colonelqubit: importance is project-wide, not individual wide
[04:18] <micahg> colonelqubit: I don't work with the kernel package, so I can't be of much help
[04:18] <colonelqubit> lifeless: yes. That's why I was wondering if I should be the one marking importance, seeing as how I kind of have a personal bias on this one bug... :-)
[04:18] <colonelqubit> micahg: Should I ask people in #ubuntu-kernel ?
[04:19] <micahg> colonelqubit: probably worth a shot
[04:19] <colonelqubit> micahg: thanks
[06:38] <YoBoY> hi
[06:38] <micahg> hi
[15:29] <skroon> looking for kubuntu package: clicking on logout in the KDE menu causes my machine to _shut down_ (default behaviour after upgrades - no configuration done)
[15:30] <skroon> any suggestions for a workaround also appreciated
[15:33] <skroon> any suggestions which package to report the bug under?
[15:59] <bddebian> Boo
[16:25] <hggdh> bdmurray, ping
[16:26] <bdmurray> hggdh: howdy
[16:29] <hggdh> bdmurray, morning, can you please renew my bugs-control membership?
[16:29] <bdmurray> hggdh: your lp id is hggdh2 correct?
[16:29] <hggdh> bdmurray, correct
[16:31] <plars> bdmurray: while you're at it... could I get an extension on my by a few weeks?  I've got that list I showed you down to <200 bugs, but it will take me longer than the 40 hours or so I have left
[16:31] <plars> s/my/mine
[16:33] <micahg> how often does membership expire?
[16:33] <hggdh> micahg, yearly
[16:34] <micahg> ok
[16:46] <G__81> hi hggdh
[16:48] <hggdh> hi G__81
[16:48] <G__81> hggdh, i did some triaging of bugs and then i couldnt come online so can i apply for the membership now ?
[16:50] <hggdh> G__81, it all depends on experience -- how many you triaged, how correct was your triaging, etc
[16:50] <hggdh> G__81, if I remember correctly, you were inactive for a long time, and got back a few weeks ago
[16:50] <G__81> https://bugs.launchpad.net/~balajig81
[16:50] <hggdh> looking
[16:50] <G__81> inactive for long time ?
[16:51] <hggdh> G__81, when I looked you up, you had pretty much no karma. Although I do not consider karma a precise indicator, having a *very* small karma shows one has been inactive
[16:52] <G__81> no karma >
[16:52] <G__81> :) i ve 43 :D
[16:57] <sectech> heh then I am screwed...
[16:57] <hggdh> heh. Well, yes, that's a pretty small karma... even I, not touching that many bugs/questions/etc in the last few months have a bit more than that...
[16:57]  * micahg knows karma :)
[16:57] <hggdh> again -- karma is *not* an indicator of being good on something, but it *is* an indicator of activity
[16:57] <sectech> If I can ever kick this warcraft addiction maybe I can do something productive.
[16:58] <hggdh> :-)
[16:59] <sectech> Insufficient funds should do the trick...
[17:02] <hggdh> G__81, I can see only two bugs with actions from you in 2009...
[17:02] <sectech> hggdh,  If I end up expiring and eventually want to come back it wouldn't be a problem would it? Pending I actually start triaging more bugs?
[17:02] <sectech> Not sure when I expire...
[17:03] <hggdh> sectech, er, are you planning your death? ;-)
[17:03] <hggdh> and, ah, reincarnation?
[17:03] <sectech> hggdh,  lol no.... but I seem to have lost motivation for IT work at the moment...  I imagine it will come back in time.
[17:04] <hggdh> sectech, you would be reinstated, provided you show new work (as everybody else)
[17:04] <sectech> okay.
[17:05] <G__81> hggdh, only 2 bugs ? no it cannot be on the other day i had done nearly 5-6 bugs
[17:05] <G__81> i still remember that
[17:08] <hggdh> G__81, please give me an URL with all your bugs (and yes, I could get it myself, but please look at it as a check you know where to find it)
[17:09] <hggdh> and -- sectech -- I would also be in the same boat if I leave for a while
[17:10] <sectech> fair is fair...
[17:24] <micahg> hggdh: I'm been triaging over a month, so I can go back over my Incompletes now and poke people :)
[17:29] <hggdh> micahg, yes... :-)
[17:31] <G__81> hggdh, there are actually 3 bugs in total so what i would do is triage more bugs and then think about the next step
[17:32] <G__81> and what happened to your application ?
[17:36] <hggdh> G__81, yes, this is the issue: not enough bugs to show to the -control members you know what you are doing...
[17:36] <hggdh> G__81, I guess Brian already took care of my renewal
[17:36] <G__81> you became an ubuntu member ?
[17:37] <hggdh> yes, I did... I finally came out of the closet ;-)
[17:38] <G__81> oh great congrats
[17:39] <hggdh> thanks
[17:48] <G__81> hggdh, 5 a day should be fine right ?
[17:48] <G__81> :)
[18:00] <hggdh> G__81, yes, it should... keep in mind that it is not only the number of bugs you triage, but *how* you do it
[18:00] <G__81> yes
[18:00] <G__81> i understand
[18:01] <G__81> i am more focused on bug fixing
[18:01] <G__81> :)
[18:02] <hggdh> :-)
[18:06] <kklimonda> hggdh: bug 382391 is wishlist... confirmed?
[18:06] <ubot4> Launchpad bug 382391 in bash-completion "completion support for "ubuntu-bug"" [Undecided,New] https://launchpad.net/bugs/382391
[18:07] <bencrisford> !info gcomrpis
[18:07] <ubot4> bencrisford: Package gcomrpis does not exist in jaunty
[18:07] <bencrisford> !info gcompris
[18:07] <ubot4> bencrisford: gcompris (source: gcompris): Educational games for small children. In component main, is optional. Version 8.4.4-1.1ubuntu4 (jaunty), package size 523 kB, installed size 1740 kB
[18:54] <hggdh> kklimonda, still need me?
[18:55] <hggdh> kklimonda, I think it is worth it... a wishlist?
[18:55] <kklimonda> ya
[18:56] <hggdh> kklimonda, I set it to wishlist, but left it otherwise as it was
[18:57] <kklimonda> ok, thanks
[20:03] <askand> Hi, since upgrading to Jaunty I hade a lot of crashes, someone over at #nautilus said, when I shoed him the trace of nautilus chrashed, that it looked like it was because of a pango or a cairo crash. Since these libraries are widely used in gnome this could indeed  explain that I had a lot of crashing. Is this a plausible theory?
[20:12] <hggdh> askand, yes, it is
[20:16] <askand> hggdh: How can I find out?
[20:17] <hggdh> askand, looking at the stacktrace...
[20:17] <hggdh> which functions, from which packages, are crashing
[20:23] <askand> hggdh: I'm not sure where to look really, here is the trace from nautilus http://pastebin.com/m50704da6 and another from gimp http://pastebin.com/m6a85888d
[20:36] <hggdh> askand, looking at it
[20:37] <hggdh> askand, first pastebin, frame #2 is cairo
[20:37] <bcurtiswx> hi all/hggdh
[20:38] <hggdh> hi bcurtiswx
[20:38] <hggdh> askand, it seems pango called cairo, and cairo barfed on a free()
[20:40] <askand> hggdh: okey
[20:40] <hggdh> askand, same thing with the second BT
[20:40] <askand> hggdh: great
[20:41] <hggdh> askand, one thing you can try if to search for a dupe on b.g.o
[20:41] <askand> What is b.g.o?
[20:41] <hggdh> copy & paste one of the BTs here: http://bugzilla.gnome.org/dupfinder/simple-dup-finder.cgi
[20:42] <hggdh> b.g.o is bugzilla.gnome.org
[20:42] <hggdh> the bug tracking system (BTS) for gnome
[20:42] <askand> ah :)
[20:47] <askand> hggdh: I get "     A stack trace was found in the bug description you specified.  It appears     that the first few relevant function calls in the stacktrace are" and some function calls and then "The following bug reports  contain all 5     function calls and likely match the bug description you gave" but it shows no bugs
[20:47] <askand> But I'll ask in #cairo too :)
[20:48] <hggdh> askand, so there is no hit for the first BT
[20:48] <hggdh> askand, now try the second BT. If it gets the same result, then it seems it is a new thing
[20:49] <askand> I will try, it's like firefox feels I'm on to sometthing, it crashes more than ever
[20:53] <hggdh> askand, this is on FF? Or across the board?
[20:53] <askand> hggdh: across the board
[20:53] <hggdh> weird. Jaunty, up-to-date, no non-ubuntu packages?
[20:55] <askand> hggdh: yes, memcheck is fine to, there was no dupes on the other trace either
[21:03] <hggdh> askand, sounds like something common (but, then, if all BTs show cairo on top, cairo is the commonality)
[21:03] <hggdh> are you running low on available memory?
[21:12] <askand> hggdh: nope
[21:12] <askand> hggdh: I am told that "crash in malloc means heap corruption means run valgrind"
[21:13] <hggdh> askand, yes, this is quite possible
[21:14] <hggdh> so... valgrind the beast. Take a deep breath, and get something to do while valgrind runs
[21:14] <persia> Note that it's worth checking the values being passed to malloc().  Sometimes the problem is actually that someone tries to allocate several petabytes by accident.
[21:14] <hggdh> heh
[21:15] <persia> One example might be failing to deference a pointer in a rarely used code path.  There are others.
[21:16] <hggdh> looking at the BT, in this case it seems it was a call to malloc 404 bytes
[21:17] <hggdh> askand, one command line for valgrind: G_SLICE=always-malloc G_DEBUG=gc-friendly  valgrind -v --tool=memcheck --track-origins=yes --show-reachable=yes --leak-check=full --num-callers=40 --log-file=valgrind.log <command>
[21:17] <hggdh> where <command> is whatever you are trying to run
[21:23] <persia> yeah, 404 bytes indicates something else is wrong.
[21:26] <hggdh> and it seems to happen on many different applications... X?
[21:32] <persia> What's a bug number for this set of issues?
[21:34] <hggdh> askand, ^^
[21:36] <askand> persia: bug 382504 is one
[21:36] <ubot4> askand: Bug 382504 on http://launchpad.net/bugs/382504 is private
[21:36] <persia> askand, Could you subscribe me?  That's extra private.
[21:38] <askand> persia: done
[21:43] <persia> askand, That looks deep indeed.  You say you're getting lots of crashes in different applications  with these symptoms?  Have you tried a memcheck run?
[21:57] <askand> persia: yes, a memcheck sucessfully ran for >24 h without errors
[22:05] <askand> persia: hggdh: now I have obtained a valgrind log from a gimpcrash
[22:06] <hggdh> askand, good. Do you have a bug opened for the crash?
[22:07] <askand> hggdh: no I will file one
[22:08] <askand> hggdh: here is the log in the mantime, a long one http://pastebin.com/m6f348f57
[22:08] <askand> meantime*
[22:12] <askand> hggdh: bug 382563
[22:12] <ubot4> Launchpad bug 382563 in ubuntu "Gimp crashed" [Undecided,New] https://launchpad.net/bugs/382563
[22:16] <askand> Hm, firefox, on which I run another valgrind froze now, dont know if I should kill it or wait..
[22:16] <hggdh> heh. Wait a bit
[22:19] <hggdh> even more confusing, valgrind shows a segv in gtk (http://pastebin.ca/1444068)
[22:21] <hggdh> now I *am* confused, askand. How did you get the valgrind and backtrace?
[22:21] <askand> hggdh: hm I got the backtrace running gdb on a crashfile
[22:21] <askand> and I got the valgrind log with the command you mentioned above
[22:21] <hggdh> same run?
[22:21] <hggdh> or from a different crash?
[22:22] <askand> from a different crahs
[22:22] <hggdh> ah
[22:24] <hggdh> askand, do me a favour, and please run, on  a terminal, "apport-collect -p gimp 382563"
[22:29] <askand> hggdh: it wasn't a lot that was uploaded
[22:32] <hggdh> that's OK, the important part is the dependencies file
[22:33] <askand> ok
[22:33] <hggdh> hum. You are using nvidia. Which nvidia is this?
[22:33] <askand> hggdh: the one from thre repos
[22:33] <askand> not sure what version it is
[22:33] <BUGabundo> ora boas noites
[22:37] <hggdh> ora, ora, BUGabundo
[22:37] <hggdh> askand, do you run compiz?
[22:38] <askand> hggdh: I do usually yes
[22:38] <BUGabundo> Hellow: hggdh
[22:38] <hggdh> hello BUGabundo :-)
[22:38] <hggdh> askand, can you try disabling compiz?
[22:38] <Hellow> wait, what?
[22:38] <Hellow> lol
[22:38] <hggdh> heh
[22:39] <BUGabundo> LOLOLOLOL Hellow.... sorry for the higilght
[22:39] <BUGabundo> ROFL
[22:39] <Hellow> ROFLOL
[22:39] <askand> hggdh: sure
[22:41] <askand> hggdh: are you suspecting compiz? :)
[22:43] <hggdh> askand, since this happens across the board, I am suspecting either compiz or X
[22:44] <askand> hggdh: I had gnome-terminal crashed with SIGSEGV in _XSend if that might be related
[22:47] <hggdh> it might, but it is still too early to say anything
[22:49] <askand> Ok, I got a trace for that too in bug 382143 , but I have disabled compiz now, I'll be back if things continues to crash
[22:49] <ubot4> askand: Bug 382143 on http://launchpad.net/bugs/382143 is private
[22:49] <askand> oh it was private too
[22:49] <hggdh> heh
[22:50] <askand> now its public
[22:51] <hggdh> askand, I subcribed myself, and put it back as private -- the coredump is still there
[22:53] <hggdh> let's wait for apport to retrace it, and delete the coredump, then... back to public
[22:54] <askand> hggdh: what's in the coredump that should be private?
[22:56] <kklimonda> askand: depends on program - passwords, emails etc. ;)
[22:56] <askand> kklimonda: ohh, yeah that can remain private indeed
[22:57] <kklimonda> askand: basically a lot of private data
[22:57] <BUGabundo> hey kklimonda
[22:58] <kklimonda> hey :)
[22:58] <BUGabundo> did you enjoy the album I gave you ?
[22:58] <hggdh> askand, it can have anything that was loaded in the memory address space -- for example, encryption keys
[22:58] <kklimonda> BUGabundo: it's nice
[22:58] <BUGabundo> humm really?
[22:59] <BUGabundo> I though you were a METAL dude
[22:59] <kklimonda> BUGabundo: nah, I listen to all kind of music.
[23:12] <kklimonda> how to get list of patches applied on ubuntu kernel?
[23:14] <hggdh> changelog?
[23:40] <dtchen> kklimonda: there is no easily-parsed list, unfortunately. the kernel team uses git (just as most distros tracking upstream do).
[23:40] <dtchen> kklimonda: on the other hand, it is fairly readable; see kernel.ubuntu.com/git
[23:42] <kklimonda> dtchen: thanks