[00:56] <sincere_fox> Hello
[00:58] <sincere_fox> I just installed an electron app via snap and I get this error https://pastebin.com/63MfH8NH
[05:39] <mborzecki> morning
[07:04] <mborzecki> Chipaca: mvo: morning guys
[07:11] <pstolowski> morning
[07:12] <mborzecki> pstolowski: hey
[07:14] <mvo> hey pstolowski and mborzecki
[07:16] <mborzecki> have you seen https://forum.snapcraft.io/t/new-base-snap-nix-base/11787 ?
[07:17] <mvo> yeah, its very cool
[07:18] <mborzecki> on the same note, wodner if any help is needed here: https://forum.snapcraft.io/t/base-runtime-freedesktop-sdk-runtime-19-08/11153/
[07:18] <mborzecki> would that enable a flatpak to be repacked as snap and vice versa?
[07:19] <mvo> mborzecki: I think so
[07:20] <mvo> mborzecki: or at least flat->snap it seems, not sure about the reverse but having a common base seems to be sensible
[07:21] <Chipaca> mborzecki: morning
[07:21] <mvo> pstolowski: mup is still down :( I pushed a tiny PR to not error if "current" is missing in "patch"
[07:21] <mvo> pstolowski: please have a look, maybe its too naive
[07:21] <mvo> hey Chipaca, gooood morning :)
[07:22] <Chipaca> :)
[07:23] <mborzecki> anyone up for some mkfs magic? https://github.com/snapcore/snapd/pull/6997
[07:23] <mborzecki> or i shoudl say mkfs/mtools
[07:28] <pstolowski> mvo: thanks. i've been thinking about what to do about that.. looking
[07:28] <mvo> pstolowski: again, maybe too naive but I think we don't want to fail
[07:32] <mvo> mborzecki: I like your idea about the symlink /snap to avoid the full cost of switching in the majaro case
[07:33] <mborzecki> mvo: i'm bit afraid this would break when poeple grab snapd from AUR
[07:33] <mborzecki> mvo: which they have done in the past :/
[07:33] <mvo> yeah
[07:34] <pstolowski> mvo: okay, i think it's fine, let me comment in the PR
[07:43] <mvo> pstolowski: \o/
[07:43] <mvo> pstolowski: thank you
[07:47] <pstolowski> mvo: added comments
[07:58] <mvo> pstolowski: thanks, makes perfect sense
[07:58] <mvo> mborzecki: looking at your mkfs stuff now
[07:58] <mborzecki> mvo: ta
[07:59] <mvo> mborzecki: its actually short, I like that
[07:59] <pstolowski> mvo: thanks for the change, one more remark for the test change you made
[08:00] <mvo> pstolowski: thanks, looking!
[08:00] <mvo> pstolowski: indeed, very good point
[08:00] <mvo> pstolowski: thank you!
[08:00] <pstolowski> ty!
[08:10] <mborzecki> usual issues https://www.reddit.com/r/linux/comments/c07mp1/ubuntu_devs_testing_chromium_browser_transition/ snaps are slow, themes, auto refresh etc
[08:20] <mvo> mborzecki: some ideas for your PR  looks great overall
[08:25] <mvo> gentle ping about 6691, it needs a second review
[08:35] <pstolowski> mvo: #7000, what a milestone! :)
[08:36] <mvo> pstolowski: indeed, 7k PRs its slightly crazy
[09:15] <Chipaca> mvo: does brave work for you?
[09:16] <mvo> Chipaca: it used to work
[09:16] <mvo> Chipaca: I can try again, shall I use the script from my gist?
[09:16] <mvo> Chipaca: or just deb/snap?
[09:16] <mvo> Chipaca: what release of ubuntu?
[09:17] <Chipaca> mvo: nah, just tell me if the snap's app runs
[09:17] <Chipaca> here it dies
[09:17] <Chipaca> but i'm on xenial
[09:17] <Chipaca> wondering if it's universally broken or what
[09:17] <Chipaca> (it complains about the sandbox)
[09:18] <Chipaca> wait, drat
[09:18] <Chipaca> it does work
[09:18] <Chipaca> hmm hmm
[09:18] <mvo> Chipaca: aha, ok. its still installing here :)
[09:18] <Chipaca> mvo: maybe i just needed to install it with assertions once for it to pick up the connections
[09:18] <Chipaca> :)
[09:19] <mvo> ok
[09:40] <pstolowski> grr @go-flags
[09:54] <Chipaca> pstolowski: no why?
[09:54] <Chipaca> now*
[10:16] <Chipaca> mvo: grr @ snaps that do a bunch of copying stuff around on first run :-/
[10:17] <Chipaca> on an HDD, that's nearly a whole minute waiting for the window
[10:17] <Chipaca> impressive
[10:17] <Chipaca> s/nearly/more than/
[10:17] <Chipaca> brave:none:596299776:69398:3087:2707
[10:17] <mvo> Chipaca: ohhhh, so thats the reaon?
[10:17] <mvo> Chipaca: reason?
[10:18] <mvo> Chipaca: its the copying of stuff not actually anything else?
[10:18] <Chipaca> that's SNAP:MODE:SIZE:START:START2:WALK
[10:18] <mvo> Chipaca: I'm very happy I asked you to look at this :)
[10:18] <Chipaca> is 69 seconds for first run, 3 seconds for 2nd (from an empty cache)
[10:18] <mvo> Chipaca: is that perf output?
[10:18] <Chipaca> that's my script output
[10:18] <Chipaca> one line of it
[10:18] <mvo> Chipaca: *nod*
[10:18] <Chipaca> an evolution of yours :)
[10:19] <mvo> Chipaca: nice find, out of curisoity, what is it copying around?
[10:19] <Chipaca> running it on my laptop with its blazing fast ssd, this wasn't noticeable
[10:19] <Chipaca> bah, a little: 6s to 4s or something like tht
[10:19] <Chipaca> on the gaming computer that has HDD homes, the above
[10:20] <Chipaca> anyway, will push the script and the results in a bit
[10:20] <Chipaca> i don't have zstd though so somebody else needs to run those to get that
[10:20] <Chipaca> (where is zstd supported?)
[10:21] <mvo> Chipaca: I can build you a sqaushfs-tools with zstd
[10:21] <mvo> Chipaca: its only available in git ./
[10:21] <Chipaca> mvo: will my kernel know how to mount it?
[10:21] <mvo> Chipaca: how do things compare to "on squashfs vs on ext4"? that is the most interessting one to me :)
[10:22] <mvo> Chipaca: thats a xenial kernel? I can check, iirc zstd in kernel was done way before squashfs-tools supported it (which is kinda-ironic)
[10:22] <mvo> Chipaca: 4.1.4
[10:22] <Chipaca> xenial here, bionic on the hdd
[10:22] <mvo> Chipaca: so should be in xenial, let me double check
[10:23] <Chipaca> CONFIG_SQUASHFS_ZSTD=y ← bionic
[10:23] <Chipaca> nothing like that in xenial
[10:24] <mvo> meh, ok
[10:24] <Chipaca> gnome-calculator:try:16560272:4577:3320:391
[10:24] <Chipaca> gnome-calculator:xz:4218880:4120:2904:328
[10:24] <Chipaca> mvo: ^ ext4 vs xz-compressed squashfs
[10:25] <Chipaca> about the same
[10:25] <Chipaca> (granted g-c is small)
[10:26] <mvo> Chipaca: silly me, misread - its 4.14 so no luck for you
[10:26] <mvo> Chipaca: niiiiiiiiiiiiiiice
[10:26] <mvo> Chipaca: I think that is a really good find
[10:26] <mvo> Chipaca: well, second run is with hot cache?
[10:27] <Chipaca> mvo: https://paste.ubuntu.com/p/82p3BFzwD9/
[10:27] <Chipaca> mvo: no, both drop caches
[10:27] <Chipaca> mvo: second run is without whatever the snap does on first run
[10:27] <mvo> Chipaca: \o/
[10:27] <mvo> Chipaca: you rock
[10:27] <mvo> Chipaca: this data looks very encouraging
[10:28] <Chipaca> mvo: https://gist.github.com/chipaca/2efec6e9d89cadada6478d8a010c5c2e
[10:29] <pedronis> Chipaca: what are you actually trying?  me is a bit confused here
[10:30] <Chipaca> pedronis: the effect of different compression options of squashfs on the speed of apps in a snap
[10:30] <mvo> pedronis: we talked yesterday that one of the open questions is how much overhead squashfs/xz is compared to ext4. I had some concerns about this from measurements on brave (and from feedback from the advocy team)
[10:30] <pedronis> mvo: talked when?
[10:30] <Chipaca> day before yesterday i think
[10:30] <Chipaca> pedronis: you were off
[10:32] <mvo> pedronis: do you have concerns about this ?
[10:33] <pedronis> mvo: multiple, mostly process ones
[10:33] <mvo> pedronis: as in "not the right time"?
[10:34] <pedronis> yes, also is untracked
[10:34] <pedronis> also it's hard for me to help if I don't have context
[10:36] <pedronis> mvo: if I look at trello I wouldn't know John is working on this
[10:36] <mvo> pedronis: meh, sorry then. I updated the trello to have some info on it. also its hopefully not a long task, ~1d or so. but happy to talk some more during the standup and address concerns
[10:36] <pedronis> or that it was started at all
[10:36] <mvo> pedronis: yeah, my bad, let me fix this
[10:40] <mborzecki> Chipaca: https://paste.ubuntu.com/p/wd3YjtbWbW/
[10:40] <pedronis> mvo: is John also working on https://trello.com/c/mwEvN8Hk/237-squashfs-install-performance-fuse-sucks ?
[10:40] <pedronis> or just the one you moved to WIP
[10:41] <Chipaca> pedronis: i am not working on that one
[10:41] <pedronis> ok, I thought you were
[10:41] <pedronis> that's why I was also confused
[10:41] <Chipaca> pedronis: we did talk about that i was working on this yesterday in the standup
[10:41] <pedronis> I understood as the other one
[10:41] <pedronis> funnily enough
[10:42] <pedronis> we did talk about lxd, no?
[10:42] <Chipaca> pedronis: i mentioned that tangentially i suggested the unpack-on-install approach as a global flag and that might be a solution to the fuse thing
[10:42] <pedronis> that's the other thing though
[10:42] <pedronis> so my confusion
[10:42] <mvo> pedronis: indeed, now it all makes sense. sorry for the confusion
[10:42] <Chipaca> heh
[10:43] <Chipaca> pedronis: this was one of the things that distracted me a bit from working on the benchmarking script itself (which is now done for now)
[10:43] <Chipaca> that, and people being wrong on the internet
[10:44] <mvo> Chipaca: heh :) I think we should write a forum post and maybe igor from advocacy can make it into a blog post). also would be nice to figure out what brave is doing, ideally we could suggest a fix to them (but timeboxed, lets not get dragged into a rathole :)
[10:44] <mvo> Chipaca: anyway, very happy with these numbers
[10:48] <Chipaca> mvo: http://paste.ubuntu.com/p/PVS5shj2QZ/
[10:48] <Chipaca> mvo: that's 'find ~/snap/brave' after first run, starting from it being empty
[10:49] <Chipaca> mvo: it's 37MB big
[10:49] <Chipaca> (so not big enough to justify how long it takes to do it)
[10:51] <mvo> Chipaca: thanks! its probably also doing some sort of generation for this data. oh well
[10:51] <Chipaca> mvo: desktop-launch
[10:52] <mvo> Chipaca: oh? snap run --trace-exec brave should give us some clues about this
[10:52] <Chipaca> ok let me do that on the slow box :)
[10:52] <mvo> Chipaca: i need to get lunch now, will read backlog
[10:52] <mvo> Chipaca: thank you!
[10:53] <Chipaca> pedronis: you ok with landing #6978 then? i'm not sure, from your comments
[10:59] <Chipaca> mvo: https://paste.ubuntu.com/p/sw3wGxgWzk/ (spoiler: it's update-mime-database)
[11:00] <mborzecki> off to pick up the kids
[11:16] <pedronis> Chipaca: ?
[11:17] <pedronis> Chipaca: no, need to have a pass, mostly about those switch summary messages
[11:17] <Chipaca> ok
[11:26] <pedronis> Chipaca: made my main comments
[11:33] <pedronis> Chipaca: I understand they from no channel came before, but given we are touching all of them it's a chance to improve that
[11:33] <Chipaca> yep
[11:33] <Chipaca> pedronis: but
[11:34] <Chipaca> pedronis: can i address it in a followup?
[11:35] <pedronis> Chipaca: worried about conflicts ?
[11:35] <Chipaca> pedronis: wanting to get the pr that exposes all these things (with spread test) up
[11:35] <Chipaca> and it's stacked on this one
[11:35] <pedronis> ah, ok
[11:38] <pedronis> Chipaca: ack that in the PR
[11:38] <pedronis> *acked
[11:39] <mborzecki> re
[11:58] <pedronis> mvo: pstolowski: made a comment on #7000
[12:03] <pstolowski> pedronis: thanks, thinking about it right now
[12:03] <pedronis> pstolowski: also we have a bigger problem, what if snapd comes from snapd
[12:04] <pedronis> but you have core installed
[12:05] <mvo> pedronis: thank you, in a meeting right now but will look at it once that is over
[12:07] <pstolowski> pedronis: right.. this logic predates snapd snap.. the reset only happens for level 6 under these conditions, and patches should be idempotent though
[12:07] <pstolowski> pedronis: nb, we have 2 other issues i found that led to all this, we can discuss before/after standup
[12:07] <pedronis> pstolowski: yes, the problem is that we wouldn't run them though
[12:07] <pedronis> because snapd will be updated before core maybe
[12:07] <pedronis> but we look at core
[12:08] <pedronis> (not sure it depends on ordering issues)
[12:09] <pstolowski> pedronis: hmm i see
[12:13] <zyga> hey everyone
[12:13] <zyga> last day
[12:14] <pstolowski> hey zyga! how is it going? tired?
[12:14] <zyga> it's been a fantastic week
[12:15] <zyga> lots of really amazing results
[12:15] <zyga> I strongly recommend reading the forum summary
[12:15] <pstolowski> zyga: yep i saw the tweets etc
[12:15] <zyga> https://forum.snapcraft.io/t/snapcraft-summit-montreal-2019-day-1-2-3/11763/5 <- for anyone interested
[12:15] <zyga> pstolowski: building firefox out of nixos packages in ~10 lines == mind blown
[12:15] <zyga> a little tired :)
[12:16] <zyga> but it's 14C here so I cannot complain
[12:17] <zyga> how was the week back home?
[12:18] <pstolowski> zyga: insanely hot.. with thunders yesterday afternoon, so a little relief
[12:20] <zyga> I'm off for breakfast, ttyl
[13:14] <vladoski> I'm trying to install Heroku via snap, but everytime gets stuck on this and fails: error: cannot perform the following tasks:
[13:14] <vladoski> - Run configure hook of "heroku" snap if present (run hook "configure": execv failed: Permission denied)
[13:17] <Chipaca> vladoski: strange
[13:17] <Chipaca> vladoski: what snap is it?
[13:17] <Chipaca> d'oh, "heroku"
[13:18] <vladoski> Chipaca: yep it's heroku
[13:19] <Chipaca> vladoski: looks like a buggy snap
[13:19] <Chipaca> vladoski: do you have /snap/bin ?
[13:19] <vladoski> ahm, so what should I do?
[13:20] <vladoski> Chipaca: yes
[13:21] <vladoski> I have 4 snaps in it
[13:21] <Chipaca> vladoski: what's the output of 'snap version'?
[13:26] <vladoski> snap    2.39.1-1.fc30
[13:26] <vladoski> snapd   2.39.1-1.fc30
[13:26] <vladoski> series  16
[13:26] <vladoski> fedora  30
[13:26] <vladoski> kernel  5.1.8-300.fc30.x86_64
[13:26] <vladoski> Chipaca: that's the output
[13:28] <Chipaca> mborzecki: ^ ?
[13:29] <vladoski> I'm using Fedora 30 if it helps
[13:29] <vladoski> oh nvm it was in the log ahah
[13:29] <Chipaca> vladoski: yeah, mborzecki has been looking at issues on fc30 which is why i'm asking him to take a look
[13:29] <Chipaca> just in case it's a known issue / known workaround
[13:30] <mborzecki> vladoski: it's aknown problem, we have a fix for it and it's in fedora src repo already, we just need to update the package
[13:30] <Chipaca> huzzah
[13:31] <vladoski> Yes I know that snap is a little buggy now with fedora, one week ago I had to remove it because it was giving problems with battery status, function keys and system errors
[13:31] <mborzecki> wondering if zyga or Eighth_Doctor could fedpkg build a new package maybe?
[13:32] <Eighth_Doctor> for what?
[13:32] <mborzecki> vladoski: you can temporarily switch selinux to permissive, setenforce 0, install the snap, and then setenforce 1
[13:32] <mborzecki> Eighth_Doctor: snapd
[13:32] <Eighth_Doctor> oh the fixes you sent in yesterday, right?
[13:33] <mborzecki> Eighth_Doctor: yup :)
[13:33] <Eighth_Doctor> I'll fedpkg build them now
[13:33] <Eighth_Doctor> only reason I didn't was that I thought mvo was going to release 2.39.3 with that fix integrated
[13:34] <Chipaca> Eighth_Doctor: hmm, yesterday mvo in the standup decided not to do a .3, and have it be distro-patched, so we could move on to .40
[13:35] <mborzecki> Eighth_Doctor: i think we'll do 2.40, let me double check with mvo
[13:35] <Chipaca> Eighth_Doctor: we dropped the ball on letting you know
[13:35] <Eighth_Doctor> welp
[13:35] <mborzecki> ah, missed that
[13:35] <Chipaca> mborzecki: was that a "mvo should have told you to communicate that"?
[13:35] <mvo> meh, sorry, did I fail at doing this?
[13:35] <zyga> mborzecki: next week at earliest
[13:36] <mborzecki> Chipaca: nope, i should have picked that up myself :P
[13:36] <Eighth_Doctor> I guess I'll update to 2.39.2 and push it
[13:36] <mborzecki> so basically, /me dropping the ball :)
[13:36] <Chipaca> mborzecki: yes but mvo should've double-checked :)
 etc
