| === chihchun_afk is now known as chihchun | ||
| mup | PR snapcraft#1278 opened: recording: save the snapcraft.yaml in the resulting snap <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1278> | 04:24 |
|---|---|---|
| zyga | good morning | 05:55 |
| zyga | mvo: how are you doing? :-) | 05:55 |
| mvo | hey zyga | 05:59 |
| mvo | zyga: I'm doing very well, played hockey last night, what more to wish for? | 06:00 |
| zyga | mvo: nice :) | 06:10 |
| zyga | mvo: I spent some time digging through an issue and finally got to a more-less working update-ns | 06:10 |
| zyga | hmm, tests are a bit more unreliable lately | 06:12 |
| zyga | or maybe just more starved for resources | 06:12 |
| mvo | zyga: yeah, tests are a bit flaky, annoying | 06:16 |
| mvo | zyga: but I have not seen a pattern yet | 06:16 |
| malanve | Hi there! | 06:27 |
| malanve | Anyone online? | 06:28 |
| zyga | hey | 06:29 |
| zyga | indeed | 06:29 |
| leeboby | hi | 06:34 |
| malanve | Morning | 06:37 |
| malanve | I have a serious stupid question | 06:38 |
| malanve | Does snapd work for SLES (Suse Linux Enrerprise Server) | 06:38 |
| malanve | Does snapd work for SLES (Suse Linux Enrerprise Server)? | 06:38 |
| zyga | malanve: hey | 06:38 |
| zyga | malanve: we have a openSUSE build and we're working on fixing some issues there still, we didn't look at SLES support yet but I'd certainly like to support it too | 06:39 |
| zyga | malanve: you can try the system:snappy repository to see if it'd work with a simple rebuild | 06:39 |
| morphis | malanve: there are also instructions available on https://snapcraft.io/docs/core/install-opensuse | 06:43 |
| malanve | morphis: Not looking for Opensuse, SLES instead. | 06:45 |
| malanve | zyga: Thanks, but I have already tried LOL | 06:46 |
| morphis | malanve: for SLES we don't have packages atm | 06:47 |
| morphis | but its on our list | 06:48 |
| malanve | Thanks Guys! | 06:48 |
| morphis | actually I didn't looked yet what is required to get the snapd.spec building for SLES | 06:48 |
| morphis | could be that there are a few dependencies missing in SLES | 06:48 |
| malanve | Well.... | 06:48 |
| malanve | sudo zypper install snapd Loading repository data... Reading installed packages... Resolving package dependencies... Problem: nothing provides systemd needed by snapd-2.23.6-1.6.x86_64 Solution 1: do not install snapd-2.23.6-1.6.x86_64 Solution 2: break snapd-2.23.6-1.6.x86_64 by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/c] (c): | 06:48 |
| malanve | There is your first dependency | 06:49 |
| malanve | sudo zypper install snapd Loading repository data... Reading installed packages... Resolving package dependencies... Problem: nothing provides systemd needed by snapd-2.23.6-1.6.x86_64 Solution 1: do not install snapd-2.23.6-1.6.x86_64 Solution 2: break snapd-2.23.6-1.6.x86_64 by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/c] (c): | 06:50 |
| malanve | Whoops | 06:50 |
| morphis | malanve: ah, no systemd | 06:50 |
| morphis | that makes things a bit harder | 06:50 |
| morphis | systemd is more or less a strict requirement for snapd | 06:51 |
| morphis | malanve: which SLES version are you running? | 06:51 |
| mup | PR snapd#3224 closed: interfaces/mount: write current fstab files with mode 0644 <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3224> | 06:52 |
| malanve | morphis: SUSE Linux Enterprise Server 11 SP4 | 06:55 |
| morphis | looks like 12 introduced systemd if I am not looking wrong | 06:55 |
| zyga | malanve: I think we will only support SLES 15 | 06:55 |
| zyga | malanve: maybe 12 as well (as it matches leap 42) | 06:56 |
| malanve | There SUSE Guys and them versioning.... LOL | 06:57 |
| malanve | Thanks a lot for the info | 06:57 |
| malanve | These SUSE Guys and them versioning.... LOL | 06:57 |
| * zyga just shrugs thinking "LOL" | 06:58 | |
| * zyga has wired snap-update-ns into the rest of snapd, running tests now | 07:00 | |
| zyga | mvo: when is 2.25? | 07:04 |
| zyga | mvo: is that now-now? | 07:04 |
| mvo | zyga: the aliases branch need to land, right now we cannot release | 07:04 |
| zyga | mvo: I think update-ns should be merged just after release | 07:04 |
| mvo | zyga: so when this is ready we can do 2.25 | 07:04 |
| zyga | mvo: then have a cycle of testing | 07:05 |
| mvo | zyga: sounds good, or we hide it behind a feature flag | 07:05 |
| zyga | mvo: how could we do that? | 07:05 |
| zyga | mvo: I actually do like that | 07:05 |
| zyga | mvo: store a permanent feature flag in the snapd state? | 07:05 |
| zyga | mvo: then have a get/set via debug API | 07:06 |
| zyga | mvo: something like that? | 07:06 |
| zyga | wow that all worked | 07:09 |
| * zyga commits | 07:09 | |
| zyga | I'll run a full pass over main | 07:11 |
| mvo | zyga: or just an environment that people need to set in /etc/systemd/systemd/snapd.conf.d or /etc/environment | 07:11 |
| zyga | (with automatic updates to mount namespaces) | 07:11 |
| mvo | zyga: does not have to be super fancy, but merging after 2.25 also works | 07:11 |
| mvo | zyga: nice! | 07:11 |
| zyga | mvo: I think it all depends on if we can merge current branches :) | 07:11 |
| zyga | mvo: thanks for merging some of them btw :) | 07:12 |
| zyga | I think currently the most important one is https://github.com/snapcore/snapd/pull/3225 | 07:12 |
| mup | PR snapd#3225: cmd/snap-update-ns: add actual implementation <Created by zyga> <https://github.com/snapcore/snapd/pull/3225> | 07:12 |
| zyga | mvo: I added https://github.com/snapcore/snapd/pull/3208 to 2.25 as we had a few people crash their snapd with 2.24 | 07:13 |
| mup | PR snapd#3208: interfaces: recover panics when sanitizing plugs and slots <Created by zyga> <https://github.com/snapcore/snapd/pull/3208> | 07:13 |
| mvo | zyga: sounds good, I think we just need a review from gustavo on this one | 07:14 |
| zyga | mvo: okay | 07:15 |
| pstolowski | good mornings! | 07:18 |
| zyga | pstolowski: hey | 07:21 |
| zyga | mvo: do you remember what discards all namespaces between test invocations? | 07:37 |
| mvo | zyga: unfortunatly not, would have to look around, probably tests/lib/restore.sh | 07:38 |
| zyga | mvo: do we just purge the package? | 07:38 |
| mvo | zyga: yes we do | 07:40 |
| mvo | zyga: tests/lib/reset.sh | 07:40 |
| zyga | mvo: aha, thanks, I think I got it now :) | 07:40 |
| zyga | ok, so snap-update-ns works, snap-confine writes the current profile, snap-discard-ns removes the current profile, snapd runs snap-update-ns when needed | 07:41 |
| zyga | I'll focus on testing but all the patches so far look great | 07:41 |
| zyga | mvo: one request, would you +1 a small branch that makes snap-confine/snap-discard-ns grok the current profile for 2.25 | 07:41 |
| zyga | mvo: the changes are minimal there, I'll push a PR if you want to see | 07:41 |
| zyga | mvo: this way the 2.26 release will already start with the currnet profile in most cases | 07:42 |
| zyga | mvo: and thus nobody will have the more complex upgrade case | 07:42 |
| pedronis | mvo: hi, yes, I'll be working on the feedback on aliases branches today, another one just need a small tweak and then I can land it... the unalias one needs larger changes that I will do | 07:43 |
| pedronis | mvo: I'll have a couple more small branches as well | 07:43 |
| mvo | pedronis: thanks for the update | 07:44 |
| mup | PR snapd#3229 opened: overlord/snapstate: make UpdateAliases idempotent, simplify the backend interface bits for aliases not used anymore <Created by pedronis> <https://github.com/snapcore/snapd/pull/3229> | 07:57 |
| pedronis | mvo: would appreaciate a review of snapd#3229, it's small, it was of those related small branches | 07:58 |
| mup | PR snapd#3229: overlord/snapstate: make UpdateAliases idempotent, simplify the backend interface bits for aliases not used anymore <Created by pedronis> <https://github.com/snapcore/snapd/pull/3229> | 07:58 |
| pedronis | s/it was/it's one/ | 07:59 |
| morphis | mvo: having https://github.com/snapcore/snapd/pull/3177 in 2.25 would be great, its actually really close now | 07:59 |
| mup | PR snapd#3177: cmd/snap: make users Xauthority file available in snap environment <Created by morphis> <https://github.com/snapcore/snapd/pull/3177> | 07:59 |
| pedronis | mvo: also snapd#3328 small (not aliases but the issue I discussed at standup) | 07:59 |
| morphis | mvo: you and jdstrand approved I am just waiting for the last tests to go green | 07:59 |
| pedronis | morphis: it will take a while for the aliases bits in case | 08:00 |
| morphis | pedronis: ok | 08:00 |
| pedronis | also tests are flakey | 08:01 |
| === mcphail_ is now known as mcphail | ||
| mvo | zyga: ups, missed the question about the profile. I think thats fine | 08:05 |
| mvo | pedronis: checking 3229 | 08:06 |
| mvo | pedronis: yeah, was looking at 3328 earlier, there will be conflicts with the "tracks" branch, but we can sort those easily (its mostly code going away in the channels-2.0 branch) | 08:06 |
| mvo | pedronis: have you seen a pattern in the tests? I saw only some network issues and resource issues (cannot allocate machines). have you seen more? | 08:07 |
| pedronis | mvo: yes, what's blocking the tracks one? | 08:07 |
| mvo | pedronis: quick question about the repair work, what primary key (instead of repair-id) would you suggest | 08:07 |
| mvo | pedronis: I htink the tracks one is ready now, got a +1 from gustavo last night and I think I addressed his few open questions/suggestoins | 08:08 |
| pedronis | mvo: ok, good | 08:08 |
| pedronis | mvo: the question about the reapair-id, is mostly if we let other entities emit repair assertions how do we carve out the namespaces? or do we want to make authority-id, or have brand-id in the assertion and part of the primary key | 08:09 |
| mvo | pedronis: aha, so primary key would be (brand-id, repair-id) ? | 08:10 |
| pedronis | yes | 08:10 |
| pedronis | but I think maybe we should have a short meeting with Gustavo to discuss this out | 08:10 |
| pedronis | or discuss it in the forum | 08:10 |
| * pedronis late breakfast while tests run | 08:11 | |
| mvo | pedronis: thank you, this makes a lot of sense in the light of the open-up-for-brands later. I will put it into the forum | 08:11 |
| mvo | pedronis: enjoy breakfast | 08:11 |
| morphis | mvo: https://github.com/snapcore/snapd/pull/3177 is ready now | 08:18 |
| mup | PR snapd#3177: cmd/snap: make users Xauthority file available in snap environment <Created by morphis> <https://github.com/snapcore/snapd/pull/3177> | 08:18 |
| mvo | morphis: excellent, I give it a final look but I am pretty sure its excellent | 08:18 |
| morphis | mvo: :-) | 08:18 |
| mup | PR snapd#3177 closed: cmd/snap: make users Xauthority file available in snap environment <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3177> | 08:30 |
| morphis | mvo: thanks a lot! | 08:30 |
| Chipaca | mvo— today's the cutoff for 2.25, yes? | 08:30 |
| mvo | Chipaca: ideally, its a bit unusual this time because we need the aliases branches in | 08:30 |
| mvo | Chipaca: so the goal is today but it depends on reviews for those | 08:31 |
| pedronis | Chipaca: hopefully, we need aliases in, so I think either today, or middle of tomorrow | 08:31 |
| pedronis | for some value of middle | 08:31 |
| Chipaca | I'd _really_ like to get tab completion in as well | 08:31 |
| mvo | Chipaca: the door is open :) there is a bunch of stuff tagged for 2.25, I would love to see refresh-schedule landing. and tracks-2.0 | 08:33 |
| Chipaca | sigh | 08:33 |
| pedronis | mvo: should I merge #3141, it's green | 08:33 |
| mvo | Chipaca: speaking of which, are there any concerns about the (small) ui change for channels-2.0 ? | 08:33 |
| Chipaca | mvo— i haven't heard any | 08:33 |
| mvo | pedronis: there is a (small) ui change, instead of "stable" it now says "latest/stable". but if everyone if ok I think we should merge it | 08:33 |
| pedronis | ah | 08:34 |
| Chipaca | mvo— in fact snapd#3141 seems to have two +1's and is green | 08:34 |
| mup | PR snapd#3141: many: show available "tracks" in `snap info` <Created by mvo5> <https://github.com/snapcore/snapd/pull/3141> | 08:34 |
| mvo | Chipaca: great, then lets go ahead | 08:34 |
| Chipaca | heh, yeah | 08:34 |
| mvo | pedronis: -^ | 08:34 |
| Chipaca | I think there is one aliases branch i haven't reviewed yet, 3220, but it's the last one in the pipe | 08:35 |
| mup | PR snapd#3141 closed: many: show available "tracks" in `snap info` <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3141> | 08:36 |
| pedronis | Chipaca: there's a new small one as well #3229 | 08:36 |
| pedronis | Chipaca: and there's another one that needs changes after Gustavo's feedback | 08:36 |
| pedronis | mvo: I'm going to fix the conflicts in #3228 | 08:37 |
| pedronis | now | 08:37 |
| pedronis | mvo: snapd#3228 can be reviewed | 08:40 |
| mup | PR snapd#3228: store,daemon: make store interpret channel="" as stable in most cases <Created by pedronis> <https://github.com/snapcore/snapd/pull/3228> | 08:40 |
| morphis | mvo, zyga: a review on https://github.com/snapcore/snapd/pull/3222 would be great | 08:41 |
| mup | PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222> | 08:41 |
| pedronis | Chipaca: mvo: as I said reviews for #3229 appreciated (it's small) | 08:41 |
| mvo | pedronis: just looking at it | 08:41 |
| mvo | pedronis: looks fine, wondering if it can ever happen that UpdateAliases(add, remove) gets the same alias.Name in both add and remove, e.g. to change alias.name to a new alias.target. but I guess no? | 08:43 |
| pedronis | mvo: it can happen but it works anyway | 08:43 |
| mup | PR snapd#3136 closed: snap-confine: add code to ensure that / or /snap is mounted "shared" <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3136> | 08:44 |
| mvo | pedronis: oh, you are right of course | 08:44 |
| pedronis | mvo: removed is for that case, it's just an opt though really | 08:44 |
| mvo | pedronis: yeah, I see that now. thank, will approve | 08:44 |
| mup | PR snapd#3230 opened: tests: extend network-control spread test to cope with network namespaces <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3230> | 08:45 |
| pedronis | thx | 08:45 |
| Chipaca | morphis, mvo, are there any distros where bash-completion isn't installed in /usr/share/bash-completion? | 08:45 |
| morphis | Chipaca: good question | 08:45 |
| morphis | on fedora it is | 08:46 |
| mvo | Chipaca: a really good question, no idea. it is on debian | 08:53 |
| zyga | ooh | 08:53 |
| zyga | 139 tests passing with update-ns :D | 08:54 |
| * zyga starts to shoot branches | 08:54 | |
| mup | PR snapd#3191 closed: many: implement snap alias <snap.app> <alias> (aliases v2) <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3191> | 08:56 |
| pedronis | ok, back to bigger fish now | 08:57 |
| mup | PR snapd#3229 closed: overlord/snapstate: make UpdateAliases idempotent, simplify the backend interface bits for aliases not used anymore (aliases v2) <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3229> | 09:06 |
| pstolowski | pedronis, hey, 3220 appears to have conflicts | 09:07 |
| === cjwatson_ is now known as cjwatson | ||
| pedronis | I need to fix 3192 first anyway | 09:08 |
| mvo | pedronis: I can look at the conflicts in 3220 if you want | 09:10 |
| mvo | (my branch caused them afterall) | 09:10 |
| pedronis | mvo: no, 3220 is something else | 09:11 |
| mvo | aha, 3228 is the one I had in mind | 09:11 |
| pedronis | and the conflicts are already in 3192 | 09:11 |
| pedronis | mvo: that one is fixed already, just needs a 2nd review | 09:12 |
| mvo | pedronis: cool, let me do that then | 09:12 |
| pedronis | mvo: I mean I fixed the conflicts | 09:12 |
| morphis | zyga, mvo: https://github.com/snapcore/snapd/pull/3222 would be nice to get merged too now that all tests are passing | 09:33 |
| mup | PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222> | 09:33 |
| zyga | morphis: hey | 09:38 |
| zyga | morphis: I'll have a look in a sec | 09:38 |
| morphis | zyga: whenever you have time :-) | 09:38 |
| zyga | morphis: just finished a call and I'm wrapping up something | 09:40 |
| morphis | ok | 09:40 |
| * zyga looks now | 09:44 | |
| pstolowski | zyga, commented on 3225 | 09:44 |
| zyga | thanks, checing | 09:49 |
| zyga | checking* | 09:49 |
| zyga | pstolowski: replied | 09:51 |
| pstolowski | k thanks | 09:52 |
| zyga | mvo: added one small branch to 2.25, I'll add two more (equally short) | 09:56 |
| mup | PR snapd#3231 opened: cmd/snap-discard-ns: remove current profile when cleaning up <Created by zyga> <https://github.com/snapcore/snapd/pull/3231> | 09:56 |
| mvo | zyga: ok | 10:03 |
| mup | PR snapd#3232 opened: cmd/snap-confine: write current mount profile <Created by zyga> <https://github.com/snapcore/snapd/pull/3232> | 10:16 |
| mup | PR snapd#3233 opened: packaging: remove current mount profiles when purging <Created by zyga> <https://github.com/snapcore/snapd/pull/3233> | 10:19 |
| zyga | mvo: done | 10:19 |
| mvo | zyga: brace yourself for a grumpy review ;) - I see a lot of C | 10:21 |
| zyga | mvo: not lots, very little! | 10:21 |
| zyga | mvo: :D | 10:21 |
| mvo | zyga: yeah | 10:22 |
| zyga | mvo: if those three PRs land 2.26 will be efortless | 10:26 |
| zyga | for update-ns | 10:26 |
| mup | PR snapd#3234 opened: overlord/snapstate/backend,interfaces/mount: move ns management code <Created by zyga> <https://github.com/snapcore/snapd/pull/3234> | 10:27 |
| mup | PR snapd#3235 opened: overlord/hooks: make sure only one hook for given snap is executed at a time <Created by stolowski> <https://github.com/snapcore/snapd/pull/3235> | 10:29 |
| zyga | pstolowski: updated https://github.com/snapcore/snapd/pull/3225 | 10:49 |
| mup | PR snapd#3225: cmd/snap-update-ns: add actual implementation <Created by zyga> <https://github.com/snapcore/snapd/pull/3225> | 10:49 |
| zyga | pstolowski: looking at https://github.com/snapcore/snapd/pull/3235/files I don't understand the nesting/looping there | 10:55 |
| mup | PR snapd#3235: overlord/hooks: make sure only one hook for given snap is executed at a time <Created by stolowski> <https://github.com/snapcore/snapd/pull/3235> | 10:55 |
| zyga | pstolowski: maybe it'd be easier if the function was reworked to do "bail out" style | 10:55 |
| zyga | pstolowski: if !something { return false }; | 10:56 |
| zyga | pstolowski: instead if a { if { b if c { } } } | 10:56 |
| zyga | pstolowski: the loop and second check for run-hook kind is something I don't understand though, can you help? | 10:56 |
| morphis | Chipaca: /usr/share/bash-completion exists in suse too | 11:01 |
| morphis | hm, Linode is really overallocated .. | 11:01 |
| zyga | morphis: yeah | 11:10 |
| zyga | morphis: sorry, I pushed a few branches now and spread, without queueing, is really bad | 11:11 |
| morphis | it is | 11:11 |
| morphis | zyga: aren't we specifying a maximum number of concurrent builds for travis? | 11:14 |
| zyga | not sure | 11:16 |
| morphis | https://docs.travis-ci.com/user/customizing-the-build/#Limiting-Concurrent-Builds | 11:16 |
| pedronis | lots of test run timing out :( | 11:22 |
| pstolowski | zyga, ok, let me rework it a little bit and you will let me know if it needs explanation | 11:23 |
| zyga | morphis: have a look at https://github.com/snapcore/snapd/pull/3222/files | 11:28 |
| mup | PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222> | 11:28 |
| zyga | pstolowski: thanks | 11:28 |
| ogra_ | mvo, i think i addressed all issues in https://github.com/snapcore/core-build/pull/6 (dont want to make shellcheck a build-dep, i'll add another branch that runs it for every commit instead) | 11:29 |
| mup | PR core-build#6: add the initramfs-tools-ubuntu-core package source <Created by ogra1> <https://github.com/snapcore/core-build/pull/6> | 11:29 |
| zyga | morphis: I'm reviewing the rest, I only gave one nitpick about the true/false argument | 11:29 |
| morphis | zyga: ok, reworking that | 11:32 |
| zyga | thank you! | 11:32 |
| zyga | morphis: will that let you run tests on fedora already? | 11:32 |
| zyga | morphis: or just the first step towards that | 11:33 |
| morphis | zyga: yes that allows us running all tests with 100% pass rate but just for the vendorized build | 11:33 |
| zyga | morphis: oh, that's nice | 11:34 |
| morphis | zyga: for the not-vendorized build we need to update a few more packages | 11:34 |
| morphis | zyga: and introduce one new package | 11:34 |
| zyga | morphis: I'll look at suse reviews, I think that needs some love too | 11:34 |
| * zyga breaks for lunch | 11:34 | |
| morphis | zyga: I am on that one right now | 11:34 |
| zyga | I'll focus on code reviews now | 11:35 |
| zyga | for the rest of the day | 11:35 |
| zyga | I'll start with chipaca's, then morphis' then jdstrand's | 11:35 |
| morphis | zyga: sounds good | 11:39 |
| zyga | 2017-04-25 10:37:01 Cannot allocate linode:ubuntu-core-16-64: cannot create Linode disk with ubuntu-core-16-64: you do not have enough unallocated storage to create this Disk (608 requested, but only 0 available) | 11:40 |
| zyga | pstolowski: replied on https://github.com/snapcore/snapd/pull/3225 | 11:44 |
| mup | PR snapd#3225: cmd/snap-update-ns: add actual implementation <Created by zyga> <https://github.com/snapcore/snapd/pull/3225> | 11:44 |
| pstolowski | zyga, ok, will check in a moment. I've simplified 3235 a bit, let me know if it's more clear now | 11:47 |
| zyga | pstolowski: checking! | 11:48 |
| zyga | pstolowski: nice!! | 11:48 |
| morphis | zyga: updated https://build.opensuse.org/request/show/490989 | 11:50 |
| zyga | morphis: I just got a beep on my phone :) | 11:50 |
| zyga | morphis: thanks! | 11:50 |
| morphis | zyga: hehe | 11:50 |
| zyga | morphis: what is the rcsnapd file? | 11:52 |
| morphis | that is something suse wants for systemd services to have backward compatiblity with sysvinit | 11:52 |
| morphis | rpmlint complains about this when it's not there | 11:52 |
| morphis | zyga: https://en.opensuse.org/openSUSE:Packaging_checks#suse-missing-rclink | 11:53 |
| zyga | morphis: approved | 11:53 |
| morphis | zyga: thanks | 11:54 |
| pstolowski | zyga, cool. i need to get rid of the habit of nesting if's... :/ | 11:58 |
| mup | PR snapd#3228 closed: store,daemon: make store interpret channel="" as stable in most cases <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3228> | 12:02 |
| mvo | ogra_: thank you, I have a look | 12:07 |
| ogra_ | sigh ...runniing shellcheck on the whole tree gives some mad ooutput :/ | 12:07 |
| morphis | ogra_: snapd tree? | 12:07 |
| ogra_ | morphis, core-build tree | 12:08 |
| morphis | ah | 12:08 |
| mvo | ogra_: yeah, we will certainly need to exclude some tests | 12:08 |
| ogra_ | i'm working on a travis commit check ... but simply running shellcheck gets me like 100 lines about missign quotes | 12:08 |
| mvo | ogra_: i.e. --exclude=1,2,3 etc :) anyway, maybe not worth the hassle | 12:09 |
| ogra_ | and some really pointless bits ... like | 12:09 |
| ogra_ | for i in $(cat /proc/cmdline); do | 12:09 |
| ogra_ | ^-- SC2013: To read lines rather than words, pipe/redirect to a 'while read' loop. | 12:09 |
| ogra_ | (that code obviously wants to read words, not lines) | 12:10 |
| ogra_ | mvo, well, i wonder how we can exclude only single hits like the above ... SC2013 doesnt seem like a bad suggestion but i dont want to be notified for "cat /proc/cmdline" | 12:11 |
| zyga | re | 12:25 |
| mup | PR snapcraft#1261 closed: storeapi: improve the error message for the case the Store answers an upload needs manual review <Created by facundobatista> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1261> | 12:28 |
| niemeyer | o/ | 12:28 |
| zyga | niemeyer: hey :) | 12:32 |
| pstolowski | mvo, any idea why https://travis-ci.org/snapcore/snapd/builds/225133882 says "All good..", yet travis concluded a failure? | 12:32 |
| pstolowski | hi niemeyer ! | 12:32 |
| zyga | all good, patient died | 12:32 |
| zyga | weird :) | 12:32 |
| zyga | pstolowski: I saw that too a few times | 12:32 |
| === JanC_ is now known as JanC | ||
| pstolowski | :) | 12:33 |
| zyga | I just re-triggered | 12:33 |
| zyga | though I'd wait now, everything is busy | 12:33 |
| mvo | pstolowski: usually when the static tests earlire faied | 12:33 |
| mvo | failed | 12:33 |
| youmin | hi everyone, I spend more than 3h to set up static IP address on Dell Edge with Core 16 without success. I tried everything... network-manager, interfaces, etc. Ideas? | 12:34 |
| zyga | /home/travis/gopath/src/github.com/snapcore/snapd/cmd/snap/cmd_changes_test.go:133:2: ineffectual assignment to rest | 12:34 |
| zyga | pstolowski: ^^ indeed | 12:34 |
| zyga | the static check should have stopped the rest | 12:34 |
| mvo | I think we should fix that in our tests, i.e. fail early | 12:34 |
| zyga | youmin: hey | 12:34 |
| zyga | mvo: yeah | 12:34 |
| zyga | youmin: at what stage are you know, do you have a keyboard/monitor connected to your device? | 12:35 |
| pstolowski | zyga, ah! thanks | 12:35 |
| youmin | zyga: I have access through network and console | 12:36 |
| zyga | s/know/now/ | 12:36 |
| zyga | youmin: ok, so from the console run ... | 12:36 |
| * zyga thinks | 12:36 | |
| zyga | console-conf? | 12:36 |
| zyga | ogra_: is that how the binary is called? | 12:36 |
| ogra_ | zyga, yep | 12:36 |
| zyga | yeah | 12:37 |
| ogra_ | you want sudo | 12:37 |
| zyga | fortunately the core snap is at hand to check ^_^ | 12:37 |
| zyga | youmin: run sudo console-conf | 12:37 |
| zyga | youmin: and follow along :) | 12:37 |
| zyga | youmin: I also recommend that you check out forum.snapcraft.io | 12:37 |
| mvo | pstolowski, zyga: I will do a branch in a bit that makes it fail early, silly travis :) | 12:37 |
| zyga | mvo: thank you! | 12:37 |
| ogra_ | zyga, though the dell might be special ... i.e. using some kind of assertion mgmt and NM | 12:38 |
| zyga | ogra_: oh, I see | 12:38 |
| ogra_ | not sure ... | 12:38 |
| zyga | youmin: if that doesn't work please open a question on the forum | 12:38 |
| zyga | youmin: the people that know the dell gateway very well will surely answer | 12:38 |
| ogra_ | right, the CE guys shoudl know and be able to answer if it doesnt work | 12:38 |
| youmin | zyga: thanks I'll try it, is not possible to configure that manually? | 12:38 |
| morphis | youmin: you need to do that via nmcli, can you tell me what you tried so far? | 12:39 |
| ogra_ | sigh ... shellcheck really makes me doubbt my shell skills :P ... so many missing quotes | 12:39 |
| youmin | morphis: I did it with nmcli and it's automatically reconfigured by the system when I reboot, I don't know how to do that properly | 12:40 |
| morphis | youmin: can you show me what exactly you did? | 12:40 |
| youmin | morphis: the problem is not my knowldge about nmcli because it works and when I reboot my configuration disapear | 12:41 |
| zyga | youmin: I think this is managed through netplan | 12:41 |
| zyga | youmin: netplan describes the configuration declaratively | 12:41 |
| zyga | youmin: this is picked up by either systemd-networkd or nmcli | 12:41 |
| morphis | zyga: no, no netplan | 12:41 |
| zyga | youmin: (well, network-manager) | 12:41 |
| zyga | morphis: oh? no? | 12:41 |
| mup | PR snapd#3236 opened: tests: ensure travis fails early if static checks fail <Created by mvo5> <https://github.com/snapcore/snapd/pull/3236> | 12:41 |
| zyga | morphis: can you tell me more, I thought that how it worked | 12:41 |
| morphis | zyga: you can use netplan yes, but that is not ver well working | 12:42 |
| morphis | like for every netplan change you have to restart NetworkManager etc. | 12:42 |
| morphis | which will have effects on the actual network configuration .. | 12:42 |
| zyga | mmm | 12:43 |
| youmin | morphis: where do I can find information about how netplan works? | 12:44 |
| morphis | youmin: don't consider netplan for this case, can you show me the exact commands you executed? | 12:44 |
| morphis | zyga: I can explain that more in depth later | 12:44 |
| morphis | zyga: we plan to inverse the call chain from netplan -> network-manager | 12:45 |
| morphis | network-manager needs native read/write support for netplan instead of netplan generates network-manager configuration files | 12:45 |
| mup | PR snapcraft#1273 closed: core: check SNAP_NAME to detect if snapcraft is a snap <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1273> | 12:46 |
| morphis | Son_Goku: you already took a look at the postrm implementation for the snapd rpm? | 12:48 |
| Son_Goku | yep | 12:48 |
| Son_Goku | I've got something cooking for snapd 2.25 | 12:48 |
| morphis | Son_Goku: nice, do you mind if I reuse that for suse then? | 12:49 |
| youmin | morphis: I use network-manager.cli con edit eth0 and then using the CLI I modify mode to manual and I set up the network parameters, then I save the config I check the configuration files and I restart network manager and it works perfectly | 12:49 |
| morphis | youmin: but not after reboot? | 12:50 |
| youmin | after reboot my configuration disapear | 12:50 |
| morphis | youmin: you saw the configuration being saved into a file? | 12:50 |
| morphis | youmin: do you mind sharing the output of journalctl --no-pager -u snap.network-manager.networkmanager with me? | 12:51 |
| youmin | morphis: yes it is in the network-manager directories | 12:51 |
| youmin | morphis: now I lost the log because I reconfigured it with console-conf like you told me; but I don't know where the configuration is saved now | 12:52 |
| Son_Goku | morphis: sure, I'll let you know when it's ready | 12:52 |
| Son_Goku | I'm still testing and tweaking | 12:52 |
| morphis | youmin: can you check which files are in /etc/netplan | 12:53 |
| youmin | morphis: yes, here it's. Let me go to have lunch and later I'll follow trying everything | 12:54 |
| youmin | morphis, zyga: thanks | 12:54 |
| morphis | youmin: can you show me the content of these files? | 12:55 |
| youmin | /etc/netplan$ l 00-snapd-config.yaml | 12:55 |
| youmin | sudo cat 00-snapd-config.yaml # This is the network config written by 'console_conf' network: ethernets: eth0: addresses: [10.2.0.22/26] gateway4: 10.2.0.1 nameservers: addresses: [10.2.0.1] search: [] version: 2 | 12:56 |
| youmin | now it's working thanks the console-conf configuration | 12:56 |
| youmin | sorry I have to have lunch, I'll be here in some minutes | 12:57 |
| morphis | youmin: ok, just ping me when you're back :-) | 12:59 |
| niemeyer | omw! | 13:02 |
| ogra_ | morphis, if you implement snapd --user. please also make it time out (or add a --timeout= option the dbus invocation can use) so we dont end up with a constantly running daemon | 13:06 |
| morphis | ogra_: good idea | 13:07 |
| cwayne | morphis: ping | 13:09 |
| morphis | cwayne: pong | 13:09 |
| cwayne | morphis: hey after running wifi-ap.setup-wizard it tells me to systemctl restart a service that doesn't seem to exist.. | 13:10 |
| niemeyer | morphis: Some late review comments on snapd#3177 | 13:10 |
| mup | PR snapd#3177: cmd/snap: make users Xauthority file available in snap environment <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3177> | 13:10 |
| morphis | niemeyer: thanks! responded on the PR already | 13:10 |
| morphis | cwayne: looks like the message is out of date, these days you don't have to restart the service anymore | 13:11 |
| morphis | cwayne: https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/wifi-ap/tree/cmd/client/cmd_wizard.go#n413 | 13:11 |
| morphis | cwayne: mind propose a MP to fix that? | 13:11 |
| cwayne | morphis: sure | 13:16 |
| morphis | cwayne: awesome! | 13:16 |
| youmin | morphis: I'm here | 13:27 |
| morphis | youmin: ok, can you paste me the content of the files in /etc/netplan? | 13:28 |
| youmin | I did it before, but when I paste the format is lost. How do you want to receive that pastebin? | 13:28 |
| youmin | https://pastebin.com/aR9YBSDH | 13:29 |
| mzanetti | hey, we're trying to host our own snappy store following http://blog.dustinkirkland.com/2016/06/howto-host-your-own-snap-store.html but struggling with the assertions/signatures thing atm. Does anyone have some pointers on how that stuff works? | 13:30 |
| morphis | mzanetti: you mean creating assertions or distributing them? | 13:33 |
| youmin | morphis: https://pastebin.com/aR9YBSDH | 13:33 |
| morphis | mzanetti: general documentation is available at https://docs.ubuntu.com/core/en/reference/assertions | 13:33 |
| morphis | youmin: ok, that is one way you can do it but now you can't use nmcli on that connection anymore | 13:33 |
| pedronis | mzanetti: there is no documented way to have a full idenpedent store atm, it's something we are thinking about | 13:34 |
| youmin | yes, noticed it | 13:34 |
| youmin | morphis: yes, I noticed it | 13:34 |
| youmin | morphis: is there a way to disable netplan? | 13:34 |
| morphis | youmin: just remove all lines from 00-snapd-config.yaml | 13:34 |
| youmin | morphis: sorry this is not enough... as I explained some times after reboot configuration of nmcli is lost | 13:36 |
| morphis | youmin: sure, but I want to get to find out why :-) | 13:36 |
| morphis | youmin: so drop the configuration from 00-snapd-config.yaml, try to configure via nmcli again, reboot and give me the output of $ sudo journalctl --no-pager -u snap.network-manager.networkmanager | 13:37 |
| youmin | morphis: me too, I assume Dell guys added anything... I'm going to do what you ask me | 13:37 |
| morphis | youmin: trust me, you're talking with the right person to solve this problem :-) | 13:38 |
| youmin | nice | 13:38 |
| Chipaca | zyga, niemeyer, here do this: mkdir /tmp/foo && cd /tmp/foo && touch "foo$(tput setaf 1 1)bar.txt" | 13:38 |
| === alan_g is now known as alan_g_ | ||
| Chipaca | zyga, niemeyer, and tell me what tab completion does when you try to use it in that directory (eg 'ls <tab>') | 13:38 |
| niemeyer | morphis: Thanks! | 13:39 |
| niemeyer | ls foo$'\033'\[31mbar.txt | 13:39 |
| niemeyer | Chipaca: ^ | 13:39 |
| Chipaca | exactly | 13:39 |
| Chipaca | it's not echoed as control characters to the terminal | 13:39 |
| niemeyer | Chipaca: That's slightly different, right? | 13:39 |
| Chipaca | niemeyer— if it is, then i didn't get the point? | 13:40 |
| niemeyer | Chipaca: I mean that one is being handled by bash internally to precisely manipulate the terminal line being edited.. the other is trying to do the right thing | 13:41 |
| niemeyer | Chipaca: Maybe it's a non-issue, but I wouldn't be convinced just by looking at that example alone | 13:41 |
| Chipaca | niemeyer— that kind of thing you see is what you get when trying to complete control characters | 13:42 |
| Chipaca | e.g. if I do, in a function, COMPREPLY=( "hello\rthere" ) | 13:42 |
| Chipaca | the completion will offer “hello^Mthere" | 13:43 |
| mzanetti | morphis: am I reading that right that I should be able to use snap sign to sign our snap package and then somehow host that resulting assertions file on our store? | 13:43 |
| niemeyer | Chipaca: Okay, that's great then | 13:43 |
| morphis | mzanetti: you have the store working without an assertion? | 13:43 |
| mzanetti | morphis: yes, we can snap find and everything, just snap install fails because of the missing assertion and snap download downloads the package and then complains about not finding an assertion | 13:44 |
| morphis | mzanetti: easiest would be to install with --dangerous for now | 13:44 |
| mzanetti | it says --dangerous can only be used for local files... | 13:45 |
| ogra_ | that would also prevent updates | 13:45 |
| youmin | morphis: https://pastebin.com/hWqT5HXa | 13:45 |
| morphis | generating your own signed assertions will be a bit more tricky as you need a trusted key in your store and snapd needs to have its public key configured | 13:45 |
| mzanetti | and well, sure, we could, in theory call snap download and then do the --dangerous thing, but this is supposed to be a product, would like to set up things properly | 13:45 |
| pedronis | mzanetti: the issue is how to setup the chain of trust, at the moment snapd doesn't support parallel/multiple chain of trust | 13:46 |
| morphis | mzanetti: https://github.com/snapcore/snapd/blob/master/asserts/sysdb/trusted.go | 13:46 |
| morphis | mzanetti: but pedronis is the right person you want to talk to about this :-) | 13:47 |
| mzanetti | ah ok | 13:47 |
| morphis | mzanetti: btw. why do you want to have your own store? | 13:47 |
| mzanetti | because canonical promised us one but isn't able to deliver in time | 13:47 |
| mzanetti | so, that's kinda plan b already... | 13:48 |
| pedronis | but there's no real support for that plan b atm | 13:48 |
| pedronis | sorry I don't have enough context to suggest a way forward | 13:48 |
| pedronis | you probably need to reengage with the people that propsed plan a | 13:49 |
| morphis | mzanetti: so you want a branded snap store, right? | 13:49 |
| pedronis | morphis: I suppose not, those are easy to setup | 13:49 |
| morphis | pedronis: yeah | 13:49 |
| mzanetti | I think yes, that's what we want | 13:49 |
| pedronis | then I'm confused, those are easy to setup | 13:49 |
| morphis | mzanetti: who is "we"? | 13:49 |
| mzanetti | maarten said it's not | 13:50 |
| mzanetti | guh.io, that is | 13:50 |
| mzanetti | we ^ | 13:50 |
| ogra_ | zyga, do you feel like giving a second ack on https://github.com/snapcore/core-build/pull/6 so i can merge (and move on with the tests) ? | 13:50 |
| mup | PR core-build#6: add the initramfs-tools-ubuntu-core package source <Created by ogra1> <https://github.com/snapcore/core-build/pull/6> | 13:50 |
| Chipaca | there's some detail escaping us i guess | 13:50 |
| pedronis | mzanetti: depends what you are talking about, a branded store in our terminology is a substore in the normal store, but can be private/limited access etc | 13:50 |
| mzanetti | yes, that's exactly what we want | 13:50 |
| youmin | morphis: in the latest pastebin that I pasted there are the logs that you want | 13:51 |
| morphis | youmin: thanks! I will look in a bit | 13:51 |
| mzanetti | in order to use snapd to distribute updates to the devices we ship... | 13:51 |
| youmin | morphis: no problem | 13:51 |
| pedronis | mzanetti: sorry, we really lack context here, as I said we are probably missing something here, because those are relatively easy to setup | 13:51 |
| pedronis | there may be a feature or property X that you need and our current concept doesn't offer | 13:51 |
| pedronis | or some other kind of miscommunication | 13:52 |
| mzanetti | one sec, will ask t-mon to join, he has more details than I do as I am just about to join them | 13:52 |
| ogra_ | we definitely have a bunch of branded stores running in production already | 13:52 |
| zyga | ogra_: looking | 13:53 |
| ogra_ | thx | 13:53 |
| niemeyer | zyga: I think the Travis thing might be a momentary hiccup of travis itslef | 13:54 |
| zyga | niemeyer: what were you seeing exactly? | 13:54 |
| niemeyer | There was a period of a day or so where most of the issues happened | 13:54 |
| mzanetti | ok, so, t-mon, what exactly is the issue why we can't use the branded snappy store? | 13:55 |
| niemeyer | zyga: Spread cleans after itself today.. for us to get space allocation issues, it means several independent PRs were sequentially interrupted in the middle | 13:55 |
| niemeyer | zyga: In other words, several independent PRs, one after another, start and are not allowed to finihs | 13:55 |
| zyga | ok, I'll push fewer branches, if it happens for whatever reason it will be easier to scope | 13:56 |
| niemeyer | Hmm.. one reason why this might happen is if we get our tests to consistently blow the 50 minutes limit | 13:56 |
| niemeyer | zyga: ack | 13:56 |
| zyga | niemeyer: ah, this is a self accelerating issue then | 13:56 |
| niemeyer | zyga: Thanks for keeping an eye | 13:56 |
| zyga | niemeyer: you do over 50 because whatever, those machines stay allocated | 13:56 |
| zyga | niemeyer: another PR will hit the same issue, use more VMs | 13:57 |
| zyga | niemeyer: until all grinds down to a hald | 13:57 |
| zyga | halt | 13:57 |
| niemeyer | zyga: Well, the timing each unit takes is unrelated to whether other machines are allocated or not | 13:57 |
| niemeyer | zyga: So not self-accelerating in that sense | 13:57 |
| zyga | niemeyer: yes but you can miss it just by trying to allocate a machine and failing | 13:58 |
| niemeyer | zyga: Hmm.. still don't understand it.. | 13:58 |
| niemeyer | zyga: You can miss what? | 13:58 |
| zyga | niemeyer: trying spread-A, busy, trying spread-B no space, trying spread-... then you run and you don't have enough time to finish | 13:58 |
| zyga | niemeyer: miss the 50 minute window | 13:58 |
| zyga | allocation takes a non-trivial amount of time | 13:58 |
| niemeyer | zyga: Ah, yes, although it doesn't really continue forever, nor will the independent tries sum up | 13:59 |
| zyga | niemeyer: but if those VMs don't get cleaned up they don't return to the pool instantly | 13:59 |
| niemeyer | zyga: But yes, it will consume a slice of time to not be able to allocate | 13:59 |
| zyga | niemeyer: so the next PR will have the same experience (unless something else finishes in time) | 13:59 |
| niemeyer | zyga: Yes, but it's not accelerating was my point | 14:00 |
| niemeyer | zyga: Each PR will wait for a fixed time limit until it gives up | 14:00 |
| zyga | niemeyer: once travis kills a job how long does it take for spread to collect those machines? | 14:00 |
| niemeyer | zyga: 2h is what we configured on spread.yaml, IIRC | 14:00 |
| zyga | and woud that also clean up the disk space? | 14:01 |
| jdstrand | ogra_: fyi, new kernels available for generic (bbb) | 14:02 |
| jdstrand | ogra_: and hi! | 14:02 |
| ogra_ | jdstrand, yeah, i saw them on -changes | 14:02 |
| ogra_ | (and hi! too :) ) | 14:03 |
| t-mon | Hi! as mzanetti already meantioned, we have a branded store, but maarten told us this is for testing | 14:04 |
| mzanetti | pedronis: morphis ^ | 14:04 |
| t-mon | an we are not able to release snaps (need manual review) which are not allowed | 14:04 |
| t-mon | i f we go in production with a test store, and the store will be switched off (for what ever reason) we are dead :-D | 14:05 |
| niemeyer | zyga: Spread cleans up every single disk at the end of the test | 14:05 |
| niemeyer | zyga: Whether it allocated it for the test or not | 14:05 |
| niemeyer | zyga: So to drive it completely out of space a sequence of several mishaps needs to take place | 14:05 |
| pedronis | t-mon: sorry, these sounds like commercial issues of which I don't understand the details, I don't think I can help | 14:05 |
| mzanetti | hmm, interesting... but from a technical point of view it should just work, no? | 14:06 |
| ogra_ | yeah ... it definitely does for others | 14:06 |
| niemeyer | I've just put 6 more machines on the Spread cluster to help the review week | 14:06 |
| pedronis | mzanetti: yes, usually once it's really yours you can do reviews for it etc | 14:06 |
| jdstrand | t-mon: I might mention that if you have a branded store, you (or someone working on your behalf) should be in control of the review process to that store. this is part of the commercial pedronis mentioned | 14:07 |
| zyga | ogra_: why do we ship dpkg on core? | 14:08 |
| ogra_ | zyga, ?? | 14:08 |
| ogra_ | zyga, we explicitly remove it | 14:08 |
| zyga | /snap/core/current/usr/bin/dpkg | 14:08 |
| zyga | try that | 14:08 |
| t-mon | perdonis: jdstrand: mzanetti: thanks, I'll get in contact on offical ways :) | 14:08 |
| ogra_ | (we do ship /usr/local/bin/dpkg to print a pretty error ... | 14:09 |
| mzanetti | yeah... that makes sense... ok, we'll try to contact maarten again then... so far we were under the impression that there is something missing on the server end to be able to actually turn the production branded stores | 14:09 |
| ogra_ | ) | 14:09 |
| ogra_ | zyga, definitely a bug | 14:09 |
| zyga | do you want me to report it | 14:09 |
| ogra_ | zyga, yeah, assign me | 14:09 |
| zyga | done | 14:11 |
| zyga | https://bugs.launchpad.net/snapd/+bug/1686106 | 14:11 |
| mup | Bug #1686106: The core snap contains fully working dpkg <snapd:New for ogra> <https://launchpad.net/bugs/1686106> | 14:11 |
| ogra_ | zyga, thanks for catching that ... we obviously remove all dpkg-* binaries http://paste.ubuntu.com/24454366/ ... not sure why dpkg is left | 14:12 |
| zyga | ogra_: you don't remove plain dpkg | 14:12 |
| ogra_ | https://github.com/snapcore/core/blob/master/live-build/hooks/600-no-debian.binary | 14:12 |
| ogra_ | right | 14:12 |
| ogra_ | just anything else related to it | 14:13 |
| ogra_ | silly oversight | 14:13 |
| ogra_ | i actually think there was a reason for that in 15.04 thats not relevant in 16 | 14:14 |
| ogra_ | zyga, trust me !!!! | 14:16 |
| ogra_ | :) | 14:16 |
| youmin | morphis: have you had the chance to see the pastebin? | 14:18 |
| morphis | youmin: not yet, will do in a few min | 14:18 |
| youmin | morphis: oK | 14:20 |
| zyga | ogra_: merged | 14:21 |
| * ogra_ hugs zyga | 14:21 | |
| mup | PR core-build#6 closed: add the initramfs-tools-ubuntu-core package source <Created by ogra1> <Merged by zyga> <https://github.com/snapcore/core-build/pull/6> | 14:22 |
| niemeyer | morphis: Once you have a PR for those notes in the merged PR, please let me know the # and I'll include it in the review sprint board | 14:28 |
| === chihchun is now known as chihchun_afk | ||
| morphis | niemeyer: will do | 14:33 |
| Chipaca | jdstrand— give me a shout when you have a moment please? | 14:33 |
| Facu | Hi all, I'm getting a test failure in snapcraft's master, snapcraft.tests.sources.test_subversion.SubversionDetailsTestCase.test_svn_details_commit, fails with testtools.matchers._impl.MismatchError: '1' != None | 14:34 |
| Facu | does it happen to anybody else? thanks! | 14:34 |
| === Facu is now known as facubatista | ||
| morphis | youmin: you created /etc/network/interfaces.d/eth0 ? | 14:38 |
| youmin | no | 14:38 |
| morphis | can you paste its content? | 14:38 |
| morphis | youmin: also, is this a device upgrade from 15.04? | 14:41 |
| youmin | yes, it is | 14:41 |
| zyga | ha, curious | 14:42 |
| zyga | how does one upgrade from 15.04? | 14:42 |
| morphis | zyga: with a special upgrade tool we wrote | 14:43 |
| morphis | zyga: its more or less a migration than a direct upgrade | 14:43 |
| morphis | and needs to be run manually | 14:43 |
| youmin | I used a pendrive that Dell gave me | 14:43 |
| morphis | youmin: if you move the eth0 file somewhere else the problem should be solved | 14:43 |
| youmin | just rename' | 14:44 |
| youmin | ¿ | 14:44 |
| youmin | ? | 14:44 |
| morphis | youmin: you need to move it out of /etc/network/interfaces.d or remove it if you are sure you don't need it anymore | 14:46 |
| jdstrand | Chipaca: I have an errand atm. when I get back I intend to look at your feedback from yesterday | 14:47 |
| Chipaca | jdstrand— ok, i'll be here | 14:47 |
| youmin | morphis: sorry I created this file just for testing, it doesn't work. It is ignored by the system. | 14:48 |
| youmin | morphis: let check something | 14:49 |
| morphis | youmin: you need to remove it | 14:52 |
| morphis | that is why your configuration isn't correctly applied | 14:53 |
| youmin | morphis: now I've got the point, you're right this is the file that is processed just now | 14:53 |
| morphis | youmin: what happens when you remove it? | 14:56 |
| youmin | morphis: now networkmanager start working | 14:57 |
| morphis | youmin: so even after a reboot you have the configuraiton now applied via nmcli? | 15:08 |
| niemeyer | Lunch, biab | 15:10 |
| youmin | morphis: I though network manager has been loaded but it seams is failing.... and now admin/admin is not working for login and the only IP that I have is localhost | 15:16 |
| youmin | morphis: I'm trying to log in but there is no way | 15:17 |
| mup | PR snapd#3237 opened: many: adjust /aliases and "snap aliases" to aliases v2, also some cleanup <Created by pedronis> <https://github.com/snapcore/snapd/pull/3237> | 15:22 |
| pedronis | niemeyer: ^ I opened this one as well about "snap aliases" | 15:24 |
| morphis | youmin: can you give me a few more details, like which commands did you use to configure the network connection via nmcli etc. | 15:25 |
| morphis | youmin: now that /etc/netplan and /etc/network/interfaces.d network configuration is gone you need to manually configure things via nmcli | 15:25 |
| morphis | youmin: btw. the best to track this would be to file a bug as described in https://docs.ubuntu.com/core/en/stacks/network/network-manager/docs/report-bug | 15:28 |
| mup | PR core-build#8 opened: add shellcheck test, fix code for shellcheck <Created by ogra1> <https://github.com/snapcore/core-build/pull/8> | 15:33 |
| niemeyer | pedronis: Thanks, added to the board | 15:38 |
| morphis | zyga: https://github.com/snapcore/snapd/pull/3156 .. all green, finally :-) | 15:40 |
| mup | PR snapd#3156: many: support debian in our CI <Created by morphis> <https://github.com/snapcore/snapd/pull/3156> | 15:40 |
| zyga | morphis: wow, that's pretty neat! | 15:58 |
| mup | PR snapd#3236 closed: tests: ensure travis fails early if static checks fail <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3236> | 16:03 |
| zyga | morphis: does [ ] support globbin? | 16:07 |
| zyga | morphis: you do tests like [ "$SPREAD_SYSTEM" != "debian-*" ] | 16:08 |
| Chipaca | zyga— no | 16:12 |
| niemeyer | fgimenez: Can you join a call just now? | 16:12 |
| zyga | Chipaca: right, I think you need [[ for that | 16:12 |
| Chipaca | yep | 16:12 |
| fgimenez | niemeyer: sure | 16:12 |
| ogra_ | or something like ... [ "$(echo "$SPREAD_SYSTEM" | grep -q debian-)" ] | 16:13 |
| Chipaca | ogra_— or case/esac | 16:17 |
| ogra_ | which would be the fastest and cleanest | 16:17 |
| zyga | mvo: hey, are you in a meeting now? | 16:22 |
| mvo | zyga*: yes | 16:22 |
| zyga | mvo: let me know if you plan to relesae 2.25 today or is that slipping to tomorrow/ | 16:24 |
| zyga | (when you can) | 16:24 |
| mup | PR snapd#3238 opened: cmd/snap-confine: re-enable re-assciate fix for CE <Created by zyga> <https://github.com/snapcore/snapd/pull/3238> | 16:25 |
| mvo | zyga: looks like !today at this point :/ | 16:26 |
| mup | PR snapcraft#1279 opened: misc: rename the snap dir variable to prime dir <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1279> | 16:43 |
| niemeyer | Current stats on review sprint: 44 total → ( 14 waiting → 16 reviewing → 4 reviewed → 9 merged ) → 10 closed | 16:49 |
| niemeyer | Incorporated that to the bottom of the board | 16:50 |
| niemeyer | 34 to go... | 16:50 |
| niemeyer | https://forum.snapcraft.io/t/review-sprint-1/377 | 16:50 |
| jdstrand | Chipaca: I'm here but haven't had a chance to really work through your comment. do you want me to do that first or discuss now? | 16:54 |
| Chipaca | jdstrand— whichever you'd rather. One big question I have is whether something completing '; sudo yadda' is a problem | 16:55 |
| jdstrand | Chipaca: well, basically what I'm thinking is that I don't want bash completion to be any worse than simply running a cli command | 16:56 |
| jdstrand | Chipaca: and I've not tried to attack bash completion in the past, so just thinking through everything | 16:57 |
| Chipaca | mhmm | 16:58 |
| jdstrand | Chipaca: the user's input going into snap run --complete and then running under confinement for the bash completion is no different than just running a snap command (and whatever shell tricks that might give you. ie, no worse) | 16:58 |
| jdstrand | Chipaca: (and again, I really like you design) | 16:58 |
| Chipaca | jdstrand— your review made me think about what i _wasn't_ checking, and i added checks for those things | 16:59 |
| jdstrand | Chipaca: it is the handoff from confined to unconfined that I am thinking about, and I'm not super familiar with the whole completion mechanism to know the attack surface there (yet) | 16:59 |
| Chipaca | jdstrand— yeap | 17:00 |
| Chipaca | jdstrand— is there anything i can do to help? | 17:01 |
| jdstrand | Chipaca: I think there are two things to think about: 1) attacking completion after go from confined to unconfined but before the user does anything and 2) tricking the user | 17:01 |
| jdstrand | if there are successful attacks against '1', we could *probably* chalk that up to vulnerabilities in bash that should be fixed. however, if there are hardening measures to put some guardrails there, that would be nice | 17:02 |
| Chipaca | on the tricking the user front I haven't found a way to abuse, say, terminal escape chars to do evil stuff; bash escapes those before offering suggestions to the user | 17:02 |
| Chipaca | for escaping, i think the sanitization i did last night fixes one way that might have existed of doing that (if a malicious completion script set arbitrary things that got passed to compopt) | 17:03 |
| jdstrand | Chipaca: yeah, echo doesn't allow that by default. I'd like to play with printf a bit more | 17:04 |
| jdstrand | cool, I haven't seen the updates for sanitization there | 17:04 |
| Chipaca | https://github.com/snapcore/snapd/pull/3150/commits/b02ba90d15d61ad5817eda8e241975669b3fff43 | 17:05 |
| mup | PR snapd#3150: In-snap bash tab completion <Created by chipaca> <https://github.com/snapcore/snapd/pull/3150> | 17:05 |
| jdstrand | Chipaca: the nice thing about printf %q is it definitely makes it shell safe. I do wonder how that might trip up things in practice. I suspect a lot of things would be ok with it, but I'm not sure about everything | 17:06 |
| Chipaca | jdstrand— for COMPREPLY (ie for the last print), it adds a layer of quoting | 17:06 |
| Chipaca | that will break things; a lot of code in bash completion is about getting the right layer of quoting in place :-/ | 17:07 |
| === kay is now known as Guest92058 | ||
| jdstrand | ah, I like https://github.com/snapcore/snapd/pull/3150/commits/b02ba90d15d61ad5817eda8e241975669b3fff43#diff-65f7e8d7984bf6791a40090a663253abR17 | 17:07 |
| mup | PR snapd#3150: In-snap bash tab completion <Created by chipaca> <https://github.com/snapcore/snapd/pull/3150> | 17:07 |
| jdstrand | Chipaca: note, you say non-alphanumeric but it is really just lowercase alpha | 17:07 |
| Chipaca | e.g. if you have a file with a space, a line there would be foo\\ bar, so you get offered something that works when completed | 17:07 |
| Chipaca | jdstrand— yeah; i was about to just list all the known options even but thought it overkill | 17:08 |
| jdstrand | Chipaca: re right layer of quoting. are you saying that bash(-completion) itself is making sure that happens? | 17:08 |
| niemeyer | mvo: snapd#2833 reviewed and approved aside from trivials.. one more review from pedronis and it should be ready to move on | 17:09 |
| mup | PR snapd#2833: many: allow core refresh.schedule setting <Created by mvo5> <https://github.com/snapcore/snapd/pull/2833> | 17:09 |
| pedronis | finishing something and then I will look at it | 17:09 |
| Chipaca | jdstrand— i'm saying if you want to offer the user "foo\\ bar" (so that if they choose that they get something with a space in it and not two somethings separated by a space), and we pass that through %q, they'll be offered foo\\\\ bar which is two somethings one of which ends in a backslash | 17:11 |
| Chipaca | jdstrand— that kind of problem | 17:11 |
| jdstrand | Chipaca: (I also acknowledge the issues with escaping ' '. it's also hard getting the blacklist correct. I was thinking a whitelist of something like '^[a-zA-Z0-9\._ -]$' and escaping everything else, but again, not thought all this through) | 17:11 |
| jdstrand | Chipaca: yep, I get that | 17:12 |
| jdstrand | Chipaca: eg, a kinder, gentler %q | 17:12 |
| jdstrand | Chipaca: mind you, I'm not saying to do that, I'm saying that is something I was thinking about. do you think that is feasible? | 17:14 |
| Chipaca | jdstrand— I'm sceptical it can be made to work in a practical way and still be useful | 17:15 |
| Chipaca | jdstrand— i'm still hopeful you'll find it unnecessary, but if it's got to be done ¯\_(ツ)_/¯ | 17:16 |
| jdstrand | Chipaca: the other thing I was thinking about is that assuming we can trust the handoff, maybe just at the end we do some escaping. again, not looked at this | 17:16 |
| mvo | niemeyer: thanks a lot! | 17:17 |
| Chipaca | jdstrand— if i can help by writing tests (or trying stuff), give me a shout | 17:18 |
| jdstrand | Chipaca: yet another thing I was thinking of is that we can, in theory, so that we support x, y, and z completions, but not a, b and c. meaning, yes, ' ' can be in there, but no, ';' cannot | 17:19 |
| jdstrand | Chipaca: that is a variation on the kinder, gentler %q. you said you thought that would break things to the point of it not being useful. is there something you can think of otoh? | 17:20 |
| jdstrand | s/so that/say that/ | 17:20 |
| niemeyer | mvo: np, glad to see this one getting in :) | 17:20 |
| Chipaca | jdstrand— if we definitely want to filter, ';' would probably do relatively little damage (i have very few files that have that in them, and don't think i've ever seen a commandline tool that takes explicit ;s outside of 'find' or programming languages) | 17:22 |
| Chipaca | jdstrand— i mean: passing the completion through grep and doing no completion if it matches some regexp seems like it'd do less damage than quoting | 17:23 |
| === deltab_ is now known as deltab | ||
| Chipaca | alternatively filtering individual completions could be done in the same way | 17:23 |
| jdstrand | Chipaca: yeah, I have a feeling we'd want to be pretty agressive on that. I think we are at the point where I need to study the handoff | 17:25 |
| Chipaca | jdstrand— ok | 17:25 |
| morphis | zyga: fixed the PR | 17:26 |
| zyga | morphis: thanks! | 17:26 |
| jdstrand | Chipaca: I wonder if it would be useful to land the feature with a fairly aggressive grep. this would demonstrate the feature and we could always loosen it | 17:26 |
| Chipaca | jdstrand— I think it might | 17:27 |
| Chipaca | jdstrand— we have people waiting for the feature so if we're going to do that, i should check whatever we land is workable for them :-) | 17:28 |
| jdstrand | heh, indeed :) | 17:28 |
| lazyPower | Do we have a why snaps vs $alternative page somewhere? | 17:29 |
| zyga | lazyPower: alternative? | 17:29 |
| lazyPower | zyga: eg: flatpack | 17:29 |
| zyga | lazyPower: ah | 17:29 |
| zyga | lazyPower: I misread your question | 17:29 |
| zyga | lazyPower: I don't think we do | 17:29 |
| zyga | niemeyer: quick question, so you say it's okay to use camel case for system-level C constants like UMOUNT_NOFOLLOW? | 17:31 |
| niemeyer | zyga: Let's be a bit more specific.. | 17:31 |
| niemeyer | zyga: I meant that | 17:31 |
| niemeyer | const Foo // This is FOO | 17:31 |
| zyga | lazyPower: er | 17:31 |
| niemeyer | method(Foo) | 17:31 |
| zyga | er | 17:31 |
| * zyga meant under_score | 17:32 | |
| niemeyer | Is better as const FOO; method(FOO) | 17:32 |
| zyga | ok | 17:33 |
| nacc | can classic snaps only be in beta and edge channels? | 17:35 |
| zyga | nacc: they can be in stable as well but need store review | 17:35 |
| nacc | zyga: ah ok -- do i need to request that manually? i don't see a way to do that from the web UI? | 17:35 |
| zyga | nacc: I don't know TBH :/ | 17:36 |
| nacc | zyga: ok :) | 17:36 |
| nacc | i can recommend --edge for now, for this snap, it's fine | 17:36 |
| mup | PR snapd#3239 opened: many: show aliases changes on snap alias/unalias (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3239> | 17:36 |
| niemeyer | nacc: I think you can just try to push it and the store should provide some feedback.. if it doesn't seem straighforward, please let us know as that's something we'd like to fix | 17:37 |
| nacc | niemeyer: ok, it's an already published snap so i would have though there'd be a way to do it from the web interface (it let me add beta but didn't list the other channels) | 17:37 |
| niemeyer | nacc: We've been handling store requested in the forum under the store category, but still.. this particular need is something that should be more integrated into the release workflow | 17:37 |
| nacc | niemeyer: i'll try the push now though | 17:38 |
| niemeyer | nacc: Right.. please try to just put it in the stable channel and let us know how it goes | 17:38 |
| niemeyer | nacc: It should really be that obvious.. if it's not we have work to do | 17:38 |
| nacc | heh, well i need to change my yaml grade first :) | 17:39 |
| niemeyer | nacc: Indeed | 17:39 |
| nacc | niemeyer: will wait for that to autobuild and try again, thanks! | 17:39 |
| niemeyer | nacc: np, let us kno | 17:52 |
| niemeyer | w | 17:52 |
| niemeyer | pedronis: snapd#3192 reviewed again, and LGTM assuming you like the suggestion | 17:53 |
| mup | PR snapd#3192: many: implement snap unalias <alias-or-snap> (aliases v2) <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3192> | 17:53 |
| niemeyer | We need a second review on this one pleeeeease ^ | 17:53 |
| pedronis | niemeyer: ah, I had that idea, if you prefer it I can go for it | 17:54 |
| niemeyer | pedronis: +1! | 17:54 |
| niemeyer | pedronis: A, B, A+B, sounds great | 17:54 |
| pedronis | finishing rereviewing the refresh one and then will go back to that | 17:55 |
| pedronis | mvo: commented on the refresh one, what I'm wondering is the Sleep left in the tests given that we don't have a timer anymore | 18:04 |
| * Chipaca takes a break | 18:08 | |
| mup | PR snapd#3218 closed: interfaces: allow writing to /run/systemd/journal/stdout by default <Created by jdstrand> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3218> | 18:12 |
| nacc | niemeyer: confirmed, after opening the channel via `snapcraft` it did work | 18:18 |
| nacc | niemeyer: and now the web ui shows it for the i386 build (i did it for the amd64 build) | 18:18 |
| nacc | niemeyer: it does seem like, though, that there is no web ui way to 'open' a channel | 18:18 |
| niemeyer | nacc: Opening a channel is just a matter of publishing a snap into it | 18:21 |
| nacc | niemeyer: right, but the snap is already published in the web ui | 18:21 |
| nacc | niemeyer: and there's no option to publish it to further hcannels | 18:22 |
| nacc | but `snapcraft` can | 18:22 |
| nacc | seems odd to an end user, imo | 18:22 |
| === JanC_ is now known as JanC | ||
| cachio | niemeyer, hey, I am trying to automate the console conf tests by using spread | 18:27 |
| cachio | niemeyer, the tests console conf is started and is it suddenly closed if I run a expect from spread | 18:28 |
| pedronis | niemeyer: done | 18:28 |
| Chipaca | nacc— if you go into a revision, the "release" link lets you add it to different channels | 18:29 |
| cachio | niemeyer, but If I run the same with -shell and invoque the expect manually with expect -f the test work | 18:29 |
| cachio | niemeyer, If replicate the test execution from the test machine and execute the same command the spread executed it also works | 18:29 |
| cachio | niemeyer, any idea? | 18:30 |
| niemeyer | cachio: The allocation of the terminal is a bit different when running a shell or not.. we do have expect tests in our suite, though, so somehow it does work | 18:31 |
| niemeyer | Let me get an example | 18:31 |
| cachio | niemeyer, yes I saw the code | 18:32 |
| niemeyer | cachio: https://github.com/snapcore/snapd/blob/master/tests/main/create-key/task.yaml | 18:32 |
| niemeyer | cachio: These tests are passing all the time | 18:33 |
| niemeyer | So it necessarily must work somehow | 18:33 |
| cachio | niemeyer, what I see expect is not the problem, because if I run the same but form the test machine it works | 18:35 |
| cachio | and it is using expect | 18:35 |
| cachio | niemeyer, I think there is something aroud ssh or the terminal that could be affecting, but not sure | 18:35 |
| niemeyer | cachio: That's why I'm pointing out that expect itself works, somehow, in that environment | 18:36 |
| cachio | I changed spread to print the command that executed to run a test and if I run the same commadn with all the exports it works | 18:36 |
| niemeyer | cachio: I suggest starting from the task I mentioned above, and transforming it into your task until it breaks | 18:36 |
| niemeyer | cachio: Then you'll know what's the delta that makes it not work | 18:36 |
| cachio | niemeyer, ok, I'll try that | 18:37 |
| niemeyer | jdstrand: Question on snapd#3219 | 18:40 |
| mup | PR snapd#3219: interfaces/i2c: allow modifying device-specific sysfs entries <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3219> | 18:40 |
| niemeyer | jdstrand: Sorry, nevermind.. I'm blind | 18:42 |
| mup | PR snapd#3219 closed: interfaces/i2c: allow modifying device-specific sysfs entries <Created by jdstrand> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3219> | 18:44 |
| jdstrand | Chipaca: ok, I have data/completion/* copied over to a vm. where do those files go? | 18:47 |
| jdstrand | Chipaca: (I of course also have the rebuilt snapd, snap, snap-exec) | 18:47 |
| jdstrand | looks like etelpmoc.sh goes in /usr/lib/snapd... | 18:49 |
| mup | PR snapcraft#1262 closed: replace : with _ in file names <Created by andyli> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1262> | 18:49 |
| jdstrand | snap probably goes in /etc/bash_completion.d | 18:50 |
| mup | PR snapcraft#1275 closed: init: add a newline at the end of the file <Created by roxyd> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1275> | 18:52 |
| jdstrand | ah, complete.sh also lives in /usr/lib/snapd | 18:54 |
| Chipaca | jdstrand— yeah in /usr/lib | 18:55 |
| Chipaca | jdstrand— but complete.sh can be wherever | 18:55 |
| * jdstrand puts snap in /usr/share/bash-completion/completions/ | 18:55 | |
| Chipaca | jdstrand— that's completion for the snap command, not related to this :-) | 18:55 |
| jdstrand | ah, ok | 18:56 |
| jdstrand | Chipaca: so, my snap would source complete.sh, so it just needs to be somewhere predictable? | 18:56 |
| * jdstrand is trying to understand the 'can be wherever' comment | 18:57 | |
| Chipaca | jdstrand— your snap wouldn't source complete.sh | 18:57 |
| jdstrand | right, duh | 18:57 |
| Chipaca | (unless you're sourcing complete.sh for reasons) | 18:57 |
| Chipaca | complete.sh is the "outside" one | 18:57 |
| Chipaca | ie the user would source it after sourcing bash_completion | 18:57 |
| jdstrand | Chipaca: ok, that is was the comment is about. at the moment, that is happening and there needs to be some way for that to happen, but for me, I can source it and just have etelpmoc.sh in /usr/lib/snapd | 18:58 |
| Chipaca | jdstrand— your snap needs to have a completer entry in its snap.yaml | 18:58 |
| jdstrand | err | 18:58 |
| jdstrand | that *isn't* happening | 18:58 |
| * jdstrand nods | 18:58 | |
| jdstrand | btw, etelpmoc.sh is incredibly hard to type :P | 18:58 |
| Chipaca | jdstrand— yep, and you need the new snap-exec "inside" for it all to work | 18:59 |
| Chipaca | :-D | 18:59 |
| Chipaca | it doesn't get easier | 18:59 |
| jdstrand | hehe | 18:59 |
| jdstrand | Chipaca: so, hmm, how are you putting snap-exec insode, a bind mount/overlay mount? | 19:00 |
| Chipaca | yeah, i just copy everything into a snapd directory and bind-mount it | 19:00 |
| jdstrand | normally I only deal with snapd and just use SNAP_REXEC=0, but this is different | 19:00 |
| jdstrand | ok | 19:00 |
| mup | PR snapcraft#1268 closed: Added link to forums in the Get in touch section <Created by Ads20000> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1268> | 19:04 |
| mup | PR snapcraft#1274 closed: Simple explanation of what the test groups mean <Created by facundobatista> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1274> | 19:04 |
| zyga | jdstrand: question: I want to create an interface that provides data from snaps to unconfined world | 19:07 |
| zyga | jdstrand: technically snapd would need to expand $SNAP to the externally visible location of the mounted snap | 19:08 |
| jdstrand | zyga: can you be more specific. what kind of data? for what unconfined process to use? | 19:08 |
| zyga | jdstrand: so the question is this, it kind of feels like content but it's not really, snapd would need to manage a namespace of files (say snap.$SNAP_NAME.$stuff) in a fixed directory for that interface | 19:08 |
| zyga | jdstrand: specifically wallpapers for gnome | 19:09 |
| zyga | jdstrand: gnome needs an XML file that describes each wallpaper | 19:09 |
| zyga | jdstrand: I'd like to have a snap that can ship wallpapers and then get the XML file where the background selector expects it | 19:09 |
| zyga | jdstrand: I was thinking about possible attacks but let's set that aside for a moment and just think about mechanics | 19:09 |
| zyga | (we can say that each image is converted via a confined helper to a bmp so that it is not an attack vector) | 19:10 |
| zyga | jdstrand: should this be a new backend | 19:10 |
| zyga | jdstrand: that instances of that backend can manage things like this | 19:10 |
| zyga | jdstrand: (e.g. files that are visible from classic world) | 19:10 |
| jdstrand | fyi, it isn't thrilling to think about xml and image files coming from a snap to be fed to unconfined processes. the wallpapers code is likely not coded defensively against malicous input | 19:10 |
| jdstrand | images you can't really get away from, but xml parsing, this could be done in other ways | 19:11 |
| zyga | jdstrand: right, we can generate the xml in confined trusted helper, we can post-process each image as I described | 19:11 |
| zyga | jdstrand: I want to focus on just the part where you want to let snapd manage part (likely via glob like snap.*) of the classic filesystem | 19:11 |
| zyga | jdstrand: is that a new backend? | 19:11 |
| zyga | jdstrand: and if so is it generic or super specific to this instance of the problem | 19:11 |
| jdstrand | zyga: otoh I'd skip bind mounts. we have too many of them. just symlink from /usr/share/wherever/gnome/knows/about/wallpapers/snap.$SNAP_NAME.1.png to /snap/wallpapers/current/1.png | 19:13 |
| zyga | jdstrand: we need an xml file in /usr/share/gnome-background-properties/*.xml | 19:13 |
| zyga | jdstrand: then those files name (and describe) wallpapers | 19:13 |
| jdstrand | that's fine too | 19:13 |
| jdstrand | usr/share/gnome-background-properties/snap.$SNAP_NAME.1.xml or whatever | 19:14 |
| zyga | jdstrand: there's some meta-data like what is the background color, which type of scaling to use, etc etc | 19:14 |
| zyga | jdstrand: ok | 19:14 |
| zyga | jdstrand: snapd can even write that file though it'd be somewhat repetetive but doable (ther'es a lot of little useless things there like i18n) | 19:14 |
| niemeyer | pedronis: snapd#3239 reviewed too | 19:14 |
| mup | PR snapd#3239: many: show alias changes on snap alias/unalias (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3239> | 19:14 |
| jdstrand | point is, use the snap.$SNAP_NAME.* mechanism and hook into existing dirs with symlinks. this should work for all kinds of things and at least parts are generalizable | 19:14 |
| niemeyer | This also needs a second review ^^^ | 19:15 |
| zyga | jdstrand: symlinks targetting what? I think we need to get an actual file as $SNAP is not known at build time | 19:15 |
| jdstrand | generating xml is not, but, we could generate xml into /var/lib/snapd somewhere and symlink into there (or generate in place if that makes more sense) | 19:16 |
| zyga | jdstrand: right, that's doable | 19:16 |
| zyga | jdstrand: so snapd would manage generated files in /var/lib/snapd and symlinks in a designated directory | 19:16 |
| jdstrand | zyga: I was assuming that gnome just read the xml that told it where the images are. is that not correct? | 19:16 |
| zyga | jdstrand: yes that's correct | 19:17 |
| jdstrand | ok, yes | 19:17 |
| jdstrand | then what you said last | 19:17 |
| zyga | jdstrand: thanks, I may have some code for that in a few evenings :) | 19:17 |
| zyga | jdstrand: just something I wanted to tackle personally | 19:17 |
| zyga | jdstrand: perhaps this could be reused to allow man pages or other similar content | 19:18 |
| jdstrand | the generalizable part is symlinking data from known dirs to places in /snap. the wallpaper-specific part is the xml | 19:18 |
| zyga | (through again always the issue will be having software munge on untrusted data) | 19:18 |
| jdstrand | zyga: man pages I think we could do if we ran the man page through a linter. if it passes, symlink. if not, don't | 19:19 |
| jdstrand | that can happen at install/refresh | 19:19 |
| zyga | jdstrand: hmm, here it'd not be a symlink to /snap/* anything; I assumed snapd would generate the xml files in /var/lib/snapd/(made up, say dataproviders)/gnome-wallpapers/snap.hello-kitty-1.xml and put a symlink to that file in /usr/share/gnome-background-properties/snap.hello-kitty.xml | 19:20 |
| jdstrand | of course, that linter should run confined, but that isn't insurmountable | 19:20 |
| zyga | jdstrand: yeah, I think a linter or perhaps a transformation tool could be a generic step | 19:20 |
| jdstrand | zyga: yeah, that's fine too. I wasn't sure if gnome wanted the data in some convenient location | 19:20 |
| zyga | jdstrand: though interesting what ships the linter, perhaps a snap that has the slot? | 19:20 |
| zyga | jdstrand: just the xml files, the images can be anywhere | 19:21 |
| jdstrand | zyga: perhaps /usr/share/wallpapers so other DEs could use it without xml or something | 19:21 |
| pedronis | niemeyer: thanks | 19:21 |
| zyga | jdstrand: perhaps, I was trying to get it to work in gnome first but yeah; depending on how the interface is coded it could be a generic wallpaper provider | 19:21 |
| pedronis | niemeyer: "snap prefer" and "snap aliases" are the two left | 19:22 |
| jdstrand | zyga: if we are shipping man page, core snap should arguably have the man command. it would be easy to create a profile for man to have it run checks. effectively aa-exec -p man-lint -- man /snap/foo/current/path/to/man/page | 19:23 |
| jdstrand | are allowing shipping man pages | 19:23 |
| zyga | jdstrand: yes, for man I agree | 19:23 |
| jdstrand | it could be a separate snap such that if man command is present, just use it (putting the man page in the right place) | 19:24 |
| zyga | jdstrand: ha, the "man" snap | 19:24 |
| zyga | quite literally | 19:24 |
| jdstrand | yeah | 19:24 |
| zyga | it's also interesting for classic vs core | 19:24 |
| zyga | on core the snap makes sense | 19:24 |
| zyga | on classic the man slot would be on the core snap itself | 19:25 |
| jdstrand | well, possibly | 19:25 |
| jdstrand | I'd like to see the man command on there, but it isn't up to me | 19:25 |
| zyga | jdstrand: thanks for the discussion | 19:27 |
| jdstrand | np | 19:28 |
| jdstrand | this may actually help the plasma guy actually. there is a discussion there where he is running arbitrary script through a dbus api in order to set the wallpaper | 19:29 |
| zyga | jdstrand: aha, interesting, where is that discussion? | 19:29 |
| jdstrand | I wonder if whatever plasma needs (ie, its equivalent of gnome's xml), perhaps he doesn't need to do all that | 19:29 |
| jdstrand | snapcraft@ mailing list | 19:29 |
| zyga | jdstrand: yes, looking at more than one consumer of wallpapers would help | 19:29 |
| zyga | jdstrand: though this feels like wallpaper-control interface | 19:30 |
| jdstrand | it does | 19:30 |
| mup | PR snapcraft#1280 opened: Added support for 'branches' in Store responses (release, close, and status) <Created by facundobatista> <https://github.com/snapcore/snapcraft/pull/1280> | 19:31 |
| jdstrand | and that's ok. perhaps it uses the ExposeData (ie symlinks) backend or maybe not (depends if the data needs to be symlinked or just the meta data files) | 19:31 |
| facubatista | roadmr, ↑ | 19:31 |
| roadmr | facubatista: whee! | 19:32 |
| facubatista | :) | 19:32 |
| zyga | jdstrand: I see what you did there ;-) | 19:32 |
| zyga | jdstrand: naming backends already, thanks! | 19:32 |
| jdstrand | hehe | 19:32 |
| zyga | jdstrand: would you put the symlink + generate data functionality into that backend? | 19:32 |
| zyga | jdstrand: I'd actually allow the specification to carry that | 19:33 |
| jdstrand | maybe? | 19:33 |
| zyga | jdstrand: as after all, it's all in snapd | 19:33 |
| zyga | jdstrand: (then two interfaces can do different stuff without being any less trusted) | 19:33 |
| jdstrand | it seems clear that the backend would be useful for even just the xml, cause the backend could do the symlinking | 19:33 |
| zyga | jdstrand: yes, I bet it could be pretty generic | 19:33 |
| jdstrand | perhaps the backend has a generator api that could be xml for gnome, linter for man, nothing for /usr/share/wallpapers | 19:34 |
| zyga | jdstrand: yes, I think the symlinking is a generic feature but where the data comes from (generator) is a function the interface can attach to the specification | 19:35 |
| jdstrand | yeah | 19:35 |
| zyga | jdstrand: symlink or copy or something similar, details to be defined | 19:35 |
| jdstrand | yes | 19:35 |
| zyga | jdstrand: I also smell... | 19:35 |
| zyga | jdstrand: ssl :D | 19:35 |
| zyga | jdstrand: we could ship ssl certs with a plug | 19:35 |
| zyga | jdstrand: (and control via assertions) | 19:36 |
| zyga | jdstrand: and update out of bound or let private entities install their own certs | 19:36 |
| zyga | jdstrand: we may even look at desktop files a little this way (though that's a stretch) | 19:36 |
| zyga | jdstrand: (well just as an interface, much of the strucutre would fit right in) | 19:37 |
| zyga | jdstrand: maybe themes | 19:37 |
| * jdstrand nods | 19:37 | |
| zyga | jdstrand: I'd love if one could ship a theme this way and have it available in classic world and in snaps the same way (.so files aside) | 19:37 |
| zyga | anyway, I think I need to try something small firsT :) | 19:37 |
| pedronis | Chipaca: mvo: a 2nd review of snapd#3192 would be appreciated | 19:38 |
| mup | PR snapd#3192: many: implement snap unalias <alias-or-snap> (aliases v2) <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3192> | 19:38 |
| jdstrand | desktop is slightly messy cause they are so particular about the file name and the contents of the file, but sure | 19:41 |
| jdstrand | and yes, would be nice for themes. .so files are a bit scary though | 19:41 |
| niemeyer | pedronis: Just did snap prefer | 19:56 |
| niemeyer | pedronis: Looks sane, although it's getting a bit hard to make sure I'm not skipping anything | 19:57 |
| niemeyer | I'll take a break now | 19:58 |
| pedronis | niemeyer: yea, they are quite big :/ | 19:58 |
| pedronis | thx | 19:58 |
| zyga | niemeyer: enjoy! thanks for the reviews! | 19:58 |
| jdstrand | oh huh, 'assumes'. I hadn't seen that | 20:25 |
| mup | PR snapcraft#1281 opened: core: switch to version git <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1281> | 20:25 |
| ryebot | is there a timeout on `snap login`, or does the login token last indefinitely? | 20:55 |
| roadmr | ryebot: it should last unless you logout or change your password | 20:56 |
| ryebot | roadmr: excellent, thanks :) | 20:56 |
| roadmr | ryebot: (technically it expires periodically but snapd takes care of refreshing it for you, no need to re-enter credentials) | 20:57 |
| ryebot | roadmr: ah, good to know, thanks :) | 20:58 |
| niemeyer | zyga_: Thanks! | 22:02 |
| niemeyer | jdstrand: Yeah, not very well known | 22:02 |
| pedronis | niemeyer: I tried to answer the comments on the "snap aliases" one with some further questions, I do prefer to keep Status honestly | 22:36 |
| niemeyer | pedronis: Yo | 22:36 |
| niemeyer | pedronis: Sorry, which Status was that? | 22:36 |
| pedronis | niemeyer: Status in /aliases response | 22:36 |
| niemeyer | pedronis: Ah, ack.. what's the background? | 22:37 |
| pedronis | niemeyer: well we discussed a lot of options how to do things, having one set of aliases per snap is the simplest possible thing, not clear it will stay like that forever | 22:37 |
| pedronis | niemeyer: having one status per aliases should keep working though, independently of the policy by which they are disabled/enabled in groups | 22:38 |
| niemeyer | pedronis: Hmm | 22:38 |
| niemeyer | pedronis: I think we can always bring it back if necessary, but the structure we evolved towards in the server seems to ring a nice bell | 22:39 |
| niemeyer | pedronis: We basically have a snap, with aliases, and Auto/Manual targets | 22:40 |
| pedronis | niemeyer: well, it means the client needs to do all the computation that aliasesv2.go does to interpret the status | 22:40 |
| niemeyer | pedronis: Even if we introduce groups, it sounds like this would still fit | 22:40 |
| niemeyer | pedronis: Yeah, but isn't that trivial? I find it awkward that we're still modeling the client end after the old model when the server end seems to have improved a lot recently | 22:41 |
| pedronis | niemeyer: sorry, personally I find it strange to have to teach the exact semantics to the client code again | 22:43 |
| pedronis | it needs to know again that manual wins , apply a flag across aliases etc | 22:44 |
| niemeyer | pedronis: I find the opposite end strange: we're sending data to the client as if aliases might have individual settings, when they really can't... people will end up building algorithms on it which don't really make sense if they think that's the case | 22:44 |
| niemeyer | pedronis: If this sounds controversial, it would be fine to wait a bit I think | 22:45 |
| pedronis | niemeyer: well we need something, atm "snap aliases is broken" | 22:45 |
| niemeyer | Just disabling the API for the time being so we don't buy incompatibilities | 22:45 |
| niemeyer | pedronis: Ok, let's come back into this tomorrow then.. it's a bit late here, and even later there! | 22:45 |
| pedronis | niemeyer: I see it mostly as a display to user API atm, if we want to send more details they would probably go in /snap no, like other bits of snapstate? | 22:47 |
| niemeyer | pedronis: Hmm | 22:47 |
| niemeyer | pedronis: Okay, indeed.. we can keep this API and include the additional fields in the snap when we want to.. that's the idea I had as well (to have them in the actual snap structure instead of under /aliases) | 22:50 |
| niemeyer | pedronis: Can we replace "unaliased" by "disabled"? | 22:50 |
| niemeyer | pedronis: In the Status | 22:51 |
| pedronis | yes | 22:51 |
| niemeyer | pedronis: Okay, deal | 22:51 |
| pedronis | I think you proposed "unaliased" at some point, maybe because of snap install --unaliased ? | 22:51 |
| niemeyer | pedronis: I do have crackful ideas sometimes.. | 22:51 |
| niemeyer | pedronis: It's a terrible term for what is simply "disabled" | 22:52 |
| niemeyer | pedronis: and now that we have AutoAliasesDisabled, that stands out even more | 22:52 |
| pedronis | niemeyer: do we care about being backward compatible at all? I'm taking abotu App/app vs Command/command in the struct? | 22:53 |
| pedronis | s/taking/thinking/ | 22:54 |
| niemeyer | pedronis: In this particular case we've opted to bite the bullet and break compatibility to have a major overhaul, and I seriously doubt there was enough time for anyone to build on this API yet, so these two things summed up make me think it's fine | 22:54 |
| pedronis | ok | 22:55 |
| pedronis | so I'll change the struct and not just the output | 22:55 |
| pedronis | thanks | 22:55 |
| pedronis | in the morning though, it's indeed late | 22:55 |
| pedronis | niemeyer: I summarized what we discussed here in the PR | 22:57 |
| * pedronis -> rest | 22:59 | |
| pedronis | ttfn! | 22:59 |
| niemeyer | pedronis: Thanks a lot, and have a good night! | 23:01 |
| === kay is now known as Guest53543 | ||
| azubieta | Hello, I heard that the Ubuntu store is closing, will this affect snappy technologies to ? | 23:27 |
| kyrofa | azubieta, no no, just phones | 23:35 |
| kyrofa | snappy/ubuntu core is still going strong | 23:35 |
| azubieta | oh | 23:35 |
| azubieta | good | 23:35 |
| azubieta | :D | 23:35 |
| azubieta | thanks! | 23:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!