| === chihchun_afk is now known as chihchun | ||
| mup | PR snapcraft#1765 opened: store: refactor acquirement of attenuated macaroon <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1765> | 00:41 |
|---|---|---|
| mup | PR snapd#4307 opened: Fix for issues when snad service is canceled and cleanup for snaps <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4307> | 05:17 |
| mborzecki | morning | 06:02 |
| zyga-ubuntu | good morning | 07:01 |
| mborzecki | zyga-ubuntu: hey | 07:18 |
| mborzecki | zyga-ubuntu: how's your daughter? better? | 07:19 |
| zyga-ubuntu | mborzecki: yeah, she's better but will stay one more day at home | 07:22 |
| zyga-ubuntu | mborzecki: but hopefully I won't have to spend most of my time next to her as she will not (hopefully) stay in bed all day | 07:23 |
| mup | PR snapd#4308 opened: packaging/arch: install snap-mgmt tool <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4308> | 07:40 |
| zyga-ubuntu | mborzecki: reviewed | 07:54 |
| mborzecki | thanks | 07:54 |
| zyga-ubuntu | pstolowski: hey | 08:20 |
| pstolowski | zyga-ubuntu, morning! | 08:21 |
| zyga-ubuntu | pstolowski: I looked at 4303 and it seems to be really failing | 08:21 |
| pstolowski | zyga-ubuntu, indeed, thanks for heads up, will check | 08:29 |
| === __chip__ is now known as Chipaca | ||
| Chipaca | moin moin | 09:25 |
| pedronis | Chipaca: hello | 09:27 |
| mvo | hey Chipaca, good morning and good morning to pedronis | 09:27 |
| Chipaca | pedronis: mvo: hiya :-) | 09:27 |
| Chipaca | what's on fire? | 09:28 |
| mvo | Chipaca: surprisingly little this morning | 09:28 |
| mvo | Chipaca: the 2.30 branching is immanent but thats hardly a fire :) | 09:28 |
| Chipaca | mvo: unless you mean 2.30 branching pervades the universe, i think you mean it's imminent | 09:29 |
| pedronis | mvo: we still have some PRs open for 2.30 right? | 09:29 |
| Chipaca | snapd is imanent \o/ nothing more for us to do | 09:30 |
| Chipaca | immanent* | 09:30 |
| Chipaca | silly english | 09:30 |
| pedronis | s/IOT/immanent computing/ | 09:31 |
| mvo | Chipaca: haha, indeed, sorry. ENEEDMORETEA | 09:31 |
| mvo | pedronis: yes, we are still waiting for those | 09:31 |
| zyga-ubuntu | Chipaca: hey | 09:36 |
| Chipaca | zyga-ubuntu: hiya :) | 09:39 |
| Chipaca | can anyone see what went wrong in the spread run of #4299? It seems to have just stopped mid-dance | 09:45 |
| mup | PR #4299: osutil/user: replace our uses of os/user and filepath.Glob("/home/*") <Created by chipaca> <https://github.com/snapcore/snapd/pull/4299> | 09:45 |
| mvo | Chipaca: yeah, confusing | 09:46 |
| Chipaca | mvo: #1734845 sounds like fun | 09:50 |
| mup | Bug #1734845: hook (core) configure → exit status 1 cannot create lock directory /run/snapd/lock → Permission denied <snapd (Ubuntu):New> <https://launchpad.net/bugs/1734845> | 09:50 |
| ogra_ | pedronis, where does the firstboot key generation exactly live again ? could you point mvo to it in 4304 ? | 09:51 |
| pedronis | overlord/devicestate/crypto.go using ssh-keygen | 09:52 |
| pedronis | nothing to do with gnupg | 09:53 |
| ogra_ | eek ... damn | 09:55 |
| ogra_ | mvo, sorry for the noise ... | 09:55 |
| ogra_ | i thought we also generate gpg keys there | 09:56 |
| pedronis | so we need openssh-client | 09:58 |
| ogra_ | yeah | 09:58 |
| ogra_ | but 4304 is about dropping gnupg only ... so thats fine | 09:59 |
| pedronis | that's used only for snap *-key commands | 10:00 |
| pedronis | and the corresponding snapcraft ones | 10:00 |
| ogra_ | yeah | 10:00 |
| mvo | ogra_: no worries, that was my understanding that we don't need it but it does not hurt to double check | 10:01 |
| ogra_ | true indeed | 10:01 |
| Chipaca | oooh, bug | 10:10 |
| Chipaca | pedronis: I like the idea of making Init more Mock-like more and more | 10:17 |
| Chipaca | pedronis: would a bare Mock be alright? | 10:17 |
| pedronis | taking nothing? | 10:17 |
| Chipaca | pedronis: taking nothing, but returning a restorer func | 10:17 |
| Chipaca | pedronis: otherwise every test that calls this would leave the system in a weird state after | 10:18 |
| pedronis | ah | 10:18 |
| pedronis | then yes | 10:18 |
| pedronis | you probably want a function that does the init bit alone though | 10:18 |
| pedronis | to call from init() | 10:18 |
| Chipaca | or viceversa | 10:18 |
| Chipaca | i could call init by hand from the mock :-) | 10:18 |
| Chipaca | zyga-ubuntu: if you have a bunch of distros hanging around, could you do a login.defs zoo? | 10:21 |
| zyga-ubuntu | Chipaca: haha, sure | 10:23 |
| zyga-ubuntu | Chipaca: I never looked at that file | 10:23 |
| Chipaca | zyga-ubuntu: also: man subuid | 10:23 |
| zyga-ubuntu | Chipaca: what's interesting about it? | 10:23 |
| Chipaca | zyga-ubuntu: for osutil/user, SYS_UID_MAX | 10:24 |
| Chipaca | i didn't know about subordinate uids | 10:26 |
| pedronis | Chipaca: I don't think you can call init functions, they are special | 10:35 |
| pedronis | you can have many of them, but not call them | 10:35 |
| Chipaca | pedronis: I'll call it innit then | 10:35 |
| Chipaca | :-) | 10:35 |
| Chipaca | zyga-ubuntu: I don't need the login.defs zoo, fwiw -- i'm reading the file directly | 11:01 |
| zyga-ubuntu | brb | 11:07 |
| mup | PR snapd#4309 opened: snap: fix TestDirAndFileMethods() test to work with gccgo <Created by mvo5> <https://github.com/snapcore/snapd/pull/4309> | 11:08 |
| zyga-ubuntu | mvo: that's weird | 11:11 |
| pedronis | mvo: do we need more special casing now that we are removing configure-snapd to make it so, that snap set core works also before there's core at all ? | 11:20 |
| mvo | zyga-ubuntu: yes it is - gccgo | 11:30 |
| mvo | pedronis: maybe, I need to look | 11:30 |
| pedronis | mvo: we do | 11:31 |
| mvo | pedronis: thank you | 11:35 |
| pedronis | mvo: is not easy to have no core snap in a spread test, right? unless it has its own prepare sequence? | 12:04 |
| zyga-ubuntu | pedronis: I think so, though some tests just purge snapd | 12:04 |
| pedronis | ah | 12:04 |
| zyga-ubuntu | pedronis: I'd like to fix some things and change the prepare/restore code so that each test automatically installs snapd and starts from a clean slate otherwise | 12:05 |
| zyga-ubuntu | pedronis: (the fixes would involve making that operation very cheap) | 12:05 |
| zyga-ubuntu | pedronis: IMO the prepare/restore code is a bit complex today and optimizes for time rather than clarity while we can have both | 12:05 |
| pedronis | anyway I just need some expedient for today, and now I see indeed some tests start purging snapd | 12:09 |
| mvo | pedronis: yeah, purging is probably the easiest, or just rm -f /var/lib/snapd/state.json if you need to simulate an empty state | 12:17 |
| === chihchun is now known as chihchun_afk | ||
| simosx | there is a source code repository (plugin: qmake) that does not implement "make install". How would I pick up the executable in order to move it in the snap? | 12:38 |
| jdstrand | sergiusens: hey, is 'SNAPCRAFT_BUILD_INFO=1 snapcraft cleanbuild' supposd to work? (ie, SNAPCRAFT_BUILD_INFO with cleanbuild) | 12:43 |
| mup | PR snapcraft#1766 opened: Enhanced fake store to detect that metadata can't be pushed prior to pushing the binary, and fixed the test <Created by facundobatista> <https://github.com/snapcore/snapcraft/pull/1766> | 12:44 |
| jdstrand | sergiusens: I have 2.34+17.10 and I don't see a build artifact | 12:44 |
| jdstrand | (maybe I am looking in the wrong place?) | 12:44 |
| sergiusens | jdstrand it is inside the snap, under the `snap` directory | 12:45 |
| jdstrand | sergiusens: yeah. that is where I looked | 12:47 |
| jdstrand | not there | 12:47 |
| zyga-ubuntu | jdstrand: hey, | 12:47 |
| jdstrand | hey zyga-ubuntu :) | 12:47 |
| zyga-ubuntu | jdstrand: do you have some time, I made updates to https://github.com/snapcore/snapd/pull/4224 | 12:47 |
| mup | PR #4224: cmd/snap-update-ns: teach update logic to handle synthetic changes <Created by zyga> <https://github.com/snapcore/snapd/pull/4224> | 12:47 |
| zyga-ubuntu | jdstrand: just comment changes + one function rename | 12:47 |
| zyga-ubuntu | jdstrand: there's also one other PR that waits for your review: https://github.com/snapcore/snapd/pull/4140 a new interface | 12:48 |
| mup | PR #4140: interfaces: add an interface for gnome-online-accounts D-Bus service <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4140> | 12:48 |
| zyga-ubuntu | jdstrand: and lastly you have some feedback on https://github.com/snapcore/snapd/pull/4100 that looks like low hanging fruit, maybe something I can help with? | 12:48 |
| mup | PR #4100: add ssh-keys, ssh-public-keys, gpg-keys and gpg-public keys interfaces <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4100> | 12:48 |
| jdstrand | zyga-ubuntu: all are on my list for this week (I mentioned this yesterday) | 12:48 |
| jdstrand | zyga-ubuntu: 4224 is for today | 12:49 |
| jdstrand | zyga-ubuntu: 4140 requires some investigating from me. 4100 I need to think through a little bit more | 12:49 |
| zyga-ubuntu | jdstrand: thank you on all counts :) | 12:50 |
| mup | PR snapcraft#1763 closed: Make the pip filtering in the Python plugin more fine-grained <Created by OddBloke> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1763> | 12:50 |
| zyga-ubuntu | jdstrand: I'm preparing follow-up for layouts, I'd like to finally finish that and I think we are really close now | 12:50 |
| jdstrand | sergiusens: 06:47 < jdstrand> not there | 12:56 |
| jdstrand | sergiusens: wait, what snap directory? snap/ during the build or in meta/ of the snap? | 12:56 |
| jdstrand | zyga-ubuntu: nice | 12:57 |
| === alan_g is now known as alan_g|lunch | ||
| jdstrand | sergiusens: I have a toplevel snapcraft.yaml. let me put it in snap/ | 13:00 |
| zyga-ubuntu | oh | 13:04 |
| zyga-ubuntu | standup | 13:04 |
| zyga-ubuntu | joining | 13:04 |
| jdstrand | sergiusens: ok, I moved snapcraft.yaml to snap/snapcraft.yaml, then ran 'SNAPCRAFT_BUILD_INFO=1 snapcraft cleanbuild'. I now have a snap/ directory in the snap, but no manifest | 13:05 |
| sergiusens | jdstrand oh, with cleanbuild you need 2.35, the env var wasn't being passed in before | 13:08 |
| sergiusens | jdstrand `snap install snapcraft --classic` :-) | 13:08 |
| jdstrand | hmmm, if I do that I need to remember what you said to do about lxd and networking | 13:09 |
| jdstrand | sergiusens: yes, that worked. thanks | 13:36 |
| sergiusens | cjwatson btw, mind if we work on switching snapcraft to use the snap for lp buidlers? | 13:40 |
| cjwatson | sergiusens: I don't mind, but how were you planning to go about it? | 13:40 |
| cjwatson | it's a bit involved | 13:40 |
| sergiusens | cjwatson oh, then step one would be to get an idea of how involved it is :-) | 13:41 |
| sergiusens | I had the impression it would be more about testing that s/apt install snapcraft/snap install snapcraft --classic/ was working as expected on staging | 13:42 |
| cjwatson | sergiusens: we need to make it be a switch, not just change it in the code (which is harder to roll back, harder to experiment with on particular snaps, etc.); and probably as part of the same chunk of work we need to add channel control | 13:43 |
| cjwatson | sergiusens: which means it needs to be propagated down from the LP buildd-manager, and probably needs data model changes | 13:43 |
| sergiusens | cjwatson up to LP or even build.snapcraft.io ? | 13:47 |
| sergiusens | I'll write up the proposed set of steps on the forum | 13:48 |
| cjwatson | sergiusens: not build.snapcraft.io IMO. We can flip the switch eventually but it needs to be controlled | 13:53 |
| cjwatson | sergiusens: IMO the steps are: (1) design data model in LP (possibly taking into account where core is installed from too, at least for the future?) (2) add option to snap build type in launchpad-buildd to cause it to install snapcraft as a snap (3) LP database migration to add whatever new columns we need (4) implement new data model and API changes in LP, and adjust the build args sent to ... | 13:56 |
| cjwatson | ... builders (5) possible UI changes | 13:56 |
| cjwatson | sergiusens: ordering is important because builders, DB migrations, LP code are all deployed independently so we need to ensure the right kind of compatibility | 13:57 |
| niemeyer | cachio: Spread-24 is now a brand new machine | 13:58 |
| niemeyer | cachio: Let me know how it goes please | 13:58 |
| cachio | niemeyer, great, thanks | 13:58 |
| cachio | niemeyer, I'll put an eye on it | 13:59 |
| === alan_g|lunch is now known as alan_g | ||
| mup | PR snapd#4310 opened: many: allow to configure core before is installed <Created by pedronis> <https://github.com/snapcore/snapd/pull/4310> | 14:13 |
| pedronis | mvo: ^ it has conflicts though, what stops merging your PR ? | 14:14 |
| jdstrand | zyga-ubuntu: I've not looked at this at all, but fyi https://bugs.launchpad.net/bugs/1734845 | 14:14 |
| mup | Bug #1734845: hook (core) configure → exit status 1 cannot create lock directory /run/snapd/lock → Permission denied <snapd (Ubuntu):New> <https://launchpad.net/bugs/1734845> | 14:14 |
| zyga-ubuntu | jdstrand: ack | 14:15 |
| pedronis | mvo: your PR is red | 14:15 |
| zyga-ubuntu | jdstrand: I looked at this when initially made aware of this about a week ago, my best theory is this is in a privileged container without apparmor stacking | 14:15 |
| jdstrand | zyga-ubuntu: like I said, I don't know, but there are quite a few issues on errors.u.c: https://errors.ubuntu.com/problem/cf07c2fa3f39a98f0b52aaf20ff82faab7969129 | 14:17 |
| jdstrand | zyga-ubuntu: 515 instances in the last week: https://errors.ubuntu.com/?period=week | 14:20 |
| mvo | pedronis: yes, timeout | 14:21 |
| mvo | pedronis: interestingly in snap set core prxy.store=fake | 14:22 |
| pedronis | real bug? | 14:22 |
| mvo | pedronis: maybe but it looks a bit random | 14:23 |
| pedronis | it's never been green afaict | 14:23 |
| mvo | pedronis: :/ | 14:23 |
| mvo | pedronis: I debug once I have the nvidia done | 14:25 |
| mvo | pedronis: if its real it might be some race, I wonder if something with the state lock, that would explain why it times out, but I don't think there is anything racy in there | 14:25 |
| pedronis | mvo: probably something wrong with the lock | 14:25 |
| pedronis | that's my guess as well | 14:26 |
| pedronis | (that we don't see in the unit tests) | 14:26 |
| mup | PR snapd#4311 opened: debian: ensure /var/lib/snapd/lib/vulkan is available <Created by mvo5> <https://github.com/snapcore/snapd/pull/4311> | 14:27 |
| pedronis | mvo: I see corecfg.Run expects to run without the lock, but the new code in hookmgr locks | 14:30 |
| mvo | pedronis: heh, that would explain it | 14:31 |
| pedronis | I think we need to think a bit who should be responsible for what | 14:31 |
| pedronis | mvo: we probably shouldn't lock around the hijack, and make it it's problem | 14:34 |
| pedronis | mvo: I need to take my walk break, but I can look in to this afterward | 14:38 |
| zyga-ubuntu | jdstrand: FYI, after "plan writable mimic" branch lands I'd like to propose this: https://github.com/zyga/snapd/commit/9b4507bdbfd22f858808924fa45c633209d290c1 | 14:38 |
| zyga-ubuntu | jdstrand: I think it fits into the discussion and I'm just letting you know in case you need context for the other review | 14:39 |
| mvo | pedronis: sounds good, lets sync when you are back, I'm fighting apparmor right now | 14:39 |
| zyga-ubuntu | jdstrand: this patch does the execution of the plan and creation of the undo changes | 14:39 |
| * zyga-ubuntu jumpst onto the user mount namespace topic | 14:45 | |
| jdstrand | mvo: is that the include issue or something else? | 14:48 |
| mup | PR snapd#4312 opened: snap-confine: create mount target for lib32,vulkan on demand <Created by mvo5> <https://github.com/snapcore/snapd/pull/4312> | 14:53 |
| mvo | jdstrand: I was refering to the include issue earlier, but I think its a non-issue now, we fixed it by using #include now instead of "include" | 14:53 |
| mvo | jdstrand: well, when I say "we" I mean zyga-ubuntu | 14:53 |
| lundmar | Hi guys, I'm looking forward to more +1 in this alias request: https://forum.snapcraft.io/t/request-automatic-aliases-for-lxi-tools/2956 . Thanks! :) | 14:54 |
| * jdstrand nods | 14:54 | |
| jdstrand | lundmar: you don't need any more | 14:55 |
| lundmar | oh great. Can it move to next step already? | 14:56 |
| jdstrand | lundmar: you have two votes. we just need to wait the allotted time to allow others the opportunity to vote against | 14:56 |
| lundmar | ok | 14:56 |
| jdstrand | lundmar: then we'll grant the alias. fyi, the voting period is one week, so next monday I'll tally/grant | 14:57 |
| lundmar | ok, parience it is then :) | 14:57 |
| lundmar | patience* | 14:57 |
| mup | PR snapd#4313 opened: timeutil: refresh timer take 2 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4313> | 14:58 |
| lundmar | jdstrand: btw, I'm the guy who made the feature request for completions scripts support long ago. I recently revisited snap and I'm happy to see it has been added. However, it seems it is not working for aliased commands. | 14:58 |
| Chipaca | lundmar: hello | 14:59 |
| mup | PR snapd#4314 opened: interfaces: switch to ConnectedPlug/ConnectedSlot API <Created by stolowski> <https://github.com/snapcore/snapd/pull/4314> | 14:59 |
| Chipaca | lundmar: https://forum.snapcraft.io/t/tab-completion-for-snaps-bash/2261 | 14:59 |
| Chipaca | lundmar: 2.30 has support for aliased commands | 14:59 |
| lundmar | Chipaca: Ahh, 2.30 . Got it. Thanks. | 15:00 |
| Chipaca | lundmar: let me know how it breaks :-) | 15:00 |
| lundmar | of couse, I expect it to :) | 15:00 |
| lundmar | courseØ | 15:00 |
| lundmar | course* | 15:00 |
| Chipaca | lundmar: also note the completion snippet doesn't "see" the alias | 15:01 |
| Chipaca | ie if a snap foo has an app called bar that has a snippet, the snippet is always called as if the user had used foo.bar, even if the user aliased foo.bar to quux and used that | 15:02 |
| mvo | pedronis: nvidia is under control, I will fix the locking now (unless you are already on it) | 15:03 |
| lundmar | Chipaca: I'll look into to the snippet stuff. The less defintion we have to add to get completion scripts working in its traditional form the better. | 15:03 |
| Chipaca | lundmar: you should be able to just drop in the snippet you'd usually drop in /usr/share/bash-completion/completions into you snap, set a 'completer' key in the yaml, and things work. At most you need to make it handle foo.bar instead of just bar. | 15:04 |
| lundmar | Chipaca: Like this right? https://github.com/lxi-tools/lxi-tools.snapcraft/blob/master/snap/snapcraft.yaml | 15:04 |
| Chipaca | lundmar: like so | 15:04 |
| lundmar | I'm adding the alias manually, however I noticed it does not work. | 15:05 |
| zyga-ubuntu | mvo: what do you know about the locking issue | 15:05 |
| zyga-ubuntu | mvo: do you have any theory? | 15:05 |
| Chipaca | lundmar: completion, or the alias? | 15:06 |
| mvo | zyga-ubuntu: none at all currently :( | 15:06 |
| zyga-ubuntu | mvo: question is 2.29 really open as milestone? are you doing a 2.29.x release? | 15:07 |
| lundmar | Chipaca: completion not working for the lxi-tools.lxi command nor lxi alias (the latter is most important). | 15:07 |
| mvo | zyga-ubuntu: not sure I understand but yes, 2.29 is still open because its not released yet to stable core and also it looks like there are some warts with the SRU | 15:08 |
| Chipaca | lundmar: is it the one in the store? | 15:08 |
| mup | PR snapd#4311 closed: debian: ensure /var/lib/snapd/lib/vulkan is available <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4311> | 15:08 |
| lundmar | Chipaca: yes | 15:08 |
| Chipaca | lundmar: complete -o default -F _lxi lxi | 15:09 |
| jdstrand | lundmar: glad completion scripts are (finally) getting there for you :) they were a very interesting feature to enable (huge thanks to Chipaca) | 15:09 |
| Chipaca | lundmar: that bit in your snippet will only work with "lxi" | 15:09 |
| jdstrand | (he did all the heavy lifting) | 15:09 |
| Chipaca | lundmar: and that will never get called with 'lxi' because the snap is called lxi-tools | 15:09 |
| Chipaca | lundmar: so... you probably ant complete -o default -F _lxi lxi-tools.lxi | 15:09 |
| Chipaca | want* | 15:10 |
| lundmar | Chipaca: which is just fine. I'm really only interested in it working for the 'lxi' alias, not lxi-tools.lxi | 15:10 |
| Chipaca | lundmar: the snippet doesn't see the alias, as i tried to explain | 15:10 |
| Chipaca | the snippet always sees the 'canonical' (heh) app name | 15:10 |
| Chipaca | lundmar: (because the user can alias it to _anything_ and still want completion to work) | 15:10 |
| lundmar | jdstrand: yeah, I know getting it working across confiment was interesting. Now, next feture we need to have first class commandline support is support for the 'man' command to view man pages ;) | 15:11 |
| === cachio is now known as cachio_lunch | ||
| jdstrand | lundmar: work on that recently continued, thanks to cjwatson | 15:12 |
| jdstrand | once the confinement is working in the man command, then snapd can implement the bits to put man pages from snaps in the right place | 15:12 |
| mup | PR snapd#4309 closed: snap: fix TestDirAndFileMethods() test to work with gccgo <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4309> | 15:13 |
| lundmar | Chipaca: Hmm. Then I will have to create a duplicate completion script just for the sake of snap. | 15:14 |
| Chipaca | jdstrand: next after that... devhelp :-D | 15:14 |
| jdstrand | Chipaca: heh | 15:14 |
| Chipaca | lundmar: aw | 15:14 |
| Chipaca | lundmar: or! or | 15:14 |
| Chipaca | lundmar: “complete -o default -F _lxi lxi lxi-tools.lxi” | 15:14 |
| Chipaca | lundmar: that should work in both places | 15:15 |
| lundmar | Chipaca: yes, and that line belongs in the completion script (that I will have to create specifically for snap) unless I can somehow add the single line in the .yaml? | 15:15 |
| Chipaca | lundmar: i mean, you can ship that line in both places, it won't break stuff | 15:16 |
| jdstrand | mvo: whenever is convenient, can you take a look at https://dashboard.snapcraft.io/dev/snaps/8748/feedback/ | 15:16 |
| jdstrand | mvo: (base-18 issues) | 15:16 |
| jdstrand | mvo: I approved it for now, but it would be nice to get it to pass automated review | 15:17 |
| mvo | jdstrand: sure | 15:17 |
| lundmar | I guess my point is, if possible I want to avoid changing anything in my source to reflects snap support. If possible it would be better to find a way for snap to support standard configurations. | 15:17 |
| mvo | jdstrand: thank you, it looks really messy :) | 15:17 |
| jdstrand | mvo: (note that r950 of the review tools have changes for base-18 but aren't in prod yet) | 15:17 |
| mvo | jdstrand: but note the version number | 15:17 |
| jdstrand | mvo: yes. I like your style :) | 15:17 |
| mvo | jdstrand: thank you for doing those | 15:17 |
| mvo | jdstrand: :P I will work on the errors after the other fires are under control | 15:18 |
| Chipaca | lundmar: i didn't find a way for that to work, unfortunately | 15:18 |
| mvo | jdstrand: thanks for the heads up | 15:18 |
| lundmar | Chipaca: I can see how it is tricky to solve. | 15:18 |
| Chipaca | lundmar: that is: users can decide not to install your aliases (snap install --unaliased), or to override it with anything else, and we still want completion to work in those cases | 15:19 |
| Chipaca | if there's a trick i missed, i'd be happy to learn it | 15:19 |
| lundmar | Chipaca: I'm thinking what if we define “complete -o default -F _lxi lxi lxi-tools.lxi” directly or indirectly (through simple key) and have that be picked up and source by some of the command wrappers. This way we can support standard completion scripts and end users don't have to touch their original completion scripts. | 15:23 |
| lundmar | sourced* | 15:23 |
| Chipaca | lundmar: doable but a lot of work, because of how hairy complete can get | 15:24 |
| lundmar | I mean, we could create maybe a completer-alias: lxi-tools.lxi key and support it that way. | 15:25 |
| cjwatson | jdstrand: Yeah, I landed the apparmor work in unstable/bionic but I still need to finish the seccomp work | 15:27 |
| lundmar | the have the command wrapper source the completer script in case the _lxi bash function does not already exist (not sourced before). Might be simple to do. | 15:27 |
| lundmar | then* | 15:27 |
| lundmar | Chipaca: either way, users are free to change aliases manually. It seems to me we need to figure out a way to support that. I think changing the command wrapper accordingly might be a way. | 15:37 |
| mvo | pedronis: my local spread run appears to be happy now, fingers crossed for the spread run | 15:38 |
| pedronis | mvo: thanks, I think the test need some tweaking to fail earlier | 15:42 |
| mvo | pedronis: the spread test you mean? | 15:43 |
| mvo | pedronis: or do you mean we need a unit test that tests this particular combination ? | 15:43 |
| pedronis | mvo: no, the unit tests, I think the Mock function in configstate is a bit strange | 15:43 |
| pedronis | it mocks too much | 15:43 |
| pedronis | anyway I'm picking up the branch to work a bit on this | 15:43 |
| mvo | pedronis: much appreciated, thank you | 15:43 |
| Chipaca | lundmar: in all the above you refer to 'command wrappers'. What do you mean? | 15:45 |
| pedronis | mvo: am I confused, or there are no tests for the hijack in configstate itself? | 15:50 |
| Chipaca | lundmar: note that if your snap were called just 'lxi' things would just work :-) | 15:50 |
| mvo | pedronis: iirc only indirect via coreCfgRun mocking | 15:50 |
| mvo | pedronis: so +1 for adding one, let me know if I should do this. sorry for this | 15:51 |
| pedronis | mvo: no, the mocking is not called in configstate | 15:51 |
| pedronis | it's only used far away (devicestate) | 15:51 |
| mvo | pedronis: autsch, indeed | 15:52 |
| pedronis | I'll see if I can add one | 15:52 |
| lundmar | Chipaca: Yes, however - that is not an option. We can't name all snaps after the primary tool it includes ;) | 15:52 |
| Chipaca | lundmar: one can dream though | 15:52 |
| Chipaca | lundmar: (also: why not?) | 15:53 |
| mvo | pedronis: please let me know if its too annoying, then I will do it :) | 15:53 |
| kyrofa | sergiusens, is there a reason we're using mypy 0.540 instead of the newest? | 15:54 |
| lundmar | Chipaca: image a snap package with many tools (apps). You would need aliases for each app to avoid the <snap name>. prefix. | 15:54 |
| lundmar | imagine* | 15:54 |
| kyrofa | If not, mind if I update? | 15:54 |
| Chipaca | lundmar: most tools that are parts of a whole do have a common prefix or suffix, though | 15:55 |
| lundmar | Chipaca: I assume the overall goal with aliases is to make it possible for the users to never know they are using a snap. | 15:56 |
| lundmar | that is very aliases become powerfull feature | 15:57 |
| lundmar | where* | 15:57 |
| lundmar | Chipaca: I was looking at this file: /snap/lxi-tools/current/command-lxi.wrapper | 15:57 |
| Chipaca | lundmar: ah, that's a snapcraft thing | 15:57 |
| Chipaca | not sure what's in there today | 15:57 |
| Chipaca | (haven't had to look in a while because it mostly just works) | 15:58 |
| lundmar | Chipaca: oh, it's not used when firing commands? | 15:58 |
| Chipaca | lundmar: completion doesn't run the command though | 15:58 |
| lundmar | I thought maybe this file was fired every thing you fire the lxi-tools.lxi command | 15:59 |
| kyrofa | lundmar, indeed it is | 15:59 |
| kyrofa | lundmar, that's how snapcraft gets the LD_LIBRARY_PATH in there, runs any required setup scripts, etc. | 16:00 |
| lundmar | in which case it would be possible to add a check to see if the e.g. _lxi function (defined via eg. new completer-alias key) and if the _lxi function does not exist it will simply source the completion script. | 16:01 |
| zyga-ubuntu | jdstrand: I'll resume work on the base snap staleness issue | 16:01 |
| kyrofa | Hey zyga-ubuntu, any more progress on the lxd upgrade issue? | 16:01 |
| zyga-ubuntu | kyrofa: no, not yet | 16:03 |
| === cachio_lunch is now known as cachio | ||
| Facu | sergiusens, so, my last commit in the metadata branch failed in travis with "The job exceeded the maximum time limit for jobs, and has been terminated." ... what should I do? | 16:16 |
| Facu | roadmr, matiasb ^ | 16:16 |
| matiasb | hm.. no idea, trigger it again? :/ | 16:18 |
| mup | PR snapcraft#1580 closed: cli: setup gitignore when working from git directory at init <Created by msis> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1580> | 16:18 |
| roadmr | Facu: I'd trigger it again. Travis is brutal, it takes ages :( | 16:18 |
| Facu | roadmr, ack | 16:18 |
| Chipaca | lundmar: https://forum.snapcraft.io/t/2972?u=chipaca | 16:19 |
| jdstrand | sergiusens: I meant to ask before, are snap rebuilds expected to work now? I tried by just copying manifest.yaml over snapcraft.yaml but it didn't work. if it is expected to work, what is the right way to do it? | 16:24 |
| roadmr | jdstrand: hey, we made a proposal on how to solve https://bugs.launchpad.net/snapstore/+bug/1732781, could you check the last comment (mine!) and let me know if that sounds acceptable? if not, I'm happy to find other alternatives | 16:24 |
| mup | Bug #1732781: store should detect and reject changing snap types <Snap Store:New> <https://launchpad.net/bugs/1732781> | 16:24 |
| jdstrand | roadmr: oh I missed that | 16:24 |
| * jdstrand reads | 16:24 | |
| roadmr | :D | 16:25 |
| jdstrand | roadmr: commented | 16:26 |
| roadmr | thanks1 | 16:26 |
| roadmr | ! | 16:27 |
| jdstrand | hehe | 16:27 |
| pedronis | mvo: I noticed that configmanger has still the runner but now is unused | 16:27 |
| pedronis | mvo: I pushed the test and tweaks if you want to look | 16:28 |
| Facu | roadmr, the github page says "failed", should it say "testing" or something? | 16:29 |
| lundmar | Chipaca: great, let me get back to that thread later. I have a few things to take care of first. | 16:30 |
| Chipaca | lundmar: forum is async \o/ | 16:30 |
| lundmar | my brain is async :D | 16:30 |
| pdefreitas | hello guys, I'm looking forward to get a full dev reference of snapcraft. Can anyone guide me regarding that? | 16:32 |
| zyga-ubuntu | pdefreitas: hey, did you see snapcraft.io | 16:33 |
| zyga-ubuntu | pdefreitas: we have a forum, tutorials and other documents | 16:33 |
| roadmr | Facu: let me check | 16:33 |
| niemeyer | mborzecki: Btw, I don't know if I ever sent you the link to https://forum.snapcraft.io/t/task-workflow-in-the-forum/206 | 16:35 |
| pdefreitas | yes, I did, but I am looking for more advanced reference. | 16:36 |
| niemeyer | mborzecki: I know we talked about it, but I don't recall if I did send the link or not | 16:36 |
| mborzecki | niemeyer: thanks, i'll check it out | 16:36 |
| mvo | pedronis: re runner> yeah, we can kill that one again I think | 16:37 |
| pedronis | mvo: I pushed the test if you want to look | 16:37 |
| pedronis | mvo: killing the runner, yes, don't know if it's urgent | 16:37 |
| mvo | pedronis: test is nice, thank you | 16:37 |
| niemeyer | mborzecki: I just removed one of your nick tags from a topic because I thought you forgot to drop that when you dropped upcoming or backlog, but now I realize that you were probably not aware of those conventions | 16:37 |
| mvo | pedronis: probably not urgent, I make a note and fix it in my morning | 16:37 |
| zyga-ubuntu | pdefreitas: which topic in particular are you interested in? | 16:37 |
| mborzecki | niemeyer: yup, i was not | 16:38 |
| roadmr | Facu: checking how to re-trigger the travis run | 16:38 |
| Facu | roadmr, thanks | 16:38 |
| mvo | pedronis: nice simplification in your commit, thanks for this | 16:39 |
| roadmr | Facu: I don't think I can trigger a rebuild, you might be able to, I found some advice in https://stackoverflow.com/questions/17606874/trigger-a-travis-ci-rebuild-without-pushing-a-commit | 16:39 |
| Facu | roadmr, but if I close the PR and reopen it again won't lose all the conversation? | 16:40 |
| Facu | sergiusens, you have write access to the repo? may re-trigger that travis? | 16:41 |
| roadmr | Facu: yes, that sounds scary :( sounds like the best option is to get someone with write access to retrigger the build | 16:41 |
| mup | Issue snapcraft#1767 opened: stage-packages does not respect architectures <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1767> | 16:51 |
| Chipaca | niemeyer: ping | 16:51 |
| niemeyer | Chipaca: pongus | 16:51 |
| Chipaca | niemeyer: running spread with -debug, and not getting shell prompts; instead i'm getting “Error running debug shell: EOF” | 16:52 |
| Chipaca | niemeyer: and then “Error restoring linode:ubuntu-14.04-64:tests/main/ : EOF” | 16:52 |
| niemeyer | Chipaca: That means a disconnection | 16:52 |
| niemeyer | Chipaca: Thus no shell | 16:52 |
| Chipaca | niemeyer: 20+ in a single run? | 16:53 |
| niemeyer | Chipaca: Clearly something wild going on | 16:53 |
| pdefreitas | zyga-ubuntu: the use of interfaces, in particular the bluez interface | 16:54 |
| niemeyer | Chipaca: Note that if the connection is killed in general it's not reestablished, as Spread assumes the machine is in a random state | 16:54 |
| Chipaca | niemeyer: i can tell you think you're explaining something to me, but alas | 16:55 |
| Chipaca | niemeyer: "a disconnection" -- what disconnected? | 16:55 |
| niemeyer | Chipaca: The Spread connection to the machine | 16:55 |
| niemeyer | Chipaca: ssh | 16:55 |
| Chipaca | niemeyer: so, all my ssh's disconnected | 16:55 |
| Chipaca | because they're all doing the same thing | 16:56 |
| niemeyer | Chipaca: Were you connected to multiple machines, or a single machine?> | 16:56 |
| Chipaca | but, if it disconnected, how is it still reporting progress? | 16:56 |
| niemeyer | Chipaca: IOW, was it a full run, all systems in Linode, or a custom run with only a single machine? | 16:56 |
| Chipaca | niemeyer: a full run on linode | 16:57 |
| niemeyer | Chipaca: Ok, so that tastes a lot like a local network hiccup | 16:57 |
| Chipaca | niemeyer: if the EOF is a disconnect, how does it continue after that? | 16:57 |
| niemeyer | Chipaca: If all machines were disconnected at once, your ISP might have quickly bounced your connections | 16:57 |
| niemeyer | IP change or whatever | 16:58 |
| niemeyer | Chipaca: It does not continue.. not on the EOFd machine.. that's why no shell | 16:58 |
| niemeyer | Chipaca: So the tasks will keep up waiting, and if nothing else picks up (a second worker with the same exact system, if any) the remaining tasks are reported as Aborted at the end | 16:59 |
| Chipaca | niemeyer: i'm not sure that matches what i see, but fair enough; i'll wait for it to finish and then kick it off again | 17:00 |
| niemeyer | Chipaca: If the errors is across machines, it needs to be network related | 17:02 |
| niemeyer | Chipaca: Even more if it's an EOF, that's a huge hint | 17:02 |
| niemeyer | Chipaca: Either on your end, or on Linode's | 17:03 |
| niemeyer | Chipaca: We have half of our systems on our DC and half on another.. if vaguely half of your systems got an EOF, I'd suspect one data center got a kick | 17:03 |
| niemeyer | Sorry, s/our DC/one DC/ | 17:03 |
| Chipaca | niemeyer: this is an excerpt of what I see (removed the "running late" lines): https://pastebin.canonical.com/204297/ | 17:06 |
| Chipaca | niemeyer: the thing that puzzles me is that, if each EOF takes a machine out of the pool, and we have 4 14.04 workers, how are there so many more than 4 EOFs? | 17:06 |
| Chipaca | niemeyer: i think i can answer that now though | 17:07 |
| niemeyer | Chipaca: I see, so the EOF actually happened on a single system | 17:07 |
| Chipaca | it's an EOF for the debug output, an EOF for the two restores (test and project) and an EOF for the debug shell itself | 17:08 |
| niemeyer | Chipaca: Looks like Spread is not realizing the EOF isn't going away any time soon, and should stop trying to debug those | 17:08 |
| Chipaca | niemeyer: or that :-) | 17:08 |
| niemeyer | Chipaca: This is a single system, most likely a single machine too | 17:08 |
| niemeyer | Chipaca: (most likely because we have multiple workers per system) | 17:08 |
| pdefreitas | If I want to run multiple snaps that use the very same bluetooth API (bluez) would I have any kind of trouble? Are they independent? | 17:11 |
| kyrofa | mpt, cprov I'd like to meet with you two some time this week to discuss `snapcraft enable-ci`. Any chance you have some slots available? | 17:22 |
| mpt | kyrofa, it’s possible, but we’re in quite different time zones, so check the calendars | 17:26 |
| kyrofa | mpt, alright, will do | 17:26 |
| kyrofa | snappy-m-o, autopkgtest 1765 xenial:amd64 | 17:38 |
| snappy-m-o | kyrofa: I've just triggered your test. | 17:38 |
| kyrofa | Noo, wrong PR | 17:39 |
| kyrofa | snappy-m-o, autopkgtest 1760 xenial:i386 | 17:39 |
| snappy-m-o | kyrofa: I've just triggered your test. | 17:39 |
| cprov | kyrofa: I am available, please schedule something in my calendar too. | 17:41 |
| kyrofa | Thanks cprov, taking a look now :) | 17:41 |
| kyrofa | sergiusens, by the way, given that it's just us and we talked this morning, I have nothing new for our 1-1 today. Want to skip? | 17:42 |
| kyrofa | mpt cprov invite sent | 17:55 |
| zyga-ubuntu | pdefreitas: re, sorry for lagging | 18:07 |
| zyga-ubuntu | pdefreitas: so I was thinking about this and indeed I could not find any good documentation | 18:07 |
| sergiusens | kyrofe sure | 18:07 |
| zyga-ubuntu | pdefreitas: but in fact we have an interface for bluetooth and we even provide a good snap for core devices | 18:07 |
| sergiusens | Facu sure, just finished lunch with perrito | 18:08 |
| zyga-ubuntu | pdefreitas: perhaps you could start a topic on the forum and this topic could, over time, transform into a documentation of those aspects (the canonical bluez snap, the bluez and bluetooth-control interfaces | 18:08 |
| cachio | zyga-ubuntu, did you see that? https://travis-ci.org/snapcore/snapd/builds/308480596#L4586 | 18:13 |
| cachio | zyga-ubuntu, It is not happening always | 18:14 |
| cachio | I am trying to reproduce it here but I can't | 18:14 |
| sergiusens | kyrofa do you have an ETA on that split? | 18:19 |
| kyrofa | sergiusens, PR modified, tests running | 18:20 |
| sergiusens | kyrofa great, because everything is timing out :-) | 18:20 |
| kyrofa | sergiusens, ugh | 18:20 |
| davidcalle | pdefreitas: zyga-ubuntu: we have a bluez snap reference here https://docs.ubuntu.com/core/en/stacks/bluetooth/bluez/docs/ | 18:22 |
| davidcalle | (not sure if it's advanced enough, though) | 18:23 |
| KrzysiekSiemv | Hi! | 18:40 |
| zyga-ubuntu | cachio: looking now | 18:42 |
| zyga-ubuntu | + rm -rf /snap | 18:46 |
| zyga-ubuntu | looots of "read-only file system" | 18:46 |
| zyga-ubuntu | snaps are still mounted | 18:46 |
| zyga-ubuntu | cachio: it may be related to the LXD issue | 18:46 |
| zyga-ubuntu | cachio: it would be good (if you ever get to reproduce it) what is the state of the mount table then (/proc/self/mountinfo) | 18:47 |
| zyga-ubuntu | davidcalle: awesome, could we link to that page from the forum | 18:48 |
| andre-geert | hey all, I have a question about encryption | 18:49 |
| andre-geert | we are considering adopting Snappy Core to replace some of our existing OS on devices | 18:49 |
| zyga-ubuntu | andre-geert: hey | 18:50 |
| andre-geert | we would be producing a snap (not published on the store) | 18:50 |
| m4sk1n | hi | 18:50 |
| zyga-ubuntu | andre-geert: you can publish that snap on your own LAN in your private store proxy | 18:50 |
| zyga-ubuntu | hey m4sk1n | 18:50 |
| andre-geert | and would want that snap (and all the configuration/generated data) to live on an encrypted partition | 18:50 |
| andre-geert | ah, that's good to know, thanks! | 18:50 |
| andre-geert | is there a way to choose the install directory (symlink before an install, etc?) | 18:51 |
| zyga-ubuntu | andre-geert: are you thinking about a "core" system where you just use snaps or a classic system that is a hybrid of other packages and snaps? | 18:51 |
| cachio | zyga-ubuntu, still trying to reproduce it | 18:51 |
| zyga-ubuntu | andre-geert: we don't have support for encrypted partitions _yet_ AFAIK | 18:51 |
| zyga-ubuntu | andre-geert: unless canonical commercial engineering has something I'm not aware of (they might), it'd be worth asking on the forum | 18:52 |
| zyga-ubuntu | andre-geert: on a classic system you can certainly use snaps and encrypted disk or home partition | 18:52 |
| * Chipaca sees the time and disappears in a cloud if tardy smoke | 18:55 | |
| * zyga-ubuntu never knew chipaca was a genie but that explains a lot of things :) | 18:56 | |
| davidcalle | I'm looking for a Polish native speaker https://github.com/canonical-websites/tutorials.ubuntu.com/pull/505 | 19:20 |
| davidcalle | zyga-ubuntu: would you happen to know one, reasonably well versed in snaps too ? :-) | 19:21 |
| sergiusens | zyga-ubuntu stgraber any idea why I cannot mount snaps in lxd on fedora or non ubuntu kernels in general? | 19:23 |
| zyga-ubuntu | davidcalle: re | 19:25 |
| lundmar | zyga-ubuntu: Hi. Are you aware of any issues with accessing the avahi-daemon via the avahi-observe plug on Ubuntu snap? I notice that my lxi-tools snap (see https://github.com/lxi-tools/lxi-tools.snapcraft/blob/master/snap/snapcraft.yaml) works fine in Fedora but not on Ubunu 17.10 (it reports avahi daemon not running, despite it works fine when not using snap). | 19:25 |
| zyga-ubuntu | davidcalle: hehe gladly :) | 19:25 |
| zyga-ubuntu | lundmar: oh, interesting, do you have any apparmor denials when you do that? | 19:26 |
| zyga-ubuntu | lundmar: I'm not immediately aware of any issues but I didn't look at the interface code, | 19:26 |
| lundmar | I haven't checked, I'm running defaults | 19:26 |
| zyga-ubuntu | lundmar: let me check the PR from davidcalle first and I'll look at avahi-observe next | 19:26 |
| zyga-ubuntu | lundmar: dmesg | grep DENIED | 19:26 |
| lundmar | zyga-ubuntu: thanks | 19:26 |
| lundmar | zyga-ubuntu: correct, I get some DENIED messages for lxi-tools regarding avahi daemon. Should i use the avahi-control plug instead? | 19:28 |
| lundmar | I thought the avahi-observe plug was meant for clients (which should be my case). | 19:28 |
| zyga-ubuntu | lundmar: not sure, show the denials and what you were expecting to do | 19:29 |
| zyga-ubuntu | lundmar: bonus points for asking on the forum ^_^ | 19:29 |
| sergiusens | davidcalle are you a mentor for codein? you don't seem to be on #ubuntu-google | 19:29 |
| lundmar | well, irc is always a good starting point ^^ | 19:29 |
| lundmar | I'll try avahi-control, if that does not work I'll ask aroun in the forum. thanks. | 19:30 |
| sergiusens | zyga-ubuntu now answer me :-) | 19:30 |
| lundmar | around* | 19:30 |
| lundmar | Ahh, i think I know what is the issue. The avahi-observe nor the avahi-control plug autoconnects to any snaps. | 19:35 |
| lundmar | so the snap providing the avahi daemon is not connected/loaded. | 19:36 |
| zyga-ubuntu | lundmar: ah, that explains it | 19:39 |
| lundmar | yup, 'snap connect lxi-tools:avahi-observe :avahi-observe' and now it works fine. | 19:39 |
| lundmar | is there any way to avoid firing this command to make it work automagically? | 19:40 |
| lundmar | I mean, can I add something to the snapcraft.yaml to make it work | 19:40 |
| zyga-ubuntu | yes | 19:43 |
| lundmar | I guess Fedora runs a more relaxed security policy and simply autoconnect most plugs | 19:43 |
| zyga-ubuntu | lundmar: you can request your snap declaration to contain some language that will make that connection happen automaticlaly | 19:43 |
| zyga-ubuntu | but this is per-snap store-side decision | 19:43 |
| zyga-ubuntu | lundmar: no, on fedora you don't have the confinement that kept that from connecting | 19:44 |
| zyga-ubuntu | apparmor does DBus mediation | 19:44 |
| lundmar | zyga-ubuntu: I understand. Makes sense. So I should request a vote for it like I recently did a request for aliases? | 19:44 |
| lundmar | Fedora is not running apparmor? | 19:45 |
| * lundmar is not that familiar with the internals of Fedora | 19:45 | |
| zyga-ubuntu | yes | 19:46 |
| zyga-ubuntu | lundmar: nope | 19:46 |
| zyga-ubuntu | lundmar: fedora uses SELinux and SELinux doesn't (AFAIK) do per-method mediation (though maybe I'm wrong, Pharaoh_Atem can correct me probably) | 19:47 |
| lundmar | zyga-ubuntu: got it. Thanks for you help. FYI - your *-ubuntu nick makes you a natural target for Ubuntu questions ;) | 19:48 |
| lundmar | your* | 19:48 |
| zyga-ubuntu | davidcalle: done | 19:50 |
| zyga-ubuntu | lundmar: haha, nice | 19:50 |
| zyga-ubuntu | lundmar: I use many OSes and I keep the -$OS suffix to avoid them from crashing | 19:50 |
| zyga-ubuntu | on crazier days there's a good chunk of zyga's in the channel | 19:50 |
| zyga-ubuntu | davidcalle: please look at my review | 19:50 |
| davidcalle | zyga-ubuntu: that was fast o_o | 19:51 |
| zyga-ubuntu | davidcalle: with such a large minority of snapd developers using polish that is something we could perhaps look at periodically | 19:51 |
| zyga-ubuntu | davidcalle: polish is probably 1st native language in the team :) | 19:52 |
| zyga-ubuntu | davidcalle: some things need changes in the original | 19:53 |
| zyga-ubuntu | davidcalle: I'd rip out gentoo (see my comment) and actually put solus in its place | 19:53 |
| davidcalle | zyga-ubuntu: definitely | 19:53 |
| zyga-ubuntu | davidcalle: solus has great snapd integration and has some interesting features (thank you ikey) straight from the distributor | 19:53 |
| zyga-ubuntu | (and is preinstalled now) | 19:53 |
| mup | Issue snapcraft#1710 closed: Research circle-ci <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1710> | 19:58 |
| lundmar | guys, just one question more. Am I correct to assume that my lxi-tools snap does not connect the hosts avahi daemon but rather it connects to an avahi-daemon runnning in another snap? | 19:58 |
| zyga-ubuntu | lundmar: on classic, it talks to the normal avahi daemon running on the host | 19:59 |
| zyga-ubuntu | jdstrand: any chance for a 2nd look on https://github.com/snapcore/snapd/pull/4224 today? | 20:02 |
| mup | PR #4224: cmd/snap-update-ns: teach update logic to handle synthetic changes <Created by zyga> <https://github.com/snapcore/snapd/pull/4224> | 20:02 |
| mup | PR snapd#4315 opened: cmd/snap-update-ns: add code that executes a plan for writable mimic <Created by zyga> <https://github.com/snapcore/snapd/pull/4315> | 20:03 |
| zyga-ubuntu | I need a review for https://github.com/snapcore/snapd/pull/4315 | 20:03 |
| mup | PR #4315: cmd/snap-update-ns: add code that executes a plan for writable mimic <Created by zyga> <https://github.com/snapcore/snapd/pull/4315> | 20:03 |
| kyrofa | snappy-m-o, autopkgtest 1760 xenial:amd64 | 20:04 |
| lundmar | zyga-ubuntu: Great thanks. Then I understand correctly. | 20:04 |
| snappy-m-o | kyrofa: I've just triggered your test. | 20:04 |
| lundmar | I've put a vote here if anyone would like to +1 it :) https://forum.snapcraft.io/t/request-autoconnect-avahi-observe-plug-for-lxi-tools/2976 | 20:06 |
| lundmar | I mean, request. | 20:06 |
| mup | PR snapcraft#1766 closed: Enhanced fake store to detect that metadata can't be pushed prior to pushing the binary, and fixed the test <Created by facundobatista> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1766> | 20:10 |
| mup | PR snapd#4298 closed: many: remove configure-snapd task again and handle internally <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4298> | 20:18 |
| Facu | yay | 20:39 |
| jdstrand | zyga-ubuntu: yes, done | 20:42 |
| zyga-ubuntu | thanks, looking | 20:44 |
| kyrofa | sergiusens, snapcraft#1760 is green on Travis anyway | 20:46 |
| mup | PR snapcraft#1760: tests: move the catkin integration tests to a separate suite <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1760> | 20:46 |
| kyrofa | Your call on adt | 20:46 |
| kyrofa | plugins suite is back to 44 minutes or so | 20:48 |
| zyga-ubuntu | jdstrand: thank you! | 20:49 |
| zyga-ubuntu | jdstrand: I tried to document and be clear about everything in https://github.com/snapcore/snapd/commit/5e75000f604a2eddece5c1c3669164999b453b2d | 20:50 |
| zyga-ubuntu | jdstrand: not sure if you have the time to look at that today | 20:50 |
| jdstrand | zyga-ubuntu: I added it to my todo to review as part of your next PR | 20:51 |
| jdstrand | zyga-ubuntu: is that not sufficient? | 20:51 |
| jdstrand | zyga-ubuntu: ie, part of PR 4315? | 20:52 |
| mup | PR #4315: cmd/snap-update-ns: add code that executes a plan for writable mimic <Created by zyga> <https://github.com/snapcore/snapd/pull/4315> | 20:52 |
| zyga-ubuntu | jdstrand: yeah, that's the same thing | 20:55 |
| zyga-ubuntu | jdstrand: thanks, I should stop nagging :) | 20:55 |
| kyrofa | zyga-ubuntu, alright, any ETA on the lxd upgrade issue, then? It's super painful, and has been for months | 20:58 |
| zyga-ubuntu | kyrofa: it's in the top of my list but I'm rotating among this and two other topics | 20:58 |
| zyga-ubuntu | kyrofa: I'll talk to mvo tomorrow and plan something based on past attempts | 20:58 |
| kyrofa | Haha, so your list is a lazy susan? | 20:59 |
| kyrofa | Thanks zyga-ubuntu | 20:59 |
| zyga-ubuntu | lazy susan? | 20:59 |
| zyga-ubuntu | not sure what that is but I try to keep it close to roundy robin | 20:59 |
| mup | PR snapcraft#1760 closed: tests: move the catkin integration tests to a separate suite <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1760> | 21:07 |
| mup | PR snapcraft#1718 closed: lxd: let lxd choose the architecture <Created by mwhudson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1718> | 21:31 |
| mup | PR snapcraft#1768 opened: project: export the arch triplet into the environment <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1768> | 21:31 |
| Pharaoh_Atem | zyga-ubuntu: I don't know if per-method mediation is supported, you should ask the SELinux guys | 22:16 |
| Pharaoh_Atem | I suspect it may be partially there | 22:16 |
| ikey | i saw a ping but i know not why | 22:23 |
| ikey | cursed be the small back buffer.. | 22:23 |
| mcphail | ikey: 19:53 < zyga-ubuntu> davidcalle: solus has great snapd integration and has some interesting features (thank you ikey) straight from the distributor | 22:51 |
| ikey | o. :3 | 22:52 |
| * ikey doesn't get context now xD | 22:52 | |
| * ikey buys a bigger backbuffer | 22:52 | |
| ikey | (ty for sharing ^^) | 22:52 |
| mcphail | ikey: http://termbin.com/gbqm | 22:55 |
| mcphail | context is everything | 22:55 |
| ikey | ty ^^ | 23:02 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!