[13:36]  * Chipaca lazy
[13:36] <mborzecki> Eighth_Doctor: that last 2 patches are not in .2, so please apply those separately
[13:37] <Eighth_Doctor> will do
[13:37] <mborzecki> Eighth_Doctor: great, thank you!
[13:47] <Eighth_Doctor> they're building now
[13:49] <Eighth_Doctor> zyga, mborzecki: I've been thinking that for Fedora snaps, we should look to plug into the modularity toolchain
[13:49] <Eighth_Doctor> instead of trying to beat snapcraft into working
[13:49] <Eighth_Doctor> I'm tired of trying to figure out how to make snapcraft do what I want, and getting the modularity toolchain to do it would make it possible for Fedora contributors to officially build and submit snaps
[13:50] <mborzecki> ha
[13:50] <mborzecki> Eighth_Doctor: sounds like what the nix guys did
[13:50] <zyga> Eighth_Doctor: I have the exact same feeling this week
[13:50] <Eighth_Doctor> and like the flatpaks/ namespace we have in Dist-Git, we could have a snaps/ one for people to make snap modules
[13:50] <zyga> Eighth_Doctor: it is the most direct way to get the right things to happen
[13:50] <zyga> Eighth_Doctor: oh, btw, I asked the godot deveoper to go to flock
[13:50] <Eighth_Doctor> yeah
[13:50] <zyga> his work on using fedora in snaps is amazing
[13:50] <Eighth_Doctor> which one?
[13:50] <zyga> and it  is really an eye-opening experience as to why this is done this way
[13:51] <zyga> Eighth_Doctor: godot stack, including games, are all built from fedora bits
[13:51] <zyga> Eighth_Doctor: but the story there is much deeper
[13:51] <Eighth_Doctor> nice!
[13:51] <Eighth_Doctor> I knew that at least one godot dev liked the fedora stack :)
[13:52] <Eighth_Doctor> and that would be an awesome surprise to put into our presentation at flock: https://pagure.io/flock/issue/163
[13:53] <Eighth_Doctor> zyga, mborzecki: https://src.fedoraproject.org/projects/flatpaks/*
[13:53] <Eighth_Doctor> I want exactly the same thing for snaps
[13:53] <mborzecki> cachio: https://github.com/snapcore/snapd/pull/7004 this should work (works locally in xenial vm), i'll try to run one of nested core tests
[13:55] <Eighth_Doctor> zyga: I'm pretty close to having a new simple tool for producing a base snap
[13:55] <Eighth_Doctor> there's a few things I'm changing up so that it works in a decently portable way across rpm distros without baking too much logic into it for that
[13:56] <Eighth_Doctor> but also the part I don't know is uploading snaps properly without requiring snapcraft
[13:56] <Chipaca> siiiiigh
[13:57] <Chipaca> home isn't auto-connected on core, right?
[13:57] <Chipaca> si³³gh
[13:57]  * Chipaca fixes the spread test
[13:57] <cachio> mborzecki, nice
[13:58] <cachio> i'll try it
[13:59] <mborzecki> cachio: i'm trying google-nested:ubuntu-16.04-64:tests/nested/core/hotplug
[13:59] <zyga> Chipaca: correct
[14:01] <cachio> mborzecki, nice, I integrated that to the PR #6892 and I am running on 18.04 and 16.04
[14:01] <cachio> I'll tell you how it works
[14:02] <Eighth_Doctor> zyga, mborzecki: bodhi updates proposed
[14:02] <Eighth_Doctor> F30: https://bodhi.fedoraproject.org/updates/FEDORA-2019-17c0fb9ce6
[14:02] <Eighth_Doctor> F29: https://bodhi.fedoraproject.org/updates/FEDORA-2019-91c0be0cc5
[14:02] <Eighth_Doctor> EL7: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-502ed76053
[14:03] <Eighth_Doctor> I need testing and karma
[14:03] <mborzecki> Eighth_Doctor: great, thank you!
[14:05]  * Chipaca reckons Eighth_Doctor should have enough karma to launch a spaceship, at this point
[14:05]  * Eighth_Doctor snorts
[14:06] <mborzecki> vladoski: you should be able to get a working version from updates-testing repo once it's there ^^
[14:07] <vladoski> mborzecki: okay thanks!
[14:09]  * cachio afk
[14:10]  * zyga is extremely sleepy and tired
[14:10] <zyga> sorry everyone
[14:13] <zyga> Eighth_Doctor: some more attention on the update, thank you for working on this !
[14:24] <abeato> jdstrand, hey, I have a couple of minor updates to interfaces waiting for review: https://github.com/snapcore/snapd/pull/6962 and https://github.com/snapcore/snapd/pull/6975
[14:39] <juliank> I recently realized that snapped browsers break integration with KeePassXC, because it uses some native messaging thingy
[14:39] <juliank> but I'm not sure what could be done about that
[14:39] <pedronis> pstolowski: I reviewed #6960
[14:40] <juliank> Apparently this is super nasty stuff, where the browser invokes a binary on the host
[14:41] <juliank> e.g. https://developer.chrome.com/extensions/nativeMessaging
[14:42] <pstolowski> pedronis: ty
[15:11] <cachio> pstolowski, when you have some time could you please take a look to #6892
[15:13] <pstolowski> cachio: oh yes, looking now
[15:13] <cachio> pstolowski, thanks
[15:17] <pstolowski> cachio: so the problem with assertion disk & snapshot remains unresolved, right? no problem with the workaround, just curious, did Maciej have any other ideas?
[15:18] <cachio> pstolowski, no new ideas so fat
[15:18] <cachio> far
[15:18] <cachio> I juest tested the change on how assertions disk is created
[15:18] <cachio> and works very well
[15:19] <cachio> I'll wait Maciej reply before merging this PR
[15:23] <pstolowski> cachio: ok, +1 from me
[15:23] <cachio> pstolowski, nice, thanks
[15:47]  * cachio lunch
[19:05]  * cachio afk


