[05:05] <pitti> Good morning
[05:05] <pitti> Trevinho: yes, with hardwired key actions there are no userspace notifications, so we can't create notification bubbles in userspace
[05:06] <pitti> but not a biggie for a kbd backlight -- I mean, the notification shold be that the brightness changes :)
[07:22] <willcooke> morning all
[07:22] <willcooke> seb128, need to leave early this evening, just fyi
[07:22] <hikiko> morning willcooke
[07:22] <willcooke> once the meeting is done
[07:22] <willcooke> hi hikiko
[07:38] <seb128> hey willcooke & desktopers
[07:38] <seb128> willcooke, k, no problem ... do you want me to handle the meeting?
[07:46] <willcooke> seb128, nah, should be wrapped up by 5 my time I think
[07:46] <seb128> likely yes
[07:49] <happyaron> hey seb128
[07:50] <seb128> hey happyaron, how are you?
[07:50] <happyaron> great, you?
[07:50] <seb128> happyaron, I'm going to look at your nm 1.2.2 today, sorry didn't manage to get to it on friday and yesterday was an holiday in France
[07:50] <seb128> happyaron, I'm good thanks :-)
[07:50] <happyaron> np, the link is updated - https://launchpad.net/~happyaron/+archive/ubuntu/ppa/+sourcepub/6431454/+listing-archive-extra
[07:51] <happyaron> and will have a meeting with oem people for nm in a couple of minutes
[07:52] <Sweet5hark> goood morning desktoppers!
[07:52] <seb128> happyaron, any specific issue/topic from oem?
[07:52] <seb128> hey Sweet5hark! had a good w.e? (was yesterday off for you as well?)
[07:53] <seb128> happyaron, btw did you talk to anybody from kubuntu about the symbol issue in their bindings?
[07:53] <happyaron> seb128: there is a list, will send something out after the meeting
[07:53] <seb128> k, great
[07:53] <happyaron> seb128: yep we talked last week
[07:53] <happyaron> they are going to ask upstream for a proper solution
[07:53] <seb128> k
[07:53] <seb128> what component has the issue?
[07:53] <seb128> is https://launchpad.net/ubuntu/+source/networkmanager-qt/5.18.0-0ubuntu1.2 a fix for that?
[07:54] <seb128> or something else?
[07:54] <happyaron> it's not a fix for that
[07:54] <happyaron> but a recompile may work around it
[07:54] <seb128> k
[07:54] <Sweet5hark> seb128: yesterday was off too here. I wasted a lot of time on the weekend to #makespacegreatagain (aka playing Stellaris now that its out)
[07:54] <seb128> can  you ping them again? they are going to block the sru until that's sorted out
[07:55] <happyaron> will do today
[07:55] <Sweet5hark> stellaris is just slightly more addictive than crack. About on the same level as a new release of Civilizations just-one-more-turn-syndrome.
[07:58] <seb128> happyaron, thanks
[07:58] <seb128> Sweet5hark, lol, sounds like better to stay away from it ;-)
[07:59] <Sweet5hark> seb128: its lots of fun though ;)
[07:59] <seb128> I can imagine :-)
[07:59] <seb128> but those also the best way to cut your sleep hours :p
[08:00] <seb128> "I'm close from victory, should be done in a few more turns"
[08:00] <seb128> 1.5h later "ok, Í'm getting there, just a bit more effort and it's done"
[08:00] <seb128> then it's 3am
[08:00] <seb128> been there :p
[08:02] <Sweet5hark> seb128: yeah, the tendency of "wtf is the sun doing dawning outside, it was just setting ..." is strong in this one.
[08:02] <seb128> :-)
[08:03] <Laney> yo
[08:05] <Sweet5hark> Laney: I see the bears didnt want to eat you over the weekend?
[08:07] <Laney> just the slugs
[08:07] <Laney> but they are week
[08:07] <Laney> weak
[08:10] <seb128> hey Laney! how are you?
[08:11] <seb128> had fun camping?
[08:11] <seb128> and how was monday around? not too crazy?
[08:13] <Laney> hi seb128
[08:13] <Laney> camping was fun, nice area out there
[08:13] <Laney> didn't get much sleep though
[08:14] <Laney> so was a quiet weekend otherwise ;-)
[08:14] <Laney> monday was okay... just worked on the hire stuff a bit and then the theme for 3.20 mostly
[08:14] <Laney> how ws your long weekend?
[08:14] <seb128> oh, you are doing the theme updatE?
[08:14] <seb128> nice :-)
[08:15] <seb128> quite good! though the weather was not as nice as previous week
[08:16] <seb128> we had friends over on saturday to make fun of the eurovision singers while eating pizza ;-)
[08:16] <seb128> otherwise played some videogames/watched some tennis on TV/relaxed mostly
[08:17] <Laney> there's always tennis!
[08:22]  * Laney cries
[08:22] <Laney> email without filter rules
[08:22] <Laney> oh my dear lord
[08:23] <seb128> oh, you did that email migration?
[08:23] <Laney> I have autopkgtest failures in with debian-devel in with emails about cycling stuff in with launchpad bug mail
[08:23] <seb128> and yeah, tennis is good :p
[08:23] <Laney> "did"
[08:23] <Laney> I would say started
[08:23] <seb128> now is the fun part? ;-)
[08:24] <Laney> indeed
[08:24] <Laney> need to learn this sieve filtering language they use
[08:24] <Laney> dovecot's one
[08:29] <willcooke> hey seb128 - did you upload the new Calendar to X btw?
[08:29]  * willcooke goes looking for the link to the queue
[08:30] <seb128> willcooke, yeah, https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=gnome-calendar
[08:30] <seb128> the queue has 39 items though
[08:30] <willcooke> seb128, sweet.  thanks.  I can test in proposed though right>?
[08:31] <seb128> it's not in proposed yet
[08:31] <seb128> workflow is
[08:31] <seb128> upload -> queue
[08:31] <seb128> review/ack -> proposed
[08:31] <seb128> verified -> updates
[08:39] <willcooke> seb128, ahh, I see.  I saw "pocket: proposed" and thought it was already there.  nw
[08:39] <seb128> no, it's the target
[08:42] <willcooke> got it
[08:47] <willcooke> seb128, Laney - with the +1 from design and a comment from sabdfl, I (think I) have made this bug SRU compliant:
[08:47] <willcooke> https://bugs.launchpad.net/ubuntu/+source/ubuntu-themes/+bug/762349
[08:47] <willcooke> when you get a sec, could you read over it and see if it's ok?
[09:13] <seb128> Sweet5hark, seems like people mentioned your name on bug #1577316 / asking for debugging hint
[09:13]  * Sweet5hark looks
[09:19] <willcooke> happyaron, great work on OEM NM issues - thanks
[09:22] <Sweet5hark> seb128: commented on with some (hopefully helpful) hints
[09:22] <seb128> Sweet5hark, thanks
[09:59] <andyrock> morning
[10:00] <andyrock> seb128: https://bugs.launchpad.net/ubuntu/+source/gnome-menus/+bug/1506744/comments/42
[10:14] <willcooke> new wifi card is here
[10:14] <willcooke> going to attempt to fit it.
[10:14] <willcooke> wish me luck....
[10:15] <Laney> live strong
[10:15] <willcooke> oh man, there are about a mllion screws to remote
[10:15] <willcooke> remove
[10:16] <willcooke> I predict pain
[10:16] <Laney> is this in a laptop?
[10:16] <willcooke> yeah, x220
[10:16] <Laney> fun
[10:16] <Laney> keep track of where they all came from
[10:16] <willcooke> I found a video on the Lenovo website
[10:17] <willcooke> right, here goes nothing... powering off....  START THE CLOCK
[10:19] <Laney> a suspicious single beep just sounded from somewhere in this room
[10:20]  * Laney panics
[10:30] <Laney> http://people.canonical.com/~laney/weird-things/gtk320.png
[10:30] <Laney> don't know about you but that looks pixel perfect to me
[10:30] <Laney> going to upload now
[10:33] <ricotz> hey desktopers
[10:33] <ricotz> Laney, hi, please make sure to add https://git.gnome.org/browse/gtk+/commit/?h=gtk-3-20&id=e006f3ca98990f6e3c8da58b49d7feba8403bb47
[10:34] <Laney> did you look at the screenshot?
[10:34] <ricotz> Laney, not really
[10:34] <Laney> pretty sure there will be a point release before this is good
[10:35] <ricotz> I didnt expect this so land any other than in a PPA though
[10:37] <Laney> check it yo
[10:39] <willcooke> Done!
[10:41] <Laney> congrats
[10:41] <willcooke> wifi is connected at a massive 1Mb
[10:42] <willcooke> so... hmmmmmmmmmm
[10:42] <Laney> 5mb/s \m/
[10:43] <willcooke> Thankfully my wired ethernet connection is connected at 1000 Mb :)
[10:45] <willcooke> suppose I should test it actually works then...
[10:45] <willcooke> undocking........
[10:47] <willcooke_> yay
[10:47] <willcooke_> now connected at 65 Mb
[10:47]  * willcooke_ goes for a walk around the house
[10:47] <willcooke_> Kitchen!
[10:48] <willcooke_> End of the garden!
[10:48] <willcooke_> 58Mbps
[10:49] <willcooke_> In reality I'm getting 3Mb, but thats ok
[10:50] <willcooke_> redocked
[10:51] <willcooke> good.
[11:22] <willcooke> hello aquarius_
[11:22] <aquarius_> yo :)
[11:23] <aquarius_> hey, desktop peeps. How should a Python Gtk3 program play a system sound? GSound doesn't seem to be present in gi.repository on 14.04 or 16.04. (Perhaps a Trevinho question?)
[11:24] <pitti> aquarius_: gir1.2-gsound-1.0 should provide libcanberra bindings
[11:24] <pitti> or rather, GSound wraps libcanberra, and that's the GI binding
[11:24] <aquarius_> pitti, that doesn't seem to exist on 14.04?
[11:24] <pitti> but on 16.04
[11:24] <aquarius_> ya, it's in 16.04
[11:25] <pitti> and you said "14.04 or 16.04" :)
[11:25] <aquarius_> heh :) Apologies. It's not present in 14.04 and it's not installed by default in 16.04, I should have said :)
[11:25] <pitti> no idea for 14.04 I'm afraid, perhaps subprocess.call(['paplay', 'stuff.wav']) ? :-)
[11:25] <pitti> (honestly, no idea)
[11:25] <aquarius_> on 14.04, am I best to use the old static canberra bindings? I could just shell out to canberra-gtk-play...
[11:26] <aquarius_> haha! great minds, etc :)
[11:28] <aquarius_> actually, shelling out is probably not a terrible idea; sounds are fire-and-forget anyway, it's not critical if they don't work, and process startup is fast.
[11:32] <seb128> hey pitti, wie gehts? had a good w.e?
[11:32] <pitti> hey seb128! wonderful indeed, thanks! We went to Dresden to visit family again
[11:32] <seb128> ah, nice!
[11:33] <pitti> seb128: on Sunday we did a rafting tour on a wildwater channel, that was a lot of fun (and splash and water :) )
[11:33] <pitti> pics coming soon
[11:33] <pitti> seb128: and we had a long w.e. here due to Pentecost
[11:33] <pitti> seb128: et toi, as-tu passé un bon weekend?
[11:34] <seb128> oui, aussi merci
[11:34] <seb128> had a 3 days w.e as well
[11:34] <seb128> was mostly relaxing
[11:34] <seb128> we had friends over on saturday to eat pizza and made fun of eurovision singers ;-)
[11:35] <seb128> otherwise watching tennis on tv, played some video game, had some walks outside
[11:38] <Trevinho> aquarius_: mh yeah.... I guess for 14.04 you've to fallback to canberra or some scripts
[11:38] <aquarius_> yeah. I shall shell out. :)
[11:38] <aquarius_> thank you pitti and Trevinho!
[11:38] <pitti> aquarius_: not shell, just subprocess.call()
[11:39] <aquarius_> os.system is probably as good here, I think? I'm not passing untrusted data to it (it's only called from within my app with hardcoded sound names), and it needs to be a background process so we don't block on it
[11:40] <pitti> os.system is almost never a good idea
[11:40] <aquarius_> agreed, because you have to escape things properly, you can't get its response, etc. In this particular case, I'm not worried about any of that, though?
[11:41] <pitti> aquarius_: subprocess.Popen(['canberra-gtk-play', 'yoursound.wav']) and clean it up later on
[11:41] <pitti> (or don't, if you aren't interested in the exit code)
[11:44] <aquarius_> I agree it's not hard, I'm just wondering why the change in this particular case matters? I normally avoid os.system because it's bad for security, as mentioned.
[11:45] <aquarius_> (reads documentation on how to run it in the background)
[11:48] <seb128> happyaron, do you have a packaging vcs for network-manager?
[11:49] <aquarius_> pitti, hrm, running the process in the background seems quite a bit harder this way...
[11:49] <pitti> aquarius_: how do you mean? Popen() always starts it in the background
[11:50] <pitti> (unlike .call() or .check_call())
[11:50] <pitti> to the contrary, os.system() is syncronous
[11:50] <aquarius_> Yes. Yes, it does. subprocess.call doesn't, though, because I am stupid :)
[11:50] <aquarius_> fixed now :)
[11:51] <happyaron> seb128: https://code.launchpad.net/~happyaron/network-manager/+git/ubuntu
[11:56] <seb128> happyaron, thanks, it means I can't just cowboy hack the upload :p
[11:56] <seb128> happyaron, I was pondering adding https://git.gnome.org/browse/network-manager-applet/commit/?id=c3255ed740592a2f23a7ebc47f1acd2dd2d768b3 to the applet update
[11:56] <happyaron> seb128: I'm thinking about pushing 1.2.2 directly
[11:57] <happyaron> as the OEM guys would need that for most of their problems
[11:57] <happyaron> what do you think?
[11:59] <seb128> happyaron, that commit is after 1.2.2
[11:59] <seb128> you mean in xenial?
[11:59] <seb128> we just need the current SRU copied over first
[11:59] <seb128> it has the important fix for oem
[11:59] <seb128> or do they have other issues?
[12:00] <happyaron> they have several other issues
[12:00] <seb128> happyaron, do they have a list/bugs?
[12:01] <happyaron> seb128: check email
[12:01] <seb128> happyaron, thanks
[12:03] <seb128> happyaron, but yeah, let's keep rolling and prepare 1.2.2 for xenial
[12:03] <happyaron> yep, will prepare 1.2.2 for yakkety for the moment
[12:06] <seb128> happyaron, I though you had that ready?
[12:06] <seb128> next steps would be to get it in a ppa that oem&co can use for testing and that is going to turn into the next SRU
[12:06] <seb128> xenial ppa that is
[12:26] <Trevinho> seb128: hey, on the snap world... I've did some tests and at the end I think we can run most of gtk apps generating caches at runtime... here's an example: https://code.launchpad.net/~3v1n0/snappy-playpen/hello-unity-fixes/+merge/294858 but I can apply the same to the calc snap we were hacking in Prague
[12:27] <Trevinho> pitti: I can't find the channel now, but I read somewhere a ping from you about the fact that hardwired events can't be notifier by udev/upower, or something like that, right?
[12:28] <pitti> Trevinho: yes, some laptop models are like that -- the brightness keys (screen or kbd) don't send any software event, they just directly change the brightness
[12:28] <seb128> Trevinho, shrugh, hacks on hacks :-/
[12:29] <Trevinho> seb128: yeah, I know.. that's how things work, though :/
[12:29] <seb128> Trevinho, so we would regenerate the caches at every application run?
[12:29] <Trevinho> seb128:  at least now things are generated on first run, which means later startup times are reduced a lot
[12:29] <seb128> ah, right
[12:29] <Trevinho> seb128: no, just first time
[12:29] <seb128> the user dir is persistent
[12:29] <seb128> right
[12:29] <Trevinho> yes, I made it snap version-dependent though
[12:30] <seb128> that makes sense
[12:30] <Trevinho> so if new packages, or new gsettings are added, they get regenrated
[12:30] <seb128> the content might change between versions
[12:30] <Trevinho> exactly
[12:30] <seb128> what do you build from?
[12:30] <seb128> source?
[12:30] <seb128> for the quilt thing to work
[12:30] <seb128> because the ones we played with was using the deb
[12:30] <seb128> so no compilation
[12:32] <Trevinho> pitti: yes... That's almost true... Almost since... in my thinkpads for example, the event is not triggered by default. However, by tuning the proc ibm hotkeys sysnode, I can get a KEY_KBDTOGGLEILLUM (or whatherver iscalled). But that break things, since laptop-side is just a notification that brightness has changed, not a request of changing it from
[12:32] <Trevinho> userland level
[12:32] <Trevinho> pitti: so... I was wondering if there's a way to use that event, and instead of triggering it to the userpsace, handling it a the kernel module level, to send an udev event that the led status has changed
[12:33] <Trevinho> pitti: then... upower could monitor that, maybe...
[12:33] <pitti> Trevinho: that's a lot of custom code in userspace then (new uevents etc.)
[12:33] <pitti> presumably sending a new type of key via evdev is simpler, but we don't have a definition for such new "indicate only" keys
[12:34] <seb128> pitti, is there any chance you get slot for the upower issue this week? can I help in some way to move it forward (I'm going to have a quick look to the upower code but if it's not trivial and I'm probably not going to be able to block enough days to learn the code&co)
[12:34] <pitti> Trevinho: I don't know whether this can be tweaked in the kernel/BIOS
[12:34] <Trevinho> pitti: mh.. I see... Well in some cases it seems that kernel events are fired when kbd illumination changes (only when zero'ed though)
[12:35]  * pitti frankly doesn't see the point -- isn't the best (and only) notification that you should see that the bridghtness of the keyboard actually changes?
[12:35] <Trevinho> pitti: so... making upower to actually read the value instead of relying on a cached one is something better for you?
[12:35] <pitti> Trevinho: upower reads the actual values from sysfs
[12:35] <Trevinho> pitti: yeah, I don't mind of the notification...
[12:35] <pitti> it doesn't "cache" anything, it just proxies sysfs as dbus properties
[12:35] <Trevinho> pitti: the thing is that u-s-d needs to know the actual state before idling the laptop
[12:35] <Trevinho> or it will resume things to the old value
[12:36] <pitti> seb128: ugh, is it that complicated? I guess most of that code is autogenerated indeed
[12:36] <pitti> seb128: anyway, I'll have a look now
[12:36] <Trevinho> pitti: mhmh... https://cgit.freedesktop.org/upower/tree/src/up-kbd-backlight.c#n106
[12:36] <pitti> seb128: this "one dbus per user" is highly annoying, I'll postpone that
[12:36] <Trevinho> seb128: are we spakeing of the same thing?
[12:37] <Trevinho> seb128: of the same issue, I mean, or something else?
[12:38] <Trevinho> pitti: priv->brightness is only updated  when user sets it, and that's what is returned when you call the getter
[12:38] <pitti> Trevinho: oh, this; ok, so you're saying this never gets written correctly from sysfs?
[12:39] <pitti> Trevinho: no, seb128 means freedesktop bug 95350
[12:40] <Trevinho> pitti: currently thinkpad and dell systems have this scenario: you change brightness from keyboard, the laptop goes idle, ups turn down the brightnes... Saving the previous level around. However the previous level is got from a cached value since if you call getbrightness from upower, it will always return the cached value, not the last one you changed. Now,
[12:40] <Trevinho> when you get back to the laptop, you won't get the proper backlight.
[12:41] <Trevinho> this is done this way, because there are laptops (like asus ones), which just reports a kernel request to change brightness., then userspace changes it.. calling SetBrightness in Upower... And so all this works. But in the other cases it doesn't
[12:42] <Trevinho> marco@tricky:~$ cat /sys/class/leds/tpacpi\:\:kbd_backlight/brightness
[12:42] <Trevinho> 1
[12:42] <Trevinho> marco@tricky:~$ gdbus call --system --dest org.freedesktop.UPower --object-path /org/freedesktop/UPower/KbdBacklight --method org.freedesktop.UPower.KbdBacklight.GetBrightness
[12:42] <Trevinho> (2,)
[12:42] <pitti> Trevinho: so this could be changed to drop the brightness iternal property and always read it
[12:42] <Trevinho> this is what I'm getting now
[12:42] <Trevinho> exactly... that's what I wanted to do in fact
[12:42] <Trevinho> I just was wondering if upstream is fine with that
[12:43] <pitti> ok from my side; best to file an upstream bug report, then we can ask hughsie
[12:45] <Trevinho> ok
[12:47] <seb128> pitti, I don't know if it's complicated but I'm not familiar with the codebase, I can start pocking a bit around in case it's easy but I've some meetings in the afternoon and I'm probably not going to be able to do much in between
[12:47] <pitti> seb128: looking at it now
[12:47] <seb128> danke
[12:47] <seb128> sorry to be nagging but it seems to hit quite some LTS users
[12:48] <pitti> seb128: does u-s-d check for up_client_new() returning NULL?
[12:48] <pitti> i. e. will that actually help fixing a crash, or just make it crash differently on a NULL ptr?
[12:51] <seb128> pitti, it's up_client_get_lid_is_closed() which segfaults, has that function in upower-glib has "g_return_val_if_fail (UP_IS_CLIENT (client), FALSE);"
[12:51] <seb128> has->and
[12:51] <seb128> pitti, also the usd side didn't change since trusty and that was not an issue
[12:52] <seb128> so I expect that fixing the bug is going to make usd happy again
[12:58] <pitti> seb128: hm, same upower behaviour in trusty and wily
[12:59] <pitti> seb128: so I guess the fact that upowerd doesn't start is the thing that actually changed and triggered this?
[13:00] <pitti> (or takes long to start)
[13:01] <seb128> could be I guess :-/
[13:06] <seb128> pitti, sorry otp ... but yeah, the root of the issue is probably a kernel bug delaying upower start on usb enumeration
[13:06] <seb128> unsure how we could workaround from usd is upower returns a valid object
[13:06] <seb128> is->if
[13:07] <seb128> which then trigger an upower segfault in an libupower-glib function when used on the said object
[13:07] <seb128> -upower
[13:07] <pitti> seb128: I am looking into that now, but as I said this won't really help to fix the issue
[13:07] <pitti> seb128: unless usd repeatedly tries to connect, it will be stuck with a NULL object forever, and thus not work
[13:08] <seb128> hum, right...
[13:09] <pitti> seb128: sorry, it's been too long: g_object_new (UP_TYPE_CLIENT, NULL);
[13:10] <pitti> that calls some type specific constructor, something like up_client_alloc() or so?
[13:10] <pitti> which we could change to return NULL on failure?
[13:10] <seb128> (otp,going to look in a bit)
[13:10] <pitti> but I'm really not sure that this is the correct fix
[13:10] <a1fa> andrea, you here?
[13:11] <pitti> because of the above (once upower does finish starting, the object should become useful
[13:13] <pitti> oh, _init()
[13:13] <seb128> pitti, shouldn't the upower call just block until upower gets ready rather than timing out then?
[13:13] <pitti> seb128: no, would potentially block forever then
[13:14] <pitti> and I can't change the object pointer in _init()
[13:14] <seb128> that would be the right thing to do in that case, the upower plugin is useless without upower
[13:14]  * Sweet5hark is out for a bit (shopping for an office chair that doesnt suck)
[13:15] <seb128> Sweet5hark, good luck finding one!
[13:15] <pitti> seb128: ah, I think I could unref the object in up_client_new() and return NULL; that would at least provide a more defined behaviour
[13:16] <pitti> but I'm not sure whether it's actually the more desirable behaviour
[13:16] <pitti> desrt: halp
[13:16] <seb128> pitti, he's in a call talking I guess we can discuss that more after that meeting
[13:16] <seb128> she*
[13:18] <pitti> bah, up_client_get() doesn't have such an UP_IS_CLIENT() assertion, but instead
[13:19] <pitti> ……………………if (client->priv->proxy == NULL)
[13:19] <pitti>                 return;
[13:19] <pitti> *throws hands into air* horribly inconsistent
[13:24] <seb128> pitti, but yeah, maybe we need to just get the kernel bug fixed...
[13:40] <seb128> happyaron, do you know why bug #1547826 was not closed? is that still an issue?
[13:54] <dandre> Hello,
[13:54] <dandre> I am looking for a widget I could place in my desktop toobar to create more or less a custom menu like th main menu but not included as a sub menu of it. I am using gnome flashbak desktop
[13:57] <dandre> I have found a simple python script sshmenu but the launch button goes into the notification area and I want a separate button. Is there any possibility?
[14:00] <dandre> it's not sshmenu but sshplus
[14:01] <seb128> desrt, hey
[14:01] <desrt> hey
[14:02] <seb128> desrt, in the call you mentioned discussions about mimetype/url handlers/help
[14:02] <seb128> who discussed that/where
[14:02] <desrt> attente and i were discussing it yesterday
[14:02] <desrt> he's writing a dbus service to allow confined apps to open uris "on the outside"
[14:02] <seb128> ah ok, I've that on my list of things I meant to look at
[14:02] <desrt> right now we're doing it really simple, as mentioned: allow http, https, mailto... everything else is a no-no
[14:03] <seb128> desrt, attente, I opened https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1576296 about that btw
[14:03] <willcooke> I think those urli's will probably cover 99% of cases
[14:04] <willcooke> uri
[14:04] <seb128> well, "help" is usually help: uris
[14:04] <seb128> which yelp is the handler for
[14:11] <seb128> desrt, also I didn't understand the bits about what is flatpack currently doing for gsettings? do they have something to let app change its own keys?
[14:11] <desrt> not yet
[14:11] <desrt> that's what we're discussing on the call
[14:12] <desrt> *flatpak btw
[14:12] <seb128> thanks
[14:12] <seb128> and yeah, I followed the discussion
[14:12] <desrt> because, you know, dropping letters is cool
[14:12] <seb128> I just didn't hear alex at the start, audio was cutting
[14:12] <desrt> basically, they will do the same thing as we do
[14:13] <seb128> I though he said that they had a simple solution which restricted the schemas to current app
[14:13] <desrt> this was a theoretical imagined solution.  it doesn't exist yet.
[14:13] <seb128> k, that's the bit I missed
[14:13] <seb128> thanks
[14:13] <desrt> he was talking more about how he supposed it would work
[14:13] <seb128> do they currently give access to the system db?
[14:13] <desrt> there is not usually a system db
[14:14] <seb128> sorry, I meant the user one
[14:14] <seb128> but full db
[14:14] <desrt> it depends on the settings
[14:14] <desrt> it's possible to specify a package that gets full user homedir access
[14:14] <desrt> just like we can
[14:14] <desrt> in that case, it would work
[14:14] <seb128> right
[14:14] <desrt> otherwise, not
[14:14] <seb128> it's all or something
[14:14] <seb128> shrug
[14:14] <seb128> it's all or *nothing*
[14:15] <seb128> they also have the userdir under the normal location when they do that, right?
[14:15] <seb128> where snaps has it under some /snap path
[14:17] <desrt> in general, flatpaks are much more flexible in terms of file locations because they use a new mount namespace instead of apparmor-based filtering
[14:17] <desrt> so they don't run into the same path-relocation problems that we do
[14:18]  * jdstrand notes that the apparmor-based filtering has nothing to do with that
[14:18] <jdstrand> it is the choice of paths that is the problem
[14:19] <jdstrand> but that is a technicality
[14:19] <seb128> well, if we had a mount namespace doing the restriction we wouldn't need to apparmor filter behind?
[14:20] <jdstrand> yes
[14:20] <jdstrand> you want the MAC
[14:20] <jdstrand> but don't get hung up on that
[14:21] <jdstrand> I think you mean file namespace
[14:21] <seb128> yeah
[14:21] <jdstrand> well, NEWNS
[14:22] <jdstrand> anyhoo
[14:22] <seb128> but right, what is creating issues from our side is not what is used to restrict the locations
[14:22] <seb128> just that things are available at a non standard path
[14:22] <jdstrand> correct
[14:22] <seb128> which confuses existing code
[14:23] <jdstrand> but there are problems on either side
[14:24] <jdstrand> as soon as you use a mount namespace, things get really complicated with sharing
[14:25] <seb128> sharing?
[14:25] <jdstrand> yes
[14:25] <tyhicks> sharing data between two or more snaps
[14:25] <jdstrand> imagine a snap ships two commands
[14:26] <jdstrand> if they are supposed to share the same mount namespace, you need to make sure you do that right
[14:26] <tyhicks> oh, I wasn't thinking about sharing between two commands but that's true...
[14:26] <jdstrand> that isn't insurmountable
[14:26] <jdstrand> but then, like tyhicks said, if you have two snaps sharing data, things get complicated. 3, 4, more, etc
[14:26] <seb128> I didn't even know that snaps could share datas
[14:27] <seb128> I though they each had their own private dir
[14:27] <seb128> with maybe access to some "normal" system locations
[14:27] <jdstrand> by default, a snap gets private dirs that the commands use
[14:27] <tyhicks> jdstrand: they'd need to share the same mount namespace or the launcher would need to set up a bind mount for a shared area between the two commands
[14:28] <jdstrand> but interfaces will soon allow a snap from the same publisher to share data
[14:28] <jdstrand> and other interfaces might share data as well
[14:28] <jdstrand> tyhicks: yes
[14:28] <seb128> I see
[14:29] <jdstrand> tyhicks: let's explore this here for a moment (I know you and I have a meeting, but perhaps we can push it a moment)
[14:30] <seb128> jdstrand, tyhicks, do you know if there is any plan to try make some things available at their standard location (by bind mount, or whatever else)?
[14:30] <tyhicks> jdstrand: that's fine - I've been wanting to look into the possibility of a new mount ns some more anyways
[14:31] <jdstrand> seb128: yes-- that is what opengl does, there is already some bind mount stuff happening in the launcher
[14:31] <tyhicks> seb128: zyga and I will be working on adding the ability for interfaces to convey an fstab-like file so that the launcher will set up a series of bind mounts
[14:31] <seb128> oh, nice
[14:32] <seb128> tyhicks, is there a bug/blueprint/google doc about that?
[14:32] <tyhicks> seb128: not that I know of - we just discovered the need for it late last week at the snappy sprint
[14:32] <seb128> tyhicks, k, just curious on what cases did you find the need?
[14:33] <seb128> tyhicks, I can see that being useful for things like locales definitions, mimetypes, fonts, etc
[14:33] <jdstrand> tyhicks: I would think that planned work would fix these sorts of things in the same manner. I mean, in a way, we are effecting a new file namespace since we force commands to run within core's fs, then bind mount into it
[14:33] <tyhicks> seb128: opengl support requires it - AFAIK, the kernel snap needs to ship some libs that need to be bind mounted in known locations for app snaps to use
[14:34] <jdstrand> with newns, you create a blank one then bind mount into it
[14:34] <tyhicks> seb128: yes, fonts are another identified usage
[14:34] <seb128> great
[14:35] <tyhicks> jdstrand: yes, there's a lot of overlap here
[14:36] <jdstrand> tyhicks: ok, so, if we were going to implement newns now, what would it look like? then we can see what it would buy us and if it is appreciably different from the planned work
[14:37] <tyhicks> jdstrand: they're setting up a mount namespace where / is a private tmpfs
[14:38] <tyhicks> jdstrand: "/ is a private tmpfs not visible anywhere else. This is pivot_root:ed into so it is the new / and all other mounts from the host are unmounted from the namespace."
[14:39] <tyhicks> so they're setting up *everything* in the new mount namespace
[14:39] <jdstrand> right
[14:39] <jdstrand> that is flatpak
[14:39] <tyhicks> yes
[14:39] <jdstrand> that's fine
[14:40] <jdstrand> I'm trying to think if we were going to use newns, what would it look like so we can compare that to what we have and the planned bind mount work
[14:41] <tyhicks> if we're going to use a new mount namespace, we'd have to do something similar
[14:41] <jdstrand> sure
[14:41] <jdstrand> what would we mount into it?
[14:41] <jdstrand> I guess the core os snap
[14:41] <tyhicks> yes
[14:41] <tyhicks> possibly things from the kernel snap
[14:42] <tyhicks> (like opengl libs)
[14:42] <jdstrand> right
[14:42] <tyhicks> on classic, we'd mount in certain things that we'd want to use from the system, such as fonts
[14:42] <jdstrand> sure
[14:42] <jdstrand> what about HOME?
[14:43] <jdstrand> would one mount ~/snap/<name>/<version> as HOME?
[14:43] <tyhicks> yes, if the home interface was plugged in
[14:43] <jdstrand> ok, so not that
[14:43] <tyhicks> I'd think we'd use ~/snap/<name>/<version> by default or $HOME depending on the home interface being plugged in
[14:44] <willcooke> probably a stupid question, but.... could this be used to avoid shipping a whole Gtk in each Gtk app?  Like we could make the version shipping with classic available for use by snaps, and if you want something else (newer) then you ship it, or ship a snap with it in and then re-use that?
[14:44] <jdstrand> that could be weird since home isn't autoconnected-- you can imagine a snap starts unconnected, then writes files, then is connected, etc
[14:44] <jdstrand> willcooke: it could, but so could the planned work
[14:45] <willcooke> even better :)
[14:45] <jdstrand> willcooke: I think that is a different question. snaps are the way they are because they are supposed to be independent of the os
[14:45] <tyhicks> jdstrand: true - the operation of connecting the home interface would need to migrate data or warn that data will be lost
[14:45] <jdstrand> tyhicks: but let's assume that is fixed
[14:45]  * tyhicks nods
[14:46] <willcooke> jdstrand, sure, understood.  Just seeing if there is a potential work around to massive snaps for tiny apps.
[14:46] <jdstrand> tyhicks: so, my feeling is that we aren't really gaining anything-- we identified everything we are already doing or planning to do
[14:46] <jdstrand> the problem today is we aren't doing these other bind mounts
[14:46] <tyhicks> that may be true
[14:47] <jdstrand> let's for a moment assume that is true
[14:47] <jdstrand> what do we gain if we do newns? what do we lose?
[14:48]  * jdstrand is struggling to see what we gain since we are mounting large chunks of things into the newns so we still need fine-grained MAC
[14:48] <jdstrand> but we are possibly adding more complexity
[14:48] <tyhicks> the main difference is that we could prevent access to certain files/directories by simply not mounting them inside the new mount namespace instead of using AppArmor to mediate the access
[14:48] <jdstrand> tyhicks: so I was assuming that we would still wrap this in MAC
[14:49] <tyhicks> yes, we definitely would
[14:49] <jdstrand> right
[14:49] <jdstrand> so, what would we not mount?
[14:49] <jdstrand> in other words, what is a specific example of what we might gain?
[14:49] <tyhicks> well, since we said that we'd bind mount all of the os snap, everything would be mounted
[14:50] <jdstrand> so we could slice that up
[14:50] <tyhicks> we could
[14:50] <tyhicks> don't know if it gains us anything
[14:50] <jdstrand> or we could use what we already have
[14:51] <tyhicks> I'm in agreement that, at this time, there are no tangible benefits to using a new mount ns versus bind mount support in interfaces
[14:52] <jdstrand> ok, cool
[14:52] <jdstrand> I think I am at the same place
[14:52] <tyhicks> maybe we'll see something that we're missing when we do the bind mount work
[14:53] <tyhicks> I'll keep an eye out for anything like that
[14:54] <jdstrand> seb128, willcooke, desrt: so, the ease of the flatpak approach wrt to relocation compared to ours isn't a technical issue (ie, newns vs apparmor). currently what we are doing is similar to newns in a lot of ways, it is just that the planned bind mount/fstab work is not done yet
[14:55] <seb128> jdstrand, I didn't know we had such work planned, so that's good news
[14:56] <jdstrand> we could redo the fs setup and use the newns approach (wrapped with apparmor) and build up the bind mounts, but we can also just continue with the current fs setup and build up the bind mounts as planned
[14:56] <seb128> jdstrand, tyhicks, did that work start? is there a place where to follow the work/discussions?
[14:56]  * jdstrand defers to tyhicks
[14:57] <jdstrand> I can say it came up last week at the sprint
[14:57] <tyhicks> seb128: I think zyga has started on his changes for snapd but I haven't started on my changes to ubuntu-core-launcher
[14:57] <seb128> k
[14:57] <seb128> well, in any case I guess we better wait on that then
[14:57] <tyhicks> seb128: it is on both of our lists for this week
[14:58] <seb128> rather than trying to patch glibc to make it loads locales from other custom dirs
[14:58] <tyhicks> seb128: if there's not a bug, I'll get one filed soon and point you to it
[14:58] <seb128> and other similar hacks we were considering
[14:58] <seb128> tyhicks, thanks
[14:58] <seb128> willcooke, ^ fyi
[14:58] <willcooke> yeah, sounds like good news all round
[15:00] <jdstrand> seb128: it sounds to me that the flatpak approach is sorta trying to also solve willcooke's question. you have a thick os that has your gtk libs, etc in it, and bind mount into the newns. snaps have a philosophical difference though in that snaps are supposed to be independent of the os. if we bind mount /usr/blah into the snap, then that snap is very much tied to a specific version of the os
[15:01] <jdstrand> so there is probably some discussions that need to happen with the snappy architects on these fronts
[15:01] <jdstrand> things I've heard about sdoc seem to be at odds with the 'snaps are independent' approach
[15:01] <seb128> jdstrand, willcooke, right, bundling gtk or not ... that's a different approach and I can see pro&con in each
[15:02] <seb128> I'm more concerned about things like having to bundle the glibc locales definitions
[15:02] <seb128> or fonts
[15:02] <jdstrand> I think there is probably a line that needs to be defined
[15:02] <seb128> but that should be fixed with the bind mount&interfaces
[15:02] <seb128> right
[15:03] <jdstrand> it seems that locales and fonts are fairly straightforward in the 'I need to use what is available on the system' line, but other things are less clear
[15:03] <jdstrand> like gschemas
[15:03] <jdstrand> anyhoo
[15:03] <jdstrand> interesting times
[15:05] <seb128> indeed
[15:05] <jdstrand> seb128, desrt, willcooke: hopefully this dispels any misconceptions that flatpaks are better in terms of relocation. I mean, they might be *today*, but the planned work is to not have as much reloaction pain
[15:05] <seb128> well, we at least have wrapper hacks for image loaders & schemas
[15:05] <seb128> jdstrand, it does, thanks
[15:05] <desrt> jdstrand: so if we move over to mount namespaces does that mean we can stop using apparmor for enforcement?
[15:06] <desrt> because that's sort of putting a cramp in our style in terms of advocating snaps as _the_ portable format for apps (since apparmor is not universal)
[15:06] <jdstrand> desrt: that is a funny takeaway, but I'll answer your question in the way you asked-- no, we will want to wrap in MAC
[15:06]  * jdstrand notes flatpak wants to use MAC as well
[15:06] <desrt> no.  it doesn't.
[15:07] <jdstrand> yes they do-- I just read about it
[15:07] <desrt> just had a call with them and they made it quite clear
[15:07] <jdstrand> then their docs are out of date
[15:08] <desrt> if they do use it it will only be in the way that apparmor/selinux are typically used today
[15:08] <desrt> ie: second line of defence against security breaches in apps
[15:08] <desrt> it will not in any way be used as a front-line confinement mechanism
[15:08] <jdstrand> snappy is more ambitious than flatpak as I read the current documentation. ie, they are using system namespaces to constrain apps. snaps may run root daemons and you can't constrain a root daemon with user namespaces
[15:08] <desrt> that's going to be entirely namespaces, seccomp, etc.
[15:08] <jdstrand> err
[15:08] <jdstrand> system namespaces
[15:09] <jdstrand> and user namespaces need a MAC as well considering all the security issues
[15:09] <Trevinho> xnox: hey, for that upstart / dbus work... It seems it really fixes stuff :-), so can you backport to xenial?
[15:09] <happyaron> seb128: need double check tomorrow
[15:09] <Trevinho> I think you told me the steps, but I forgot what to do :-)
[15:10] <desrt> jdstrand: i feel like we've been having this conversation for about 5 years...
[15:10] <Trevinho> pitti: so, this does the trick for me: http://pastebin.ubuntu.com/16475829/
[15:11] <desrt> i think neither of us have changed position at all during that time
[15:11] <jdstrand> the other thing a MAC does is provide very convenient fine-grained mediation which can be used in combination with a file namespace
[15:11] <Trevinho> together with an "hacked" usd that always check the last value before caching it
[15:13] <jdstrand> I don't really appreciate that comment-- the security team has given a lot of thought to namespaces and we are actually using them in snappy. the fact system namespaces (which flatpak uses) cannot be used to constrain root processes. that isn't just me-- there are plenty of selinux and docker guys who say the same thing
[15:13] <jdstrand> we must be able to constrain root, so we must have a MAC
[15:14] <jdstrand> but we want to use namespace technologies in combination with a MAC
[15:14] <jdstrand> that gives the best of both worlds in terms of security
[15:14] <jdstrand> and sets us up for user namespaces (which in the last 5 years have literally had scores of CVEs attributed to them)
[15:16]  * jdstrand notes that docker, lxc and lxd *also* use MAC in combination with namespaces. they work great together and offer a lot of flexibility
[15:20] <pitti> seb128: if you are in a position to test (sorry, I'm not right now), I attached two patches to the upstream bug; the first one is the important one
[15:21] <seb128> pitti, did you need/want desrt's input on the topic?
[15:21] <pitti> seb128: it's now much clearer, but one question remains indeed
[15:22] <pitti> desrt: is it a common or at least acceptable pattern that my_gobject_new() returns NULL on failure?
[15:22] <desrt> only if the object in question is a subclass of GInitable
[15:22] <pitti> desrt: in particular, should libupower-glib's up_client_new() return NULL if it can't connect to upowerd via dbus?
[15:22] <desrt> er.  implements.
[15:23] <pitti> otherwise, how would a client know that the returned object is useless/broken?
[15:23] <desrt> pitti: the normal pattern here is to make this thing GInitable and GAsyncInitable and use those interfaces to implement a sync and async version of the constructor... both with cancellables, and both failable
[15:23] <pitti> UpClient does not implement GIinitable
[15:23] <desrt> then instead of using g_object_new() inside of your _new() you use g_initable_new()
[15:23] <desrt> ditto for the _new_async()
[15:24] <desrt> if the constructor can fail, then it ought to
[15:24] <desrt> this is practically a "by definition" sort of thing
[15:24] <pitti> yeah, it's more ore less a gdbus wrapper around upower's d-bus API
[15:25] <desrt> sounds perfect, then
[15:25] <desrt> GDBusProxy, itself, is async-initable
[15:25] <desrt> if you did g_dbus_proxy_new_for_bus() then it would be a one-step operation for you
[15:26] <desrt> (you could even do subclassing, but imho that would be pretty gross)
[15:26] <pitti> desrt: so the patch on freedesktop bug 95350 is bad because UpClient doesn't implement GInitable?
[15:26] <pitti> well, it *has* a GDbusProxy thing in its private class members, but it is not by itself a GInitable
[15:27] <desrt> that's how you should be doing it, indeed
[15:27] <pitti> the _init() does priv->proxy = up_exported_daemon_proxy_new_for_bus_sync(...)
[15:28] <desrt> this is definitely evil.
[15:28] <desrt> _init() should not block
[15:28] <pitti> and that function is autogenerated code from that gdbus-binding-tool
[15:28] <desrt> !!
[15:28] <desrt> seriously?
[15:29] <desrt> the tool codegens code that does blocking IO in an init function?
[15:29] <pitti> _init() isn't autogenerated
[15:29] <pitti> up_exported_daemon_proxy_new_for_bus_sync() is
[15:29] <desrt> ah.  ya.  that makes sense.
[15:30] <willcooke> zut alors!  It's team meeting time...  I have to leave in 30 mins, so desrt pitti ok to interupt you?
[15:30] <pitti> what should block then? _new()?
[15:30] <pitti> willcooke: sure, sorry
[15:30] <willcooke> pitti, no no, sorry to jump in
[15:30] <willcooke> oki
[15:30] <seb128> just move them to #ubuntu-devel
[15:30] <seb128> ;-)
[15:31] <willcooke> #startmeeting Desktop Team Weekly Meeting - 2016-05-17
[15:31] <meetingology> Meeting started Tue May 17 15:31:05 2016 UTC.  The chair is willcooke. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[15:31] <meetingology> Available commands: action commands idea info link nick
[15:31] <willcooke> Roll call: andyrock, attente, desrt,  dgadomski, fjkong(out), happyaron, hikiko, laney, qengho, seb128, sweet5hark, themuso (out), tkamppeter(out), trevinho, robert_ancell (out)
[15:31] <desrt> pitti: do you want me to try to do a patch for this?
[15:31] <desrt> willcooke: o/
[15:31] <andyrock> o/
[15:32] <seb128> hey
[15:32] <Trevinho> \o
[15:32] <Sweet5hark> heya
[15:32] <dgadomski> o/
[15:32] <willcooke> that'll do to get started
[15:32] <willcooke> #topic andyrock
[15:33] <andyrock> # proposed a fix for the bug about the newly installed application not appearing on the dash
[15:33] <andyrock> # started working on https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1582433 just because I've aleady everthing setup to work on it
[15:33] <seb128> andyrock, I saw your ping, just didn't have slots to go back to that yet, let me know if you need sponsoring (need to see if libunity and gnome-menus needs to land in locked steps)
[15:34] <andyrock> # bug traging
[15:34] <andyrock> *triaging
[15:34] <andyrock> # reviews
[15:34] <andyrock> # eof
[15:34] <willcooke> thanks andyrock
[15:34] <willcooke> #topic attente
[15:34] <andyrock> seb128: yeah i may need sponsoring
[15:34] <seb128> let's discuss that after the meeting
[15:34] <attente> hi, was at the snappy sprint last week
[15:34] <attente> looked into how to add featured snaps to the overview shell of gnome-software
[15:34] <attente> debugging some theming issues and menus in snaps for qt applications
[15:35] <attente> looked into https://bugs.launchpad.net/snappy/+bug/1580740, did a proof of concept fix with didrocks
[15:35] <attente> uploaded gnome-software rebased to 3.20.2 to a ppa, could use a lot of testing: https://launchpad.net/~attente/+archive/ubuntu/gnome-software
[15:35] <attente> (eof)
[15:35] <willcooke> thanks attente
[15:35] <willcooke> welcome back home :)
[15:35] <attente> thanks :)
[15:35] <willcooke> #topic desrt
[15:35] <seb128> attente, hey, wb! hope it was a good week, glad you made it back ;-)
[15:35] <desrt> o hai!
[15:35] <attente> seb128: lol
[15:36] <desrt> having a pretty interesting week.  got caught up on some glib reviewing last week, and this week i'm being pulled into a couple of new and interesting directions
[15:36] <desrt> going to look at the possibility of using jhbuild to get more up-to-date versions of apps into snaps, while at the same time resolving all of the hardcoded-path issues that we keep running in to based on using .debs
[15:37] <desrt> also had a really interesting conversation with alex just now about dconf in confined apps... have a clearer sense of direction now
[15:37] <desrt> and for the rest of today i'm probably helping pitti make a much more complicated patch than he needs to for upower
[15:37] <desrt> eof.
[15:37] <willcooke> thanks desrt
[15:37] <willcooke> did you ever make headway with that bug btw?
[15:38] <willcooke> #topic dgadomski
[15:38] <dgadomski> hey
[15:38] <dgadomski> * more Samba debugging - turned out that 2 more users hit bug 1576109 - fortunately there already was a fix to that in a ppa
[15:38] <dgadomski> * still waiting for input to examine the kerberos auth samba bug I mentioned last week, so I'm stuck with this
[15:38] <dgadomski> * researching possible fixes for bug 1578398 - prepared debdiffs with a temporary workaround for concerned users
[15:38] <dgadomski> eof
[15:38] <willcooke> thanks dgadomski
[15:38] <dgadomski> thanks
[15:39] <willcooke> #topic FJKong
[15:39] <willcooke> 1 do research on how to display candidate word window vertically,
[15:39] <willcooke> 2 continue on animated skin work of sogou im.
[15:39] <willcooke> 3 tracking bug : wrong position of candidate words window on firefox
[15:39] <willcooke> eof
[15:39] <willcooke> #topic happyaron
[15:39] <happyaron> hey
[15:39] <happyaron> 1. Update NM (and some friends) 1.2.2 for yakkety and 1.2.0 for xenial
[15:39] <happyaron> 2. Work with OEM people for NM related issues
[15:39] <happyaron> eof
[15:39] <willcooke> thanks happyaron
[15:39] <willcooke> #topic hikiko
[15:39] <hikiko> hello
[15:39] <hikiko> - working on this nasty bug in multimonitor: if we have two outputs o1 and o2, when the rendering is done in o2 and the components of o2 are scaled, some parts of the o1 appear in both outputs (eg o1's panel appears without artifacts in o1 but a part of it reappears scaled in o2). This indicates that there's either a problem in our 2D clipping (parts of o1 that should be clipped still appear and follow the o2 transformations) or that for some
[15:39] <hikiko> reason we render in all outputs when we should only render in one. (what happens at the end is that compiz renders things per output but nux renders things in the whole screen).
[15:39] <hikiko> - fixes in ezoom damage, +added signals to damage components only when there's a change in zoom transform
[15:39] <hikiko> - a fix in expo, scale branch (merged by marco)
[15:39] <hikiko> - a brief look at the vm issues - tasks
[15:39] <hikiko> EOF
[15:40] <willcooke> thanks hikiko
[15:40] <willcooke> #topic Laney
[15:40] <Laney> hi
[15:40] <Laney> • Got PagerDuty working for appstream monitoring, now I get called, texted and emailed when it stops updating!
[15:40] <Laney> • Send upstream fixes to move the 'show-weekdate' setting to a new key in gsettings-desktop-schemas
[15:40] <Laney> • A few updates/SRUs: glib, glib-networking gvfs
[15:40] <Laney> • Fix to gnome-calendar goa activation
[15:40] <Laney> • Start working on gtk 3.20 theme changes, going to be a few days worth of work there at least
[15:40] <Laney> • Help with reviewing/tweaking job description for new hires
[15:40] <Laney> 𝇛
[15:40] <willcooke> thanks Laney
[15:41] <willcooke> #topic qengho
[15:41] <qengho> * Finished with chromium 50.0.2661.102. Yes. Version 50. Gave to #security for upload.
[15:41] <qengho> * Didn't get appstream included in Chromium yet. Sorry, Laney. Maybe later.
[15:41] <qengho> * To-do: Figure out most recent SIGILL on snap of Google Chrome/Chromium. Could be some hidden SECCOMP fiddling.
[15:41] <qengho> EOF
[15:41] <willcooke> thanks qengho
[15:41] <willcooke> #topic seb128
[15:41] <qengho> And Laney, I made a kind of dead-man's-switch for notifications when a machine stops working.
[15:41] <seb128> • had monday off
[15:41] <seb128> • debugged usd/upower segfault, reduced to a simple upower example, filed upstream bug
[15:41] <seb128> • looked at the versions page not updating and restored the service
[15:41] <seb128> • joined discussion about using systemd user sessions in y
[15:41] <seb128> • SRUed a brasero update to fix translations and libdvdcss loading
[15:41] <seb128> • helped willcooke to debug missing speaker icon issue
[15:41] <seb128> • removed non working "browse files..." buttons from bluetooth settings/indicator
[15:41] <seb128> • webkitgtk 2.4.11 bugfix update+SRU
[15:41] <seb128> • backported u-s-d fix for keyboard backlight status on login
[15:41] <seb128> • some snappy discussions
[15:41] <seb128> • triaging of incoming launchpad/errors reports

[15:42] <willcooke> thanks seb128
[15:42] <willcooke> #topic Sweet5hark
[15:42] <Sweet5hark> - short week (monday was holiday here)
[15:42] <Sweet5hark> - some upstream mentoring/codereview for GSoC work on my hometurf
[15:42] <Sweet5hark> - work on snapcrafting 5.2 alpha
[15:42] <Sweet5hark> - still/again seeing weird linking/header foo with building NSS => investigating
[15:42] <Sweet5hark> EOF
[15:43] <willcooke> thanks Sweet5hark
[15:43] <willcooke> #topic TheMuso
[15:43] <willcooke> please let me have your update TheMuso, unless I've deleted by accident
[15:43] <willcooke> #topic tkamppeter
[15:43] <willcooke> - Google Summer of Code 2016: Guide students to get started with their projects
[15:43] <willcooke> - lsb package: Re-introduced the LSB compatibility binary packages Ubuntu-only to fix incompatibility of Ubuntu 16.04 with Epson's printer drivers (bug 1536353).
[15:43] <willcooke> - cups-browsed: Adding debug log file generation to more easily investigate bugs, especially problems during system boot and shutdown, like bug 1579905.
[15:43] <willcooke> - Bugs.
[15:43] <willcooke> #topic Trevinho
[15:44] <Trevinho> · New landing for bamf, compiz, unity, unity settins daemon
[15:44] <Trevinho> · Created xenial branches for bamf, compiz, unity, u-s-d
[15:44] <Trevinho> · Fixed build failures for unity in yakkety
[15:44] <Trevinho> · Reviews for lots of compiz community contributions (yay!) and unity
[15:44] <Trevinho> · New unity upstream release 7.4.0 is out (compiz will follow soon)
[15:44] <Trevinho> · u-s-d improvements for keyboard backlight support
[15:44] <Trevinho> · UPower patch for getting proper keyboard brightness, instead of the cached one
[15:44] <Trevinho> · Built a small snapcraft build plugin to make possible to patch upstream code
[15:44] <Trevinho> · Made hello-unity snap working, making building of gtk/gdk/minecaches dynamic on first start
[15:44] <Trevinho> · Snapcrafted a simple electron app (working only unconfined, for now)
[15:44] <Trevinho> · Fixed two crashes in unity7
[15:44] <Trevinho> · Preapared PPAs for gnome-terminal and emacs windows restoration fix.
[15:44] <Trevinho>  /EOF
[15:44] <willcooke> BOOM!
[15:44] <willcooke> thanks Trevinho
[15:44] <willcooke> #topic robert_ancell
[15:44] <willcooke> - GNOME package updates / filing bugs with excuses
[15:44] <willcooke> - Fix up versions page [1] to track correct versions
[15:44] <willcooke> - Paid snap work
[15:44] <willcooke> #topic willcooke
[15:44] <willcooke> Unprepared...
[15:45] <willcooke> Make tabs bug SRU compliant
[15:45] <willcooke> Helped fix missing speaker icon
[15:45] <willcooke> #Politics
[15:45] <seb128> willcooke, was the [1] from robert_ancell pointing to some url?
[15:45] <willcooke> http://people.canonical.com/~platform/desktop/versions.html
[15:45] <willcooke> seb128, sorry
[15:46] <willcooke> erm, can't remember what else, sorry, have to leave in a second
[15:46] <willcooke> oh, worked with recruitment to get them up to speed on the hires
[15:46] <willcooke> Laney helped with the JD so we will start getting CVs soon
[15:46] <willcooke> \o/
[15:46] <seb128> sorry, I didn't managed to reply to that today, got caught up with backlog and meetings
[15:46] <seb128> on my list for tomorrow
[15:46] <willcooke> seb128, no worries
[15:47] <willcooke> #topic Any Other Business
[15:47] <seb128> I'm trusting Laney for giving good feedback though ;-)
[15:47] <willcooke> :)
[15:47] <willcooke> anyone got bidnezz?
[15:47] <willcooke> going
[15:48] <willcooke> going
[15:48] <willcooke> gone
[15:48] <willcooke> #endmeeting
[15:48] <meetingology> Meeting ended Tue May 17 15:48:19 2016 UTC.
[15:48] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-desktop/2016/ubuntu-desktop.2016-05-17-15.31.moin.txt
[15:48] <willcooke> thanks everyone
[15:48] <seb128> thanks!
[15:48] <willcooke> Got to go out now, but telegram if I can help with anything
[15:48] <seb128> have fun!
[15:49] <Laney> you can help me get a 99 flake
[15:49] <willcooke> Laney, from the ice cream man, or a fake one from the supermarket
[15:49] <willcooke> http://www.tesco.com/groceries/Product/Details/?id=251821479
[15:50] <Laney> hah
[15:50] <Laney> my browser won't even load tesco's css
[15:50]  * Laney high fives firefox
[15:51] <Laney> waitrose.com works though :) :) :) :)
[15:51] <willcooke> :D
[15:52] <Sweet5hark> willcooke: are JDs online? if so, do you have a link?
[15:56] <willcooke> Sweet5hark, not online yet, probably tomorrow
[15:56] <willcooke> will send you a link
[15:56] <Sweet5hark> willcooke: awesome, thanks!
[16:01] <Laney> ah the fun of an initial offlineimap sync
[16:02] <seb128> happyaron, hum, was https://launchpad.net/~happyaron/+archive/ubuntu/network-manager were you had the 1.2.2 update ready? did you superseed it with another update? also did you do the other sources, gnome/vpn/...?
[16:07] <seb128> happyaron, also why did you rename patches? need to undo that for the SRU or the diff is going to be harder to review
[16:08] <happyaron> seb128: will maintain a seperate branch for xential SRU, in yakkety I switched to use gbp-pq to manage the patch queue
[16:09] <happyaron> seb128: https://launchpad.net/~happyaron/+archive/ubuntu/ppa/+sourcepub/6431454/+listing-archive-extra
[16:09] <seb128> happyaron, is debian using that?
[16:09] <seb128> or is that increasing diff?
[16:10] <seb128> I never use gbp so I can't comment on how much of a win that is
[16:11] <mitya57> The -gnome part of the new NM is the most interesting because upstream integrated our indicator stuff
[16:12] <happyaron> seb128: plan to sell that, there are quite a lot of projects using gbp-pq in debian though
[16:12] <seb128> mitya57, that's already true in 1.2.0 no?
[16:13] <seb128> happyaron, ok, you are maintaining it so your call ... do you have updates for -gnome/vpn/etc? ;-) I guess nm 1.2.2 works fine with the others still being on 1.2.0/you are testing that?
[16:13] <happyaron> seb128: it's basically the same diffs, but managed by git patch queues
[16:13] <mitya57> Oh yes, I missed that we already have 1.2.0 :)
[16:13] <happyaron> seb128: will update most of them by this weekend
[16:14] <seb128> mitya57, :-)
[16:15] <seb128> happyaron, thanks, just to confirm you tested n-m 1.2.2 with applet 1.2.0 and it works right? good to upload? ;-)
[16:17] <happyaron> yes that works
[16:17] <seb128> happyaron, good, I'm sponsoring it, thanks for the work! when you update -gnome please backport the commit I pointed earlier ;-)
[16:17] <happyaron> no problem
[16:19] <happyaron> time to bed, cy
[16:19] <seb128> happyaron, night!
[16:25] <Trevinho> pitti: https://bugs.freedesktop.org/show_bug.cgi?id=95457 I've pinged also hughsie about that
[17:15] <Laney> nn!
[17:16] <seb128> Laney, have a good evening!
[17:16] <seb128> other desktopers as well ;-)
[17:16] <seb128> time for dinner and sport here
[19:29] <cinch> where can i find a kernel for 16.04 with the BFQ scheduler?
[19:30] <cinch> the "ck" patchset
[19:32] <sarnold> cinch: I don't think I've seen any ppas for it; I think if you want it you have to build it yourself
[19:34] <cinch> hmm ok
[19:35] <cinch> i think ill try other things first
[19:35] <cinch> im concerned with latency on the desktop, alt+tab takes awhile compared to windows 10
[19:35] <cinch> using ubuntu mate with the default software compositor
[19:36] <cinch> and in general its not as "snappy"
[19:38] <sarnold> I would seriously hope alt-tab doesn't need to hit the disk :)
[19:38] <cinch>  :-D
[19:38] <sarnold> if it does there are problems elsewhere that need addressing rather than whatever IO scheduler is in use :)
[19:38] <cinch> yeah
[19:38] <cinch> firefox has screen tearing when i scroll..
[19:39] <cinch> using the non_gnu Nvidia driver
[19:39] <cinch> oh well, linux woes as usual ;)
[19:40] <cinch> interestingly, on my old thinkpad x200s it's super snappy
[19:40] <cinch> with intel on board graphics, core 2 duo
[19:41] <cinch> but this monster core i5 2500k with a nvidia gtx 760 has issues :P
[19:43] <cinch> i solved it: -> in "Mate Tweak" -> change the window manager to compiz
[19:43] <cinch> easy :-)
[19:43] <sarnold> yeah, my intel onboard on my ~3.5 year old laptop is super-snappy doing virtual desktop changes, no tearing with firefox scrolling, etc., but I understand newer intel drivers don't have the quality of the old intel drivers :( and what with their recent "lay off ALL the employees" binge, it's hard to imagine their driver quality improving :(
[19:43] <sarnold> hah, nice
[19:44] <cinch> oh i didnt know that about newer intel drivers
[19:44] <cinch> they layed off alot of workers
[19:45] <cinch> now i just need to get reliable suspend/resume
[19:45] <cinch> when i suspend, the monitor doesnt go into standby
[20:24] <cinch> d'oh compiz crashed :)
[20:35] <cinch> let's say i want to log each process that was started (with its command line parameters), how would i go about it
[21:42] <sarnold> cinch: you've got a few choices here :) auditctl should be able to log executions, but it may not get arguments; old-school unix process accounting should also be able to get e.g. summaries of executions _after_ the processes have exited; the execsnoop program from https://github.com/iovisor/bcc can give you exactly what you wanted, but it's not in the archive so it requires a bit more work to install it and use it
[22:02] <cinch> sarnold, tyvm


[16:28] <blackboxsw> hey smoser, so where do things stand with the current SRU process? I'm trying to find an sru bug related to the work.
[16:30] <smoser> blackboxsw, ok.. collecting some info
[16:30] <blackboxsw> good deal, thanks.
[16:31] <smoser> typing https://public.etherpad-mozilla.org/p/cloud-init-sru-info
[16:35] <smoser> blackboxsw, so i guess the easiest thing to do is just start doing it... we can walk down the list and pick one by one. if you dont understand the test case / verification that i put in for anything, then you can either
[16:35] <smoser> a.) ask questions
[16:35] <smoser> b.) go to the next one
[16:36] <smoser>  (until you run out and are forced to 'a')
[16:37] <blackboxsw> yeah that sounds like a good loop. expect the a's
[16:39]  * blackboxsw starts at the top
[16:39] <blackboxsw> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1676460 xenial validation
[16:40] <smoser> blackboxsw, many of the bugs reference 'lxc-proposed-snapshot'
[16:40] <smoser> that one did not. it would be good to make yourself a lxc with proposed cloud-init in it.
[16:41] <smoser> see http://pad.lv/1674766 for an example.
[16:42] <blackboxsw> cool will do
[16:44] <smoser> that requires 'mount-image-callback' (cloud-utils) .. and it requires lxc1 for 'lxcnsuserexec'
[16:44] <smoser> err... lxc-nsuserexec
[16:47] <smoser> so i just ran
[16:47] <smoser>  ./bin/lxc-proposed-snapshot -vvv xenial --proposed xenial-proposed --publish
[16:48] <smoser> which means i can now:
[16:48] <smoser> lxc launch xenial-proposed xp1
[16:48] <smoser> and it starts with cloud-init inside from -proposed
[16:52] <blackboxsw> hrm /home/csmith/src/server/lxd:xenial-proposed-11791681: not a file   re-reading the script intent
[16:53] <blackboxsw> and I have lxc1 & cloud-utils
[16:53] <blackboxsw> per http://pastebin.ubuntu.com/24375059/
[16:54] <smoser> newer cloud-utils needed. :-(. that support i think went into zesty.
[16:55] <blackboxsw> updating... :/
[16:55] <smoser> if you want, you can probably just grab it
[16:55] <smoser> its a simplish script
[16:55] <smoser> and put it in $PATH
[16:56] <blackboxsw> yeah might just do that while waiting on my desktop upgrade.
[17:01] <smoser> yikes. you are brave.
[17:01] <smoser> (i run the development release but most do not :)
[17:01] <smoser> the other option is doing this on an instance somewhere. that is why lxd is nice.
[17:02] <smoser> blackboxsw, http://bazaar.launchpad.net/~cloud-utils-dev/cloud-utils/trunk/view/head:/bin/mount-image-callback
[17:11] <blackboxsw> ok, looks better thanks smoser with the path tweaked to reference the mount-image-callback script thanks.
[17:22] <blackboxsw> have a quick errand, back in 20
[17:29] <smoser> k
[17:42] <ahasenack> blackboxsw_bbl: smoser reading the etherpad and backlog
[17:51] <blackboxsw> meh, looks like my xenial flavor of lxc doesn't accept push -p
[17:54] <ahasenack> smoser: ok, read it all, +1 on the plan to go down the list and note which bug we are verifying
[17:54] <ahasenack> smoser: https://bugs.launchpad.net/cloud-init/+bug/1674946 has been commented by someone saying the fix worked
[17:55] <smoser> blackboxsw, yeah. you can use the snap i think for lxd
[17:55] <ahasenack> not the reporter, though
[17:55] <smoser> but migth still have the issue with mount-image-callback there.
[17:55] <smoser> ahasenack, so what i'd do is just comment:
[17:56] <smoser>  I'm marking this verification-done-xenial based on comment X
[17:56] <smoser> and then do that.
[17:56] <ahasenack> ok
[18:03] <smoser> ahasenack, blackboxsw i think you are both aware, but you tag with 'verification-done-xenial' and 'verification-done-yakkety'  rather than just 'verification-done'
[18:03] <ahasenack> right
[18:04] <blackboxsw> smoser, hmm looks like my xenial proposed validation fell over the for https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1674766  http://pastebin.ubuntu.com/24375361/
[18:04] <blackboxsw> the pastbin indicates ds-identify didn't process BigStep support right?
[18:05] <blackboxsw> I'll double check that I have setup the seed files properl
[18:05] <smoser> blackboxsw, right. let me try too
[18:06] <blackboxsw> smoser this might be because I had started this lxc in the first place before adding the seed files in an attempt to work around my lxc file push not supporting -p option
[18:07] <smoser> quite possibly. yes.
[18:07] <blackboxsw> start would have run through cloud-init I expect
[18:07] <blackboxsw> yeah sorting my lxc command version
[18:10] <ahasenack> it's good to see the "before" case
[18:18] <smoser> blackboxsw, yeah. so when working with cloud-init and lxc  i have some tools (like the lxc-propsed-snapshot) that help you to adjust a container without starting it.
[18:18] <smoser> the other option is to start it and then "clean" it.
[18:22] <smoser> the bin/do-reboot  script there helps do the clean
[18:23] <ahasenack> smoser: config-drive newbie here, sorry
[18:23] <ahasenack> how do I pass that to a container?
[18:23] <ahasenack> a config-drive configuration, and where can i find out what it should look like?
[18:24] <blackboxsw> TIL, thx smoser
[18:25] <ahasenack> going through https://bugs.launchpad.net/nova-lxd/+bug/1673411 for some reference, looks like it has a helper script attached
[18:25] <ahasenack> ah, it's in tools/
[18:30]  * ahasenack sees the commented bits about network_data.json
[18:34] <smoser> i've been walking up from the bottom
[18:34] <smoser> but i'm going to leave https://bugs.launchpad.net/cloud-init/+bug/1665694 for one of you as a introduction to integration test suite
[18:57] <blackboxsw> smoser, great. ok finally sorted things and have a zesty box at my disposal
[18:57] <blackboxsw> lxc file pull $name/run/cloud-init/result.json -
[18:57] <blackboxsw> {
[18:57] <blackboxsw>  "v1": {
[18:57] <blackboxsw>   "datasource": "DataSourceBigstep",
[18:57] <blackboxsw>   "errors": []
[18:57] <blackboxsw>  }
[18:57] <blackboxsw> }
[18:58] <blackboxsw> ok progress. now time to do some work
[18:59] <smoser> woot!
[18:59] <smoser> blackboxsw, you can take the https://bugs.launchpad.net/cloud-init/+bug/1665694
[18:59] <blackboxsw> will do thx
[19:08] <ahasenack> smoser: can I trigger this bug with just lxd, faking hyperv somehow? https://bugs.launchpad.net/cloud-init/+bug/1674946
[19:09] <ahasenack> I have a config drive in /config-drive in this lxd, with network_data.json, but it looks like it's not being read (I want to trigger the bug first, then check the fix)
[19:12] <ahasenack> or maybe I'm being hit by https://bugs.launchpad.net/nova-lxd/+bug/1673411, but this cloud-init in -proposed should have that fix
[19:12] <smoser> reading
[19:12] <ahasenack> which is also in our list
[19:13] <ahasenack> ah
[19:13] <ahasenack> ok, got it
[19:13] <smoser> ahasenack, (/me realizes for the first time that you have different internal and external personalities... andreas -> ahasenack)
[19:13] <ahasenack> I wanted to test the "before" case, but I can't because I need the fixed cloud-init for it to parse /config-drive according to #1673411
[19:13] <ahasenack> smoser: :)
[19:13] <ahasenack> andreas was already taken here, my ninjas didn't find him
[19:14] <smoser> so before the new version, you should be able to populate /var/lib/cloud/data/seed/ConfigDrive
[19:14] <smoser> i think
[19:14] <smoser> (with the same contents as /config-drive)
[19:14] <ahasenack> smoser: ok
[19:14] <smoser> and it should look there.
[19:33] <ahasenack> yay
[19:33] <ahasenack> I haz result.json
[19:40] <blackboxsw> interesting in running tox on the cloud-init tests is that my cd drive started spinning up. wondering if we're leaking some calls to mount that drive from the unit tests
[19:41] <smoser> blackboxsw, it probably is.
[19:41] <smoser> someone working on freebsd found one of those the other day ... let me se
[19:44]  * ahasenack injecting errors to see what happens
[19:44] <ahasenack>    "Unknown network_data link type: dvs-andreas-was-here",
[19:45] <ahasenack> good
[19:46] <smoser> nice ahasenack !
[19:47] <ahasenack> you made an MP against upstream to stop sending these deprecated link types, right
[19:47] <ahasenack> https://review.openstack.org/#/c/400883/2
[19:47] <smoser> yeah, and it just made it into trunk
[19:48] <smoser> they're really not "deprecated". as they're real and useful link types at the hypervisor level
[19:48] <smoser> but not at the guest level
[19:49] <ahasenack> right, wrong choice of words
[19:50] <ahasenack> smoser: is cloud-init also responsible for creating the ubuntu user?
[19:50] <smoser> yes
[19:50] <smoser> > precise at least
[19:50] <ahasenack> smoser: ok, because once I injected that failure in the network, the ubuntu user wasn't created: https://pastebin.canonical.com/185908/
[19:51] <smoser> yeah. if the datasource traces it wont go on
[19:51] <ahasenack> ok
[19:51] <smoser> well, in that way at least.
[19:51] <ahasenack> sorry about the canonical pastebin
[19:52] <ahasenack> habit
[19:52] <ahasenack> and bookmarks
[19:55] <smoser> ahasenack, well you can just use 'pastebinit' now!
[19:55] <smoser> i am constantly doing:
[19:55] <smoser>  xsel -o | pastebinit
[19:55] <ahasenack> indeed!
[19:55] <ahasenack> finally
[19:55] <blackboxsw> smoser, looks like I'm hitting a dependency error trying to install pylxd as the tox -e citest environment
[19:55] <smoser> (highlight something  and then paste and paste the url to something)
[19:56] <smoser> hm..
[19:56] <blackboxsw> http://paste.ubuntu.com/24375992/
[19:56] <smoser> i suspect you need python3-dev
[19:56] <rharper> blackboxsw: ping powersj ; he's worked through those before
[19:56] <smoser> yeah
[19:56] <blackboxsw> powersj, has been invoked :)
[19:57] <smoser> tox is wonderful
[19:57] <smoser> until you have c extentions
[19:57] <smoser> then it becomes honestly kind of silly in my opinion
[19:57] <smoser> but still better than lots of other stuff
[19:57] <smoser> blackboxsw, install python3-dev with apt
[19:57] <smoser> and try again
[19:58] <smoser> pylxc needs c bindings to lxc and thus the sillynees. python3-dev is pretty light though.
[19:59] <blackboxsw> getting closer. ok new traceback, missing C headers as well. I'll iterate over these to get them fixed. and report a list of the deps I had to install to get things working
[20:04] <blackboxsw> ok needed only libssl-dev too. So, the list of packages I've installed on a fresh zesty system: ls
[20:05] <blackboxsw> lxc1, cloud-utils, devscripts, python3-dev, libssl-dev
[20:06] <nacc> we use lxc1?
[20:10] <smoser> lxc1 provids lxc-usernsexec
[20:10] <smoser> which is used by mount-image-callback lxd:foo
[20:10] <smoser> to get the right user namespace when it chroots to the target
[20:10] <rharper> nacc: yeah; I suggested we get lxd to implement lxc-usernsexec but I forget why they said not to
[20:17] <smoser> blackboxsw, http://paste.ubuntu.com/24376111/
[20:17] <smoser> so inside an lxc container ^ worked.
[20:18] <smoser> well, it shows me jumping into the container
[20:18] <smoser> but that should list everything you need on xenial which i suspect is the same on zesty
[20:19] <blackboxsw> excellent, will not distrupt my other systems then
[20:20] <smoser> blackboxsw, well. you dont *really* want to run inside lxc
[20:20] <smoser> because then you can't use zfs
[20:20] <smoser> :)
[20:20] <smoser> i'm not certain if it works or not fully. but lack of zfs is reason enough for me to not want to do it.
[20:22] <blackboxsw> certainly. makes sense
[20:22] <smoser> if you want... you can walk the merge proposal path ...
[20:22] <smoser> with a doc enhancement to doc/rtd/topics/tests.rst
[20:22] <smoser> with the above
[20:23] <smoser> (the dependencies needed and such)
[20:23] <blackboxsw> +1 smoser sure I'll put up an mp.
[20:30] <ahasenack> smoser: ok, so I verified xenial and yakkety and added the respective verification-done-<release> tags. Someone else will flip the verification-needed tag into verification-done?
[20:30] <ahasenack> ops, for bug https://bugs.launchpad.net/nova-lxd/+bug/1673411 that is
[20:35] <smoser> ahasenack, no. you drop the verification-needed.
[20:35] <smoser> changing it to verification-done-<x>
[20:35] <smoser> really with 2 srus in flight at the same time... there really should be verificaton-needed-xenial and verification-needed-yakkety
[20:36] <smoser> the sru process really just doesn't handle the different releases at once all that well
[20:37] <ahasenack> smoser: how do they know they should hold pushing this to updates since we have the other bugs for the same package still being verified? Via debian/changelog?
[20:51] <smoser> ahasenack, https://people.canonical.com/~ubuntu-archive/pending-sru.html
[20:52] <smoser> look for cloud-init there. after everything gets verified, all its bugs should be green or gold (i dont understand the difference)
[20:52] <ahasenack> ok, I see the proposed package associated with all the bugs
[20:56] <blackboxsw> smoser, so I added verification-done-xenial verfication-done-yakkety tags to https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1674766
[21:00] <Rafael> Hello folks
[21:00] <Guest678> can somebody help to clarify a doubt that I have
[21:01] <Guest678> do I need any special configuration to enable cloud-init to reset SSH keys?
[21:01] <Guest678> The first time I create an instance it assigns the configure SSH key to it, however, if I change the key, cloud-init is not updating it in the VM
[21:02] <smoser> change the key ?
[21:02] <smoser> hi Raboo
[21:02] <smoser> bah. sorry Raboo tab complete fail.
[21:04] <Guest678> yeap
[21:04] <Guest678> I mean change the public key that is inject into the VM
[21:05] <Guest678> When the VM is created cloud-init succesfuly install the keys under ~/.ssh/authrozied_keys
[21:05] <Guest678> However, if I change the keys in my cloud orchestrator, and then reboot the VM, cloud-init is not changing the keys
[21:06] <smoser> Guest678, yeah, that is only done on first instance boot.
[21:06] <Guest678> I am guessing it has something to do with these logs ""
[21:06] <Guest678> yep
[21:06] <Guest678> that is what I thought from reading the log files
[21:06] <smoser> it is not kept in sync. that is a feature that we'd like to have at some point.
[21:06] <Guest678> yes there a way to configure this?
[21:06] <Guest678> ah
[21:06] <smoser> um... maybe.
[21:07] <Guest678> is there a work around?
[21:07] <Guest678> I thought that there would be a way to indicate which modules I want to run once per instance, or once per boot, or constantly with the VM running
[21:08] <smoser> actually, not easily. you could turn the ssh config module (which is what puts those keys into the default user's .ssh/authorized_keys)
[21:08] <smoser> but changing that to run PER_ALWAYS (boot) would be not ideal
[21:08] <smoser> as that is the same thing that wipes the host keys
[21:08] <smoser> which you probably do not want ot happen every boot
[21:09] <smoser> what cloud provider is this ?
[21:09] <Guest678> ah
[21:09] <Guest678> the same script that configures SSH keys is setting up host keys?
[21:09] <Guest678> CloudStack
[21:09] <Guest678> the module you are talking about is the one called "ssh"?
[21:10] <Guest678> I noticed some other module called "ssh-authkey-fingerprints"
[21:10] <smoser> blackboxsw, on https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1674766
[21:11] <smoser> (and the others you have done)
[21:11] <smoser> the sru person will want to see a comment at least stating "i verified both xenial and yakkety following the test case template above"
[21:11] <smoser> i like to copy and paste evidence of having done that
[21:11] <smoser>
[21:11] <smoser> https://bugs.launchpad.net/cloud-init/+bug/1674685https://bugs.launchpad.net/cloud-init/+bug/1674685
[21:12] <smoser> Guest678, yeah, that does sound silly doesnt it :)
[21:12] <smoser> yes, its ssh. we really should separate that out so you could tweak one wihtout the other.
[21:12] <smoser> but as it is right now... the datasources cache the data on disk (so as to not rely upon a metadata service on reboot)
[21:12] <Guest678> hmm
[21:12] <smoser> so.. they'd just re-aply the cached data.
[21:13] <smoser> this is a feature we'd like to have, but its not present now. sorry .
[21:13] <blackboxsw> +1 smoser will add that now and close those bugs appropriately
[21:13] <smoser> well, you dont change the state of the bugs..
[21:13] <blackboxsw> s/close/tag
[21:13] <Guest678> thanks @smoser
[21:13] <smoser> once the bug moves from -prpoosed to -updates it will automatically do that.
[21:17] <smoser> ahasenack, https://bugs.launchpad.net/cloud-init/+bug/1570325
[21:17] <smoser> you can do that one... that is a integration test also. (for learning to at least run the integration test)
[21:17] <ahasenack> deal
[21:21] <smoser> ok. /me has to run.
[21:27] <ahasenack> ok, https://bugs.launchpad.net/cloud-init/+bug/1674946 verified
[21:27] <ahasenack> this will go much faster from now on
[21:31] <ahasenack> ok, I'm EOD
[21:45]  * blackboxsw is spending some time walking through those integration tests on cloud-init
[21:45] <blackboxsw> see you smoser/ahasenack
[21:46] <powersj> blackboxsw: https://cloudinit.readthedocs.io/en/latest/topics/tests.html also worth a read
[21:50] <blackboxsw> excellent
[21:50] <blackboxsw> keep 'em coming
[21:51] <blackboxsw> actually, that's what I'm going to put up a simple doc mp for
[21:51] <blackboxsw> just trying to wrap up some verification first
[21:52] <powersj> blackboxsw: are you familiar with tox and running it?
[21:52] <powersj> both cloud-init and curtin use tox as a wrapper around our unit tests and style tests. When we get a MR that is what we expect to pass
[21:52] <blackboxsw> just a bit, TIL about environments. you guys have a bit more tox.ini config options/setup than services I've worked on
[21:52] <powersj> you can look at tox.ini in the root dir of both projects
[21:52] <powersj> ah ok :)
[21:53] <dpb1> powersj: MR... wth
[21:53] <powersj> O.o
[21:53] <powersj> merge request?
[21:53] <dpb1> step child of MP and PR
[21:53] <powersj> lol
[21:53] <blackboxsw> haha
[21:54]  * powersj is split brain due to github and launchpad usage
[21:54] <dpb1> :)
[23:54] <powersj> Looks like pylint 1.7 was released today O.o


