[09:23] <mshadle> i am trying to create an upstart script... and can't figure out why this one in paritcular doesnt work
[09:23] <saz> what does it do?
[09:24] <mshadle> the command is this:
[09:24] <mshadle>  /usr/local/bin/php-cgi --fpm --fpm-config /etc/php-fpm.conf
[09:24] <mshadle> that's it. it daemonizes itself by default
[09:24] <mshadle> if i run it on the command line it works like a charm. but inside of a basic upstart script with exec /usr/local/bin/php-cgi --fpm --fpm-config /etc/php-fpm.conf it doesnt work
[09:25] <mshadle> i tried adding & for kicks.. i tried fork, respawn, task
[09:26] <saz> tried it minus the 'exec'?
[09:27] <mshadle> doesn't seem to do anything
[09:28] <saz> have you got the output going to the console?
[09:28] <mshadle> no..
[09:28] <saz> if so, use xconsole to check for any messages
[09:28] <saz> console output <- add that line to your script
[09:30] <mshadle> im downstairs right now. i'll have to go up and look.
[09:30] <saz> if you've got an ssh session, you can just run xconsole
[09:33] <mshadle> here i'll let you examine this
[09:33] <mshadle> http://pastebin.com/z0B2uV7e
[09:40] <saz> where is your script/end-script ?
[09:41] <saz> er
[09:41] <saz> s/-//
[09:41] <saz> you shouldn't need to fork or the exec
[09:43] <mshadle> well, does i matter if it is daemonized or not ?
[09:44] <saz> I have no idea
[09:44] <saz> but I'd try putting script and end script around it
[09:44] <mshadle>  /etc/init/php-fpm.conf:12: Unknown stanza
[09:45] <saz> ?
[09:45] <mshadle> that's the line without exec prefixing it
[09:45] <mshadle> let's try the script
[09:45] <mshadle> no change :/
[09:46] <saz> http://pastebin.com/fsmKJNw0
[09:47] <saz> something like that
[09:47] <saz> I'm not a guru on this, I've only started playing with upstart yesterday
[09:48] <mshadle> yeah nothing seems to b e working
[09:49] <saz> I would try replacing your call to the php program with
[09:49] <saz> echo "hello world"
[09:49] <saz> and see if you see hello world in your xconsole
[09:49] <saz> and take it from there
[09:50] <mshadle> yeah i just did touch /tmp/php-fpm and nothing
[09:50] <mshadle> i just made one for nginx, no problem
[09:54] <saz> oh wait
[09:54] <saz> /etc/init/php-fpm.conf:12: Unknown stanza  <- you need to quote the whole thing
[09:55] <saz> http://pastebin.com/wSEMYiQ3
[09:55] <saz> try that
[09:55] <saz> or maybe that with exec in front of it
[09:55] <mshadle> nope.
[09:55] <mshadle> you do need exec
[09:55] <mshadle> i know that for sure
[09:56] <saz> is php-cgi a script?
[09:56] <saz> I had enormous amounts of trouble with tightvncserver, because it's a script
[09:56] <mshadle> not working.
[09:56] <mshadle> no php-cgi is a binary
[09:56] <mshadle> and it daemonizes itself
[09:57] <mshadle> there is a script too which could be used but it doesnt work. what worries me is touch /tmp/php-fpm isnt even working
[09:59] <mshadle> i see the issue. there is some sort of upstart registry or something that has that job blackballed
[09:59] <mshadle> i made a new random named service and it touched the file no problem
[09:59] <mshadle> so i bet i have had it working one way.. but it doesn't like my php-fpm service name
[10:00] <saz> ah
[10:01] <mshadle> hah. what do you know. i changed the name of the .conf file and now php-fpm2 works
[10:01] <mshadle> but php-fpm is 'stuck'
[10:01] <mshadle> i had the right idea the entire time :p
[10:02] <mshadle> problem is i dont know where the cache/db is
[10:05] <mshadle> we'll try a reboot. i'll be pissed if it gets stuck on that.
[10:09] <mshadle> awesome.
[20:59] <ink> I'm writing my first init script in upstart; is it sufficient for my script to say 'emits foo' to have that signal to be sent after it's up and running, or do I have send from within the daemon itself?
[21:00] <ink> (via some C code or initctl)
[21:21] <sadmac> ink: you must send it
[21:21] <ink> thanks
[21:21] <sadmac> ink: emits is just for documentation
[22:04] <ink> this script starts xorg:  http://pastebin.com/UfdU1kZ8
[22:04] <ink> but `initctl status gui-test` always says stop/waiting
[22:05] <ink> (never emits the signal?)
[22:09] <ink> or does post-start not fire until the emit...