[08:50]  * Daviey ponders mongo...
[08:51] <Daviey> you know.. Ubuntu isn't ready for mongo do be a dependency..
[08:51] <Daviey> bigjools: ^
[08:53] <bigjools> Daviey: fancy that
[08:53] <bigjools> jtv: how may I help?
[08:57] <Daviey> bigjools: I assume current quantal version is the release that has been developed against ?
[08:57] <Daviey> (another project asked us to consider a major version update)
[08:57] <bigjools> Daviey: yeah - is someone pulling in mongo?
[08:59] <Daviey> bigjools: Are we not?
[09:00] <bigjools> Daviey: AFAIK, no
[09:00] <bigjools> not right now anyway
[09:00] <Daviey> we will, no?
[09:01] <bigjools> Daviey: possibly - I don't recall the exact discussions that jam1 had around this
[09:01] <mgz> Daviey: we decided to avoid the excitement
[09:02] <mgz> at least until 13.04
[09:02] <Daviey> mgz: What what ding ding?
[09:02] <mgz> why exactly isn't ubuntu ready for a committed relationship with mongo though?
[09:02] <mgz> and it's us that needs to change, not them?
[09:02] <Daviey> mgz: you make it sound like a marriage :)
[09:03] <Daviey> I think we should see other people..
[09:03] <Daviey> mgz: The process for mongo to be in main, hasn't been started... that is all.
[09:03] <mgz> there are plenty of other databases in the sea
[09:03] <lifeless> hah
[09:03] <lifeless> not sure that that analogy holds
[09:14] <rbasak> Do we have a preferred method of defining properties? Is @property def foo, then @foo.setter OK?
[09:18] <mgz> jam: https://codereview.appspot.com/6569053
[09:19] <bigjools> rbasak: I think that's ok
[09:19] <jam> mgz: hmm.. I don't see a way to sub to just the MP without commenting on it.
[09:20] <jam> mgz: is it possible to call it just 'tags'? rather than 'maas-tags' ?
[09:20] <jam> I believe we want to match the search in our web UI with what you pass to juju, and putting 'maas-' in there is a bit annoying.
[09:20] <jam> (I recognize the idea of namespacing, though)
[09:22] <jam> mgz: also here: https://codereview.appspot.com/6569053/patch/1/5 you seem to be removing 'maas-name' but it is still listed as supported in the other files
[09:22] <jam> or is it just that you fallback to None if not supplied?
[09:23] <jam> mgz: and here: https://codereview.appspot.com/6569053/patch/1/6 I think we are going to go with 'tag1,tag2,tag3' style rather than tag1&!tag2|tag3
[09:23] <mgz> jam: there's a linked lp proposal you can comment on if their funny code review doesn't play ball
[09:23] <mgz> https://code.launchpad.net/~gz/juju/add_maas_constraints/+merge/126203
[09:24] <jam> the changes look good to me, just some small bits
[09:24] <mgz> I think in the context of the maas code, just using "tags" is fine, but it's so generic a term I don't like exposing it as a general constraint without getting more specific
[09:25] <mgz> the removal of maas-name from those tests is just cleanup, it's not required and confuses what they're trying to test
[09:26] <mgz> my first pass at this parsed and validated the tags on the juju side
[09:26] <mgz> but I reverted to this approach of just passing a string through, because I'm not sure how far we want to go with tag combinations
[09:27] <jam> mgz: well I know hazmat asked us to make it less specific, so the provider should query Maas for a list of acceptable tags.
[09:27] <mgz> could just pick nodes with a superset of the tags specified, or could do full boolean logic
[09:27] <jam> less generic?
[09:27] <mgz> I think hazmat will be fine with maas returning good errors for non-existant tags or a bad tag string
[09:27] <jam> The argument is that deploying is async, so by the time the provider responds, it is too late to inform the user of a typo/etc.
[09:28] <mgz> right, so provided we catch before acquire actually happens that a tag is bad, and return a 4XX straight away without going down to the cluster, I think that's fine
[09:30] <mgz> ...I probably want to add some tests for that error case
[09:38] <jam> mgz: shall we chat on mumble/
[09:38] <jam> ?
[09:41] <bigjools> Daviey: should I reference the snakeoil certs as an example when I stick in SSL support? (so it just works as a demo)
[09:45] <mgz> jam: lets
[09:46] <Daviey> bigjools: i'd say so
[09:46] <Daviey> hmm
[09:46] <Daviey> what do you think?
[09:46] <bigjools> Daviey: WFM
[09:47] <bigjools> it works, anyway :)
[10:02] <jam> mgz: http://ezix.org/project/wiki/HardwareLiSter#Howtointerpretlshwsoutput
[10:56] <rbasak> rvba: having some trouble migrating Node.architecture into Node._arch with a Node.architecture frontend property. It works, except NodeForm screws up. I think it's because it can't automatically generate the form from the model for the architecture property, since that's no longer an ORM field.
[10:57] <rbasak> rvba: can I perhaps make NodeForm.architecture an "extra" field which does map to Node.architecture's property but not automatically?
[10:58] <rvba> rbasak: sounds like a good idea.  You'll have to create a form field which handles that logic: display a single choice but stores into two fields.
[10:59] <rbasak> rvba: to start with I'm just trying to move architecture into _arch but with the same behaviour as before
[10:59] <rbasak> So there's an abstraction layer that I can then modify. But all tests should pass at this stage
[11:00] <rvba> rbasak: let me have a look at NodeForm.
[11:00] <rbasak> rvba: I'm not clear on the exact mechanics between ModelForm, Form and Model
[11:00] <rvba> rbasak: it overrides the 'architecture' field so you'll need to rename that field as well.
[11:01] <rvba> rbasak: ModelForm is only a base class for forms that help creating forms from model definitions.
[11:02] <rvba> That's the 'Meta' part where you define on which model a ModelForm is based and which fields are taken from that model.
[11:02] <rbasak> rvba: yep - so if I remove fields = ( 'architecture') from NodeForm, it should still work? I'm a bit confused as to what purpose it's serving at the mment, since there's already an explicit architecture definition in NodeForm
[11:03] <rvba> rbasak: the ModelForm also handles the fact that when you save that form, an specific object is needed.
[11:04] <rvba> rbasak: s/needed/created/
[11:05] <rbasak> rvba: so if I remove fields=('architecture'), then the object will be created but without that field? How would I override that to add it again?
[11:07] <rvba> rbasak: having 'architecture' in fields (even if the form field is defined on the form itself) is to instruct the form that whatever comes out of the form's field 'architecture' is a field on the created/modified model object.
[11:08] <rbasak> rvba: thanks. I think I understand that part then, but don't understand the failure I'm getting
[11:08] <rbasak> rvba: lots of ValidationError: {u'architecture': [u'This field is required.']
[11:08] <rvba> rbasak: I think you want to create a multivalue field (https://docs.djangoproject.com/en/dev/ref/forms/fields/#multivaluefield).
[11:08] <rvba> rbasak: can I see the diff?
[11:09] <rbasak> rvba: http://paste.ubuntu.com/1226381/
[11:10] <rvba> rbasak: right, but NodeForm still has a required 'architecture' field.  Hence the validation failure.
[11:10] <rbasak> rvba: but I still require an 'architecture' to be set in the model
[11:14] <rbasak> rvba: ah. Is it that model_to_dict isn't returning an 'architecture' field?
[11:15] <rbasak> rvba: one failure is in NodeGroupInterfaceHandler.update for example. Perhaps it's not retrieving the architecture field, so when it tries to update it updates without one
[11:16] <rvba> rbasak: yep, something like that.  But I'm trying to work out if the problem is in Django itself (which would mean it can't work with python properties) or in how MAAS handles the forms in the API.
[11:17] <rbasak> rvba: sqlalchemy has a solution to this it calls hybrid properties, which allow derived attributes to be defined in the model and mapped properly.
[11:17] <rbasak> rvba: I found http://stackoverflow.com/questions/12217763/does-django-orm-have-an-equivalent-to-sqlalchemys-hybrid-attribute which suggests that django doesn't have an equivalent
[11:24] <rvba> rbasak: also, without the db migration in place, South hijacks the models definition so your new field is probably not even properly registered.
[11:25] <rbasak> rvba: I don't have a new field!
[11:25] <rbasak> (yet)
[11:25] <rvba> Right, but I'm wondering if the change is still something that South needs to know about.
[11:25] <rbasak> ok
[11:25] <allenap> mgz: You can self-review https://code.launchpad.net/~gz/maas/move_update_hardware_details_tests/+merge/126226 if you want; there's nothing controversial in there.
[11:30] <rbasak> rvba: looks like this might be an alternate approach to using properties: Challenger 600
[11:30] <rbasak> Aarh
[11:31] <rbasak> https://docs.djangoproject.com/en/dev/howto/custom-model-fields/
[11:31] <rvba> rbasak: did you consider keeping the architecture field as is but have it populated with things like 'arch/subarch' and have two methods on the node to get just the arch or just the subarch?
[11:31] <rbasak> rvba: I thought it would be cleaner if everything apart from the model dealt with the architecture as a 2-tuple
[11:31] <rbasak> rvba: rather than adding another subarchitecture field
[11:32] <rbasak> (and needing to pass two values around all the time)
[11:32] <rbasak> But perhaps this is more complicated than it first seemed
[11:32] <rvba> But what about storing both the arch and the subarch in the 'architecture' field?
[11:32] <rbasak> Oh
[11:32] <rbasak> Using a '/' as a separator?
[11:32] <rvba> Yes
[11:33] <rvba> 'arch/subarch'
[11:33] <rbasak> That would work too but I think even more ugly. At what layer would we translate to a 2-tuple? And if we don't translate to a 2-tuple, then code that needs to just match arch will have to split('/') and we'd end up with those all over the place
[11:34] <rvba> What part of the code needs a 2-tuple?
[11:35] <rvba> Probably only a fraction of the code.
[11:35] <rvba> All the rest of the code (UI/API/model) could deal with 'arch/subarch'.
[11:36] <rbasak> Any time I want to say "if arm", I'd need to say "if architecture.split('/')[0] == 'armhf'"
[11:40] <rvba> If the code that needs to do that is manipulating node objects, then this could be a method of Node.
[11:43] <rbasak> I suspect that the node object itself will be lost higher up in the call stack, and only the architecture field will be passed down
[11:43] <rvba> Yeah, probably.
[11:43] <rbasak> But it's a trade-off, and implementing a 2-tuple may be too complicated
[11:43] <rbasak> The only way clean way right now seems to be a django custom field
[11:44] <rbasak> If overloading the string type is acceptable to the team, I'll happily do it that way
[11:44] <rbasak> allenap: ^^ your opinion please?
[11:45]  * allenap looks
[11:46] <rvba> rbasak: the problem you're having right now is that the ModelForm only tries to save on the node object the fields that a) are listed in 'field' and b) correspond to a real DB field.
[11:47] <rvba> s/'field'/'fields'/
[11:47] <rbasak> rvba: I think I follow (just)
[11:47] <rbasak> rvba: so it seems that using a property on a Model in order to map derived fields is not so straightforward in django
[11:47] <rvba> Indeed.
[11:48] <rbasak> rvba: I'm concerned that there will be other areas where doing it this way might be a problem in future even if we do manage to make it work
[11:48] <rvba> And a custom field is only really helpful if you're trying to store a structure inside a single db column.
[11:48] <rbasak> ah
[11:49] <rbasak> well that eliminates that option then
[11:49] <rbasak> so it looks like overloading a string is the only option left
[11:50] <rbasak> I'll just do that then
[11:50] <rbasak> At least it's easier even if it is ugly!
[11:50] <rbasak> Unless allenap has a better suggestion?
[11:51] <rvba> I think this will be much more simple as a single field.
[11:51] <allenap> rbasak: I was thinking of something like http://paste.ubuntu.com/1226429/
[11:51] <rvba> Even if it's slightly ugly.
[11:52] <rvba> allenap: that's the cleanest possible in terms of db but it will make the form code complicated.
[11:52] <allenap> I didn't know how far back to read, so you might have discounted that idea already.
[11:52] <rvba> Because now you've got one field which is dependent on the other.
[11:52] <rbasak> allenap: yeah that's exactly what I tried, but it breaks model_to_dict
[11:53] <allenap> rvba: Does the form code have to be driven from the model definition, or can its "architecture" field be specially prepared?
[11:53] <rbasak> allenap: and it feels that trying to fix that up is a step too far, and will end up being more hacky than just overloading the string
[11:53] <allenap> Yeah.
[11:54] <rvba> allenap: it can be done at the form level.
[11:54] <allenap> Just put "arch/subarch" in the field, and have a couple of functions to get the arch and subarch out. I guess that was the intention behind subclassing str/unicode. Can Django be taught to always use a particular string class for a field?
[11:55] <rvba> allenap: "subclassing str/unicode"?
[11:55] <rbasak> oooh
[11:56] <allenap> rvba: I thought that was what rbasak had suggested earlier with "overloading the string type".
[11:56] <rbasak> that's not what I meant, but it's an interesting idea
[11:56] <rbasak> or just have an Architecture class which can be contructed with a string
[11:57] <allenap> It would be nice to avoid impedance problems when dealing with Django's models, if we can.
[11:58] <allenap> Custom field type territory then.
[11:58] <rbasak> yeah
[11:58] <rbasak> but it would work
[11:58] <rbasak> Is it worth the effort?
[11:58] <rbasak> Or can I just use a string for now?
[11:58] <allenap> Again, not sure if the form machinery will cope.
[11:59] <rvba> The form machinery should be fine I think.
[11:59] <allenap> rbasak: Just use a string I think :)
[11:59] <rbasak> Although a custom field would save a db migration
[11:59] <rbasak> though maybe we should do one anyway
[11:59] <rvba> A db migration is really cheap.
[12:00] <rbasak> I presume we can do a migration even without a db schema change?
[12:00] <rbasak> update node set architecture=architecture + 'generic'
[12:00] <rbasak> update node set architecture=architecture + '/generic'
[12:00] <rvba> You want a datamigration (and not a schema migration).
[12:00] <allenap> I have to go and feed children, back later.
[12:00] <rbasak> ok
[12:01] <rbasak> I think that's a decision then
[12:01] <rbasak> thank to both of you!
[12:01] <rbasak> thanks
[12:06] <mgz> this is an error?
[12:06] <mgz> While: Installing repl. Getting distribution for 'amqplib>=0.6.1'.
[12:06] <mgz> Error: Picked: amqplib = 1.0.2
[12:08] <mgz> what is buildout trying to tell me?
[12:21] <jtv> mgz: it's configured not to pick its versions freely, yet the versions we specify are minima, not exact values.  We fixed it by relying on installed packages more.
[12:22] <jtv> Removing the egg from your cache may help.
[12:24] <mgz> that's not an egg, it's what precise installed I suspect
[12:24] <jtv> oh, precise
[12:24] <mgz> but... it really can't do > properly? really?
[12:24] <jtv> It's configured not to.
[12:25] <jtv> Don't ask me for the details; I don't know them.
[12:25] <jam> jtv: I think your patch is breaking Jenkins. Did you see the failures?
[12:25] <jtv> jam: not yet -- I'll have a look.
[12:25] <jam> https://jenkins.qa.ubuntu.com/job/maas-trunk/849/console d
[12:25] <jam> has: u'refresh_workers' not in '--[12:25] <jam> in a 'test_start_up_calls_refresh_secrets"
[12:25] <jam> jtv: for what it is worth, that test fails locally for me as well.
[12:26] <jam> It looks like it is a mix of your test plus allenap's change to use email
[12:26] <jam> (given that it is asserting a string is present in a mime encoded chunk)
[12:28] <jtv> It sounds as if registration of tasks got messed up somehow
[12:29] <mgz> removing the egg alas did not help, precise has 1.0.0+ds-1, buildout gets and installs 1.0.2 then complains that 1.0.2>=0.6.1 is false...
[12:30] <jtv> No, trunk is for quantal now.
[12:33] <jtv> jam: ahhh, looks like something in the data presentation changed -- may have been Gavin's work on maascli.
[12:34] <jam> jtv: or his recent change to use the email module?
[12:34] <jam> I wouldn't usually expect to do 'content in mime_string'
[12:34] <jtv> dunno about that
[12:34] <jam> (given that mime_string might be base64 encoded)
[12:34] <jtv> Yeah -- and mime is such a pain to deal with
[12:35] <jtv> :(
[12:35] <jam> jtv: since you're here, I'm trying to add a test that if you give bad data, we make sure the db stays consistent.
[12:35] <jam> I am able to trigger the DatabaseError
[12:35] <jam> but now I don't know how to rollback
[12:35] <jtv> otp though
[12:35] <jam> in order to inspect the db to make sure the content is consistent
[12:35] <jam> rvba: ^^
[12:35] <jam> I see there is 'transaction' objects in Django, do I just need to use it in the test suite?
[12:36] <rvba> jam: you need to use a special test case if you want to use transaction management in your test.
[12:37] <jam> rvba: well, there are 2 levels then. I also want to test that the API call doesn't bork things up in the middle, which means it might need a transaction object as well.
[12:37] <rvba> This is because the default testcase in Django uses rollback to wipe out the data between tests.  More details here: https://docs.djangoproject.com/en/dev/topics/testing/#django.test.TransactionTestCase
[12:38] <jam> rvba: ah, so none of the 'obj.save()' calls are actually being committed?
[12:38] <jtv> that's not a commit
[12:38] <jtv> that's just "write this to the database"
[12:38] <jtv> doesn't care one hoot about transactions.
[12:38] <jam> jtv: https://docs.djangoproject.com/en/dev/topics/db/transactions/?from=olddocs (by default .save is committed in essentially autocommit mode)
[12:38] <jtv> The same goes for the "commit" argument to form.save():  it's about writing stuff to the db, not about transactions
[12:39] <jtv> Not "essentially" autocommit, but actual autocommit.
[12:40] <jtv> It's entirely divorced from transaction management.
[12:40] <jam> jtv: right, I was trying to ascertain what is being done in Maas.
[12:40] <jtv> OK
[12:40] <jam> I do understand the difference between a .save() and a .commit.
[12:41] <rvba> jtv: right, unless you're using the TransactionTestCase.
[12:41] <jtv> (Sorry, I'm in the next phone call, a friend who seems upset but there doesn't seem to be anything to do for him but let him tallk.  Very distracting)
[12:41] <jam> for the API calls, what is the transaction logic? Autocommit? The "TransactionMiddleware" that is recommended.
[12:41] <rvba> err, jam ^
[12:41] <allenap> jtv: Want me to fix that failing test? I know what to do, and have a function ready to do it.
[12:41] <jtv> Oh, that'd be great!
[12:41] <rvba> allenap: since you're there, mgz seems to be having the same problem I had yesterday.
[12:42] <allenap> rvba: The amqp one?
[12:42] <rvba> Since then I upgraded to Quantal and the problem is gone.
[12:42] <rvba> allenap: yes
[12:42] <allenap> Damnable buildout.
[12:43] <allenap> mgz: Are you able to upgrade to Quantal, or at least use it on Canonistack?
[12:43] <jam> rvba: so is it as simple as importing maastesting.djangotestcase.TransactionTestCase? And not worry about the other setup code in maasserver.testing.testcase.TestCase.setUp() ?
[12:43] <jam> allenap: mgz is off to lunch. But he did mention it to me.
[12:44] <jam> I think it is a matter of: "why is running on P so horribly broken" vs
[12:44] <jam> I cannot run on Q
[12:44] <allenap> jam: That sounds like he's not blocked, phew :)
[12:45] <jam> I think it is a bit of 'I don't *want* to run on Q as well' but he mentioned being able to switch VMs.
[12:45] <jtv> jam: it should be as easy as changing TestCase classes, yes.  Just slower.
[12:46] <rbasak> rvba: so I'm think of this: http://paste.ubuntu.com/1226522/ - would this work for the web UI?
[12:46] <jtv> However we've been seeing some mysterious test failures with unusual invocations of the test suite, and those _seem_ to be related to TransactionTestCase.  So whatever you do, run the full test suite!
[12:46] <rvba> jam: Good point, you might need to create a class which inherits from the TransactionalTestCase and have the setup from maasserver.testing.testcase.TestCase.
[12:47] <rvba> rbasak: that should be ok.
[12:47] <rbasak> thanks - I'll continue
[12:48] <jtv> jam: about that pastebin -- I'm not sure the migration runs in a transaction, so breakage in mid-transaction might leave you with only some of the nodes updated.
[12:49] <jtv> Oh, that's rbasak!
[12:49] <jtv> rbasak: don't know how much it matters but those node updates in your schema patch may run in autocommit.
[12:50] <rbasak> that's insane
[12:50] <rbasak> whose idea was it to make data migrations _not_ run in a transaction by default?
[12:50] <jtv> I'm not _sure_ they don't run in transactions.
[12:50] <rbasak> why would one ever not want to do that?!
[12:50] <jtv> The django people do not seem to have much truck with the whole notion.
[12:51] <jtv> I hope my impression is just an exaggeration, but I hear the same from others.
[12:51] <rbasak> jtv: we're good: http://south.readthedocs.org/en/latest/migrationstructure.html#transactions
[12:53] <jtv> Phew.  Thanks, that's a load off my mind!
[12:53] <jtv> South != django :)
[12:55] <jtv> There's another reason to be pleasantly surprised: don't know what it's like now, but transactionality of schema changes used to be a laughable concept in many databases.
[12:56] <jtv> allenap: out of interest, do you know which change broke my test?  And what is that fix you had lying around?
[12:59] <allenap> jtv: I changed the multipart mime stuff to use the built-in email stuff for generation, but owing to a "bug" in it, I had to ensure that everything is now base64 encoded so that I can post-process line-endings.
[12:59] <allenap> jtv: The reason for the change was unicode support.
[12:59] <allenap> jtv: The function that's lying around is parse_headers_and_body_with_django.
[12:59] <jtv> Ah.  That means you understand more of MIME in python than most now.  Please while you're at it give us a better replacement for the standard library's MIME bits.  :)
[12:59] <jtv> Ahhh nice.
[13:00] <allenap> However, that's a pita because it requires DJANGO_SETTINGS_MODULE, not something that's typically lying around in the pserv.
[13:00] <allenap> I HATE DJANGO.
[13:09] <jtv> There's no way to get the requirements out into... apiclient or something?
[13:16] <mgz> allenap: yup, I can upgrade, I just need to deal with scott's change to how cloud-init displays ssh fingerprint stuff
[13:18] <rbasak> mgz: will it be an issue if arch constraints start needing to specify "i386/generic" instead of just i386?
[13:19] <rbasak> The reason is that armhf/highbank and armhf/armadaxp need to be distinguished
[13:20] <mgz> rbasak: wouldn't be an issue, but also not hard to match if only a main(?) arch is given and not a subarch
[13:21] <rbasak> mgz: it's a bit annoying as sql queries go, because we concluded above that we want to squeeze both into a single string field
[13:21] <mgz> so people could still use arch=amd64 as the constraint, and maas knows that amd64/generic satisfies that
[13:21] <rbasak> but we could check for a prefix of arch + '/'
[13:22] <mgz> well, for that case you can just expand the input
[13:22] <rbasak> it can't be farmed off to the db to process then though
[13:22] <mgz> and for arm, you can do much the same, treat "armhf" in the api as filter to ('armhf/highbank', 'armhf/armadaxp') or whatever the acceptable full values are
[13:22] <rbasak> Oh, I see
[13:23] <mgz> have a dict at the python level of what the short versions are in full
[13:23] <rbasak> right
[13:40] <roaksoax_> big/win 11
[14:03] <allenap> jtv: Got time for a review? https://code.launchpad.net/~allenap/maas/no-string-in-mime/+merge/126248
[14:04] <jtv> allenap: right after I answer nature's call
[14:04] <allenap> Hah, ta.
[14:13] <jtv> allenap: nature and your MP have been answered.
[14:15] <allenap> jtv: Thanks :)
[14:16] <jtv> Thanks for fixing my test.
[14:34] <jtv> hey there matsubara
[15:01] <matsubara> hi jtv
[15:03] <jtv> matsubara: wanted to give you a heads up for a change I landed: a new maas-provision command that registers a cluster controller with the region controller.
[15:03] <jtv> We're not using it yet, but it should work.
[15:03] <matsubara> jtv, ok
[15:03] <jtv> Assuming that celery is not running, you should be able to start the cluster controller by running "maas-provision start-cluster-controller <region-controller URL>"
[15:04] <matsubara> jtv, is this the work to make maas work across different subnet?
[15:04] <jtv> Part of it, yes.
[15:05] <jtv> It lets us run multiple clusters.
[15:05] <jtv> The nice thing is that the exact same registration procedure will work for existing cluster controllers that are rebooting, new ones that haven't been registered yet, and new ones that have just been approved.
[15:06] <jtv> Cluster controller asks the region controller: "Hi, I'd like to work for you as a cluster controller.  Is that OK?"
[15:06] <jtv> Region controller answers with either:
[15:06] <jtv> (a) Get lost, creep.  I don't know you.
[15:06] <jtv> (b) Still waiting for my human to make a decision.  Can you call me back in a minute or so?
[15:07] <jtv> (c) Sure buddy, and welcome!  Here's the information you need to connect to RabbitMQ.
[15:07] <jtv> If the cluster was already known, it just immediately gets (c).
[15:07] <Daviey> b opens itself to brute force fwiw.. It confirms there is an account with that user.
[15:07] <jtv> Daviey: no account or user is implicated.
[15:08] <Daviey> so how does the client know the difference between a and b?
[15:08] <jtv> Just the http status code in the response.
[15:08] <allenap> rvba: Do you have time for a call to help me understand what I'm doing with this dns stuff?
[15:08] <rvba> allenap: sure.
[15:09] <jtv> matsubara: the important thing to know for the future is that we won't be starting an upstart celery service.  We'll be starting this new command, and once it gets a positive response, it will fire up celery.
[15:11] <jtv> Once the cluster controller has been accepted, it sends the region controller a request: "now that I'm one of your cluster controller and am connected to the RabbitMQ channel, could you send each of your known cluster controllers their individual credentials etc. over rabbit?"
[15:49] <allenap> matsubara: Hey there, can you change the `make check` line in Jenkins to `make offline=true check`?
[15:51] <matsubara> allenap, yes, sure
[15:51] <allenap> matsubara: Ta.
[15:57] <matsubara> allenap, so, should it look like this: make distclean && make offline=true build && make offline=true check?
[16:21] <allenap> matsubara: Yep.
[16:21] <matsubara> allenap, ok, so it's been done. I take this should be applied for both maas jobs, right?
[16:22] <allenap> matsubara: Yes, think so; I backported it to 12.04-nocobbler.
[16:22] <matsubara> cool
[17:15] <platypusfriend> Greets
[17:16] <platypusfriend> I have a question about configuring maas-dhcp on a system with two network interfaces (I'd like my MAAS server to provision nodes on a private network)
[17:17] <platypusfriend> How do I configure maas-dhcp to use my second interface? I wasn't able to find this answer in the documentation, or in a Google search.
[17:21] <platypusfriend> Additionally I'm unable to use or install the maas-provision utility.
[17:22] <platypusfriend> $ maas-provision generate-dhcp-config -h maas-provision: command not found
[17:22] <platypusfriend> $ sudo apt-get install maas-provision Reading package lists... Done Building dependency tree        Reading state information... Done maas-provision is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
[17:41] <smoser> roaksoax_, have you poked at all at commissioning ipmi stuff
[17:41] <roaksoax_> smoser: yeah... was just waiting a way to commit that stuff to finish it
[17:42] <smoser> ?
[17:42] <smoser> can we chat here in 30  minutes?
[17:42] <roaksoax_> smoser: sure
[17:43] <platypusfriend> Has anyone been able to use maas-provision with 12.04.1?
[17:51] <roaksoax_> platypusfriend: precise's version of MAAS does not ship maas-provision
[17:51] <roaksoax_> platypusfriend: that's only in quantal
[17:51] <platypusfriend> aaahhh....
[17:51] <platypusfriend> ty
[22:26] <roaksoax> wq/win 12
[22:26] <roaksoax> bigjools: around already?
[22:27] <bigjools> roaksoax: it seems so
[22:27] <bigjools> twins woke up at $EARLY
[22:27] <roaksoax> bigjools: hehe sounds like fun
[22:27] <bigjools> not so much :)
[22:28] <roaksoax> :)
[22:28] <roaksoax> bigjools: so do you want to go over the packaging stuff?
[22:29] <bigjools> yes gimme 1 min
[22:35] <bigjools> roaksoax: ok let's, err, rock :)
[22:36] <roaksoax> bigjools: http://paste.ubuntu.com/1227561/
[22:36] <roaksoax> bigjools: ok so overall it is looking good
[22:37] <roaksoax> bigjools: now, if you see I've made a few changes. python-* should not really contain any binaries
[22:37] <roaksoax> nor config files
[22:37] <bigjools> yeah I figured there would be some of that
[22:37] <roaksoax> bigjools: now, celery...  where is it needed?
[22:38] <bigjools> cluster controller
[22:38] <bigjools> there's a wrapper that will start it up
[22:39] <roaksoax> bigjools: so maas-region-controller does not need it at all?
[22:39] <roaksoax> bigjools: nothing else needs the config?"
[22:39] <bigjools> nope
[22:41] <roaksoax> bigjools: so this changes like: http://paste.ubuntu.com/1227581/
[22:41] <bigjools> why did you make python-maas-provisioningserver conflict with python-django-maas?
[22:41] <roaksoax> bigjools: now, maas-dns is to be installed only on the region, on the cluster, or both?
[22:41] <bigjools> only region
[22:42] <roaksoax> bigjools: check the versions of conflict. Any lower than the current 1049
[22:42] <roaksoax> bigjools: the reason is becuase provisioning server used to be part of python-django-maas and for upgrades to work, we need that
[22:42] <bigjools> why does it need that?
[22:43] <bigjools> ok
[22:44] <roaksoax> ok so maas-dns is *only* on the region
[22:44] <bigjools> yup
[22:44] <bigjools> roaksoax: argh
[22:44] <bigjools> one small fly
[22:44] <roaksoax> what is it?
[22:44] <bigjools> the region controller does need a celeryd
[22:45] <bigjools> let me try and explain
[22:45] <bigjools> this is a little awkward and I'm not sure if it's the best way, but we have a concept of a "master" cluster
[22:45] <bigjools> where the worker also handles the dns jobs
[22:46] <bigjools> it needs to install appropriately
[22:46] <roaksoax> bigjools: right, so what's the difference?
[22:46] <bigjools> roaksoax: when it sets up the nodegroup it needs to have a special name
[22:47] <roaksoax> bigjools: where is this being set?
[22:47] <bigjools> so maas generate_dhcp_config
[22:47] <bigjools> which maas-dhcp calls right now
[22:47] <bigjools> even  if dhcp is not managed
[22:48] <roaksoax> bigjools: right, so my questions remains, who needs celery?
[22:48] <roaksoax> bigjools: python-maas-provisioningserver
[22:48] <roaksoax> i pressume
[22:49] <bigjools> roaksoax: clusters and the region controller then, sorry I was not clear
[22:49] <roaksoax> bigjools: right, but from the clusters and the region, who needs it exactly. Who needs the daemon running
[22:49] <bigjools> but there's a requirement for a cluster controller as a "master"
[22:49] <bigjools> which is on the region
[22:50] <bigjools> roaksoax: let me rewind a bit
[22:50] <bigjools> it's not a direct dependency of a region controller, but a region controller needs a master cluster controller somewhere, which needs celeryd
[22:50] <bigjools> make sense?
[22:51] <roaksoax> bigjools: yes, but my point being is this "maasserver/api.py" imports celery, and then, provisioningserver does
[22:51] <bigjools> roaksoax: so a region needs at least one cluster
[22:51] <bigjools> roaksoax: yes but the region doesn't run the daemon
[22:52] <roaksoax> bigjools: that's what I needed to know
[22:52] <roaksoax> bigjools: so cluster runs the daemon, both need python-celery
[22:52] <roaksoax> and both need celeryconfig right?
[22:52] <bigjools> roaksoax: yes
[22:53] <bigjools> roaksoax: however see bug https://bugs.launchpad.net/bugs/1056250
[22:53] <roaksoax> bigjools: ok so celeryconfig should go in a common package, i.e maas-common and the upstart job with the twisted daemon in maas-cluster-controller
[22:54] <bigjools> yes
[22:54] <bigjools> well the cluster is a little more complicated
[22:54] <bigjools> it needs to start two upstart jobs
[22:54] <bigjools> 1. the existing pserv twisted daemon
[22:54] <bigjools> 2. the new script that wraps celeryd
[22:54] <bigjools> I added the latter in this branch
[22:55] <roaksoax> what script?\
[22:56] <roaksoax> bigjools: ok so what else is common?
[22:57] <bigjools> maas-cluster-controller.maas-celery.upstart is the new upstart
[22:57] <roaksoax> ah ok
[22:57] <roaksoax> that's fine then
[22:57]  * bigjools thinks what else is common
[22:57] <roaksoax> so we only need the celeryconfig and maas_local_celeryconfig.py in a common package
[22:57] <bigjools> yeah this is what I thought could go in the provisioningserver package :)
[22:57] <bigjools> but you nixed that
[22:59] <roaksoax> bigjools: yeah python-xyz packages usually don't contain config files
[22:59] <roaksoax> at least i can't recall seeing one
[22:59] <bigjools> I learned something today
[23:00] <roaksoax> bigjools: ok, now DHCP only on cluster
[23:00] <roaksoax> right?
[23:01] <bigjools> yep
[23:01] <roaksoax> bigjools: now, rsyslog.d, where will it be?
[23:01] <bigjools> roaksoax: NFI!
[23:01] <bigjools> that one I didn't play with really, needed to talk about it
[23:01] <roaksoax> ok that's something to fiure out
[23:01] <bigjools> it's for syslog from the nodes right?
[23:01] <roaksoax> bigjools: now, preseeds?
[23:02] <roaksoax> bigjools: yes
[23:02] <bigjools> depends where we want the log to go then, region or cluster?
[23:02] <bigjools> logs*
[23:02] <roaksoax> bigjools: let's take care of other stuff first
[23:02]  * bigjools spins the quantal roulette wheel daily updates
[23:02] <bigjools> preseeds are on region only
[23:03] <roaksoax> bigjools: so the cluster will provide DHCP, tftp, right?
[23:03] <roaksoax> bigjools: hold on... so when a node boots with the cluste,r the cluster will tell him "here's your preseed in the REGION?"
[23:04] <bigjools> roaksoax: no, the cluster controller fetches them over the api
[23:04] <roaksoax> bigjools: ok, what about squid-deb-proxy?
[23:04] <roaksoax> region too?
[23:04] <bigjools> yeah
[23:04] <bigjools> that one's a bit horrible
[23:04] <roaksoax> ok so I guess syslog also makes sense to be in region for now
[23:04] <bigjools> it is not scalable
[23:05] <roaksoax> bigjools: well TBH, that's why mirrors are for :)
[23:08] <roaksoax> bigjools: now there's a problem
[23:08] <bigjools>  /o\
[23:08] <roaksoax> bigjools: the problem is that in packagin we modify the config files in order to set the settings we want automatically right?
[23:09] <roaksoax> bigjools: so everytime we upgrade, and the upstream config file differs from the installed one (pre-modification), it will prompt
[23:09] <roaksoax> the user
[23:09] <roaksoax> to upgrade it
[23:09] <bigjools> yeah
[23:09] <roaksoax> so we need to find a way to handle that gracefully
[23:09] <bigjools> and that is very very annoying
[23:10] <roaksoax> indeed
[23:10]  * bigjools stares at cups packaging
[23:10] <roaksoax> and annother annoring thing is dbconfig-common
[23:11] <roaksoax> bigjools: ok so thjis is what I've got so far: http://paste.ubuntu.com/1227614/
[23:11] <roaksoax> bigjools: it would be usefull to have this branch in ~maas-maintainers so I can alsocommit to it
[23:12] <bigjools> roaksoax: let me work something out
[23:12] <bigjools> roaksoax: alternatively I can merge your branch if you have a copy
[23:12] <bigjools> prob easier in the long run
[23:12] <roaksoax> bigjools: apply this patch so far :) http://paste.ubuntu.com/1227614/
[23:12] <roaksoax> take a look at it, and if you agree please merge it
[23:12] <bigjools> hax0ring without a branch? :)
[23:12] <bigjools> oik
[23:13] <bigjools> ok even
[23:15] <bigjools> roaksoax: ok changes pushed up, the diff will update soon
[23:15] <roaksoax> bigjools: what comes to my head is find a way to determine when it has changed upstream automatically, and when that happens, simply move the old config file, display a message, and reconfigure things
[23:16] <bigjools> roaksoax: should we just write the new config to the side and leave a message?
[23:16] <bigjools> let the user merge later
[23:16] <bigjools> Ideally we won't amend the *local* configs
[23:17] <roaksoax> bigjools: right, but pserv.yaml and txlongpoll.yaml have no local configs
[23:17] <bigjools> roaksoax: also see https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1055951
[23:17] <bigjools> yeah
[23:17] <roaksoax> bigjools: and maas_local_settings has changed quite frequently
[23:17] <bigjools> it has, until it settles down :)
[23:20] <roaksoax> bigjools: the fix for the bug above: https://code.launchpad.net/~andreserl/maas/packaging_update
[23:21] <roaksoax> https://code.launchpad.net/~andreserl/maas/packaging_update/+merge/126350
[23:21] <bigjools> roaksoax: that was quicj!
[23:21] <bigjools> roaksoax: can you set a commit msgt
[23:21] <bigjools> msg
[23:21] <roaksoax> :)
[23:22] <roaksoax> done
[23:22] <roaksoax> alright, i'm off
[23:22] <roaksoax> will probably be back later
[23:22] <bigjools> roaksoax: nice one, thanks.  One more problem is that of upgrading from 12.04
[23:22] <bigjools> the upgrade scripts are in maas-region-controller
[23:22] <bigjools> but will be checking unknown versions
[23:22] <bigjools> since they used to be in maas
[23:23] <bigjools> but we can chat when you get back
[23:25] <roaksoax> alrighty. Will talk about that later