[00:04] <agaida> i guess you should compare the hash of the downloaded file with the original, makes more sense
[00:05] <Aison> I did and it's equal
[00:05] <Aison> but I just fixed it
[00:06] <Aison> it bootet now into initramfs, there I mounted the local drive, changerooted into it
[00:06] <Aison> and did lilo -r /
[00:06] <Aison> now the machine boot
[00:07] <Aison> somehow the installer cannot install the boot manager properly
[03:34] <LogicalDash> I'm trying to run lubuntu in a kvm virtual machine. I get the bootloader screen and can select things there as normal but when I try to actually boot I get a kernel panic.  The message says to try passing init=, I have no clue what to put there though. Help?
[03:36] <LogicalDash> ok, error says "Starting init: /bin/sh exists but couldn't execute it"
[03:56] <holstein> LogicalDash: i would treat it just like normal.. test my downloaded iso
[03:56] <holstein> !md5
[03:57] <holstein> test my installation media, if any.. then, test other isos, and make sure the KVM virtuam machine can start a "known good" live media
[03:57] <holstein> then, i would look at things like, is my host setup for what my VM needs.. etc
[03:59] <LogicalDash> holstein: ok, well, I think my issue is with kvm. thanks for your help
[04:00] <holstein> you can always try the iso you downloaded in something like virtualbox, to help rule out the host..
[04:07] <agaida> LogicalDash: and the simplest init will be init=/bin/bash - really, it works
[04:08] <agaida> something we all have learned from the initwars :)
[04:09] <LogicalDash> It does work in virtualbox. init=/bin/bash seems not to make any difference.
[04:10] <holstein> well, if it works in vbox, id say, its just something with your kvm setup.. i dont know enought about kvm to be helpful, but, you can ask in #ubuntu or in whatever support kvm specifically has, or another channel, depending on the host OS
[08:11] <ioio> Hi
[08:11] <ioio> Anybody there ?
[08:12] <ioio> Does anyone know a LXLE irc channel ?
[08:14] <Unit193> Likely #lxle.
[08:14] <Unit193> !alis
[08:19] <ioio> thanks
[08:19] <ioio> !alis
[08:23] <ioio> #ubuntu-ro
[09:27] <xchatter> Lubuntu newbie here. When I install a program in Lubuntu like xchat or others it does not show up in the menu afterwards. What am I doing wrong?
[09:39] <mysteriousdarren> xchatter: are you sure it was actually installed?
[09:39] <xchatter> Yes, I can start the programs with the run command. But I am on a live stick, maybe I should mention that.
[09:42] <mysteriousdarren> live stick? so you have no intention of an install?
[09:58] <xchatter> no
[10:38] <Thunder3> i installed jdownloader and it worked fine... but now i dont know how to start it again :/
[11:00] <Thunder3> ah got it running by starting "sh ./jd.sh"
[11:01] <Thunder3> can i make a desktop icon?
[12:30] <LogicalDash> Thunder3: sure, those are just text files written in a certain way. more info: http://standards.freedesktop.org/desktop-entry-spec/latest/
[12:31] <Thunder3> thx will look at this later
[23:17] <terratoma> i can never get an audible bell to happen in lubuntu + any sort of terminal + remote tmux and irssi session
[23:18] <terratoma> or even in a local terminal and local irssi session ( no tmux or screen )