[00:41] <rick_h__> howdy huwshimi
[00:42] <huwshimi> rick_h__: Hey
[00:44] <rick_h__> huwshimi: updated the board with the list of things I think we need for release
[00:44] <rick_h__> talked with Luca, they've tweaked some things and so we're not shooting for release this week, but for the first week post-london
[00:44] <huwshimi> rick_h__: Ah ok, that's a shame :)
[00:45] <rick_h__> huwshimi: so anything you can crank out from the todo side of the board is appreciated. We need to have the release by that week so when I go to leader sprint I can demo it
[00:45] <rick_h__> and Mark S won't hang me by my britches :)
[00:45] <huwshimi> rick_h__: Yep, no problems.
[00:46] <rick_h__> huwshimi: let me know if you hit any questions on any of the cards, and if you do, feel free to put it back and grab something more clear until I can update and word things better
[00:46] <huwshimi> np
[00:46] <rick_h__> party party
[00:48] <huwshimi> rick_h__: In my current branch I have something that has a data-bind="something", which works, but I want to test it, it appears to be bound to a model, but I don't have that model in my test, I'm just a bit confused about what I need to do to get a data-bind actually bound to anything at all
[00:49] <rick_h__> huwshimi: hmm, I'd push the branch up and send an email asking for test help. And I'll get you some from jeff or matt in the morning
[00:49] <rick_h__> I'm not sure myself without looking at it closely
[00:50] <huwshimi> rick_h__: Sure, I'll send an email. I'll tackle something else today then.
[10:46] <rick_h__> morning
[11:55] <jrwren> morning
[12:05] <bac> morning
[12:05] <bac> hi rick_h__, you around?
[12:05] <rick_h__> bac: yep, on the phone what's up?
[12:06] <bac> rick_h__: nothing important. ping me when ^otp
[12:06] <rick_h__> bac rgr
[12:06] <bac> er !otp
[12:48] <rick_h__> bac: I've got 12
[12:49] <bac> rick_h__: short.  i was just going to mention i inadvertantly requested this thursday and friday off.  but there's no reason i cannot work thursday so i'd like to cancel it.
[12:49] <bac> just wanted to give you a heads up before you got stuff from the hr site
[12:50] <rick_h__> bac: ok, will cancel thurs, /me goes to look
[12:50] <bac> rick_h__:  i can do it
[12:50] <bac> rick_h__: will cancel swap on thursday, vacation on friday, and make friday swap.
[12:51] <rick_h__> bac: rgr
[13:21]  * rogpeppe goes for lunch
[14:42] <rick_h__> hatch: huw hit an issue with testing and data binding in a branch he was working on last night.
[14:42] <rick_h__> hatch: if you get a sec, can you look at his email to the list about it and maybe help him get the tests started/going please?
[14:42] <hatch> yeah there are other tests with use the databinding
[14:42] <hatch> I'll have to dig one up
[14:43] <rick_h__> hatch: yep, ty much. With time constraints the more help he gets the better.
[14:46] <hatch> welp no wonder he had a hard time testing it
[14:46] <hatch> it's not hooked up....
[14:46] <hatch> but it works
[14:46] <hatch> oy vey
[14:46] <rick_h__> lol
[14:46] <rick_h__> yea, he mentioned it worked but couldn't figure out how to test it right
[14:50] <hatch> jujugui call in 10
[14:50] <rick_h__> candadian time :P
[14:50] <rick_h__> one min fast
[14:50] <rick_h__> or my laptop is a min slow :/
[14:56] <hatch> I don't think i've ever set my clock.....blame Apple
[14:57] <hatch> ok I know what the issue is with huw's branch I'll reply to his email with instructions
[14:57] <rick_h__> hatch: ty much
[15:00] <rick_h__> jujugui call in 1 go go go
[15:03] <jcsackett> rick_h__: trying to join--no google page will load for me.
[15:03] <jcsackett> be there asap..
[15:03] <rick_h__> Makyo: jcsackett ^
[15:03] <rick_h__> jcsackett: k
[15:11] <hatch> lazyPower thanks :) so now how do I update the charm?
[15:13] <hatch> They are working on the internets again it's so darn laggy
[15:14] <rick_h__> hatch: by now are you offering to just connect their wires for them?
[15:14] <hatch> rick_h__ it's getting to be close to that, I'm seriously doubting their ability to do anything at this point
[15:15] <rick_h__> hatch: /me pushes you good interweb lucks
[15:15] <hatch> haha thanks
[15:15] <hatch> jrwren lol gulp...js....ahh what an ecosystem we have
[15:16] <hatch> so we are teaching our niece how to read....apparently English is a disaster of a language, how did it become the international language of commerce...lol
[15:16] <hatch> "i before e except after c, or whenever the heck it doesn't feel like it"
[15:17] <jrwren> i blame windows.
[15:17] <jrwren> if windows would just ship a sensible make, this would not be an issue.
[15:17] <hatch> oh that's a _long_ O....no reason, it just is
[15:18] <hatch> windows....windows....hmm that's that operating system that people used 10 years ago right?
[15:38] <jrwren> hatch: I thought it was a desktop gaming platform or something.
[15:39] <bac> jujugui: comingsoon.jujucharms.com now points to our azure instance.  let me know if you see wonkiness.
[15:40] <hatch> jrwren lol
[15:47] <rick_h__> bac: awesome thanks
[15:47] <hatch> jcsackett hey which branches have you reviewed? or do you want me to just take em?
[15:47] <rick_h__> hazmat: you can shut'er down now thanks for running that for so long
[15:48] <hatch> it's a monumental day
[15:48] <hatch> should we light a candle for that instance?
[15:48] <hatch> jcsackett ok I'll take em
[15:50] <rick_h__> hatch: heh, /me plays taps
[15:50] <hatch> :-)
[15:50] <hatch> well I updated my laptop
[15:51] <hatch> there goes my bootloader again
[15:51] <hatch> I really wish it wouldn't do that
[15:58] <bac> hazmat: maybe don't pull the plug yet.  dns hasn't fully propogated yet.
[16:04] <hatch> yeah I'm getting some oddities there
[16:10] <hatch> rick_h__ a mv blocker bug https://bugs.launchpad.net/juju-gui/+bug/1341653
[16:10] <_mup_> Bug #1341653: Cannot drop an unplaced unit on a ghost container <juju-gui:New> <https://launchpad.net/bugs/1341653>
[16:13] <bac> jujugui: one of our 3 dns servers is not updating, so that change won't become reliable until it does.
[16:14] <rick_h__> bac: ok thanks for the heads up
[16:14] <rick_h__> hatch: looking
[16:15] <rick_h__> hatch: k, added to the board
[16:15] <hatch> thx
[16:19] <hatch> jujugui is there an 'easy' way to run charmworld locally? with this internet it's killing me to load the requests every time
[16:20] <jrwren> what is charmworld?
[16:20] <rick_h__> hatch: :/ juju deploy the bundle into a local lxc and wait hours for it to populate?
[16:20] <hatch> rick_h__ hmm, not so awesome :)
[16:21] <rick_h__> jrwren: http://launchpad.net/charmworld and http://manage.jujucharms.com/
[16:21] <rick_h__> hatch: yea, pretty much
[16:21] <hatch> ok well maybe the net will get better sooner rather than later :)
[16:24] <hazmat> bac, rick_h__ i'll hold off till later this week (wed/thursday)
[16:24] <hazmat> bac, rick_h__ and thanks!
[17:12] <jcsackett> hatch: it's seriously fun seeing the ghost icon appear in the charmbrowser while working today. :)
[17:13] <rick_h__> jcsackett: hatch :)
[17:13] <rick_h__> rock on
[17:14] <hatch> jcsackett haha nice - I guess this means I will now have to deploy my blog as a ghost blog....and figure out how to move my tumblr posts to it
[17:14] <jcsackett> hatch: same for me.
[17:14] <hatch> you're also on tumblr?
[17:14] <jcsackett> hatch: i actually use a static generator right now and syndicate to tumblr with ifttt.
[17:15] <jcsackett> but i had to migrate from tumblr to the static, and now i have to figure out how to migrate the static to ghost.
[17:15] <jcsackett> i think it's just a case of scripting something that takes the .md files and dumps 'em into ghost json.
[17:15] <hatch> ahh - I was hoping tumblr has an api so I can write a python script or something to port them over
[17:16] <jcsackett> hatch: since you've got a mac, tumblr has an export tool you can run to pull down all your stuff.
[17:16] <jcsackett> it's a desktop thing, pulls down a goofy formatted archive folder.
[17:16] <jcsackett> hatch: tumblr definitely has an API, but i don't know what level of data it gives you. it might be write-only, since they're keen on sucking things into tumblr, not so much broadcasting them out. :p
[17:17] <jcsackett> but there must be something, b/c there are (or were) some third party ios tumblr apps that could view posts etc.
[17:17] <hatch> ahh cool then
[17:17] <hatch> I'll have to look into it
[17:17] <hatch> I haven't done any research yet
[17:26] <hatch> jcsackett you did the review on my branch for the scale up service tokens one right?
[17:27] <jcsackett> hatch: i believe so--saw one UI oddity that i don't think was your branch that i asked you to throw a card/bug up for follow up, but otherwise it was :+1:
[17:27] <hatch> I'm trying to figure out the best place to put the util method for adding units
[17:27] <hatch> any preference? I was thinking views/utils.js?
[17:27] <jcsackett> the bit you can break out?
[17:28] <jcsackett> that loop?
[17:28] <hatch> yeah
[17:28] <hatch> you'd have to pass in ref to the env and db but I think that that would be acceptable
[17:29] <jcsackett> hatch: i don't know. view/utils.js seems overly generic for something that, while a utility, is pretty much only useful for machine stuff.
[17:29] <jcsackett> that said, i can't think of a better place.
[17:29] <hatch> well it needs to be accesible from the inspector scale up view and the machine scale up view
[17:29] <jcsackett> hatch: ah, right.
[17:29] <hatch> I was also thinking extension....
[17:29] <hatch> but an extension for one method is....overkill?
[17:29] <jcsackett> hatch: yeah, i don't love it, but i can't think of a better place.
[17:29] <jcsackett> hatch: agreed.
[17:30] <jcsackett> go for views/utils
[17:30] <hatch> sounds like a plan
[17:30] <hatch> +1
[17:44] <rogpeppe> g'night all
[17:45] <rick_h__> have a good evening rogpeppe
[17:47] <hatch> rick_h__ we just had an intermittent landing failure from the pyjuju test suite, it might be time to look at cutting that out if it proves to be a bigger issue
[17:48] <rick_h__> hatch: rgr, it's one of the cards I've got in the maint queue for post MV 1.0
[17:48] <rick_h__> hatch: if only to speed up tests and start to clean out some code.
[17:49] <hatch> yeah I've never seen a failure out of it until today
[18:00] <lazyPower> hatch: https://jujucharms.com/precise/ghost/ - whats this I see here?
[18:00] <hatch> haha yes thanks muchly!
[18:00] <hatch> :)
[18:00] <hatch> so now how do I update it when I do more work on it?
[18:01] <lazyPower> same process
[18:01] <lazyPower> create a MP, assign charmers as the reviewer, it'll show up in the rev queue
[18:01] <lazyPower> you need to point the MP at lp:~charmers/charms/precise/ghost/trunk
[18:01] <lazyPower> good question - i'll update my canned response to include the upstream target
[18:02] <hatch> ok cool - I can't wait until we can provide custom links for bugs and source and whatnot
[18:34] <Makyo> jujugui PR for destroyMachines in ECS/deployer bar: https://github.com/juju/juju-gui/pull/434
[18:42] <hatch> Makyo I'm just about to grab some lunch so I can do it when I get back if noone else has
[18:42] <Makyo> hatch, np, thanks
[18:51] <jcsackett> Makyo: i'm free now, i'll take a look.
[19:21] <jcsackett> Makyo: some questions (not blocking +1) on your PR, but unfortunately there was a QA issue too.
[19:30] <hatch> back
[19:49] <hatch> humble bundle is such a horrible service - it provides good games at a great price.....and I have no time to play them
[19:49] <hatch> lol
[20:08]  * rick_h__ runs to take boy to swim class
[20:12] <hatch> jujugui does anyone know why the constraints for the inspector scale-up vs the create machine constraints are different? Is this a bug?
[20:24] <hatch> that moment when you can't figure out what the heck is breaking so you put a debugger in which causes it to cache-bust and it works....
[20:32] <jcsackett> i hate that moment.
[20:33] <Makyo> I've gotten in the habit of just ctrl-shift-R whenever I have the debugger open to force reload.
[20:36] <hatch> well with the debugger open it's supposed to always reload
[20:36] <hatch> but doesn't seem to happen
[20:37] <hatch> maybe I'll also try the ctrl+shift+r technique though :)
[20:37]  * bac early dog walk.  bbiab.
[20:40] <hatch> heh this scale-up auto-place is pretty cool
[21:29] <hatch> rick_h__ not sure if you're back yet but this should prooooobably also be in the mv bug list https://bugs.launchpad.net/juju-gui/+bug/1341751
[21:29] <_mup_> Bug #1341751: constraints inputs don't match across the various create machine sections <juju-gui:New> <https://launchpad.net/bugs/1341751>
[21:43] <hatch> jcsackett you ran into an issue before where an event being fired from a viewlet wasn't bubbling to the browser.js what ended up being the issue?
[21:43] <jcsackett> hatch: i never solved it--we tabled the work as low priority.
[21:43] <hatch> oh...darn, I'm running into that right now too
[21:43] <hatch> switching from the manually place inspector to the machine view
[21:44] <jcsackett> hatch: there's something confusing in the viewlet creation stuff.
[21:44] <hatch> it was the overview viewlet that you were trying to fire an event from too wasn't it?
[21:44] <jcsackett> hatch: no, i was able to get the viewlet to fire a changeState (i *think*) for the unit details view.
[21:44] <jcsackett> hatch: it was the service config one.
[21:45] <jcsackett> it's target (when calling getTargets) was listed as the inspector, and empirically things that have the inspector as a target can successfully fire changeState...and yet.
[21:46] <hatch> yep that's the same issue I'm at
[21:46] <hatch> w t h
[21:46] <hatch> ok I'm going to bench this then
[21:46] <hatch> because there is clearly something wrong with it
[21:46] <hatch> people right now will have to click the machine button I guess :)
[21:47] <jcsackett> hatch: post mv release we *really* need to pick apart viewlets, slots, etc.
[21:51] <hatch> yeah - it's really not that complicated architecture but the slots thing was always tacked on the outside, even as far back as the start of viewlets
[21:58] <hatch> jcsackett I think the issue with these events is a yui bug, we should look into updating our version of YUI (we are only 7! versions back)
[21:58] <hatch> lol
[21:59] <rick_h__> hatch: looking
[22:09] <Makyo> Hail + line-of-sight internet
[22:12] <hatch> lol yeah? no more 700ms pings?
[22:12] <Makyo> Ping as fine, as long as there's not any ice in the way.
[22:20] <hatch> better get out there with the ice pick in the winter :)
[22:21] <hatch> at the lake when it rains to hard the sat tv goes out heh
[22:23] <Makyo> YEah, it's more like that.  The antenna is under the eaves, so it shouldn't be too much of a problem.
[22:26] <hatch> ahh nice - yeah our dish has to point almost horizontal to get the signal because it's so far north so the signal is weak as it is
[23:03] <huwshimi> Morning
[23:06] <hatch> morning huwshimi
[23:06] <huwshimi> hatch: Hey
[23:06] <hatch> I responded to your email, I hope it gets you in the right direction
[23:07] <hatch> I'm done hooking up the back-end, just writing tests for the scale-up ui so try to not change the markup too much :)
[23:14] <hatch> I got to run but I'll bbl if you run into issues setting up your tests
[23:14] <hatch> just remember that you don't necessarily need to test that databinding 'works' just that it's hooked up
[23:14] <hatch> there (should be) tests which show weather or not it's working heh
[23:14] <hatch> anywho bbl