[10:42] <BluesKaj> Hey folks
[10:55] <BuddyButterfly> hi, need some help repairing kubuntu.
[10:56] <BuddyButterfly> I have upgraded from a "big" trusty system to bionic.
[10:56] <BuddyButterfly> I knew it would not be without problems.
[10:56] <BuddyButterfly> I got so far that it is again usable to some state.
[10:56] <BuddyButterfly> Problem is that I am obviously missig some packages for kde.
[10:57] <BuddyButterfly> I tried reinstalling kde-full and also kubuntu-desktop. but it did not help with my problems.
[10:57] <BuddyButterfly> here they are:
[10:57] <BuddyButterfly> 1. I can not open system settings anymore. When I open them, the error messages is give that no view can be found and it exits.
[10:58] <BuddyButterfly> any idea what packages could be impacted? i tried reinstalling systemsettings with no success.
[11:06] <BuddyButterfly> second issue is that I am not able anymore to search for apps. I can type into the start menu, but nothing is selected.
[11:08] <BluesKaj> BuddyButterfly, try installing plasma-workspace and plasma-desktop
[11:08] <BuddyButterfly> BluesKaj: ok, will try... tnx for coming back.
[11:10] <BuddyButterfly> BluesKaj: do I have to re-login?
[11:10] <BluesKaj> no
[11:10] <BluesKaj> BuddyButterfly, you went from init to systemd, there are some major changes
[11:11] <BuddyButterfly> ah, ok. hmmm
[11:11] <BuddyButterfly> did not help. do you know how to force reinstall of all dependent packages?
[11:11] <BuddyButterfly> it seems to only reinstall the meta-package.
[11:12] <BluesKaj> getting dependency errors?
[11:16] <BluesKaj> BuddyButterfly, try running sudo dpkg --configure -a, then sudo apt -f install
[11:17] <BuddyButterfly> yep, did. everything fine.
[11:17] <BuddyButterfly> it seems like everything is installed fine.
[11:20] <BuddyButterfly> I am now reinstalling all rdepends on plasma-workspace...
[11:21] <BuddyButterfly> and then do the same for plasma-desktop.
[11:21] <BluesKaj> ok after that run sudo apt update && sudo apt upgrade, just to be sure your apps/packages up to date
[11:21] <BluesKaj> are
[11:22] <BuddyButterfly> BluesKaj: yes, will do. but I can tell you, i have done all of this hundred times ;-) I have the feeling that some packages are missig or corrupred during update.
[11:24] <BuddyButterfly> I will try to logoff and re-login...
[11:24] <BluesKaj> ok
[11:27] <BuddyButterfly> hmmm, did not help
[11:27] <BluesKaj>  a reboot will help if you want to chance it ...sooner or later with kernel upgrades etc it has to be done
[11:28] <BuddyButterfly> I have done all this. new kernel is installed, apt-get update shows no new update. only kde desktop is not working correctly.
[11:29] <BuddyButterfly> I have also tried to add a new user to get a fresh home dir. this helped in the first place to get the taskbar back. but with a new user it also does not show the systemsettings.
[11:29] <BluesKaj> ok, what's it doing or not doing
[11:29] <BuddyButterfly> the following is missing:
[11:30] <BuddyButterfly> 1. Context menu on backround does not exist.
[11:30] <BuddyButterfly> 2. App search does not work anymore. When starting typing, it clears the window but does not show any matching entries.
[11:31] <BluesKaj> BuddyButterfly, did you have active ppas in your sources before upgrading to Bionic
[11:31] <BuddyButterfly> 3. When trying to open system settings, it give error dialog saying that no view can be found so nothing can be displayed.
[11:31] <phoenix_firebrd> BuddyButterfly: why <IP_ADDRESS> build?
[11:32] <phoenix_firebrd> BluesKaj: ^
[11:32] <BuddyButterfly> BluesKaj: I am not entirely sure.
[11:32] <phoenix_firebrd> BuddyButterfly: sorry wrong nick
[11:33] <BuddyButterfly> BluesKaj: It could be the case. But it normally gets disabled. I have re-enabled them later.
[11:34] <BluesKaj> BuddyButterfly, look in /etc/apt/sources.list.d
[11:34] <BuddyButterfly> BluesKaj: yes, currently I have a lot of ppas.
[11:35] <BuddyButterfly> BluesKaj: hmm, I have http://ppa.launchpad.net/kubuntu-ppa/backports/ubuntu
[11:35] <BuddyButterfly> for bionic.
[11:35] <BuddyButterfly> could this maybe be wrong?
[11:35] <BluesKaj> BuddyButterfly, move them to a new folder teporarily , some won't apply to Bionic of course so they should be removed , but ppas like chrome etc should be ok
[11:36] <BuddyButterfly> BluesKaj: Ah, now I understand. I went through the ppas already and cleaned from every entry that does not have bionic. so all ppas left update and install fine.
[11:37] <phoenix_firebrd> <IP_ADDRESS> seems to be an upstream update
[11:38] <phoenix_firebrd> Plasma Discover in 5.12.5 was updated on 17 May 2018 with a <IP_ADDRESS> version. <IP_ADDRESS> ....
[11:38] <phoenix_firebrd> includes a fix for https://bugs.kde.org/show_bug.cgi?id=394048 'Software Centre Discover crashed three times out of three when searching for "latte" after hiting return'
[11:40] <BluesKaj> BuddyButterfly, yeah backports are fine
[11:41] <BluesKaj> think a reboot might help
[11:55] <BuddyButterfly> BluesKaj: could it be that for app search an idexer has to be ru?
[11:55] <BuddyButterfly> ru?
[11:55] <BuddyButterfly> run?
[11:55] <BuddyButterfly> sry, n key is not working....
[11:58] <BluesKaj> BuddyButterfly, yes but you have enable it in system settings>workspace>search
[11:58] <BuddyButterfly> lol :-)
[11:58] <BuddyButterfly> not easy if system settings are not working ;-)
[11:59] <BuddyButterfly> some command line way?
[12:00] <BuddyButterfly> is there a way to start systemsettings5 in debug mode?
[12:00] <BuddyButterfly> or verbose mode, or the like?
[12:04] <BluesKaj> BuddyButterfly, dbus-launch systemsettings5 in the konsole
[12:05] <BuddyButterfly> BluesKaj: comes up with same error but no output.
[12:06] <BluesKaj> try sudo
[12:06] <BuddyButterfly> BluesKaj: Aha! Now it comes up!!!
[12:06] <BluesKaj> ahh
[12:06] <BuddyButterfly> seems then to be some kind of rights issue....
[12:07] <BluesKaj> yup
[12:07] <BuddyButterfly> but where?
[12:07] <BuddyButterfly> BluesKaj: Cool, tnx for digging with me.
[12:08] <BluesKaj> i'm not well versed when it comes to permissions :/
[12:08] <BluesKaj> hey np
[13:20] <user|34888> wqd
[13:20] <user|34888> ?
[13:20] <user|34888> is anyone there?
[13:21] <BuddyButterfly> where?
[13:28] <BluesKaj> instant gratification and expectation must be terrible for those poor souls
[17:38] <klemax> whats the reason of freezing after logout?
[17:39] <klemax> is this related to the kde or Xorg ?
[18:30] <mohamednagy> How can I change the toolbar ?
[18:43] <danny_> icons?
[23:42] <TBotNik> All: On Kubuntu 16.04 LTS and cannot get my printer to install on CUPS.  Are Pantum 2500 on USB and Brother MFC 7360N on the LAN.  Downloaded the .deb files and installed but drivers never show in CUPS
[23:43] <TBotNik> Neither of the .deb installs produce the required .ppd file, but had installed correctly on 14.04
[23:54] <valorie> TBotNik: sounds like a "not really Kubuntu" problem, so I would ask in #ubuntu
[23:54] <valorie> much larger chan