[01:02] <chronic> so how?
[01:02] <LjL> chronic: what's your issue?
[01:03] <chronic> how are you sure it was me u banned not someone else
[01:03] <LjL> chronic: why do you need to know that information?
[01:04] <chronic> i dont know , but you say u know it
[01:04] <LjL> yes, i do know it
[01:04] <LjL> i banned you because you evaded your previous ban
[01:05] <LjL> i know it was you
[01:05] <chronic> i think u have me confused with someone else
[01:05] <LjL> and you know it was you, at least i hope your long term memory is fine and you do
[01:05] <LjL> so i don't see the problem
[01:05] <LjL> i have not confused you with someone else
[01:05] <LjL> which is also testified by the fact that you asked me "what is the problem NOW", implying there was a problem previously.
[01:06] <chronic> u surely have
[01:06] <chronic> whatever you might think, i'm not whoever u think i am
[01:07] <chronic> so please unban me now
[01:07] <LjL> your ban will not be lifted.
[01:07] <LjL> any more questions for us?
[01:07] <chronic> why not? u just banned me without reason
[01:07] <LjL> i banned you for ban evasion.
[01:08] <chronic> i dont know what that is
[01:08] <LjL> evading a ban.
[01:08] <chronic> ok, i didnt do it
[01:08] <LjL> yes, you did do it
[01:08] <chronic> no
[01:08] <LjL> i am not going to believe you didn't
[01:08] <LjL> so drop this topic
[01:08] <chronic> u are mistaken
[01:08] <LjL> anything else?
[01:08] <LjL> !u
[01:09] <chronic> who is your supervisor?
[01:09] <LjL> chronic: nobody.
[01:09] <chronic> u work for nobody
[01:10] <LjL> !attitude
[01:10] <chronic> who pays u?
[01:10] <LjL> you cannot read, can you?
[01:10] <Seeker`> he is a volunteer here
[01:11] <Seeker`> he gives up his free time to do this
[01:11] <chronic> no, he does it because he likes it
[01:11] <LjL> either way, that's none of your business
[01:12] <LjL> if you want to appeal your ban, you'll find information about that in this channel's topic
[01:12] <LjL> if you don't have any other question, then leave
[01:13] <LjL> @mark #ubuntu-ops chronic Ban evading and denying it (of course, ident and realname know much better)
[01:20] <LjL> i don't THINK so
[01:20] <Seeker`> s/so/
[01:20] <Seeker`> s/so//
[01:21] <LjL> depends on your definition of "think"
[01:48] <LjL> khaplja: hi
[01:53] <NTFS> STOP LEAVING YOUR COMPUTERS ON 24/7 YOU ARE CREATING OVER 1000kg OF C02 EMISSIONS A YEAR.
[01:54] <Seeker`> khaplja: how can we help you?
[01:55] <LjL> !staff | maybe ntfs can spend some more time trying to k-line evade? i'm kind of sick of him
[01:56] <LjL> (see #g-ops too)
[01:56] <tsimpson> and #freenode
[02:06] <LjL> what a huge idiot
[08:55] <jussi01> tsimpson: ping
[09:36] <elky> chr|s is being a tosser again i see
[09:50] <topyli> brainac0cult = sam_
[09:52] <ikonia> didn't we ban him yesterday
[09:52] <ikonia> oh, he got bored and left
[09:52] <topyli> yeah
[10:14] <Gary> is he muted in #ubuntu or just not talking? (brainetc....)
[10:14] <ikonia> not talking
[10:14] <ikonia> he was a idiot as "sam_" yesterday
[10:14] <ikonia> left before action was required
[10:15] <Gary> I remember the ip
[10:15] <ikonia> oh really
[10:16] <Gary> gone
[10:18] <elky> if a staff remembers your ip, it's probably not because of the 'being slightly annoying' thing the previous day
[10:21] <Gary> elky: yeah, but annoyingly I have a sh..bad memory, so no idea what for
[10:25] <elky> probably habitual annoyingness
[10:55] <jussi01> I think the !gary factoid might come into sam_ s situation soon :P
[11:03] <jussi01> !info roundcube
[11:03] <jussi01> has anyone used that before? ^^
[11:05] <Myrtti> I have, it had some problems so I stopped using it
[11:11] <jussi01> Myrtti: ok
[11:17] <Myrtti> oooh, an office chair
[11:20] <jussi01> Myrtti: any other suggestions for a good webmail program?
[11:20] <jussi01> Myrtti: btw, when are you coming home?
[11:22] <elky> squirrelmail
[11:24] <jussi01> elky: thats what we have currently, its ok, was hoping for something a little more practical (also, something that doesnt look like from 10 myears ago)
[11:25] <elky> it's the best i know of. sorry
[11:28] <Myrtti> squirrelmail
[11:28] <Myrtti> jussi01: we are currently discussing 30th... (yes I know)
[11:28] <jussi01> *g*
[11:30] <Myrtti> but it's the only one with reasonable ticket prices before the 6th when my mum is having her hip done
[11:32] <jussi01> Myrtti: hehee... flying ryanscare?
[11:33] <Myrtti> if my destination is Tampere, that's the easiest
[11:34] <Myrtti> ooh, working kvm
[11:40] <bazhang><EMAIL_ADDRESS>same as<EMAIL_ADDRESS>??
[12:02] <elky> Gary, you seeing #f?
[12:02] <Gary> elky: bacta?
[12:02] <elky> Gary, i cannot scream troll loud enough
[12:03] <Gary> hehe, he left gaygeeks when I laughed at him
[12:03] <elky> because every time someone laughs at me, the first thing i think of is whether they're coming on to me
[12:05] <Gary> he was being trollish, but we are a good bunch in gaygeeks and like a evil cat, like to play a bit with our prey
[12:05] <bazhang> heh
[12:06] <elky> yeah. bacta's joy comes from people scrambling to get rid of him. people trolling back hurts his little feelings
[12:14] <Gary> we find it works best to troll the trolls, they don't need a ban then, as they are too scared to ever join again :p
[12:20] <elky> yeah, when you're not upholding a social standard like ubuntu is
[12:21] <Gary> yeah, I do feel for you folks
[12:21] <elky> anyway, im going for early sleepies since i'm restless
[12:24] <bazhang> not many standards in -ot of late.
[12:25] <bazhang> none that I can see, that is.
[12:26] <Gary> but I have hardly talked in there
[12:26] <bazhang> -ru used to be troll central, now is very well policed.
[12:26] <Myrtti> thank gods
[12:26] <Gary> yeah, well done for that one bazhang
[12:27] <bazhang> odd that a loco would outshine on of the official channels
[12:27] <bazhang> Gary, its mostly a4tech
[12:28] <Myrtti> I just love how snappy my debian lenny is now that I run it with kvm instead of qemu
[13:12] <Myrtti> splät
[13:13] <Mez> indeed
[13:23] <bazhang> wolf`wolf, how may we help you
[13:24] <wolf`wolf> bazhang:  worng place sorry :)
[13:24] <bazhang> that was icebuntu
[13:24] <bazhang> * [wolf`wolf] (n=admin@<IP_ADDRESS>): hynix
[13:55] <tsimpson> jussi01: pong (21600000ms)
[13:55] <jussi01> rofl
[15:42] <Pici> !test
[17:15] <Pici> slow
[17:36] <LjL> -it op is back on irc now
[17:36] <LjL> apparently sneaked inside his house and turned the wifi router back on to connect from outside :)
[17:37] <LjL> normal people would probably give other things priority than turning on their server, but hey
[17:55] <jussi01> hehe
[17:56] <jussi01> LjL: good to hear he is ok :D
[18:04] <jussi01> Myrtti_: what happened to Myrtti?
[18:08] <Seeker`> DAMN YOU PEER!
[18:08] <jussi01> hehe
[18:59] <jussi01> I just removed badfish69<EMAIL_ADDRESS>from #u
[18:59] <jussi01> was a bot
[19:02] <tsimpson> moving ubottu over now
[19:08] <tsimpson> it's on it's way
[19:22] <jussi01> Myrtti_: I like your raspberries :D
[19:46] <jussi01> (on your blog) ;)
[22:03] <Flannel> Hi klaz168, how can we help you today?
[22:06] <klaz168> Flannel, hi
[22:07] <Flannel> klaz168: What can we do for you?
[22:08] <klaz168> Flannel, well I'm a member of Ubuntu Egypt Team, and the channel's founder does not access IRC anymore, been six months. so i was wondering if it's possible to get transferred to another user?
[22:09] <klaz168> also the LOCO admin isnt active anymore, not on mailing list or anything..
[22:13] <Myrtti> you seem to be helped at -irc which is the correct channel for these issues anyway
[23:38] <gouki> Can I ask for the presence of ububot on a loco channel?
[23:40] <gouki> The idea was to have a bot displaying the URL for Launchpad bugs when a bug # is said in the channel.
[23:44] <gnomefreak> isnt the default master bot still ubottu ?
[23:45] <gouki> Or that one, I don't know.
[23:45] <Seeker`> I thought ubottu wasn't being put in locos for loading reasons
[23:46] <gouki> We have locobot_1 there, but I believe is mainly for logging.
[23:46] <Seeker`> we have ubot4 in -uk
[23:46] <Seeker`> i think
[23:46] <gouki> The channel in questions is #ubuntu-pt
[23:47] <gnomefreak> mozilla team has ubottu and *log
[23:57] <gouki> Should I ask in another channel or just come back in a few hours?
[23:59] <Seeker`> #ubuntu-irc may be better
[23:59] <Seeker`> not sure