[04:43] <mup> PR snapd#7496 opened: tests: move "centos-7" to unstable systems <Created by mvo5> <https://github.com/snapcore/snapd/pull/7496>
[05:06] <mborzecki> morning
[05:18] <mborzecki> mvo: hi, can you take a look at https://github.com/snapcore/snapd/pull/7475 ?
[05:18] <mup> PR #7475: sandbox/cgroup, usersession/userd: move cgroup related helper to a dedicated package <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7475>
[05:18] <mvo> mborzecki: sure
[05:18] <mvo> mborzecki: I pushed a PR to move centos-7 to unstable
[05:18] <mvo> mborzecki: if we do it we need to add a trello card too to re-enable it when we can
[05:18] <mborzecki> mvo: saw that and approved :) thank you!
[05:19] <mborzecki> mvo: we're not the only ones observing this problem: https://bugs.centos.org/view.php?id=16441#c35202
[05:19] <mvo> mborzecki: nice
[05:20] <mvo> mborzecki: if its between ystemd-219-67.el7_7.1 -> systemd-219-67.el7)  it should be easy to debug hopefully
[05:23] <mborzecki> mvo: well, they just import the latest source dump from rhel in a single commit https://git.centos.org/rpms/systemd/c/9ab0c50975feeee399ced5d356cc79b9c1a9ce69?branch=c7 :/
[05:25] <mvo> mborzecki: uh, ok
[05:25] <mvo> mborzecki: still, "just" 15ish patches, should be easy to bisect
[05:25] <mvo> mborzecki: for them, not for us :)
[05:26] <mborzecki> mhm
[05:27] <mborzecki> mvo: centos 8 should be coming out today :)
[06:07] <zyga> hey guys
[06:07] <zyga> small update, I'm going to take the swap day today
[06:07] <mborzecki> zyga: hey
[06:07] <zyga> lucy has a fever and I think I'm getting one too
[06:07] <mvo> hey zyga
[06:08] <mvo> zyga: uh, get well!
[06:08] <zyga> I'll talk to Gosia and get back to you soon
[06:11] <mvo> zyga: ok - quick Q did we get an update on the not-quite rebooting pi :/ ?
[06:12] <zyga> mvo: we only know fractions, it doesn't die all the time, the journalctl --list-boots showed it booting up several times a day (though we don't know if timestamps are true), I have a journal to go through and AFAIK it's still on older version of core18 and snapd
[06:13] <zyga> mvo: about fsck, there's some more information on https://forum.snapcraft.io/t/core18-shortcoming-missing-fsck-vfat-for-boot-fat-partition/13276
[06:13] <zyga> mvo: at this point I'd like to clone the entire pi (I have the same model available now)
[06:15] <zyga> rogpeppe: ^^^ could you consider cloning the SD card of your pi for analysis? If so we can craft a script that will DD the card out while briefly re-mounting / to ro
[06:15] <rogpeppe> zyga: sure, np
[06:15]  * mvo hugs rogpeppe
[06:16] <mvo> zyga, rogpeppe THANK YOU so much
[06:16] <zyga> mvo: I'll craft the script and share it with rogpeppe, testing it on my devices locally
[06:16] <zyga> mvo: depending on how I feel today that may be my "swap day"
[06:16] <rogpeppe> zyga: it might take a while to fetch it though, as it's behind a crappy net connection
[06:16] <zyga> rogpeppe: I'll make sure to include compression :)
[06:17] <rogpeppe> zyga: good plan. xz probably isn't worth it though, given the h/w :)
[06:17] <mvo> zyga: thanks, yeah, if you feel unwell, take time off :)
[06:52] <mup> PR snapd#7464 closed: snapstate: add missing tests for checkGadgetOrKernel <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7464>
[07:04] <mborzecki> mvo: i'm looking into why snap-run test sometimes works or gets stuck on arch, and it's really weird
[07:05] <mborzecki> mvo: /usr/lib/snapd/snap-exec test-snapd-tools.echo hello appears to be stuck
[07:05] <mborzecki> mvo:  can't connect strace/perf trace nor gdb, /proc/<pid>/status shows it's stuck in D state
[07:06] <mborzecki> mvo: afaik it's uninterruptible sleep on the kernel side
[07:07] <mvo> mborzecki: uh, so its a real issue? probably just manifests itself when we attach strace?
[07:08] <mborzecki> mvo: probably, wodnering if i can tigger kernel side task dump without bringing down the whole system
[07:08] <mvo> mborzecki: IDK, sry :/
[07:10] <mvo> mborzecki: different topic, there was  a "snap run --explain" mockup during the sprint. was this a gdoc and if so, do you have the link?
[07:10] <mborzecki> mvo: i think zyga added it in the sprint notes
[07:12] <mborzecki> mvo: https://paste.ubuntu.com/p/8nVzj8Sqfq/ kernel dump of blocked tasks, only strace and snap-exec, and have a bunch of those
[07:12] <mvo> mborzecki: right, what I see there is less detailed than what I remember seeing on the screen. *but* I was in some different meeting so I may be wrong
[07:13] <mborzecki> mvo: notice how snap exec with pid 245937 is stuck in do_execve.../load_elf_binary
[07:13] <mvo> mborzecki: interessting flush_old_exec seems to be a bit of a pattern
[07:16] <pstolowski> morning!
[07:21] <zyga> mvo: it was in the sprint notes
[07:21] <zyga> mvo: you probably remember the "EX:" prefix
[07:21] <zyga> mvo: it was later removed after review
[07:22] <zyga> mvo: it starts on page 19
[07:30] <mborzecki> pstolowski: hey
[07:31] <mborzecki> zyga: look at the kernel task dump i pasted above ^^
[07:31] <mborzecki> mvo: so i tried bind mounting /bin/true from the host over snap-exec in the core snap, and wasn't able to reproduuce this anymore, similarly no luch when i bind mounted true from the core snap
[07:33] <zyga> mborzecki: I'm out of sync, can you refresh my memory please
[07:34] <mborzecki> zyga: on arch, when running snap run --strace it'd sometimes get stuck, similarly snap run --trace-exec would not list snap-exec in theoutput
[07:34] <mborzecki> zyga: so i tried running the same command as we use in tests in a loop, and was able to see it getting stuck, apparently, in the process tree, snap-exec ends up in D state
[07:35] <zyga> D as in IOWAIT
[07:35] <mborzecki> yeah
[07:37] <mvo> zyga: aha, thanks, thats fine. I was wondering where the EX went to :)
[07:40] <zyga> mvo: it was removed during the review
[07:42] <mvo> zyga: thats fine, thanks for the explaination
[08:07] <mborzecki> https://lore.kernel.org/patchwork/patch/719314/
[08:07] <mborzecki> strace lockup when tracing exec in go
[08:13] <mborzecki> heh, and tracing that trivial Go program gets stuck
[08:14]  * pstolowski quick errand, bbiab
[08:16] <Chipaca> mborzecki: that's why the recommended strace has a bunch of exceptions
[08:16] <Chipaca> mborzecki: the "-e !select,pselect6,_newselect,clock_gettime,sigaltstack,gettid,gettimeofday,nanosleep" thing is not just laziness :-)
[08:19] <mborzecki> Chipaca: strace -f -e execve gets stuck too
[08:19] <Chipaca> poor strace
[08:27] <mup> PR snapd#7497 opened: tests: listing test, make accepted snapd/core versions consistent <Created by pedronis> <https://github.com/snapcore/snapd/pull/7497>
[08:30] <mvo> mborzecki: nice, it even has a kernel patch - except its from 2016 :/
[08:31] <mborzecki> mvo: yeah, i'll just skip the strace related parts of the test on arch, no need to break the whole spread run
[08:31] <mvo> mborzecki: did the patch got applied and we just happen to hit a new issue?
[08:31] <mborzecki> mvo: afaik, the patch was not applied
[08:32] <mborzecki> mvo: and don't really feel like debugging this any further is useful :/
[08:33] <mvo> mborzecki: yeah, thats fine. I wonder if we could point our kernel people to the diff
[08:34] <mvo> I mean, if its really fixing the problem might be worthwhile to upstream it
[08:34] <mvo> mborzecki: our strace is only working because we do a bunch of !excludes
[08:34] <mvo> mborzecki: but not high priority I guess, but given that arch is usually ahead a bit we might seen it soon on ubuntu too :/
[08:35] <mborzecki> mvo: unless it's magically patched, reading the lkml thread, there's some confusion about which change fixed or masked the problem, so the issue is probably more complex than it seems
[08:36] <mvo> mborzecki: ok, I did not read the full thread so yeah, lets ignore it for now :(
[08:38] <pedronis> mvo: (repeating in case, I got disconnected) well if it's in the end is a kernel problem and it hits ubuntu we would need to involve the kernel team
[08:40] <mborzecki> pedronis: eoan is on 5.3?
[08:40] <mup> PR snapd#7498 opened: tests/main/snap-run: disable strace test cases on Arch <Simple 😃> <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7498>
[08:40] <mvo> pedronis: yes
[08:42] <mborzecki> i'll do a quick run and check if it hapens on eoan too, if so i'll file a bug in PL
[08:42] <mborzecki> LP
[08:42] <mborzecki> in the meantime, 7498 should help with the failures
[08:49] <mup> PR snapd#7496 closed: tests: move "centos-7" to unstable systems <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7496>
[08:50] <mborzecki> pedronis: mvo: there's no going to be pre2.1 right? :D
[08:50] <mvo> mborzecki: unlikely - Samuele says NO :)
[08:50] <mborzecki> haha ok
[08:51] <mup> PR snapd#7475 closed: sandbox/cgroup, usersession/userd: move cgroup related helper to a dedicated package <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7475>
[08:55] <Chipaca> pedronis: your input would be appreciated on https://forum.snapcraft.io/t/feature-request-extend-length-of-version-string/13335?u=chipaca
[09:02] <pedronis> Chipaca: I put in my queue, there's no easy answer though
[09:18] <pedronis> mvo: still red travis ?
[09:18] <mborzecki> pedronis: try merging master, the pr moving centos to unstable has landed
[09:40] <Chipaca> woo, parliament woo
[09:40]  * Chipaca watching the news
[09:46] <Chipaca> I think I need a drink, that was intense
[09:46]  * Chipaca gets a glass of water
[09:49] <zyga> Chipaca: what happened?
[09:49]  * zyga checks the guardian
[09:50] <popey> Prorogation ruled unlawful, it never happened
[09:50] <Chipaca> zyga: 11 judges, unanimously, told the gov'mnt to stuff it
[09:50] <zyga> holly smokes
[09:51] <Chipaca> ikr
[09:51] <zyga> well, it's like adding anti-matter to a fire
[09:51] <zyga> it's helping to put it out, in a way
[09:55] <Chipaca> looks like a GE or a 2nd ref, with odds heavily on a GE
[09:57] <mborzecki> mvo: good news (?), strace gets stuck on eoan too
[09:58] <Chipaca> mborzecki: https://media.giphy.com/media/3o7abA4a0QCXtSxGN2/giphy.mp4
[09:58] <mborzecki> haha :P
[10:13] <mvo> mborzecki: oh no
[10:13] <mvo> mborzecki: or yes
[10:17] <mborzecki> mvo:  filed https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1845180
[10:17] <mup> Bug #1845180: strace deadlock when tracing a trivial Go program <linux (Ubuntu):New> <https://launchpad.net/bugs/1845180>
[10:23] <ogra> ppisati, here is one for you ... https://forum.snapcraft.io/t/watchdog-soft-lockup/13375
[10:23] <ogra> (has an lp bug at the end)
[10:23] <mborzecki> hmm https://media.ccc.de/v/ASG2019-145-distributing-freedesktop-sdk-applications-to-flatpak-snapd-and-docker
[10:24] <mborzecki> isn't that they guy who posted about freedesktop base snap in the forums?
[10:26] <Chipaca> sergiusens: is having the manifest the default in snapcraft now, or does it need a flag?
[10:26] <popey> yes
[10:30] <Chipaca> ogra: I took <thing> and did <three things that are all impossible to do with thing>, and now <event that has no causal connection to the thing>! fix it!
[10:31]  * Chipaca stops forum'ing
[10:38] <ogra> Chipaca, haha
[10:40] <pstolowski> Saviq: woah @multipass on mac :). also, seems to be running fine alongside vmware fusion
[11:17] <mup> PR pc-amd64-gadget#10 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
[11:17] <mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37, core-build#48, core-build#51
[11:19] <mup> PR pc-amd64-gadget#11 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
[11:19] <mup> PR # opened: core-build#11, core-build#22, core-build#26, core-build#37, core-build#48, core-build#51
[11:19] <mup> PR # closed: snapd#5822, snapd#6108, snapd#6174, snapd#6258, snapd#6436, snapd#6666, snapd#6708, snapd#7079, snapd#7092, snapd#7129, snapd#7146, snapd#7166, snapd#7168, snapd#7193, snapd#7197, snapd#7205, snapd#7222, snapd#7228, snapd#7233, snapd#7238, snapd#7256, snapd#7261, snapd#7266,
[11:19] <mup> snapd#7277, snapd#7286, snapd#7302, snapd#7320, snapd#7348, snapd#7355, snapd#7366, snapd#7367, snapd#7377, snapd#7402, snapd#7414, snapd#7416, snapd#7417, snapd#7421, snapd#7424, snapd#7430, snapd#7431, snapd#7434, snapd#7436, snapd#7437, snapd#7438, snapd#7441, snapd#7443, snapd#7445, snapd#7447,
[11:19] <mup> snapd#7454, snapd#7456, snapd#7462, snapd#7467, snapd#7468, snapd#7469, snapd#7470, snapd#7484, snapd#7486, snapd#7490, snapd#7495, snapd#7497, snapd#7498
[11:19] <mup> Issue # closed: core18#56, core18#86, core18#89, core18#117, core18#129, core18#137
[11:19] <mup> PR # closed: core18#43, core18#72, core18#90, core18#98, core18#126, core18#134
[11:20] <mup> PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
[11:20] <mup> PR # opened: snapd#5822, snapd#6108, snapd#6174, snapd#6258, snapd#6436, snapd#6666, snapd#6708, snapd#7079, snapd#7092, snapd#7129, snapd#7146, snapd#7166, snapd#7168, snapd#7193, snapd#7197, snapd#7205, snapd#7222, snapd#7228, snapd#7233, snapd#7238, snapd#7256, snapd#7261, snapd#7266,
[11:20] <mup> snapd#7277, snapd#7286, snapd#7302, snapd#7320, snapd#7348, snapd#7355, snapd#7366, snapd#7367, snapd#7377, snapd#7402, snapd#7414, snapd#7416, snapd#7417, snapd#7421, snapd#7424, snapd#7430, snapd#7431, snapd#7434, snapd#7436, snapd#7437, snapd#7438, snapd#7441, snapd#7443, snapd#7445, snapd#7447,
[11:20] <mup> snapd#7454, snapd#7456, snapd#7462, snapd#7467, snapd#7468, snapd#7469, snapd#7470, snapd#7484, snapd#7486, snapd#7490, snapd#7495, snapd#7497, snapd#7498
[11:20] <mup> Issue # opened: core18#56, core18#86, core18#89, core18#117, core18#129, core18#137
[11:20] <mup> PR # opened: core18#43, core18#72, core18#90, core18#98, core18#126, core18#134
[11:23] <mup> PR snapd#7416 closed: seed/seedwriter: start of Writer and internal policy16/tree16 <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7416>
[11:24] <mup> PR # closed: snapd#5822, snapd#6108, snapd#6174, snapd#6258, snapd#6436, snapd#6666, snapd#6708, snapd#7079, snapd#7092, snapd#7129, snapd#7146, snapd#7166, snapd#7168, snapd#7193, snapd#7197, snapd#7205, snapd#7222, snapd#7228, snapd#7233, snapd#7238, snapd#7256, snapd#7261, snapd#7266,
[11:24] <mup> snapd#7277, snapd#7286, snapd#7302, snapd#7320, snapd#7348, snapd#7355, snapd#7366, snapd#7367, snapd#7377, snapd#7402, snapd#7414, snapd#7417, snapd#7421, snapd#7424, snapd#7430, snapd#7431, snapd#7434, snapd#7436, snapd#7437, snapd#7438, snapd#7441, snapd#7443, snapd#7445, snapd#7447, snapd#7454,
[11:24] <mup> snapd#7456, snapd#7462, snapd#7467, snapd#7468, snapd#7469, snapd#7470, snapd#7484, snapd#7486, snapd#7490, snapd#7495, snapd#7497, snapd#7498
[11:24] <mup> Issue # closed: core18#56, core18#86, core18#89, core18#117, core18#129, core18#137
[11:24] <mup> PR # closed: core18#43, core18#72, core18#90, core18#98, core18#126, core18#134
[11:25] <mup> PR # closed: snapcraft#2229, snapcraft#2239, snapcraft#2413, snapcraft#2518, snapcraft#2544, snapcraft#2658, snapcraft#2672, snapcraft#2673, snapcraft#2677, snapcraft#2678, snapcraft#2696, snapcraft#2697, snapcraft#2699, snapcraft#2707, snapcraft#2709, snapcraft#2710, snapcraft#2727, snapcraft#2729
[11:25] <mup> PR # opened: snapd#5822, snapd#6108, snapd#6174, snapd#6258, snapd#6436, snapd#6666, snapd#6708, snapd#7079, snapd#7092, snapd#7129, snapd#7146, snapd#7166, snapd#7168, snapd#7193, snapd#7197, snapd#7205, snapd#7222, snapd#7228, snapd#7233, snapd#7238, snapd#7256, snapd#7261, snapd#7266,
[11:25] <mup> snapd#7277, snapd#7286, snapd#7302, snapd#7320, snapd#7348, snapd#7355, snapd#7366, snapd#7367, snapd#7377, snapd#7402, snapd#7414, snapd#7417, snapd#7421, snapd#7424, snapd#7430, snapd#7431, snapd#7434, snapd#7436, snapd#7437, snapd#7438, snapd#7441, snapd#7443, snapd#7445, snapd#7447, snapd#7454,
[11:25] <mup> snapd#7456, snapd#7462, snapd#7467, snapd#7468, snapd#7469, snapd#7470, snapd#7484, snapd#7486, snapd#7490, snapd#7495, snapd#7497, snapd#7498
[11:25] <mup> Issue # opened: core18#56, core18#86, core18#89, core18#117, core18#129, core18#137
[11:25] <mup> PR # opened: core18#43, core18#72, core18#90, core18#98, core18#126, core18#134
[11:26] <mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37, core-build#48, core-build#51
[11:27] <mup> PR pc-amd64-gadget#10 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
[11:27] <mup> PR pc-amd64-gadget#11 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
[11:27] <mup> PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
[11:27] <mup> PR # closed: snapd#5822, snapd#6108, snapd#6174, snapd#6258, snapd#6436, snapd#6666, snapd#6708, snapd#7079, snapd#7092, snapd#7129, snapd#7146, snapd#7166, snapd#7168, snapd#7193, snapd#7197, snapd#7205, snapd#7222, snapd#7228, snapd#7233, snapd#7238, snapd#7256, snapd#7261, snapd#7266,
[11:27] <mup> snapd#7277, snapd#7286, snapd#7302, snapd#7320, snapd#7348, snapd#7355, snapd#7366, snapd#7367, snapd#7377, snapd#7402, snapd#7414, snapd#7417, snapd#7421, snapd#7424, snapd#7430, snapd#7431, snapd#7434, snapd#7436, snapd#7437, snapd#7438, snapd#7441, snapd#7443, snapd#7445, snapd#7447, snapd#7454,
[11:27] <mup> snapd#7456, snapd#7462, snapd#7467, snapd#7468, snapd#7469, snapd#7470, snapd#7484, snapd#7486, snapd#7490, snapd#7495, snapd#7497, snapd#7498
[11:28] <mup> PR pc-amd64-gadget#10 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
[11:28] <mup> PR # opened: snapcraft#2229, snapcraft#2239, snapcraft#2413, snapcraft#2518, snapcraft#2544, snapcraft#2658, snapcraft#2672, snapcraft#2673, snapcraft#2677, snapcraft#2678, snapcraft#2696, snapcraft#2697, snapcraft#2699, snapcraft#2707, snapcraft#2709, snapcraft#2710, snapcraft#2727, snapcraft#2729
[11:28] <mup> PR # opened: core-build#11, core-build#22, core-build#26, core-build#37, core-build#48, core-build#51
[11:28] <mup> PR # opened: snapd#5822, snapd#6108, snapd#6174, snapd#6258, snapd#6436, snapd#6666, snapd#6708, snapd#7079, snapd#7092, snapd#7129, snapd#7146, snapd#7166, snapd#7168, snapd#7193, snapd#7197, snapd#7205, snapd#7222, snapd#7228, snapd#7233, snapd#7238, snapd#7256, snapd#7261, snapd#7266,
[11:28] <mup> snapd#7277, snapd#7286, snapd#7302, snapd#7320, snapd#7348, snapd#7355, snapd#7366, snapd#7367, snapd#7377, snapd#7402, snapd#7414, snapd#7417, snapd#7421, snapd#7424, snapd#7430, snapd#7431, snapd#7434, snapd#7436, snapd#7437, snapd#7438, snapd#7441, snapd#7443, snapd#7445, snapd#7447, snapd#7454,
[11:28] <mup> snapd#7456, snapd#7462, snapd#7467, snapd#7468, snapd#7469, snapd#7470, snapd#7484, snapd#7486, snapd#7490, snapd#7495, snapd#7497, snapd#7498
[11:29] <mup> PR pc-amd64-gadget#11 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
[11:29] <mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
[11:29] <mup> PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
[11:33] <ogra> mupping ...
[11:38] <Chipaca> mvo, pedronis, what was the conclusion WRT rebasing? is it now the Right Way?
[11:38] <pedronis> Chipaca: I don't think there was a conclusion
[11:38] <pedronis> tbh
[11:38] <mvo> Chipaca: I though we agreed to try the "merge-with-rebase" from GH?
[11:38] <mvo> pedronis: -^
[11:39] <mvo> i.e. the automatic on click option ?
[11:39] <Chipaca> so, no force-pushing, but merge-with-rebase
[11:39] <Chipaca> ?
[11:39] <Chipaca> sgtm fwiw
[11:39] <pedronis> do we know what happens when it doesn't work?
[11:39] <pedronis> I expect it will not always work
[11:41] <Chipaca> pedronis: I'd expect github to block it if it doesn't work
[11:41] <Chipaca> but I don't know why a merge would work and a rebase-then-merge wouldn't
[11:42] <pedronis> Chipaca: I'm just not sure what happens to the tweaks you need a merge to make the merge work along the way
[11:43] <pedronis> do they get turned into extra commits? do they make the thing fail again?
[11:43] <Chipaca> not sure i understood your question
[11:43] <Chipaca> seem to have too many merges in it
[11:43] <pedronis> Chipaca: usually you fix conflicts and that fix goes into the merge commit
[11:44] <pedronis> Chipaca: I mean from experience rebase don't always work locally, so not sure why they would work on merge
[11:44] <pedronis> I mean work without intervention
[11:45] <pedronis> I'm sure I will learn soon enough
[11:45] <Chipaca> pedronis: https://github.com/isaacs/github/issues/1143
[11:45] <Chipaca> fwiw
[11:46] <Chipaca> i'm going to have lunch and stick my head in a jar of git sand, like a git ostrich of some sort
[11:48] <pedronis> Chipaca: mvo: anyway my point is that we'll see but when it will not work we will decide what to do
[11:51] <pedronis> mvo: #7434 should be ready for review
[11:51] <mup> PR #7434: seed/seedwriter:  implement WriteMeta and tree16 corresponding code <Created by pedronis> <https://github.com/snapcore/snapd/pull/7434>
[11:54] <pedronis> mvo: also notice that "rebase and merge" says not enabled for this repository
[12:05] <mup> PR snapd#7499 opened: many: move AppArmor probing code under sandbox/apparmor <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7499>
[12:05] <mborzecki> zyga: ^^ something for you
[12:06] <zyga> thx
[12:06] <mborzecki> zyga: release/selinux*.go are mostly stubs now since we have the sandbox/selinux package, so they are next in line to be dropped
[12:11] <zyga> reviewed
[12:11] <ijohnson> morning folks
[12:12] <ijohnson> pedronis, Chipaca (and others) where should I put my unit tests for SetTaskSnapSetup? the function is defined in handlers.go, but it's not clear which handlers_*_test.go I should put my tests in
[12:13] <ijohnson> I could create a new "generic" handlers_test.go for this function which isn't specific to any kind of handler
[12:13] <ijohnson> this is my update to #7430 btw
[12:13] <mup> PR #7430: overlord/snapstate: set snap-setup-task for first task in change <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7430>
[12:14] <pedronis> ijohnson: that seems ok
[12:14] <ijohnson> pedronis: handlers_test.go seems okay?
[12:15] <pedronis> yes
[12:15] <ijohnson> ack, thanks
[12:25] <pedronis> mvo: so I looked a bit, I'm not sure how switching to rebase will help, it will make the commits contiguous but not anchored, we would need to work hard on the quality of the messages of our single commits for it to make sense
[12:25] <pedronis> or allow rebases on PRs
[12:26] <ijohnson> ok, #7430 is ready for re-review Chipaca and pedronis if y'all could review that would be great
[12:26] <mup> PR #7430: overlord/snapstate: set snap-setup-task for first task in change <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7430>
[12:26] <ijohnson> pedronis, what do you mean the commits wouldn't be anchored? do you mean you can't find the PR a commit was merged in?
[12:27] <pedronis> ijohnson: where would a overall description fit in that case?
[12:27] <pedronis> I'm not even sure how to make a changelog in that mode (maybe I'm missing something)
[12:27] <ijohnson> ah you mean rebase when you merge to master
[12:28] <ijohnson> yes agreed there's nowhere to describe the overall "here's what all these commits did" when you rebase instead of doing a merge commit I suppose
[12:29] <pedronis> yea, so I don't see how it can fit our current style of PRs
[12:29] <pedronis> there's probably something we could do to our PRs
[12:29] <pedronis> to make it fit
[12:29] <pedronis> but I think it would involve allowing some rebase in them
[12:29] <Chipaca> i fear for the rebase approach we'd have to move to rebasing everywhere, to keep things tidy
[12:29] <Chipaca> or do the squash thing
[12:30] <pedronis> Chipaca: I still think that either squash or merge would fit our approach better
[12:30] <pedronis> but still seems like we would need a bot to do either
[12:30] <pedronis> because we are not very good at driving either
[12:30] <pedronis> on average
[12:31] <pedronis> anyway I don't think we have a conclusion here
[12:33] <ijohnson> I would be +1 to squashing and/or having a bot do the squash and/or regular merge to keep things consistent
[12:35] <ijohnson> there may already be github bot plugins to do this, the multipass team uses https://github.com/apps/bors
[12:37] <Chipaca> in view of recent developments, I'm wary of saying we give a bot commit
[12:37] <Chipaca> :)
[12:37] <mup> PR snapd#7497 closed: tests: listing test, make accepted snapd/core versions consistent <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7497>
[12:39] <ijohnson> fair :-)
[12:51] <mvo> pedronis: just read backlog and indeed, that seems like we have no solution yet :/
[12:51] <mvo> Chipaca: yeah, I don't like the bot idea
[12:58] <mborzecki> store throwing 503?
[13:00] <Chipaca> mborzecki: pr'aps; line is stopped over there
[13:36] <ijohnson> Chipaca: cool if I make a couple suggestions to your welcome.md gdoc thing?
[13:36] <ijohnson> (not edits, just suggestions)
[13:36] <ijohnson> I can also wait til you're done if you're still working on it
[13:37] <Chipaca> ijohnson: go for it
[13:37] <ijohnson> ack
[13:41] <Chipaca> mvo: in the bug triage policy, could you make the links say what they're to? (you can have the link text be different than the link target)
[13:42] <Chipaca> mvo: click the link, then the pencil, and you get to change things
[13:42] <Chipaca> mvo: or highlight text, ctrl+k → set a target
[13:48] <Chipaca> mvo: fwiw i did it for the last link which was easier to guess at :)
[13:54] <mvo> Chipaca: updated
[15:27] <ijohnson> anyone see a kill-timeout from a spread reboot request before like this ? https://pastebin.ubuntu.com/p/sGDkb43zrx/
[15:32] <mup> PR snapd#7498 closed: tests/main/snap-run: disable strace test cases on Arch <Simple 😃> <Test Robustness> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7498>
[15:33]  * cachio lunch
[15:46] <mup> PR snapd#7500 opened: api,timings: report duration via Doing column for ensure/startup <Created by stolowski> <https://github.com/snapcore/snapd/pull/7500>
[15:47] <pstolowski> pedronis: ^ was actually simple, but i got slightly confused initially
[15:57] <pedronis> pstolowski: +1 with small comment
[15:59] <pstolowski> pedronis: for the auto-connect & mark-seeded order issue, it's because we don't sort tasks in snap debug timings, it's whatever order change.Tasks() reported. will fix
[15:59] <pstolowski> pedronis: ty
[16:05] <Chipaca> huh
[16:05] <Chipaca> https://travis-ci.org/snapcore/snapd/jobs/589008368#L6315 ← huh
[16:06] <ogra> https://www.youtube.com/watch?v=j08nLrO_T84
[16:10] <Chipaca> in what case would snap-run --trace-exec print info about snap-exec and not snap-confine?
[16:18] <zyga> Chipaca: IIRC there is that raw thing
[16:18] <zyga> For strace
[16:18] <Chipaca> zyga: ?
[16:18] <zyga> But perhaps I misremember or misunderstand
[16:18] <Chipaca> zyga: https://api.travis-ci.org/v3/job/589008368/log.txt
[16:18] <Chipaca> zyga: look for 'error executing'
[16:19] <Chipaca> zyga: it's looking at the output of 'snap run --trace-exec'
[16:19] <zyga> snap run —strace=raw
[16:19] <zyga> Mmmmm
[16:19] <Chipaca> and it's a wee urd
[16:19] <zyga> I didn’t remember that one
[16:20] <zyga> I won’t be able to look from the phone now. I’ll make some tea and open the laptop again but this will take some time
[16:20] <zyga> Tomorrow ish
[16:22] <pedronis> pstolowski: ah, so Tasks is in creation order, I suppose here we want start times order?
[16:22] <pstolowski> pedronis: yes. fwtw 'snap changes' orders them by spawn time, perhaps we should be consistent with that
[16:23] <pstolowski> so yeah
[16:23] <pedronis> pstolowski: spawn time is not start time
[16:23] <pedronis> to be clear
[16:23] <pedronis> indeed snap changes tends also to be confusing from this POV
[16:23] <pstolowski> ah ok
[16:24] <pedronis> pstolowski: basically with spawn times all dynamically created tasks ends up after the static ones
[16:24] <pedronis> because spawn time is when NewTask happens
[16:24] <pstolowski> pedronis: indeed
[16:24] <pedronis> but in timings we have actualy start times, no?
[16:24] <Chipaca> zyga: no worries, the log isn't going away (i think?)
[16:26] <pedronis> pstolowski: we might need to think a bit though because sorting by start time is not useful for things that are parallel (usually different lanes)
[16:35] <pstolowski> pedronis: snap debug timings hits v2/changes/<id>, i think we just need to sort those on the client side
[16:42] <pedronis> pstolowski: we don't return lanes anywhere atm
[16:42] <pedronis> (it's kind of an internal detail)
[16:43] <pedronis> we don't return start time (vs spawn time) anywhere either atm
[16:45] <Chipaca> pedronis: wrt lanes we might want to start returning them
[16:45] <Chipaca> emphasis on might
[16:46] <Chipaca> pedronis: it's unclear whether we can build a good multi-progress bar without them, and we want to do that
[16:46] <pedronis> Chipaca: mmh, I see
[16:46] <Chipaca> pedronis: (because when a snap pulls in another snap, currently the UX sucks)
[16:46] <pedronis> we need a bit to think that through
[16:47] <Chipaca> explicitly installing multiple snaps also sucks, but less :)
[16:47] <pedronis> anyway here we might just return something extra in the debug endpoints
[16:47] <pedronis> for pstolowski stuff
[16:47] <Chipaca> k k
[16:48] <Chipaca> it's not like we have a timeline for the other thing :)
[16:48] <pedronis> pstolowski: so my thinking was to sort by (min(lanes), start-time, task id), except lane 0 might need to be treated specially
[16:50] <pstolowski> pedronis: sounds good. i need to digest this and continue tomorrow morning
[16:51] <pedronis> np, need/want to step away from keyboard as well
[17:17]  * Chipaca EODs
[18:12] <mup> PR snapd#7501 opened: interfaces/kubernetes-support: allow use of /run/flannel <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7501>
[18:14] <mup> PR snapd#7502 opened: interfaces/kubernetes-support: allow use of /run/flannel - 2.42 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7502>
[18:21] <jdstrand> degville: hey, I'd like to document system-usernames. I was thinking inserting it in some strategic location in the forum and linking out to a separate topic. I thought the name of the linked to topic would be 'system-usernames'. thoughts on this name and also where to link from?
[18:29] <degville> jdstrand: I think to start with, the top-level system-username doc might be best linked to from one of the snapcraft.yaml pages (https://snapcraft.io/docs/snapcraft-format). But it also sounds like it may become important enough to have it's own top-level page - maybe mirroring something like your original `Multiple users' post under the docs category. But we can obviously change all this easily. Otherwise, I
[18:29] <degville> think the name is good - thanks for doing this!
[18:32] <jdstrand> degville: I'll create https://forum.snapcraft.io/s/system-usernames in the forum under the 'doc' category, then come up with a blurb to insert into a snapcraft.yaml page and circle back to you. sound ok?
[18:45] <degville> jdstrand: perfect, thank you!
[19:05]  * cachio afk
[19:56] <om26er> roadmr Hi! Can you take a look at https://forum.snapcraft.io/t/auto-connection-request-for-deskconnd/13364 ? I am the maintainer of both snaps albeit from two different orgs
[19:56] <roadmr> O_o
[19:57] <roadmr> om26er: em suuuure but cross-publisher auto-connects are tricky :/
[19:57] <om26er> ^ that applies to https://forum.snapcraft.io/t/auto-connection-request-for-piconn/13368 and https://forum.snapcraft.io/t/auto-connection-request-for-deskconn/13367 as well :-)
[19:58] <om26er> roadmr tricket as in "conflict of interest" ?
[19:58] <om26er> *tricky
[19:58] <roadmr> om26er: no, as in it needs somewhat complex assertion wrangling
[19:58] <roadmr> om26er: if they come from the same publisher, it's easier
[19:59] <roadmr> om26er: interest-wise, as long as both publishers are OK with it (and you're both in this case) it should be OK
[19:59] <om26er> hmm the provider comes from a snap that I publish for my employer and the peer snaps are my personal projects
[20:00] <om26er> roadmr need your eyes on the two other similar requests as well ^
[20:01] <roadmr> om26er: sure, I'll have a look in a bit - but I can't really action them unilaterally, need eyes from other reviewers
[20:01] <roadmr> but at least it'll get the ball rolling :) thanks for your patience
[20:03] <om26er> roadmr indeed, thanks for looking into this, I hope Jamie will get around to reviewing that soon as well ;-)
[20:04] <roadmr> indeed
[20:29] <mup> PR snapd#7266 closed:  recovery: update run mode variable name <Created by cmatsuoka> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7266>
[21:06] <mup> PR snapd#7503 opened: tests: restart the journald service while preparing the test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7503>
[21:07]  * cachio EOD
[21:42]  * ijohnson relocates to coffee shop
[22:05] <Chipaca> mwhudson: out of curiosity, how hard would it be to snap older go versions? https://www.reddit.com/r/golang/comments/d8rrd6/install_really_old_golang_versions/
[22:54] <mwhudson> where did he go


[00:39] <TheMuso> abogani: Please make sure you preserve the changelog that is present in the linux-lowlatency package in the archive. You can find what I've done in git://kernel.ubuntu.com/themuso/ubuntu-precise-lowlatency.git
[01:05] <len-live> todays ISO says beta. I don't see other changes.
[01:47] <scott-upstairs> knome, ping
[01:48]  * scott-upstairs is hoping, but not expecting, him to be awake
[02:01] <scott-upstairs> anyone know how to make the damn background in inkscape be transparent?
[02:18] <len-live> I normally use gimp...
[02:19] <len-live> scott-upstairs, I opened the icon.png with gimp. There is a fuzzy select tool.
[02:19] <scott-upstairs> i got it
[02:19] <len-live> select the background
[02:20] <scott-upstairs> i did the background correct in inkscape
[02:20] <len-live> Great, I don't know that program at all
[02:20] <scott-upstairs> but the preview wasn't showing any linear gradients (which made me think it inkscape wasn't working)
[02:20] <scott-upstairs> AND i did the alpha over/composite wrong
[02:20] <scott-upstairs> it's all good
[02:20] <scott-upstairs> hopefully release my first netcast tonight :)
[02:21] <scott-upstairs> well for a select audience for feedback on production values
[02:21] <len-live> Gimp, shows checker for clear.
[04:12] <len-live> ScottL, the proper way to fix the plymouth text theme is to create a new one and add it to the ubuntustudio-look package
[04:13] <len-live> I have the text and colours where I want them.... I think
[04:14] <len-live> The text is as close to the US logo blue as I could get and the background is a slightly bluish dark charcoal.
[04:15] <len-live> The "progress" dots alternate from text colour to red.
[04:17] <len-live> Next I need to figure out how to do a diff to send to the bug...
[06:35] <abogani> TheMuso: Which changelog are you talking about? The debian.lowlatency/changelog file or the git's log?
[08:05] <knome> ScottL, if you are still uncertain; file -> document properties -> tab page -> "background"
[10:01] <ttoine> hi
[10:03] <ttoine> ScottL, knome what about having a Twitter account for Ubuntu Studio ? I mean that if the new website is based on Wordpress, it is very simple to sync with Twitter. So it would be good way to communicate more with the community, create some buzz, etc...
[10:05] <knome> ttoine, xubuntu has a twitter feed, and while it's not even integrated with WP, i think it's a good thing
[10:06] <ttoine> knome, there is to possibilities : have a separate twitter feed, and display it on the WP website
[10:06] <knome> ttoine, i know
[10:06] <ttoine> knome, or the other way, send all WP news to the Twitter feed
[10:06] <knome> well
[10:06] <knome> https://twitter.com/#!/XubuntuLinux
[10:06] <knome> this is what we've been doing
[10:07] <knome> (look for a bit older items)
[10:10] <ttoine> knome, you have a separate twitter feed, this is not sync with the website
[10:10] <knome> ttoine, as i said, "while it's not even integrated with WP"
[10:10] <ttoine> ok
[10:10] <knome> some attention please ;)
[10:11] <knome> we are possibly doing that later
[10:11] <knome> but it's not the #1 thing in our list right now
[10:11] <ttoine> maybe it would be great to be on social network
[10:11] <ttoine> of course, it is not #1
[10:15] <ttoine> knome, do you know if there is anything I can do today ??
[10:15] <knome> no, not really, i'm working on xubuntu content stuff and going to be afk soon
[10:16] <ttoine> afk ??
[10:17] <knome> away from keyboard
[12:49] <ttoine> ScottL, the french translationof the Slide Show is validated. It will be available with next update of the package.
[14:40] <scott-work> astraljava: did you experience any troubles with the ISO testing you recently completed for amd64?
[14:41] <astraljava> scott-work: It booted into a fine installed session, but I didn't have time to check all bits and pieces. At least there was an update-notifier icon in the top panel, so it could access the internet properly.
[14:41] <scott-work> astraljava: no problems with the kernel?  (i realize you didn't get under the hood)
[14:42] <scott-work> kate stewart is asking about releasing the beta 2 image and i want to make sure we have a modicum of comfortability about them :P
[14:42] <astraljava> scott-work: Did she give any deadlines?
[14:42] <astraljava> scott-work: I'd need to check the Xubuntu sessions as well, so I could run with them both for a bit, if there's still time.
[14:43] <scott-work> she didn't and i didn't ask yet
[14:43] <scott-work> i don't know if we even updated the kernel or not at this point
[14:44] <scott-work> right, i'll be honest about it and see what she says
[14:44] <astraljava> scott-work: Yeah, I can run it for a bit still, I suppose the deadlines used to be around 2100 UTC, but am not sure.
[14:48] <scott-work> astraljava: would you be able to run a minimal test on the kernel (just gross, top-level, sanity check) within a few hours?
[14:48] <astraljava> scott-work: I would, for sure.
[14:49] <astraljava> scott-work: I can even install it on real hw meanwhile.
[14:49] <scott-work> thank you, if we can get a single good test on the kernel, then i would think the rest can be taken as good
[14:49] <astraljava> Yep.
[15:41] <astraljava> knome: There are scrollbars in the slideshow of amd64 being installed on real hw.
[16:22] <scott-work_> here's my video i uploaded:  http://www.youtube.com/watch?v=BCO1Ebobdz4
[16:22] <scott-work_> please don't share outside this channel at this point
[16:23] <scott-work_> but i would like feedback
[16:43] <astraljava> len: ailo: scott-work_: Gimme a quick run-down on how to test for xruns best on a clean install?
[16:45] <astraljava> I just installed the proprietary nvidia drivers, and will make glxgears running while the tests are run for audio performance.
[16:51] <astraljava> Erhm... why is there even a mention of KXStudio on our Preparation page of help.u.c?
[16:52] <astraljava> Surely that's not correctly preparing for a Ubuntu Studio installation, to enable that PPA?
[16:52] <astraljava> falktx: This is in no way criticism towards your work.
[16:52] <scott-work_> astraljava: i think ttoine might have added that, he was touching that page
[16:53] <astraljava> We may have to talk about the proper documentation for the project, and what belongs to it, and what's in the more general multimedia section.
[16:53] <falktx> astraljava: no prob
[16:56] <astraljava> gah, we're pretty damn huge again. 2.0GB even for i386 image.
[16:58] <scott-work_> astraljava:  i think we also need to discuss where we _should_ have documentation
[16:59] <scott-work_> there are reasons both pro and con for the help.u.c. website and ubuntustudio.org website
[16:59] <astraljava> scott-work_: You're right there.
[16:59] <astraljava> falktx: Any thoughts on how easiest to test for xruns on a clean install?
[17:02] <falktx> there was an app to test latency
[17:02] <falktx> not sure how to test xruns...
[17:02] <astraljava> falktx: Latency would work, too.
[17:03] <astraljava> I'm just wanting to have a quick glance over the performance of the kernel.
[17:03] <falktx> I don't remember the app name, but it tested the time it took for a sound to get from speakers to mic
[17:03] <falktx> (ie, connect both, run app)
[17:05] <astraljava> Right, ok.
[18:09] <scott-work_> astraljava: my thought was that any testing would quickly show any serious errors
[18:09] <scott-work_> astraljava: i.e. just do some recording or such and if the xruns are large by orders of magnitude then we have a problem
[18:09] <scott-work_> astraljava: otherwise it's probably okay
[18:17] <astraljava> scott-work_: I'm running an rt-tests from someone's kernel git tree.
[18:17] <astraljava> Seems to work fine.
[18:17] <astraljava> But I can't seem to build a test box for the i386 testing.
[18:20] <scott-work_> astraljava: i was more worried about the configuration of the kernel for when it was built mainly
[18:20] <scott-work_> astraljava: so if it "seems" to run fine on one architecture i would think we would be okay
[18:22] <astraljava> scott-work_: But the kernels are different for each arch, that was the point for testing both.
[18:23] <scott-work_> oh yeah, the pae thing
[18:23] <scott-work_> i was just worried mainly about the config files
[19:11] <astraljava> knome: Correction, scrollbars in the slideshow of an i386 install as well, for real hw I mean.
[19:13] <TheMuso> abogani: the changelog that resides in debian.lowlatency.
[19:24] <knome> astraljava, meh. i still haven't seen them in the xubuntu slideshow. maybe we should just cut the images for studio
[19:25] <len> astraljava scott-work my xrun testing is mostly running sound in and out through effects with the lowest lat. that my hardware will handle.
[19:29] <len> On the desktop I have used -p 64 (I may be able to do less) and the netbook jack won't even start any lower than -p 128. But once they are running there are no xruns on either.... except on the netbook the headphone jack is detected and speaker turned on/off so plugging unplugging the headphones produces 1 xrun. One or both of my systems seem to get an xrun or two when the monitor powers off after screen blank. The quick fix is to change power manage
[19:29] <len> r settings.
[19:30] <len> Both machines are i386
[19:31] <len> The reality is, I don't know the system well enough to make sure I have both of them set up optimally for sound. So my tests are mostly "out of the box" tests.
[19:32] <len> scott-work_ has a tail today...  ^^^
[19:34] <astraljava> len: Thanks! Yeah, that's too time-consuming to set up for this occasion. I found a kernel test suite that I am running now. It'll do for now, until I get more experience in using the tools I help setting up. :)
[19:34] <astraljava> knome: Yeah, I mean, it's such a chore to actually _try_ the installer yourself, right? *snicker*
[19:36] <knome> astraljava, well no, i'm not touching the filthy stuff you're producing
[19:36] <knome> >:)
[19:41] <astraljava> I will soon rub that filthy stuff all over your hard drives if you won't learn some basic manners. :D
[19:41] <knome> i'm sure.
[19:41]  * astraljava is such a convincer
[19:44] <knome> i was almost to throw you a !coc, until i realised that wasn't a word that started with the exact same letters
[19:46] <astraljava> Umm... consumer? Container? What?!
[19:46] <knome> does those start with coc?
[19:46] <knome> some attention please
[19:47] <astraljava> Hehehe.
[19:47] <astraljava> Gotcha.
[19:47] <knome> gah. this minesweeper is impossible
[19:48] <knome> i have had to make two guesses already, and yet another is coming up
[19:48] <knome> oh, there it went
[19:48] <astraljava> Record?
[19:49] <knome> nah. stepped on a bomb
[19:49] <astraljava> damn
[19:52] <knome> besides, i just installed gnomine on this machine. any "passed" would be a record :)
[19:53] <astraljava> Yeah, assuming you _could_ actually pass any... *grin*
[19:53] <knome> hah
[19:53] <knome> well, the large one is actually quite hard.
[19:54] <astraljava> Granted.
[20:09] <astraljava> Thanks guys for your excellent work on the kernel! I'm still not an expert by far when it comes to kernel issues, but as far as I'm reading these test results, this kernel RAWKS!
[20:10] <astraljava> Both on i386 and amd64.
[20:11] <astraljava> I gave both images green lights on -release. We shouldn't be expecting any problems with either of them.
[20:13] <len> Yup, the only issue really is qjackctl. anything else is looks.
[20:30] <astraljava> scott-work_: You should have read in here first. :D
[20:44] <knome> yummy, good rum
[20:46] <astraljava> IHATEYOUIHATEYOUIHATEYOU!1one
[20:46] <knome> meh. i'll offer you some when you get back here again
[20:48] <astraljava> I'll see to it. :D
[21:12] <astraljava> scott-work_: Did you prepare for release notes?
[21:13] <knome> "release notes? what are those?"
[21:13] <knome> :]
[21:23] <scott-work_> astraljava: i did the technical overview notes already, skaet sends out an email about three days before the release
[21:24] <astraljava> scott-work_: Excellent, thanks!
[21:24] <scott-work_> they did an abridged version in the release email
[21:25] <scott-work_> astraljava: https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview/Beta2#Ubuntu_Studio
[21:25] <scott-work_> astraljava: https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview/Beta2#Ubuntu_Studio-1
[21:26] <scott-work_> the first is the "we did this" section and the second is the "we didn't fix these" section
[21:26] <astraljava> scott-work_: Ahh... so it is, I failed in reading the whole email Kate sent out. My apologies. :)
[21:27] <astraljava> I see a new kernel version accepted into the archives. Heads up! :)
[21:27] <scott-work_> no problem, friend :)  but i am kinda disappointed kate's email didn't include a link to the entire overview and that our section was paraphrased
[21:27] <scott-work_> oooooh, new kernel
[21:27] <astraljava> scott-work_: But not lowlatency yet. :)
[21:29] <astraljava> Thanks everyone who helped testing! You guys|gals RAWK!
[21:29] <scott-work_> indeed
[21:29] <scott-work_> astraljava: did you see my video?  http://www.youtube.com/watch?v=BCO1Ebobdz4
[21:29] <scott-work_> i'm a dork in it (as is real life)
[21:29] <astraljava> Haven't really had a chance to watch it, yet. Will do so in a few.
[21:40] <astraljava> ScottL: Way cool. :)
[21:46] <astraljava> Gotta love kids. :)
[23:29] <ScottL> thanks astraljava  :)
[23:42] <astraljava> ...aaaaaand we have lowlatency updated as well. Thanks, Luke! :)
[23:56] <ScottL> and alessio too


[12:28] <Saviq> hey, trying to install gnome-keyring:i386, fails due to libgcr-3-1:i386 requiring libgcr-3-common:i386, which is only available in "all" arch
[18:08] <Shred00> anyone know of a ppa that tracks the latest nouveau driver for the oneiric kernel?
[18:09] <Shred00> the nouveau that's in oneiric's kernel seems pretty buggy around suspend/resume
[18:11] <jbicha> Shred00: try asking in #ubuntu
[18:12] <Shred00> jbicha: will do.  just thought it was kind of "destkop" oriented so folks here might know.
[20:17] <chrisccoulson> who broke alt+tab in unity?? :(
[21:29] <dobey> chrisccoulson: you guys keep forcing bad ui on us kids!