[12:38] <ajmitch> so is hearing of it on irc
[12:39] <zul> heh..
[03:08] <kylem> BenC, ping
[03:08] <BenC> kylem: yo
[03:09] <kylem> heh, nm. figured it out.
[03:30] <kylem> just trying to make that ndiswrapper message slightly more informative
[03:31] <kylem> of course, figuring out what the possible return values of call_usermode_helper are is fun.
[04:06] <BenC> 2.6.20-1.1 is going to be a huge changelog
[04:06] <BenC> debian/rules printchanges | wc -l
[04:06] <BenC> 280
[04:11] <kylem> yow.
[04:13] <kylem> could just crop the upstream git section, heh.
[05:38] <fabbione> humpf
[05:38] <fabbione> git pull
[05:38] <fabbione> fatal: unexpected EOF
[05:38] <fabbione> Fetch failure: git://git.kernel.org/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git
[05:38] <fabbione> No changes.
[05:38] <fabbione> BenC, kylem: do you know why am I getting this error?
[06:53] <BenC> fabbione: Is this from an old edgy repo?
[06:53] <BenC> fabbione: If so, you need to re-clone the ubuntu-2.6 tree
[06:56] <fabbione> BenC: it's a clone i did 15 days ago.. but ok.. i will reclone. thx
[06:57] <fabbione> gotta feed the fattosaurus rex now :)
[07:01] <BenC> lol
[10:50] <dade`> the linux-source-2.6.19 package which versione of .19 contains ?
[10:50] <dade`> the "-0" one ?
[03:24] <mjg59> BenC: pm_prepare_console() has reappeared in kernel/power/*
[03:24] <mjg59> BenC: What happened to the patch that fixed that?
[06:27] <BenC> mjg59: There's a config option for it now...I'd have to check for it
[06:32] <mjg59> BenC: No, that's something different
[06:34] <BenC> this is the code that disables pm from mucking with the console on suspend/resume, right?
[06:34] <mjg59> Yes
[06:34] <BenC> I was sure something was added in mainline kernel for this when I moved to 2.6.19
[06:34] <mjg59> No, there are two chunks of code
[06:35] <mjg59> One controls whether messages get sent to the console (which is now a config message)
[06:35] <mjg59> And one controls whether the kernel does VT switching (which isn't)
[06:36] <BenC> So I need to re-add my config option for the vt switching
[06:36] <BenC> I'll try to get that pushed upstream during 2.6.20 too
[06:42] <mjg59> It would probably be better if it was run-time switchable in some way
[06:44] <BenC> I can do that too :)
[06:51] <Mithrandir> that'd be wonderful.
[06:51] <Mithrandir> I have graphical suspend and resume working, sans that small bug, which you can *cough* work around by sending a SAK.
[06:53] <makx> nice
[06:54] <Mithrandir> s/suspend/hibernate/, really.
[06:56] <mjg59> Mithrandir: Did you make any changes to usplash?
[06:56] <mjg59> If not, I'm not sure how you handled the password stuff
[06:57] <Mithrandir> mjg59: I ignored it, but I think I can work around it by writing a shim in uswsusp
[06:58] <Mithrandir> given that usplash supports input now
[06:58] <Mithrandir> usplash needs a few more bits exposed in the API too, iirc.
[06:58] <mjg59> I think it's trivial to do by just refactoring the input code in usplash
[06:58] <mjg59> I wrote that earlier, I'll push it now
[06:59] <Mithrandir> ok
[06:59] <Mithrandir> do we have bzr imports of suspend-cvs?
[07:00] <mjg59> Dunno
[07:01] <mjg59> Gah. What's the bzr foo to recover a file I accidently deleted?
[07:02] <mjg59> Ah, I can just cat it
[07:02] <Mithrandir> bzr revert foo, I'd think
[07:02] <mjg59> Ah, yes, that would also work
[07:04] <mjg59> Mithrandir: Pull latest code, then usplash_get_string
[07:20] <makx> hmm are there images for netboot.tar.gz?
[07:20] <makx> s/images/mirrors #uups
[09:40] <dade`> BenC: are you here ?
[11:12] <dade`> wow if i change the preempt method the kernel recompiles everything
[11:13] <BenC> yeah, things like preempt are pretty extensive


[04:54] <mborzecki> morning
[04:55] <mborzecki> morning
[04:59] <mardy> mborzecki: hi!
[05:00] <mborzecki> mardy: heya
[05:01] <mborzecki> mardy: have you figured out that mount control interface?
[05:22] <wez> Hi, does snappy plan on moving away from squashfs at some point?  My CPU and CPU fan would appreciate it.
[05:45] <mardy> mborzecki: the only question left is why we accept a list of types for the mount, rather than a single type. But it's a detail, not blocking me
[05:46] <mborzecki> wez: not that i'm aware of, but different compression methods are in use, lzo iirc which should be much more cpu friendly
[05:49] <mardy> wez: you might find this relevant: https://forum.snapcraft.io/t/squashfs-performance-effect-on-snap-startup-time/13920
[06:39] <pedronis> I need to re-review this but it also needs other reviews https://github.com/snapcore/snapd/pull/10420
[07:07] <pstolowski> morning
[07:09] <mborzecki> pstolowski: hey
[07:10] <mvo> good morning pstolowski, mborzecki and pedronis
[07:10] <mborzecki> pedronis: and good morning to you too
[07:11] <wez> mborzecki, mardy: Thank you both!
[07:12] <mborzecki> mvo: hey, thanks for landing that PR
[07:20] <mardy> from 1 to 10, how horrible would it be if from interfraces/buildin/mount-control.go I called the resolveSpecialVariable() function defined in content.go? :-)
[07:20] <zyga-mbp> good morning
[07:20] <zyga-mbp> mardy: hmmm
[07:20] <mvo> good morning mardy and zyga-mbp
[07:21] <zyga-mbp> mardy: there are two functions like that and I don't think they are exactly the same (unfortunately)
[07:21] <mardy> for the time being I'll just replicate the method with another name, and then -- if confirmed that I really need it -- I can move it to another file and share it across the two interfaces
[07:21] <mardy> hi zyga-mbp, mvo
[07:21] <zyga-mbp> mardy: I'm sick today so my memory is rusty but IIRC they don't allow the exact same things
[07:21] <zyga-mbp> but give it a try and ping me for a review, I'll gladly look
[07:22] <mardy> zyga-mbp: currently there's just one function, it's resolveSpecialVariable() in content.go. Now I'm writing a new interface (mount-control), and I think I could use the same function
[07:22] <zyga-mbp> mardy: there's another function that looks and feels like resolve special variable
[07:22] <zyga-mbp> I really don't remember where but there are two
[07:23] <zyga-mbp> mvo: hey :)
[07:25] <pedronis> mvo: do I misremember:  https://github.com/snapcore/snapd/pull/10449#discussion_r661199310 ?
[07:35] <mardy> mvo: I think you once mentioned that protecting filesystem resources via chroot and namespaces is insecured as it can be trivially bypassed; that only applies if plain chroot() is used, right? Or is pivot_root unsecure too?
[07:36] <mardy> (it's not related to what I'm working on, it's just a curiosity)
[07:36] <mvo> pedronis: I think you are right, was mostly wondering what we should do for corner cases like a pi that has no config.txt for some reason and someone sets pi-config.some-option=1. but otoh I'm not even sure a system without config.txt will even boot
[07:36] <mborzecki> mardy: you want pivot_root, chroot can be trivially bypassed
[07:36] <zyga-mbp> mardy: pivot_root breaks apparmor if you think about it
[07:37] <zyga-mbp> mardy: chroot is IIRC now unprivileged and doesn't really buy much security
[07:37] <mborzecki> `sshpass -p ubuntu ssh -p 8022 -o ConnectTimeout=10 -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no user1@localhost date -d tomorrow "+%Y-%m-%d %T"` hmm gives `date: extra operand ‘%T’`
[07:37] <mborzecki> but `sshpass -p ubuntu ssh -p 8022 -o ConnectTimeout=10 -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no user1@localhost sh -c 'date -d tomorrow "+%Y-%m-%d %T"'` works as expected
[07:38] <mborzecki> oh how i hate shell quoting
[07:40] <mvo> mardy: not sure I said this about namespacing, but definitely about chroot. let me quickly look at pivot_root
[07:41] <mborzecki> hm nope, still broken
[07:41] <zyga-mbp> mvo: pivot_root affects apparmor path resolution
[07:42] <zyga-mbp> mvo: if you can mount and pivot_root you can break out of the sandbox
[07:43] <mborzecki> hmm hmm, so passing parameters with spaces to nested_exec is broken
[07:43] <mborzecki> and that's because sshpass appears to do the wrong thing
[07:48] <mborzecki> oh well, i'm just dump
[07:48] <mborzecki> dumb
[07:54] <mardy> zyga-mbp: you mean, one could mount a partition like /dev/sda1 and the re-pivot to that, or something else? If one does not expose /dev/sd* (and other block devices) to the chroot, would you still be able to escape?
[07:55] <zyga-mbp> mardy: so first of all, the apparmor profile allows you do do certain things
[07:55] <zyga-mbp> but all that is based on paths
[07:55] <zyga-mbp> pivot_root lets you create arbitrary new place that apparmor thinks is /
[07:55] <zyga-mbp> so if we allow you do do anything in $SNAP_DATA
[07:55] <zyga-mbp> you can put the entire system in $SNAP_DATA
[07:55] <zyga-mbp> and then modify snapd state.json
[07:55] <zyga-mbp> and that's it
[07:56] <zyga-mbp> as for your question
[07:56] <zyga-mbp> again, it all depends
[07:56] <zyga-mbp> if there's a way for you to mount a block device all hope is lost
[07:56] <zyga-mbp> all snaps see device nodes in /dev
[07:57] <zyga-mbp> if apparmor was not blocking mounts, you'd be able to break out easily
[07:57] <zyga-mbp> I'm not sure exactly how powerful you want mount-control to be
[07:57] <zyga-mbp> there are ranges of options here
[07:57] <zyga-mbp> from super-privileged to mildly privileted
[07:57] <zyga-mbp> *privileged
[07:57] <mardy> zyga-mbp: my concern is about distros where we don't have apparmor; would security there be improved, if we setup a chroot (with pivot_root) and didn't mount /dev/ block devices into that?
[07:57] <zyga-mbp> there are now interesting ways to do mount mediation
[07:58] <zyga-mbp> lxd is using some of that
[07:58] <zyga-mbp> mardy: no
[07:58] <zyga-mbp> mardy: without apparmor the sandbox is entirely ineffective today
[07:59] <zyga-mbp> mardy: you can just spin up a service that runs as root, talk to udisks and ask it to mount whatever you want
[07:59] <zyga-mbp> mardy: this is just a random example, I'm sure there are countless other attacks that entirely break out of the sandbox
[08:00] <zyga-mbp> mardy: I mean, without apparmor you can just go to hostfs and modify /boot
[08:00] <zyga-mbp> or drop a new systemd unit
[08:00] <zyga-mbp> or whatever
[08:00] <mardy> zyga-mbp: right, but then udisks itself is a rather privileged interface, I guess?
[08:00] <zyga-mbp> mardy: without apparmor, there is no control over what dbus traffic is allowed
[08:00] <zyga-mbp> mardy: on a Fedora system or on a Debian system where dbus is not mediated by apparmor, you can break out instantly
[08:06] <pedronis> zyga-mbp: mount-control will be superprivileged, also like system-files it will have allow lists about device and mountpoints
[08:07] <zyga-mbp> pedronis: for a super-privileged interface things are easier
[08:07] <zyga-mbp> if the interface also comes with a list of what is effectively allowed
[08:07] <zyga-mbp> you can synthesize the apparmor profile that captures that
[08:07] <zyga-mbp> there's one complexity though
[08:08] <zyga-mbp> we don't have any logic that would react to the snap performing some mounts in arbitrary places
[08:08] <zyga-mbp> and the mount profile being updapted
[08:08] <zyga-mbp> it's likely that a mount performed by the snap itself
[08:08] <zyga-mbp> will either be undone by any mount changes done by snap-update-ns (and those can happen just because some other snap refreshes)
[08:08] <zyga-mbp> or worse, snap-update-ns can fail, leaving the mount namespace of that snap in a corrupted state
[08:09] <pedronis> I understand but the main use case is actually super privileged, is about mounts int the host, not even the snap namespace
[08:10] <pedronis> anyway another reason to have a allow list, I would expect some mounts to make no sense, or be very fragile because of the namespace
[08:12] <zyga-mbp> pedronis: can you give me an example of what might be mounted?
[08:13] <zyga-mbp> I'm asking because there's one more special bit that is relevant here
[08:13] <zyga-mbp> propagation settins
[08:13] <zyga-mbp> *settings
[08:13] <zyga-mbp> currently snaps cannot technically mount anything that would show up on the host, except for the /mnt directoy
[08:14] <zyga-mbp> to be clear: if a snap is allowed to do any mounts, and then mounts something on the host's /foo/bar, then that will not be really visible on the host's default mount namespace
[08:14] <pedronis> zyga-mbp: we will do also persistent mounts on behalf of snaps, via snapctl likely as there isn't thing that we can easily mediate that allows for that
[08:14] <zyga-mbp> because that mount event will not reach the hosts default mount namespace
[08:14] <zyga-mbp> pedronis: we could do the same thing that lxd is doing, seccomp based mount mediation
[08:15] <pedronis> I said persistent, I mean fstab or mount units
[08:15] <zyga-mbp> mardy: do you know about how snap-confine sets up /mnt or /media for mount event propagation?
[08:15] <zyga-mbp> pedronis: I see
[08:15] <zyga-mbp> so the actual mount would happen on the host
[08:15] <zyga-mbp> not in the snap
[08:15] <zyga-mbp> (mount namespace)
[08:15] <pedronis> sometimes yes
[08:18] <zyga-mbp> pedronis those are probably least problematic then
[08:18] <zyga-mbp> since they can only affect hostfs and not what snap-update-ns does
[08:21] <mborzecki> heh, opensuse TW has ssh configuration in /usr/etc/ now
[08:22] <mborzecki> the /etc/ssh/ directory is almost empty, definitely there's no ssh_config there
[08:23] <pedronis> zyga-mbp: afaict only /media (and /run/netns) are setup bidirectional in snap-confine, /mnt isn't
[08:32] <zyga-mbp> mborzecki: WAT? /usr/etc?
[08:32] <mborzecki> zyga-mbp: yeah, see https://build.opensuse.org/request/show/888799
[08:32] <mborzecki> zyga-mbp: they went through /usr/share/ssh at first ;)
[08:32] <zyga-mbp> pedronis: my memory may have been rusty
[08:33] <zyga-mbp> pedronis: you are right, and there's also /run/media depending on distro
[08:33] <zyga-mbp> mborzecki is that a FHS compliant location
[08:34] <mborzecki> hm idk, /usr/local/etc would be, but not quite sure about /usr/etc
[08:34] <mborzecki> not that i care much either
[08:36] <mborzecki> zyga-mbp: and tbh with immutable hosts, i'm not sure people care that much about it still
[08:36] <zyga-mbp> mborzecki: yeah but remember the /snap drama
[08:36] <zyga-mbp> oh my they said
[08:37] <mborzecki> well, i guess it depends on who makes the change ;)
[08:53] <mborzecki> the preseed spread test is failing now that lxd switched to core20
[09:02] <pedronis> mborzecki: didn't you just merge the fix for that?
[09:03] <mborzecki> pedronis: yeah, was about to fix that when i found a pr from sergio that was ready to land
[09:04] <pedronis> mborzecki: I merged your cgroup.freeze PR
[09:04] <mborzecki> pedronis: thanks!
[09:53] <mborzecki> pedronis: i think i've found a bug, the seed system that gets created has the old model, even though the right assertion seems to be passed around
[09:54] <mborzecki> pedronis: seedwriter fetches the model from the db?
[09:55] <mborzecki> so if the new model is just a revision bump, and isn't passed to the db, it will get the old one?
[10:23] <pedronis> mborzecki: it depends what db is used, the db used for the create from current probably doesn't make sense for the remodel case
[10:23] <mborzecki> pedronis: yeah, that's the one that is used
[10:27] <pedronis> mborzecki: there's probably a couple of ways to fix this, I'm having my lunch break. We can chat quickly after the standup?
[10:27] <mborzecki> pedronis: hm i think i can create one through WithStackedBackstore() ?
[10:27] <mborzecki> pedronis: sure, enjoy your lunch
[10:27] <pedronis> mborzecki: yes, that's one of the possible options to fix this
[10:42] <mardy> zyga-mbp: nope, I haven't digged into snap-confine yet
[11:09] <pstolowski> pedronis: i've proposed refresh control spread test - https://github.com/snapcore/snapd/pull/10476 - as well as a simple bugfix in the prerequisite pr
[11:11] <pedronis> pstolowski: thx,  I think I mentioned this already, but I reviewed the wait-chain PRs
[11:11] <pstolowski> pedronis: yes, thanks, i'm updating them right now
[11:13] <pedronis> pstolowski: I'm starting something, I'll look at the simple fix in a bit
[11:17] <pstolowski> sure, ty
[11:43] <mborzecki> pedronis: opened a proposal: https://github.com/snapcore/snapd/pull/10477
[11:48] <mardy> I'm creating a snap using snap pack, and I want to run mount(8) in it. I copied its dependencies to the snap, properly set LD_LIBRARY_PATH, but I get a segfault inside libc when running it. Any idea on what I could be doing wrong?
[11:52] <mborzecki> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/10477 ?
[11:52] <pstolowski> mborzecki: sure
[11:52] <mborzecki> mardy: snap run --strace or snap run --gdbserver
[11:53] <mborzecki> unless the backtrace is already useful :)
[11:53] <mvo> mardy: does it have to be "mount(8)" or could you simply use the mount binary? did you try to link statically?
[11:54] <mborzecki> tbh segfault is a bit unexpected, it'd expect it to fail gracefully
[11:54] <mborzecki> as in `cannot mount because reasons` & non 0 exit
[11:58] <mardy> mborzecki: [pid 187371] mprotect(0x7f606bed1000, 4096, PROT_READ) = 0
[11:58] <mardy> [pid 187371] mprotect(0x7f606c110000, 16384, PROT_READ) = 0
[11:58] <mardy> [pid 187371] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xe} ---
[11:58] <mardy> mvo: I was just being lazy and did not want to build a binary myself, so I wanted to use a shell script for testing
[11:59] <mardy> it's not only mount that it's segfaulting, also "grep" gets terminated in the same way
[12:00] <mborzecki> mardy: hmm looks like some callback through a function pointer in a structure, that address is very low
[12:00] <mborzecki> probably gdb would be more useful if you want to try it (and explote the tooling at the same time)
[12:08] <pstolowski> mborzecki: a simple one https://github.com/snapcore/snapd/pull/10461
[12:09] <mborzecki> pstolowski: sure
[12:13] <mardy> mborzecki: nice! But it does not help much, I see the same 0xe address in the backtrace, and not much else:
[12:14] <mardy> #0  0x000000000000000e in ?? ()
[12:14] <mardy> #1  0x00007f7c9e180119 in ?? ()
[12:14] <mardy> #2  0x0000000000000000 in ?? ()
[12:14] <mborzecki> mardy: hm try running `set sysroot /snap/<your-base>/<revision>` and then `set solib-search-path /snap/<your-base>/<revision>/<usual lib dirs>`
[12:33] <mborzecki> pedronis: so you're saying this should be taken care of in the fetcher we pass to seedwriter?
[12:34] <mardy> mborzecki: didn't help. I guess I'll have to drop "snap pack" and use snapcraft instead
[12:51] <pedronis> mborzecki: I commented a bit more
[12:52] <mborzecki> pedronis: ah, ok, that is clear now
[14:05] <pedronis> degville: this is the phrasing confusion issue I mentioned in the standup: https://github.com/snapcore/snapd/pull/10478/files#r661506853
[14:06] <degville> pedronis: thanks. Taking a look now.
[14:10] <pstolowski> thanks
[14:27] <mardy> I moved to python now, and I'm getting another weirdness :-) If I print the python version by running the program directly (without snappy), I get: 3.8.5 (default, May 27 2021, 13:30:53)
[14:27] <mardy> but when I run the snap (just built with "snap pack"), I get 3.5.2 (default, Jan 26 2021, 13:30:48)
[14:28] <pstolowski> cachio__: can you take a look at https://github.com/snapcore/snapd/pull/10470 ?
[14:28] <mardy> there's no python inside the snap, so where is it finding version 3.5.2 from?
[14:29] <cachio__> pstolowski, sure
[14:32] <pstolowski> need 2nd review for a simple bugfix: https://github.com/snapcore/snapd/pull/10475
[15:28]  * cachio__ lunch
[16:18] <mvo> pedronis: is 10449 something you want to have a final look over or are you okay with the reviews it has?
[16:18] <mvo> pedronis: the "# snap-edit: no" header PR
[17:17] <jdstrand> I haven't read all backscroll, but note that the seccomp backend mediates mount and the device cgroup mediates a lot of what is in /dev (I say a lot because there is some interplay with apparmor, but apparmor relies on the device cgroup currently for hotpluggable things, etc to avoid a policy recomplile in the udev helper)
[17:18] <jdstrand> we could choose to enable those backends on systems without apparmor. we've not historically since, as mentioned, things like dbus could allow breakout (eg, udisks)
[17:20] <jdstrand> since we wouldn't want to make security claims, we've historically chosen to not enable all the available backends since that would complicate testing and support due to combinatorics
[17:21] <jdstrand> (all the available backends on non-strict systems like Fedora or Debian). That said, Debian should be getting close. talk to amurray (or jj) for status
[17:22] <jdstrand> we did do it for tumbleweed. I can't recall if we did it anywhere else...
[17:26] <jdstrand> as for a snap helper to facilitate mounts, that seems quite reasonable, easy to mediate from within the helper and something that could be done on any kernel
[17:40] <sergiusens> jdstrand hey there! just to add to your list, Manjaro should also be using strict confinement these days
[17:40] <sergiusens> mardy your python 3.5.2 probably comes from the base snap (core I believe), set snap.yaml to base: core18|20 for a newer python :-)
[17:42] <sergiusens> mardy or run `python3 -c "import sys; print(sys.executable)"` to find out where python comes from :-)
[22:48] <jdstrand> sergiusens: hi! oh yes, manjaro has been there for a while. there is a list that I did in the forum at some point


[00:29] <habys> hey folks, if I'm adding a local repo key via the `user-data` file, it seems to put the keys in /etc/apt/trusted.gpg, which breaks running `apt update` with `curtin in-target`. Is this a known issue?
[00:30] <habys> seems like the work around is to add the keys manually and not use the `sources: source/key' section of `user-data`
[00:30] <habys> just curious if anyone else is running into this
[00:43] <habys> oh hey, I just saw there is a #cloud-init channel, I'm going to ask there, maybe that channel is a better match
[00:47] <sarnold> this isn't a wrong place, but perhaps it'll be less likely to be overlooked there, yeah
[00:50] <habys> I'm still trying to figure out the parts of the installer, so thanks for patience. I've gotta set up network booting for jammy server and desktop.
[00:51] <habys> I've got server pretty well handled, just trying to clean up some rough edges, desktop.. I'm trying to just use my same server ipxe config but install the `ubuntu-desktop` package at the end.. Not sure if that's crazy, but anyone has a better idea, I'd be much obliged
[01:00] <sarnold> alas I've done very little install automation :(
[01:12] <habys> no worries, I'm reading examples, and code, and slowly making progress
[01:12] <habys> I did see most people are using NFS to set up desktop, and I'm going to avoid it if I can
[05:20] <alkisg> habys: not sure I understood correctly, but if you're looking to netboot ubuntu server/desktop (not just the installer), have a look at ltsp.org
[11:24] <habys> I have a server that allows machines to install ubuntu over the network. I was able to get ubuntu-server working pretty well with some rough edges, but I am failing to make a pxe target that installs ubuntu-desktop.
[11:26] <habys> In the process of getting a working network install target of ubuntu-desktop my biggest hurdle is when there is an issue with my `user-data` file, the installer will crash. I will see this: https://termbin.com/rgfj and when I read the extremely long error log (in this case: /var/crash/167...install_fail.crash) it appears to provide no insight into what caused the install to crash.
[11:58] <Guest3335> Hello. Does somebody know: how to move data folder in wasabi wallet? I want to keep my wallets on SSD. I use Ubuntu 22.04.01 LTS. Wasabi <IP_ADDRESS> for Ubuntu
[13:19] <tomreyn> Guest3335: that's a desktop application from what i read - then #ubuntu would be the better place to ask. but you'll probably be better off asking at https://github.com/zkSNACKs/WalletWasabi/discussions/categories/support
[13:20] <tomreyn> or here https://github.com/zkSNACKs/WalletWasabi/discussions/5185
[16:15] <Liver_K> Why isn't the bug report platform in the topic here?
[16:30] <ogra> Liver_K, the "bugreport platform" is: "ubuntu-bug <packagename>"  in all *buntus ...
[16:33] <Liver_K> I was taking about launchpad
[16:34] <ogra> that is where ubuntu-bug ends up filing your bug ...
[18:53] <Liver_K> But you can also report them right on launchpad right?
[18:53] <sarnold> yeah
[20:09] <Odd_Bloke> ubuntu-advantage-client is giving me a conffile prompt on upgrade because I opted out of the apt spam it produces. >.<
[20:11] <sarnold> argh
[20:19] <Odd_Bloke> https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/2003977
[20:19] -ubottu:#ubuntu-server- Launchpad bug 2003977 in ubuntu-advantage-tools (Ubuntu) "Disabling apt spam results in a conffile prompt on upgrade" [Undecided, New]
[20:20] <sarnold> thanks
[20:25] <Odd_Bloke> Nothing says "buy our trustworthy support" like breaking people's upgrades to troll /r/linux.
[20:27] <ogra> the diff doesnt really look like it is the prompt switch alone causing the conffile prompt though ...
[20:30] <sarnold> I haven't actually looked at this package yet, but the Usual Pattern is to check an md5sum of a config file and if it's different, prompt about it; otherwise just replace it
[20:31] <sarnold> so all the spelling changes and line reorders and so on might not have been a big deal for the people who left it alone
[20:31] <sarnold> but if you do change the file, now you get all the random housekeeping changes to deal with, too
[20:33] <Odd_Bloke> Yeah, you can't infer that it would or wouldn't have been a clean upgrade from that diff.
[20:34] <JanC> there are ways to fix that with extra files for local overrides, of course...
[20:35] <JanC> (or just make the package removable, as suggested...)
[20:35] <sarnold> I'm sure i suggest The Systemd Config File Layout to someone every three months, give or take :)
[20:35] <sarnold> for as much as I grumble about systemd, some things are just worth the complexity
[20:36] <JanC> there are many ways to do it really: include something in /etc/default/, have a /etc/*.d/ config directory, etc.
[20:37] <JanC> or have the default config somewhere under /usr/
[20:40] <JanC> all of them depend on having multiple files  :)
[20:41] <JanC> in theory you could probably use 1 file and some more intelligent way to compare/merge them than an md5 sum & replace  :)
[20:41] <JanC> & replace-the-whole-file