| mup | PR snapcraft#1961 closed: Sentry <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1961> | 00:48 |
|---|---|---|
| mup | PR snapcraft#1962 closed: store: stringify message for StoreDeltaApplicationError <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1962> | 00:51 |
| === nacc_ is now known as nacc | ||
| mborzecki | morning | 06:07 |
| Faults | Goood Morning! | 06:08 |
| mborzecki | mvo: morning | 07:08 |
| mvo | hey mborzecki ! | 07:15 |
| mvo | mborzecki: good morning | 07:15 |
| mborzecki | heh the timer services spread test is failing on 14.04, can't figure out why, cannot reproduce it in spread debug shell either even if i do `snap enable test-snapd-timer-service && snap disable test-snapd-timer-service` in a loop | 07:17 |
| mborzecki | and the error does not make any sense `start snap.test-snapd-timer-service.random-timer.timer] failed with exit status 6: Failed to issue method call: Unit snap.test-snapd-timer-service.random-timer.timer failed to load: No such file or directory` | 07:19 |
| mborzecki | hmm and we don't seem have any tests for enable/disable that touch services | 07:21 |
| mvo | mborzecki: hm, I have not seen this error before | 07:26 |
| mborzecki | mvo: this happens when i reenable the snap that has timer services, i'm adding a test right now to see if this happens also if there's just regular snap with services | 07:27 |
| mborzecki | mvo: also, the start happens after enabling the unit, so somehow systemctl enable worked, but systemctl start does not | 07:30 |
| zyga | hey mvo :) | 07:31 |
| mborzecki | zyga: hey | 07:31 |
| zyga | hey :-) | 07:31 |
| zyga | man, I overslept | 07:31 |
| mvo | mborzecki: hm, lets hope its not a general problem | 07:32 |
| mvo | zyga: hey, good morning | 07:32 |
| zyga | I got a failure of snap-service-refresh-mode | 07:33 |
| zyga | reinstall did stop a service that shouldn't | 07:33 |
| zyga | full log in https://api.travis-ci.org/v3/job/346989504/log.txt | 07:33 |
| * zyga notices the extended reply on https://forum.snapcraft.io/t/lxd-issue-due-to-snap-confine-apparmor-profile/4203/19 | 07:34 | |
| Jasem[m] | Can anyone help in this? https://forum.snapcraft.io/t/cannot-upload-to-store/4250/9 | 07:40 |
| Jasem[m] | i.e. why am I getting this external libusb symlink when I built with Snapcraft? | 07:40 |
| zyga | kalikiana ^ | 07:40 |
| pedronis | hi | 07:40 |
| mborzecki | pedronis: hey, morning | 07:41 |
| pedronis | mvo: while trying to understand why the core transition tests failed with my new code, I found an interesting thing about them | 07:42 |
| mvo | pedronis: tell me more | 07:43 |
| pedronis | mvo: since we have the base code we always install core when installing a new snap (if it's not there), even if ubuntu-core is there, so the two kind of test are the same now | 07:44 |
| mvo | pedronis: oh, indeed | 07:44 |
| pedronis | I don't know if there is something to do | 07:45 |
| pedronis | but I was confused for a bit | 07:45 |
| pedronis | (I found the problem with my new code) | 07:45 |
| * mvo nods | 07:47 | |
| pedronis | mvo: we might want to remove of them, or merge them somehow | 07:48 |
| pedronis | s/of them/one of them/ | 07:48 |
| pedronis | I don't think at this point fixing the "bug" make sense | 07:49 |
| mvo | pedronis: indeed, I would love to get rid of all of them but not quite yet (its an expensive test) | 07:50 |
| zyga | and let them live there before they get removed | 07:55 |
| zyga | pedronis did you push the fix for the timestamp issue to 2.32? | 07:58 |
| pedronis | no | 07:58 |
| pedronis | only master | 07:58 |
| zyga | I just got this failure in a 2.32-based PR, perhaps it's worth doing so | 07:59 |
| zyga | mvo I wanted to update you on layouts | 08:05 |
| zyga | there is one PR that I asked you to co-review with jamie, that I would like to cherry-pick into 2.32 | 08:06 |
| zyga | there will be a follow-up today, building upon the concept, that will have a similar fate | 08:06 |
| zyga | both of those should be cherry-picked into 2.32 | 08:06 |
| zyga | the changes are non-trivial so I wanted you to be aware of that | 08:06 |
| mvo | zyga: what is the risk of breaking things there? i.e. is it a new feature (user mounts) or modifying exiting behaviour? | 08:10 |
| pstolowski | mornings | 08:10 |
| zyga | mvo a bit of both | 08:10 |
| zyga | mvo snap-update-ns will now use per-snap profile | 08:11 |
| zyga | mvo the follow-up PR will remove broadly open permissions and replace them with values that match the layout of a given snap | 08:12 |
| zyga | as well as inject $SNAP_NAME (expanded) into many places that currently use a glob | 08:12 |
| mvo | zyga: how critical is that? 2.32 already contains quite a bit of churn and its only 2 weeks away. I'm a bit concerned about adding things that might break | 08:14 |
| mvo | zyga: maybe we can discuss in more detail in the standup? | 08:14 |
| zyga | mvo pretty critical I'm afraid, jamie requested that to be in 2.32 | 08:14 |
| zyga | to avoid pretty-much unconfined snap-update-ns | 08:15 |
| mvo | ok | 08:15 |
| kalikiana | o/ | 08:21 |
| Chipaca | mo'in | 08:28 |
| Chipaca | mvo: I'm off to the dentist's first thing, should be back for a late start (my 11am) | 08:29 |
| mvo | Chipaca: hey, thanks | 08:31 |
| mborzecki | https://github.com/snapcore/snapd/blob/master/wrappers/services.go#L250 daemon-reload should probably happen when we add service files, regardless of those being enabled or not, shouldn't it? | 08:33 |
| mvo | mborzecki: yes, good catch | 08:35 |
| zyga | hmm | 09:00 |
| zyga | I'm seeing failres of snap-info | 09:00 |
| mborzecki | zyga: oh, featured list changed again? or the install date? | 09:00 |
| zyga | no, it is summary, it seems | 09:00 |
| zyga | + snap info basic_1.0_all.snap /home/gopath/src/github.com/snapcore/snapd/tests/lib/snaps/basic-desktop test-snapd-tools test-snapd-devmode core /etc/passwd test-snapd-python-webserver | 09:01 |
| zyga | + python3 check.py | 09:01 |
| zyga | in test-snapd-tools.summary expected 'Tools for testing the snapd application', got '' | 09:01 |
| zyga | starting local run now | 09:01 |
| zyga | I doubt this is something that is broken in my branch as it is entirely unrelated | 09:02 |
| mborzecki | btw. don't recall, do we do any testing with recentish nvidia cards? | 09:03 |
| zyga | mborzecki sergio ran some tests remotely recently | 09:03 |
| zyga | mborzecki not sure how recent the hardware was though | 09:03 |
| mborzecki | hmm, the user that had the stack smashing detected on manjaro with nvidia drivers got back to me, he's seeing the problem on arch too, nvidia drivers 390 | 09:04 |
| mborzecki | i'll suggest him to open a topic in the forum, maybe jdstrand will be able to suggest something | 09:05 |
| zyga | and indeed | 09:14 |
| zyga | I don't get a summary | 09:14 |
| zyga | https://pastebin.ubuntu.com/p/m5KQPxNSw4/ | 09:14 |
| zyga | any ideas anyone? | 09:14 |
| zyga | description is also empty | 09:14 |
| mborzecki | it's coming from the local snap.yaml i suppose | 09:15 |
| ackk | mvo, hi, I'm getting this error https://paste.ubuntu.com/p/gTrF3Z8yTS/ when trying to rebuild the maas snap with the custom base-18. did something change in bionic? | 09:16 |
| mborzecki | zyga: when it goes from the store there's both summary and description https://paste.ubuntu.com/p/3GZR5q5XJC/ | 09:16 |
| mvo | ackk: this looks like a snapcraft change, I wonder if it is not taking bases into account? it takes about core there | 09:17 |
| mvo | ackk: maybe kalikiana can help with the above error (cc https://paste.ubuntu.com/p/gTrF3Z8yTS/) | 09:17 |
| ackk | mvo, oh, I wonder if I'm usin an older version now (I used to use snapcraft from the snap) | 09:18 |
| zyga | hmm, test-snapd-tools doesn't have a summary | 09:18 |
| zyga | (or description) | 09:18 |
| zyga | checking master now | 09:19 |
| zyga | hmm | 09:27 |
| zyga | it passed on master | 09:27 |
| zyga | trying again | 09:27 |
| zyga | and now my branch passed | 09:28 |
| zyga | mvo there's something wonky going on, snap-info fails ~ 2/3 runs | 09:28 |
| mvo | zyga: woah, for snap info - that is astonishing | 09:36 |
| zyga | I don't understand it yet, running one test I saw a failure a moment ago | 09:36 |
| zyga | now no failures for 3 runs | 09:36 |
| mvo | zyga: only in tests? or also on a real system | 09:36 |
| mvo | zyga: is this coming from the store or from the local snap? | 09:36 |
| zyga | only in tests so far | 09:36 |
| zyga | main/snap-info | 09:37 |
| zyga | good question | 09:37 |
| zyga | from the store | 09:37 |
| zyga | maybe we hit different machine via load balancing | 09:37 |
| zyga | and one gives wonky answers | 09:37 |
| BjornT | mvo: do you know anything about this error? https://pastebin.canonical.com/p/mdnpq6rM7T/ | 09:39 |
| BjornT | mvo: it started happening recently (noticed it today), so i would suspect something changed in snapcraft | 09:39 |
| BjornT | mvo: this is trying to build agains the base-18 on bionic | 09:40 |
| zyga | mvo so on my bionic machine I just installed test-snapd-tools | 09:40 |
| zyga | and it has a summary and desscription | 09:40 |
| ackk | mvo, BjornT's error is the same as mine | 09:40 |
| zyga | but just a moment ago inside a test I did the same and they were both empty (see the pastebin I sent earlier) | 09:40 |
| ackk | mvo, BjornT I'm trying to build with snapcraft from the snap (rather then the bionic one) and it now gets stuck on priming | 09:41 |
| pedronis | zyga: was the test using a different channel? | 09:43 |
| zyga | no | 09:44 |
| zyga | same test in a loop | 09:44 |
| zyga | it doesn't fail now, maybe store got fixed now | 09:44 |
| mvo | BjornT: I talked about this with ackk some minutes ago, it looks like snapcraft is not taking "base" into account when it warns about the glibc incompatibilities | 09:45 |
| BjornT | mvo: any chance of getting it fixed (or a workaround) quickly? it's blocking maas development | 09:46 |
| ackk | ah, the deb in bionic is newer than the snap stable version, I wonder if something broke there | 09:46 |
| mvo | BjornT: that is a question for sergiusens and/or kalikiana - I am not working on snapcraft myself, sorry. but lets hope they get back to you quickly | 09:47 |
| pstolowski | mvo, do you think #4762 could go o 2.31? | 09:53 |
| mup | PR #4762: servicestate: use systemctl enable+start and disable+stop instead of --now flag <Created by stolowski> <https://github.com/snapcore/snapd/pull/4762> | 09:53 |
| ackk | kalikiana, around? any suggestion on the issue above? ^ | 10:13 |
| zyga | I cannot reproduce snap-info error anymore | 10:23 |
| zyga | so maybe just a temporary fluke | 10:23 |
| zyga | pedronis is the store undergoing any updates now? | 10:23 |
| pedronis | we reverted something I think | 10:23 |
| pedronis | don't know if it was related | 10:23 |
| mvo | pstolowski: definitely 2.32, I think I will also cherry-pick to 2.31 just to be on the safe side | 10:26 |
| zyga | mvo 4760 is ready for your review now | 10:26 |
| mvo | zyga: must be later todday, I need to meet the feature freeze deadline for c-n-f | 10:28 |
| zyga | mvo understood | 10:28 |
| zyga | mvo curious, will you still tweak the output? | 10:28 |
| mvo | sorry! | 10:28 |
| zyga | I really didn't like the odd output I saw last night? | 10:28 |
| mvo | zyga: tweak the output of c-n-f ? | 10:28 |
| zyga | yes | 10:28 |
| mvo | https://bugs.launchpad.net/command-not-found/+bug/1749777 has the latest agreements as-i-understand-them | 10:29 |
| mup | Bug #1749777: Syntax tweaks for snap-friendly output <command-not-found:In Progress> <command-not-found (Ubuntu):In Progress> <https://launchpad.net/bugs/1749777> | 10:29 |
| === LtWorf_ is now known as LtWorf | ||
| mvo | zyga: there is a bit of controversy still but its difficult to find a solution that makes everyone happy, we discussed that quite a bit | 10:29 |
| zyga | what bugs me the most is that the mixed advice there doesn't give instructions on how to do anything about installing it | 10:30 |
| mvo | zyga: indeed, I think we did a pad with some clever ideas, just need to find it | 10:33 |
| zyga | mvo I made a trivial suggestion | 10:34 |
| zyga | https://bugs.launchpad.net/ubuntu/+source/command-not-found/+bug/1752185/comments/3 | 10:34 |
| mup | Bug #1752185: Formatting of command-not-found with snap addition could use cleanup <command-not-found (Ubuntu):Confirmed> <https://launchpad.net/bugs/1752185> | 10:34 |
| mvo | zyga: https://pad.ubuntu.com/1C0cSZX9oB | 10:34 |
| mvo | zyga: sure, that is welcome | 10:34 |
| zyga | mvo is "this is what we will do" part true? | 10:35 |
| zyga | as in, that's the thing you will code | 10:35 |
| pstolowski | mvo, ack | 10:37 |
| mup | PR snapd#4762 closed: servicestate: use systemctl enable+start and disable+stop instead of --now flag <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4762> | 10:38 |
| mvo | zyga: it was true | 10:38 |
| mvo | zyga: and then this bugreport with another version of the syntax came along | 10:39 |
| mvo | zyga: that was the outcome of a long(ish) meeting with john and gustavo, I think the result is good but its also noisy, the idea from mark has the advantage that its very compact | 10:39 |
| zyga | I think it just hast to be useful and feel good | 10:39 |
| zyga | good luck on that | 10:39 |
| kalikiana | ackk: Sorry, I was in a call. Looking in a moment | 10:51 |
| ackk | kalikiana, thanks | 10:51 |
| kalikiana | BjornT: What Snapcraft are you building with? Edge? There've been some recent fixes on master although base support is still a work in progress. I'd defer to sergiusens here since he's working on that. | 11:03 |
| ackk | kalikiana, I've been using stable, I'm building with edge now | 11:07 |
| ackk | kalikiana, priming now seems to take a very long time | 11:07 |
| ackk | kalikiana, it fails with edge as well | 11:08 |
| ackk | kalikiana, so, stable does seem to take into account bases, edge (or bionic package) doesn't | 11:08 |
| ackk | BjornT, kalikiana even no-system-libraries fails for me | 11:09 |
| BjornT | kalikiana: i'm using git master to build the snap. using no-system-libraries takes me further. it still prints out warnings and i get a snap. but now i get python import errors when trying to run the snap. it seems that /usr/bin/python3 is used, which doesn't have my python modules | 11:14 |
| cachio_ | pedronis, hey, running again the tests against stagin | 11:32 |
| cachio_ | g | 11:32 |
| pedronis | cachio_: no, need, I did this morning | 11:32 |
| pedronis | also there's a problem with staging | 11:32 |
| pedronis | we are trying to fix | 11:32 |
| cachio_ | pedronis, ok, so many errors? | 11:33 |
| pedronis | yes, not a lot | 11:33 |
| pedronis | but more that there should be | 11:33 |
| cachio_ | pedronis, ok, I am making a run now | 11:37 |
| cachio_ | pedronis, I already started it | 11:38 |
| pedronis | ok | 11:38 |
| mpt | Is it possible to have multiple versions of a snap installed simultaneously? | 11:54 |
| zyga | mpt not yet but Chipaca is working on that | 11:54 |
| mpt | ah, cool | 11:54 |
| Chipaca | no i'm not | 11:54 |
| Chipaca | :) | 11:54 |
| Chipaca | but i will be, next | 11:55 |
| Chipaca | or, rather, that's the next big thing i'll be working on | 11:55 |
| mup | PR snapd#4765 opened: interfaces/apparmor: use snap name instead of wildcards <Created by zyga> <https://github.com/snapcore/snapd/pull/4765> | 11:57 |
| mup | PR snapcraft#1964 opened: Fix Store integration tests with updated snap name registration error messages (take 2) <Created by chipaca> <https://github.com/snapcore/snapcraft/pull/1964> | 11:57 |
| zyga | I need some reviews | 11:57 |
| zyga | for this (last patch only) | 11:57 |
| zyga | and the one before | 11:57 |
| zyga | anyone interested | 11:57 |
| zyga | this one is actually trivial | 11:57 |
| zyga | https://github.com/snapcore/snapd/pull/4765/commits/caafe76f4c3040426573b81def2a645119c68451 | 11:57 |
| mup | PR #4765: interfaces/apparmor: use snap name instead of wildcards <Created by zyga> <https://github.com/snapcore/snapd/pull/4765> | 11:57 |
| mpt | Chipaca, ok. When you do have multiple versions installed, will they always have access to the same interfaces? Or will it be possible to differentiate? (for example one version has access to the camera while the other doesn’t) | 11:59 |
| Chipaca | mpt: as I understand it they'll be separate entities as far as that aspect of things | 12:00 |
| Chipaca | mpt: but there isn't even a forum topic about it yet, so it's rather green | 12:01 |
| mpt | Chipaca, thanks. (Reason I’m asking is, that means they’ll need to be listed separately — and disambiguated — in GUIs for seeing/changing what permissions they currently have.) | 12:01 |
| Chipaca | mpt: (if you feel strongly one way or the other now'd be an ideal time to bring it up :-) ) | 12:01 |
| cachio_ | pedronis, I uploaded 3 snaps to staging | 12:06 |
| cachio_ | pedronis, it should fix the 3 failing tests that I swaw | 12:06 |
| cachio_ | I0ll re run to see we have 100% passing | 12:06 |
| BjornT | kalikiana: fwiw, i tried this patch: https://paste.ubuntu.com/p/s2t3wct5J3/ | 12:11 |
| BjornT | kalikiana: the maas snap builds then, but then the configure hook complains: https://paste.ubuntu.com/p/G3dsTh33Fg/ | 12:12 |
| BjornT | kalikiana: libssl.so.1.1 is in the snap, though | 12:12 |
| BjornT | kalikiana: btw, LD_LIBRARY_PATH doesn't seem to be set | 12:17 |
| mup | PR snapd#4766 opened: userd: add an OpenFile method for launching local files with xdg-open <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4766> | 12:21 |
| zyga | Chipaca have a look at 4755 please | 12:22 |
| cachio_ | mvo, still working with sru | 12:40 |
| cachio_ | I see some denials | 12:40 |
| cachio_ | https://paste.ubuntu.com/p/6WJfXd952Q/ | 12:41 |
| cachio_ | zyga, I am tesintg on google and I see bionic has not SElinux enabled | 12:48 |
| zyga | cachio_ why would it be enabled? | 12:48 |
| cachio_ | zyga, well, hte problem is that we are trying to uninstall snapd_selinux package | 12:49 |
| cachio_ | and it is failing | 12:49 |
| zyga | that package only exists for fedora | 12:49 |
| cachio_ | the package is not installed | 12:49 |
| zyga | why would we do that? | 12:49 |
| cachio_ | we do that in the upgrade test | 12:49 |
| cachio_ | ok, in that case something else is wrong | 12:51 |
| cachio_ | zyga, after remove and reinstall snapd | 12:51 |
| zyga | there's no such package in ubuntu or anywhere else but fedora | 12:51 |
| cachio_ | zyga, I see all the snaps broken | 12:51 |
| zyga | so probably some wrong pattern somewhere | 12:51 |
| cachio_ | zyga, ok, thanks!! | 12:52 |
| Chipaca | zyga: you sure you meant to ask me to look at my own pr? | 12:52 |
| zyga | yes :) meant to look at the feedback | 12:53 |
| Chipaca | zyga: I think I'll just replace it with a MatchCounter | 12:54 |
| Chipaca | the gist of this pr predates that :-) | 12:54 |
| mup | PR snapd#4767 opened: interfaces: disconnect hooks <Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4767> | 12:57 |
| mup | PR snapd#4763 closed: osutil: handle file being matched by multiple patterns (2.32) <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4763> | 13:01 |
| jdstrand | zyga: hey, I approved PR 4745 | 13:03 |
| mup | PR #4745: osutil: allow creating strings out of MountInfoEntry <Created by zyga> <https://github.com/snapcore/snapd/pull/4745> | 13:03 |
| zyga | jdstrand hey, thank you! | 13:03 |
| jdstrand | zyga: I looked at PR 4765, but I think the rules need tuning. lots of apparmor denieds | 13:03 |
| mup | PR #4765: interfaces/apparmor: use snap name instead of wildcards <Created by zyga> <https://github.com/snapcore/snapd/pull/4765> | 13:03 |
| zyga | jdstrand I'm going through hardening, got slowed down by store issue in the morning but now I'm iterating quickly | 13:03 |
| zyga | yes, I'm fixing that now | 13:04 |
| jdstrand | ok | 13:04 |
| jdstrand | I've added it to my list. when it passes automated tests, I'll look at it | 13:04 |
| zyga | thanks! | 13:05 |
| mup | PR snapd#4745 closed: osutil: allow creating strings out of MountInfoEntry <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4745> | 13:06 |
| mvo | cachio_: hm, wonder if snapd-app-helper in our installed profile | 13:12 |
| mup | PR snapd#4768 opened: [RFC] snap userd autostart v2 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4768> | 13:16 |
| === ondra_ is now known as ondra | ||
| * kalikiana lunch time | 13:32 | |
| Chipaca | sergiusens: kyrofa: snapcraft#1964 fixes your integration tests vis-a-vis new validation failure messages | 13:35 |
| mup | PR snapcraft#1964: Fix Store integration tests with updated snap name registration error messages (take 2) <Created by chipaca> <https://github.com/snapcore/snapcraft/pull/1964> | 13:35 |
| sergiusens | mvo: BjornT no, becuase I asked what the official bases would be named (you are CCed in that email mvo) to actually work on this ;-) | 13:37 |
| sergiusens | Chipaca: maxiberta is the integration store server updated to follow these strings? Once this is updated, all the store triggers will fail until updated, are you aware of that? | 13:48 |
| Chipaca | sergiusens: what's the 'integration store server'? | 13:49 |
| Chipaca | sergiusens: and what are 'store triggers'? | 13:49 |
| mup | PR snapcraft#1963 closed: Fix Store integration tests with updated snap name registration error messages <Created by maxiberta> <Closed by maxiberta> <https://github.com/snapcore/snapcraft/pull/1963> | 13:54 |
| sergiusens | Chipaca: OLS triggers pre-deployment tests using our test suite against the integration/staging store | 13:56 |
| Chipaca | sergiusens: ah! that's why maxiberta wrote the first PR (which didn't address the whole issue) | 13:57 |
| sergiusens | Chipaca: yeah, but this is chicken and egg problem unless we allow dual results in the tests :-) | 13:58 |
| mvo | sergiusens: core18 | 13:58 |
| mvo | sergiusens: will be the name | 13:58 |
| mvo | sergiusens: but there might be more | 13:58 |
| Chipaca | sergiusens: … the code with the new errors is on staging | 13:58 |
| Chipaca | sergiusens: maybe I'm not understanding something | 13:59 |
| sergiusens | Chipaca: oh, I am asking, I am not stating :-) | 13:59 |
| sergiusens | Chipaca: let's make this simple, cprov can you +1 https://github.com/snapcore/snapcraft/pull/1964 :-) | 13:59 |
| mup | PR snapcraft#1964: Fix Store integration tests with updated snap name registration error messages (take 2) <Created by chipaca> <https://github.com/snapcore/snapcraft/pull/1964> | 13:59 |
| Chipaca | sergiusens: maxiberta is probably the person to answer, then | 13:59 |
| Chipaca | I am far from understanding all the links, I just dived in there and broke stuff | 13:59 |
| Chipaca | :) | 13:59 |
| maxiberta | the new strings are already deployed on staging Store | 14:00 |
| cprov | sergiusens: production rollout is in progress, the changes matches what we have in production | 14:00 |
| sergiusens | mvo: is there a forum post or something where everyone +1s? I thought that was the process for bases. I would really like to see general agreement for this as it would be really hard for us to change this (wrt SRUing) if this changes | 14:00 |
| cprov | *will* have in production in a few minutes | 14:00 |
| sergiusens | cprov: great, then in it goes | 14:00 |
| cprov | thank you | 14:01 |
| zyga | pstolowski, niemeyer: when you talk about "snap connections", I'd love to participate | 14:01 |
| maxiberta | thanks Chipaca, sergiusens | 14:01 |
| pstolowski | zyga, sure. but i think i'll go with something straighforward as outlined by nimeyer during the standup, not sure we will discuss it more | 14:03 |
| * pstolowski lunch | 14:03 | |
| mup | PR snapcraft#1964 closed: Fix Store integration tests with updated snap name registration error messages (take 2) <bug> <Created by chipaca> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1964> | 14:07 |
| Chipaca | sergiusens: what is the 'assigned' thing github tells me when you merge stuff? | 14:07 |
| Jasem[m] | I'm getting error when uploading a snap to the store | 14:08 |
| Jasem[m] | package contains external symlinks: usr/lib/x86_64-linux-gnu/libusb-1.0.so lint-snap-v2_external_symlinks | 14:08 |
| sergiusens | Chipaca: just my internal way of making sure later who worked on what to backtrack and provide a thank you drink ;-) | 14:08 |
| Jasem[m] | But the package was built with snapcraft, isn't suppose to take care of such links? | 14:08 |
| sergiusens | Jasem[m]: some snaps are allowed some symlinks, so we cannot remove them "magically" or part of the building populus might be unable to create snaps in the first place | 14:09 |
| Jasem[m] | Chipaca: well, any idea how to resolve this problem then? | 14:11 |
| sergiusens | you can use `stage` or `prime` keywords to filter it out, but somehow I think the actual package from the archive in this case might be problematic as .so files are usually linked directly to a .so.<version> in the same directory (and this one seems to be using an absolute path) | 14:11 |
| cachio_ | mvo, did you see the denial on the sru? | 14:13 |
| cachio_ | mvo, I have a debug open | 14:15 |
| niemeyer | zyga, pstolowski: We should definitely have talk about it before spending much time on one direction | 14:20 |
| niemeyer | Forum is great for that | 14:20 |
| niemeyer | Chipaca: Just responded on that thread | 14:20 |
| Chipaca | niemeyer: appreciated | 14:21 |
| mup | PR snapd#4769 opened: wrappers: detect whether systemd-analyze can be used in unit tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4769> | 14:22 |
| Chipaca | niemeyer: can we line up the 'days' to make scanning easier? | 14:22 |
| niemeyer | Chipaca: think it'll look awkward in the general context | 14:23 |
| niemeyer | Chipaca: Similar issue we had with "installed" (the version) | 14:23 |
| niemeyer | Chipaca: Also, "today" and "yesterday" won't align either | 14:23 |
| Chipaca | true dat | 14:24 |
| Chipaca | the former is less a concern now that the first indent isn't all uniform | 14:24 |
| Chipaca | (for the best i think) | 14:24 |
| Chipaca | but, it's not like we're oging to have 10 of these lines :-) so i'm just being a nit | 14:24 |
| Chipaca | niemeyer: thanks | 14:24 |
| niemeyer | Chipaca: np, thanks for calling it out | 14:25 |
| zyga | mmmm | 14:31 |
| zyga | pierogi :-) | 14:31 |
| zyga | I missed that | 14:31 |
| zyga | jdstrand 4765 is green now | 14:32 |
| zyga | if you look at the 2nd patch there the review is easier | 14:32 |
| mvo | cachio_: yeah, so about the denial> what do you see with " grep device-helper /etc/apparmor.d/usr.lib.snapd.snap-confine.real " | 14:34 |
| cachio_ | mvo, empty | 14:36 |
| mvo | cachio_: hm, that sucks | 14:39 |
| mvo | cachio_: if you grep for udev in there, what do you get? | 14:39 |
| mvo | cachio_: and please also grep for usr.lib.snapd | 14:39 |
| jdstrand | zyga: ack | 14:41 |
| * cachio_ afk | 14:42 | |
| zyga | mvo that's weird | 14:47 |
| zyga | what's on bionic? | 14:47 |
| * zyga finished with pierogi and gets back to hardening | 14:47 | |
| mvo | zyga: it looks like something is wrong with the apprmor profile, but its strange | 14:52 |
| zyga | hmm, didn't we have something like that a moment ago | 14:52 |
| mvo | zyga: oh, actually - 2.31 still have udev/snappy-app-dev | 14:52 |
| zyga | the device-helper rules went away | 14:52 |
| zyga | hmmmm | 14:54 |
| zyga | what was that | 14:54 |
| zyga | ah | 14:54 |
| zyga | I remember now | 14:54 |
| zyga | but that was for a re-exec rule | 14:54 |
| zyga | and just for testing scenarios | 14:54 |
| zyga | not for real-life issues | 14:54 |
| zyga | and in either case, we fixed that one | 14:55 |
| zyga | so ... | 14:55 |
| zyga | no idea, I'll go back to hardening | 14:55 |
| mvo | cachio_: do you have more context about the sru error? I see the denial but in what test is that happening? what is odd is that on 2.31 we have /lib/udev/snappy-app-dev - we moved to snap-device-helper only in 2.32 | 15:08 |
| mvo | cachio_: just let me know when you are back, happy to look at this then | 15:10 |
| pstolowski | niemeyer, zyga ok! | 15:13 |
| ikey | ok jdstrand whats a good non-conflict definition to copy for an interface? | 15:30 |
| zyga | to copy for an interface? | 15:30 |
| zyga | what does that mean? | 15:31 |
| ikey | like for making a new interface | 15:31 |
| zyga | ah | 15:31 |
| zyga | you wanna start with something and iterate | 15:31 |
| ikey | whatever it is i went with last time was wonky | 15:31 |
| zyga | start with common | 15:31 |
| zyga | then see what you miss | 15:31 |
| zyga | most things are fine with common | 15:31 |
| ikey | my actual definitions were fine for apparmor and seccomp | 15:31 |
| ikey | its the actual interface struct that was wonky | 15:31 |
| ikey | which seems woefully undocumented | 15:32 |
| zyga | no no, just use commonInterface | 15:32 |
| pedronis | zyga: I'm getting this kind of error: cannot update snap namespace: cannot create writable mimic over "/opt": permission denied | 15:32 |
| pedronis | snap-update-ns failed with code 1 | 15:32 |
| ikey | i c | 15:32 |
| zyga | pedronis on /opt?, hmmm that's weird | 15:32 |
| zyga | do you have the full log | 15:32 |
| pedronis | I get this: [Wed Feb 28 14:44:11 2018] audit: type=1400 audit(1519829052.799:113): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="/snap/core/409/usr/lib/snapd/snap-confine//snap_update_ns" name="/tmp/.snap/opt/" pid=14715 comm="3" srcname="/opt/" flags="rw, rbind" | 15:33 |
| ikey | so yeah im using commonInterface. | 15:33 |
| ikey | i think this is what causes the problem: https://hastebin.com/wonojepoqo.cpp | 15:34 |
| ikey | but i honestly have nfc what it means | 15:34 |
| ikey | i copy pasted from something else a while back | 15:34 |
| zyga | pedronis do you have this line in the profile: | 15:34 |
| zyga | mount options=(rbind, rw) /** -> /tmp/.snap/**, | 15:34 |
| pedronis | that I don't know | 15:34 |
| pedronis | it's a full run | 15:34 |
| zyga | is it just a log? | 15:34 |
| zyga | ah | 15:35 |
| zyga | drat | 15:35 |
| zyga | no idea | 15:35 |
| zyga | it looks like we start and we have the wrongest profile ever | 15:35 |
| zyga | I saw this with /etc | 15:35 |
| zyga | maybe it's the same bug that mvo saw as well | 15:35 |
| zyga | as something clearly puts the wrong profile (like very old one) around us | 15:35 |
| pedronis | zyga: maybe you can add debug: to print the profiles to main/layout ? | 15:35 |
| zyga | maybe one of the migration tests reaks t he backup | 15:35 |
| zyga | yeah, good idea, I'll do that | 15:35 |
| zyga | *breaks the backup | 15:35 |
| ikey | zyga, any thoughts on that paste? | 15:37 |
| zyga | ikey oh, I didn't notice | 15:37 |
| zyga | looking | 15:37 |
| zyga | ikey and what's the problem? | 15:38 |
| ikey | its borked | 15:38 |
| zyga | so | 15:38 |
| ikey | so it was working on our existing snapd installs | 15:38 |
| ikey | but for *new snapd users* it bricked core | 15:38 |
| zyga | those are rules that say what can be done with an interface | 15:38 |
| ikey | right and i cant find any *usable* documentation on it | 15:38 |
| zyga | bricked coreR? | 15:38 |
| ikey | ya | 15:38 |
| ikey | core couldnt be installed | 15:38 |
| zyga | allow-installation: false | 15:39 |
| zyga | is this an implicit interface? | 15:39 |
| ikey | idk what that means either | 15:39 |
| ikey | again, documentation, lol | 15:39 |
| zyga | the rules are basically saying what you can and cannot do | 15:39 |
| ikey | ive been asking about this for months now.. | 15:39 |
| ikey | its the steam-support interface that gives permissions to the steam snaps | 15:40 |
| ikey | and ideally we only want those to use it | 15:40 |
| ikey | but apparently thats all private store side behaviour | 15:40 |
| zyga | they get enforced by the policy checker | 15:40 |
| zyga | look at basedeclaration.go | 15:40 |
| ikey | ya ive read it | 15:40 |
| zyga | there's a lot of documentation there | 15:40 |
| pedronis | cachio_: hi, afaict we need newer versions of test-snapd-content-plug/slot in staging | 15:40 |
| ikey | lots of words that dont really explain anything to anyone outside the inner circle | 15:40 |
| zyga | ikey so maybe I can help you out in practice | 15:41 |
| zyga | tell me about the interface you're working on | 15:41 |
| zyga | is it going to be added by core implicitly | 15:41 |
| zyga | or will it live in a specific snap | 15:41 |
| cachio_ | pedronis, ok | 15:41 |
| cachio_ | 1 minutes | 15:41 |
| pedronis | thank you | 15:41 |
| ikey | zyga, its the interface that will be added to snapd to give the permissions for steam to run | 15:41 |
| ikey | so linux-steam-integration would connect to it | 15:41 |
| ikey | and pop holes in the sandbox | 15:41 |
| zyga | ikey who will have the slot side? | 15:42 |
| ikey | ? | 15:42 |
| zyga | is it going to be linux-steam-integration snap itself | 15:42 |
| ikey | ya | 15:42 |
| zyga | or is that going to be on core? | 15:42 |
| ikey | what | 15:42 |
| zyga | I mean, look at network interface | 15:42 |
| pedronis | cachio_: I have all the other tests passing also with my code (except layout but that sort of weird fluke I have seen prod spread too) | 15:42 |
| ikey | ok see now you're confusing me again | 15:42 |
| ikey | there is no documentation on this difference | 15:42 |
| zyga | the core provides is (the slot) and anyone can get a plug and connect | 15:42 |
| ikey | just assumptions of prior knowledge and examples | 15:42 |
| zyga | the network interface is "implicit" so it gets automatically added to the core snap (as a slot) | 15:43 |
| ikey | i dont use core snap | 15:43 |
| cachio_ | pedronis, perfect | 15:43 |
| ikey | this is for solus-runtime-gaming + linux-steam-integration.. | 15:43 |
| zyga | another idea is to have a special interface that is not on the core snap (the slot) and is actually added, directly, in meta/snap.yaml in some snap | 15:43 |
| ikey | remember solus-runtime-gaming is a base snap | 15:44 |
| zyga | ikey sure but even if you don't use the core snap the interface has a plug and slot side and both plugs and slots must inhabit *some* snap to exist | 15:44 |
| zyga | so | 15:44 |
| zyga | my question is: who has the slot side of this new interface | 15:44 |
| ikey | at this point i genuinely dont know the different between slot and plug | 15:44 |
| ikey | because the terminology is grossly conflated | 15:44 |
| zyga | depending on the answer to that question we can determine the policy that will make it work | 15:44 |
| ikey | linux-steam-integration is the snap that *uses* steam-support | 15:45 |
| zyga | ikey a plug and a slot is just two ends of a wire | 15:45 |
| ikey | yes i know that but which ends go were aren't exactly well defined | 15:45 |
| ikey | case in point, core | 15:45 |
| zyga | typically the slot side is the offering end | 15:45 |
| zyga | it provides some service or capability or other thing | 15:45 |
| ikey | ok well in the plugs in snap.yaml we add steam-support | 15:45 |
| ikey | cuz we need it there. | 15:45 |
| zyga | until you connect the plug side to the slot side, the plug side cannot consume that thing and doesn't get permissions | 15:45 |
| zyga | ok | 15:45 |
| ikey | for linux-steam-integration | 15:45 |
| zyga | ok | 15:46 |
| zyga | so I suspect the slot side of steam-support is going to exist on the core snap (again, just for the sake of having to exist somewhere) | 15:46 |
| cachio_ | pedronis, test-snapd-content-plug updated | 15:46 |
| ikey | so "core snap" in this context really meaning "snapd" ? | 15:46 |
| zyga | but I may not be fully up to date on your discussions with jamie | 15:46 |
| === nacc_ is now known as nacc | ||
| zyga | ikey the long story short | 15:46 |
| zyga | no, the core snap | 15:46 |
| ikey | but i dont use core snap.. | 15:46 |
| zyga | it's all in snapd code but the core snap is the thing that can host implicit slots | 15:47 |
| cachio_ | pedronis, the test-snapd-content-slot seem to be already in the last rev | 15:47 |
| pedronis | cachio_: ok, good, wasn't sure | 15:47 |
| pedronis | thank you | 15:47 |
| pedronis | I'll try the one tests again | 15:47 |
| zyga | it isn't relevant, it's the same as you use the "network" plug in your apps and then even if you use a different base snap you get the network permission parts from this connection | 15:47 |
| zyga | ikey to fix your problem: | 15:47 |
| ikey | ok | 15:47 |
| ikey | so core defines /things/ | 15:47 |
| zyga | ikey drop the allow-installation: false line | 15:47 |
| ikey | what about those deny ones? | 15:48 |
| ikey | i assume we want autoconnect defined by store right? | 15:48 |
| zyga | and if I'm wrong and the slot side is going to be in a dedicated snap, you need to have this pre-arranged with jdstrand | 15:48 |
| zyga | yes | 15:48 |
| ikey | slot side meaning .. ? | 15:48 |
| zyga | the deny connection and deny auto connection look fine | 15:48 |
| ikey | ok | 15:48 |
| ikey | i dont "use" slots anywhere btw | 15:48 |
| zyga | the "slot side" is "the name of the snap that will ship something that looks like slots: steam-support" | 15:48 |
| ikey | just plugs | 15:49 |
| zyga | do you have any connection-based rules in that interface? | 15:49 |
| ikey | https://hastebin.com/qoqozopire.bash <- is what i have | 15:49 |
| zyga | if you have a longer pastebin with the diff, I could look | 15:49 |
| zyga | ha :D | 15:49 |
| zyga | thank you | 15:49 |
| zyga | steamSupportConnectedPlugSecComp | 15:49 |
| zyga | so the name here says it all | 15:49 |
| zyga | this is what the *plug* side gets after connecting (to a slot side) in terms of seccomp permissions | 15:49 |
| ikey | (not really its a copy paste job :P) | 15:49 |
| ikey | right | 15:50 |
| zyga | and I see you have "implicitOnCore" and "implicitOnClassic" | 15:50 |
| ikey | ya, copy paste | 15:50 |
| ikey | i have no idea what it does | 15:50 |
| ikey | :P | 15:50 |
| zyga | (yeah but my point was that those are still connection oriented concepts) | 15:50 |
| ikey | righto | 15:50 |
| ikey | i believe the original notion was to block any snap in the store autoconnecting steam-support | 15:50 |
| ikey | due to the holes it exposes | 15:51 |
| zyga | ok, if you drop the line I mentioned (allow-installation) it should move on | 15:51 |
| zyga | yeah | 15:51 |
| ikey | cuz the whole ptrace kerfuffle | 15:51 |
| zyga | then specific snaps will get an assertion that say it can connect to steam-support | 15:51 |
| ikey | like linux-steam-integration ^^ | 15:51 |
| ikey | im copying this log down locally for notes btw :P | 15:51 |
| ikey | ok so nuke that line, rebase onto git, and new PR | 15:52 |
| zyga | cool! :) | 15:52 |
| zyga | see if it works for you | 15:52 |
| zyga | not sure if anything else is missing | 15:52 |
| ikey | well that was the only issue was ran into | 15:52 |
| ikey | fresh snapd went to fetch core for the first time | 15:52 |
| ikey | and complained loudly about steam-support | 15:53 |
| ikey | obviously its a fairly nasty interface in that it "extends" another | 15:53 |
| ikey | alright cheers ima go do that | 15:54 |
| zyga | cool, good luck | 15:55 |
| * zyga replied on the LXD issue and prepares a patch for the layout bug and writes more hardening patches | 15:55 | |
| zyga | zyga.fork().fork().fork() | 15:55 |
| ikey | lol | 15:55 |
| ikey | cgroups chase you | 15:55 |
| zyga | cgroups are lovely | 15:55 |
| zyga | until 2.0 that is | 15:56 |
| ikey | xD | 15:56 |
| pedronis | cachio_: interfaces-content now passes | 16:00 |
| zyga | pedronis what did you chagne? | 16:01 |
| zyga | *change | 16:01 |
| pedronis | zyga: this was about wrong snap revision | 16:02 |
| pedronis | zyga: that failure was from main/layout | 16:02 |
| pedronis | I mean nothing to do with the thing we discussed about /opt | 16:02 |
| zyga | ack | 16:02 |
| mvo | cachio__: forum post about this problem that snap-confine runs /lib/udev/snappy-app-dev from the core snap which is a symlink in the beta core which leads to the apparmor denails that you saw on the SRU verification | 16:05 |
| mvo | cachio__: I'm not sure what the right fix is. I'm also not sure why we run the snappy-app-dev inside core and if we have to do that | 16:05 |
| mvo | zyga: I guess you don't remember why we run snappy-app-dev inside core - maybe we need to run it late when we are already inside this env. but it might mean we can never rename snappy-app-dev :/ | 16:06 |
| mup | PR snapd#4770 opened: store: parse the JSON format used by the coming new store API to convey snap information <Created by pedronis> <https://github.com/snapcore/snapd/pull/4770> | 16:06 |
| zyga | why we run snappy-app-dev inside core, I think that's easy | 16:07 |
| zyga | because we do that after we pivot root | 16:07 |
| * zyga looks | 16:07 | |
| zyga | yeah | 16:07 |
| zyga | we do that super late | 16:07 |
| zyga | hold on | 16:07 |
| zyga | we _can_ rename | 16:07 |
| zyga | we just have to be less direct | 16:07 |
| zyga | we can try the new name first | 16:08 |
| zyga | and if it's not there, fall back | 16:08 |
| zyga | and allow both in apparmor | 16:08 |
| zyga | it's like renaming snap-exec to snap-make-it-so | 16:08 |
| zyga | just | 16:09 |
| zyga | make it so | 16:09 |
| * zyga swooshes away | 16:09 | |
| mvo | zyga: right, but it means we need a transiton time where the appamor profile is updated | 16:09 |
| zyga | yes | 16:09 |
| mvo | zyga: which means we probably need to revert the rename for 2.32 | 16:10 |
| mvo | /o\ | 16:10 |
| * zyga thinks | 16:10 | |
| zyga | so | 16:10 |
| zyga | 2.32 | 16:10 |
| zyga | is this for revert? | 16:10 |
| zyga | or from reexec from stable deb | 16:10 |
| mvo | zyga: it is for when you run 2.31 and disable re-exec. then 2.31 snap run will run the 2.31 snap-confine which will not have the right rule yet | 16:11 |
| mvo | zyga: for 2.31 with re-exec everything is fine because then the right snap-confine with the correct profile runs | 16:11 |
| zyga | wait I don't follow | 16:12 |
| * mvo waits | 16:13 | |
| zyga | so | 16:13 |
| mup | PR snapd#4771 opened: store: add Store.InstallRefresh to support the new install/refresh api endpoint <Created by pedronis> <https://github.com/snapcore/snapd/pull/4771> | 16:13 |
| zyga | 2.31 is in the deb or in the core snap in your example? | 16:14 |
| cachio__ | zyga, we install 2.31.1 from deb | 16:15 |
| zyga | ok | 16:15 |
| cachio__ | and the core snap is the one in beta 2.32 | 16:16 |
| cachio__ | and it is set | 16:16 |
| zyga | so 2.31.1 deb, with all the right snap-confine profiles, installs core and gets 2.32 | 16:16 |
| cachio__ | SPREAD_MODIFY_CORE_SNAP_FOR_REEXEC=0 SPREAD_TRUST_TEST_KEYS=false SPREAD_SNAP_REEXEC=0 SPREAD_CORE_CHANNEL=beta | 16:16 |
| zyga | mvo so far so good? | 16:16 |
| zyga | mvo is that accurate? | 16:16 |
| mvo | zyga: sorry, 2.31.1 is in the deb, 2.32 (with the rename) is in the core snap | 16:17 |
| zyga | ok | 16:17 |
| zyga | so far so good | 16:17 |
| zyga | and that so far works | 16:17 |
| mvo | zyga: with *no* reexec | 16:17 |
| zyga | then we disable reexec, right? | 16:17 |
| mvo | zyga: correct | 16:17 |
| zyga | ah | 16:17 |
| zyga | I see | 16:17 |
| zyga | but | 16:17 |
| zyga | ahhh | 16:17 |
| zyga | we have a compat symlink? | 16:17 |
| zyga | nothing more? | 16:17 |
| mvo | zyga: correct | 16:18 |
| mvo | zyga: aha! | 16:18 |
| zyga | ok | 16:18 |
| mvo | zyga: so we just install the real thing :) ? | 16:18 |
| mvo | zyga: smart! | 16:18 |
| * mvo hugs zyga | 16:18 | |
| * zyga hugs mvo back and thinks about what the solution is | 16:18 | |
| mvo | zyga: didn't you just suggest the solution? | 16:19 |
| zyga | mvo you made the solution, I'm just the garden thing :) | 16:19 |
| zyga | haha, I apparently did b | 16:19 |
| zyga | but you get it and I'm still processing | 16:19 |
| mvo | zyga: if we install the real thing in two places | 16:19 |
| zyga | yes | 16:19 |
| zyga | that will work | 16:19 |
| mvo | zyga: nstead of a symlink it should work | 16:19 |
| ikey | i seem to remember you guys mentioned this being fixed somewhere: go build github.com/snapcore/snapd/cmd/snap-seccomp: invalid pkg-config package name: --static | 16:19 |
| ikey | any pointers? | 16:19 |
| zyga | ikey ah, that's the golang security SNAFU | 16:20 |
| zyga | i think we reverted the --static linking in master | 16:20 |
| ikey | oh right | 16:20 |
| zyga | and do soma hackery in ubuntu builds to restore it manually | 16:20 |
| ikey | o | 16:20 |
| zyga | but I didn't do that so no good links | 16:20 |
| * ikey hits up https://github.com/snapcore/snapd/commits/master/cmd/snap-seccomp | 16:20 | |
| ikey | https://github.com/snapcore/snapd/commit/536f30bebcbaca8b391919afbda8dd67b360d45d.patch | 16:21 |
| ikey | heh | 16:21 |
| mup | PR snapd#4772 opened: tests/lib/fakestore/store: teach the fake store to fake the new install/refresh endpoint <Created by pedronis> <https://github.com/snapcore/snapd/pull/4772> | 16:21 |
| zyga | mvo I was thinking about a bind mount becase that fools apparmor | 16:22 |
| zyga | but installing twice is just perfect | 16:22 |
| zyga | +10 | 16:22 |
| ikey | iirc we really /should/ force static linking on seccomp right? | 16:22 |
| zyga | it's complex | 16:23 |
| zyga | sometimes yes | 16:23 |
| ikey | i seem to remember it giving heartattacks to apparmor | 16:23 |
| zyga | but it depends on the context | 16:23 |
| * ikey finds a lump hammer | 16:24 | |
| ikey | bye freenode | 16:24 |
| zyga | hmm? | 16:25 |
| ikey | hi freenode. >_> | 16:25 |
| zyga | was that a bouncy hammer? | 16:25 |
| ikey | lol wasnt me i swear | 16:25 |
| ikey | this seems to make it work: | 16:25 |
| ikey | GOPATH="`pwd`" go build -o bin/snap-seccomp --ldflags '-extldflags "-static"' -v github.com/snapcore/snapd/cmd/snap-seccomp | 16:25 |
| zyga | ikey of *course* it does | 16:26 |
| zyga | programming is so logical | 16:26 |
| ikey | XD | 16:26 |
| ikey | ok well it builds at least | 16:27 |
| ikey | lets see the verdict .. | 16:27 |
| ikey | zyga, it might make more sense if i reopen my original PR and submit the fix-commit on top? | 16:28 |
| ikey | this way we preserve the old discussions | 16:28 |
| zyga | yeah, that'd be great | 16:28 |
| ikey | and then if someone wants to chuck the rebase on top, go for gold | 16:28 |
| ikey | we'll see if github likes the notion of merging first | 16:28 |
| ikey | ill get runtime-snaps changed over in git and wean them off devmode | 16:28 |
| ikey | zyga, https://github.com/solus-project/runtime-snaps/commit/d3e3e6c0e231b3e09081a603296331a0e97917e7 :p | 16:31 |
| zyga | arses in gear | 16:32 |
| zyga | that's the spirit | 16:32 |
| ikey | lol | 16:32 |
| * zyga googles what that means | 16:32 | |
| zyga | does it mean | 16:32 |
| ikey | literally just get moving and stop stalling | 16:32 |
| zyga | "let's get off our ass and do an interface"? | 16:32 |
| ikey | right | 16:32 |
| zyga | very graphic :) | 16:32 |
| ikey | mm | 16:32 |
| zyga | as we literally didn't move much | 16:33 |
| zyga | to write this | 16:33 |
| ikey | alright in theory i can install the (very old) runtime | 16:33 |
| ikey | and just build a new sideloaded snap app | 16:33 |
| ikey | and then test they havent died | 16:33 |
| ikey | i.e. regressed from the last time | 16:33 |
| ikey | and that should be all good in the hood for sending | 16:33 |
| === kwmonroe_ is now known as kwmonroe | ||
| ikey | can snaps hit the store prior to the interfaces being generally available btw? | 16:34 |
| ikey | i want to kill the old snaps with fire | 16:34 |
| zyga | I don't know | 16:34 |
| ikey | guess we'll find out eh | 16:34 |
| zyga | I suspect it will be flagged for manuak | 16:34 |
| pedronis | I started proposing some PRs for the new api | 16:34 |
| zyga | manual* | 16:34 |
| ikey | sudo ./mkapp.sh 193.03s user 40.57s system 46% cpu 8:25.21 total | 16:42 |
| ikey | not bad :o | 16:42 |
| mup | PR snapd#4773 opened: tests: add debug for layout test <Created by zyga> <https://github.com/snapcore/snapd/pull/4773> | 16:43 |
| * zyga read that tonight parts of poland will go to -24C | 16:44 | |
| === rharper` is now known as rharper | ||
| ikey | :o | 16:44 |
| zyga | so close | 16:44 |
| zyga | I remember going to high school one day (during daytime) when it was -25 | 16:44 |
| zyga | but it was before we all had phones | 16:44 |
| zyga | so nobody knew the school is closed | 16:44 |
| zyga | so I went back and forth | 16:45 |
| ikey | oof | 16:45 |
| ikey | btw is the store seeing traffic issues lately? | 16:45 |
| ikey | only hitting 2.30mbs on a download | 16:45 |
| ikey | (100mbps connection) | 16:45 |
| zyga | dunno | 16:46 |
| zyga | download is from CDN | 16:46 |
| * ikey blames snow | 16:46 | |
| mup | PR snapcraft#1965 opened: tests: remove ProjectOptions dependency from integration suite <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1965> | 16:46 |
| ikey | ok looking good | 16:49 |
| ikey | steam client is downloading.. | 16:49 |
| ikey | (had to manually snap connect ofc :)) | 16:50 |
| ikey | zyga, https://ibin.co/3tHZHjqBVVBh.png :) | 16:53 |
| zyga | I need to refresh my steam game collection | 16:54 |
| zyga | but ... all the patches | 16:54 |
| zyga | ikey nice :-) | 16:54 |
| ikey | ok so i reopened old PR, added the new commit on top | 16:54 |
| mup | PR snapd#4538 opened: interfaces/builtin: Add new steam-support interface <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4538> | 16:55 |
| ikey | ty, bot | 16:55 |
| cachio__ | zyga, do you have a5 minuts to see something? | 16:59 |
| zyga | sure | 16:59 |
| sergiusens | niemeyer: here's a first start on the ref https://forum.snapcraft.io/t/snapcraft-yaml-reference/4276 | 17:01 |
| cachio__ | zyga, hold on, I can't find the pass for the vm on google backend | 17:01 |
| niemeyer | sergiusens: Sweet, thank you! | 17:02 |
| niemeyer | sergiusens: The formatting is a bit strange, but with that material we should be able to easily play until we find something comfortable | 17:02 |
| sergiusens | niemeyer: as a first draft I welcome any suggestions | 17:02 |
| niemeyer | sergiusens: I'm not even sure what to suggest at this point.. not obvious to me either.. but now that we have the material it's easy to play.. I'll have a try later today | 17:03 |
| sergiusens | niemeyer: I tried to mimic the google docs we had, the table width should be modifieable with some CSS (on the forum at least) | 17:03 |
| niemeyer | sergiusens: I'd prefer to not play with the width.. if we're going too wide, it's not going to be comfortable to read | 17:03 |
| niemeyer | sergiusens: See the introductory material for example (Getting started, etc).. the width feels pretty reasonable | 17:04 |
| p7f_ | hi: could someone help with creating a Qt/QML snap? nothing i found in internet worked for me | 17:05 |
| sergiusens | niemeyer: yeah, that one does look good :-) | 17:06 |
| cachio__ | zyga, any idea what could be causing that problem? | 17:11 |
| zyga | no | 17:11 |
| cachio__ | zyga, it is just happening on bionic | 17:11 |
| zyga | see if this is package update scripts | 17:12 |
| zyga | or something the test is doing | 17:12 |
| zyga | I don't know | 17:12 |
| cachio__ | zyga, ok, I'll start with the update scripts | 17:13 |
| cachio__ | tx | 17:13 |
| === devil is now known as Guest59388 | ||
| * kalikiana heading out | 17:24 | |
| sergiusens | cprov: some store things seem broken https://travis-ci.org/snapcore/snapcraft/jobs/347284826 | 17:31 |
| cprov | sergiusens: let me take a look | 17:35 |
| cprov | sergiusens: pexpect timeout don't tell us much about what is failing :-/ | 17:38 |
| niemeyer | pedronis: Where's account "title" coming from? | 17:39 |
| pedronis | niemeyer: it's the display-name | 17:39 |
| niemeyer | pedronis: We have "username" and "display-name" in the account assertions | 17:39 |
| sergiusens | cprov: yeah, I know, these silent tests are killing me in the sense that we never really know what goes on, elopio can we get this one fixed? | 17:39 |
| niemeyer | pedronis: That's also how we generally referred to those filed, I think? | 17:40 |
| niemeyer | pedronis: A person's "title" is something else (Ms., etc) | 17:40 |
| cprov | sergiusens: I can only think of some issue with the test creds, tests are passing locally against staging -> https://pastebin.canonical.com/p/XfPbxgWHg7/ | 17:41 |
| pedronis | niemeyer: I think they come from wgrant/nessita, these names | 17:41 |
| niemeyer | pedronis: Sure, I mean in terms of design :) | 17:41 |
| sergiusens | cprov: thanks, I'll leave it to elopio then | 17:42 |
| pedronis | niemeyer: I need to have dinner, I'm personally fine either way, I'm not quire sure why s/display-name/title/ | 17:44 |
| niemeyer | pedronis: Okay.. let's catch up with nessita and wgrant then | 17:45 |
| niemeyer | pedronis: Enjoy! | 17:45 |
| pedronis | niemeyer: I mean I'm quite sure they were called display-name and username at some point, I'm not sure why they got changed to this | 17:56 |
| niemeyer | pedronis: Agreed, let's catch up with them | 17:59 |
| pedronis | niemeyer: as you can see in infroFromStoreSnap most other things have quite matching names now | 17:59 |
| pedronis | niemeyer: the only other serious divergence I spot is in deltas: source/target vs FromRevision/ToRevision | 18:03 |
| niemeyer | pedronis: It'd definitely be good to sync, but I'm less concerned about that one.. we won't be talking much about that | 18:04 |
| pedronis | yes | 18:04 |
| pedronis | just pointing out | 18:04 |
| niemeyer | pedronis: Accounts is a can of worms, though, and that's part of the sauce inside that can | 18:04 |
| pedronis | afai see the rest is quite aligned, except publisher | 18:04 |
| pedronis | but I vaguely remember we started from the assertion names | 18:05 |
| pedronis | and I don't know why we got there | 18:05 |
| niemeyer | pedronis: What about publisher? | 18:06 |
| niemeyer | pedronis: Is publisher not the publisher? | 18:06 |
| pedronis | it is the publisher | 18:06 |
| pedronis | I mean the field inside it | 18:06 |
| pedronis | *fields | 18:06 |
| niemeyer | pedronis: Ah, ok, phew | 18:07 |
| pedronis | no publisher is the publisher | 18:08 |
| pedronis | (I would be very unhappy if we do all this work to again mix that up) | 18:08 |
| cprov | sergiusens, elopio: FWIW our creds results in a green run -> https://travis-ci.org/snapcore/snapcraft/builds/347383931 | 18:13 |
| cachio__ | pedronis, do you know which scripts are executed when the snapd upgrade is done? | 18:22 |
| pedronis | cachio__: nothing super interesting , debian/snapd.maintscript and debian/snapd.postinst | 18:24 |
| pedronis | we do interresting things when we are removed though | 18:24 |
| pedronis | snapd.postrm | 18:24 |
| cachio__ | pedronis, ah, ok, I'll take a look to those scripts | 18:26 |
| === chihchun_afk is now known as chihchun | ||
| === mcphail_ is now known as mcphail | ||
| cachio__ | zyga, do you know where all the mounts are done after an upgrade? | 19:16 |
| mup | Issue snapcraft#1954 closed: Implement support for `common-id` <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1954> | 19:39 |
| mup | PR snapcraft#1960 closed: extractors: add support for common-id <enhancement> <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1960> | 19:39 |
| cachio__ | niemeyer, I dont see any ubuntu - 32 bits | 19:53 |
| cachio__ | in google compute images | 19:53 |
| cachio__ | niemeyer, any idea where to find? | 19:54 |
| cachio__ | which project | 19:54 |
| pedronis | cachio__: I think there was some discussion around having them made, but no, they don't exist yet afaik | 19:59 |
| cachio__ | pedronis, ah, ok | 19:59 |
| cachio__ | bad news | 19:59 |
| mup | PR snapd#4774 opened: tests: adding ubuntu-14.04-64 to the google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4774> | 20:19 |
| pedronis | niemeyer: talked with Natalia, no big objection to rechanging but double checking, we want s/title/display-name/ s/name/username/ in publisher ? | 20:27 |
| mup | PR snapcraft#1965 closed: tests: remove ProjectOptions dependency from integration suite <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1965> | 20:42 |
| mup | PR snapcraft#1966 opened: grammar: support `to` statement in source <do-not-merge-yet> <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1966> | 20:42 |
| niemeyer | pedronis: I think that matches exactly what's in the account assertion now, right? | 20:48 |
| niemeyer | If so, yeah, sounds like a good win to have a single set of terms | 20:48 |
| niemeyer | These terms also feel less ambiguous, which is another win.. username is classical.. everybody knows what to expect, and display-name is a bit more unusual, but also typical in our usage | 20:50 |
| niemeyer | cachio__: I don't think they have it.. as I mentioned today in the standup, ideally the cloud team would just push that one too.. otherwise we'll need to cook the image ourselves | 20:51 |
| mup | PR snapd#4775 opened: timeutil: timeutil.Human(t) gives a human-friendly string for t <Created by chipaca> <https://github.com/snapcore/snapd/pull/4775> | 20:53 |
| cachio__ | niemeyer, ok | 20:54 |
| cachio__ | about the ubuntu core | 20:55 |
| cachio__ | 2018-02-28 17:40:04 Cannot allocate google:ubuntu-core-16-64: cannot find any Google image matching "ubuntu-os-cloud-devel/daily-ubuntu-core-16-v20161108" on project "ubuntu-os-cloud-devel" | 20:55 |
| cachio__ | I see this error trying to use that image | 20:55 |
| cachio__ | niemeyer, https://paste.ubuntu.com/p/NXPSSVgQXN/ | 20:55 |
| cachio__ | this is the image I am trying to use | 20:55 |
| cachio__ | but itdoesn't work if I set image: ubuntu-os-cloud-devel/daily-ubuntu-core-16-v20161108 | 20:56 |
| cachio__ | in spread.yaml | 20:56 |
| cachio__ | niemeyer, any idea? | 20:56 |
| niemeyer | cachio__: Strange.. let me check | 20:57 |
| cachio__ | I am gonna add some extra debug info into the google backend to see | 20:57 |
| niemeyer | cachio__: Is that for our snapd's ubuntu-core images? | 20:57 |
| pedronis | niemeyer: yes, assertion has username and display-name | 20:58 |
| cachio__ | yes | 20:58 |
| niemeyer | pedronis: Cool | 20:58 |
| cachio__ | niemeyer, I am trying to test that | 20:58 |
| niemeyer | cachio__: Note that our images are not ubuntu-core images.. we can't do much with one of those | 20:58 |
| cachio__ | niemeyer, on, in that case I'll try to use the xenial image as we are doing currently | 20:59 |
| niemeyer | cachio__: I suggest digging a bit into the way ubuntu-core images are cooked for testing.. | 21:00 |
| cachio__ | niemeyer, ok | 21:02 |
| mup | PR snapcraft#1967 opened: project_loader: improve the logic to install patchelf on arm <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1967> | 21:06 |
| niemeyer | cachio__: Found the problem.. the API is returning less results than documented, 10 fold less.. I'll need to add support for pagination | 21:11 |
| cachio__ | niemeyer, good | 21:11 |
| cachio__ | niemeyer, thanks for see that | 21:11 |
| niemeyer | np | 21:12 |
| niemeyer | But now it's time for school pick up.. laters | 21:12 |
| mup | PR snapcraft#1968 opened: demos: avoid use of the wrapper for java-hello-world <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1968> | 21:12 |
| zyga | cachio__ mounts are done by systemd, we don't stop / start the units on package updates | 21:27 |
| zyga | unless that's something new in bionic but I don't know anything about that | 21:27 |
| Chipaca | bash manpage: "use --rcfile <file> to run file instead of /etc/bash.bashrc and ~/.bashrc". bash code: "source /etc/bash.bashrc; source rcfile or ~/.bashrc" | 21:48 |
| Chipaca | :-(((( | 21:48 |
| * Chipaca goes for icecream | 21:49 | |
| zyga | Chipaca ? | 21:52 |
| * zyga hands chipaca some lemon ice cream | 21:52 | |
| Chipaca | zyga: the bash in xenial at least, and against what's documented, always sources /etc/bash.bashrc | 21:55 |
| Chipaca | which means: | 21:55 |
| Chipaca | you'll always get the 'how to use sudo' message on 'snap run --shell' | 21:56 |
| Chipaca | zyga: please tell me you're going to the sprint next week | 21:58 |
| Chipaca | I remember how excited you got over turkish delight in london, and budapest is swimming in the stuff | 21:59 |
| kyrofa | noise][, nessita the store had a "scan error" on one of my snap revisions. It's not even showing up in my rev list, but none of the subsequent snaps are being scanned as a result (they all say "waiting for <link to other scan> to finish") | 22:14 |
| kyrofa | I'm fairly certain I could unblock things by rejecting and removing from the queue, but this seems like something that shouldn't happen | 22:14 |
| kyrofa | I don't see a reason to hold up reviews because earlier ones had issues | 22:15 |
| kyrofa | roadmr, I guess that ^ may interest you as well | 22:16 |
| kyrofa | Some sort of "rescan" button would be nice | 22:17 |
| kyrofa | I guess I'll try rejecting this one | 22:17 |
| roadmr | kyrofa: WIT | 22:17 |
| roadmr | WAIT | 22:17 |
| roadmr | which snap is this? | 22:17 |
| kyrofa | Okay | 22:17 |
| kyrofa | nextcloud | 22:17 |
| roadmr | give me a sec | 22:17 |
| roadmr | kyrofa: https://dashboard.snapcraft.io/snaps/nextcloud/revisions/5423/ is the blocky one, right? | 22:18 |
| kyrofa | You got it | 22:18 |
| roadmr | kyrofa: we've been seeing upload issues since yesterday, this strange state seems to be because there's no upload linked to this snap :( | 22:19 |
| roadmr | we haven't pinpointed the cause for the problem yet. | 22:19 |
| kyrofa | roadmr, status.snapcraft.io is all green | 22:20 |
| kyrofa | roadmr, anyway, not sure what the deal is with that snap, but we need these other ones released. How best do we unblock this? | 22:23 |
| roadmr | kyrofa: give me a sec to check things on my side. | 22:23 |
| kyrofa | Alright | 22:23 |
| roadmr | kyrofa: don't start rejecting/removing others from the queue. It won't help - the wedged one will remain there and block any new uploads | 22:23 |
| roadmr | kyrofa: to be clear - this is abnormal, a bug | 22:23 |
| roadmr | kyrofa: usually when an upload gets stuck there's a very clear "rescan this dammit" button | 22:24 |
| roadmr | I don't see it here; like you said, hell, I don't even see the upload | 22:24 |
| roadmr | kyrofa: oh wow - an oops referencing another oops | 22:28 |
| kyrofa | Oops inception | 22:31 |
| roadmr | oopseption :) | 22:31 |
| kyrofa | roadmr, things seem to be moving, now | 22:59 |
| roadmr | kyrofa: wgrant fixed them. Thanks William! | 22:59 |
| wgrant | It'll take a few minutes to process the backlog of nextcloud revisions, but it's getting there. | 23:03 |
| kyrofa | wgrant, these are uploads from LP. They aren't being released into proper channels, but I haven't received any emails about failures. Will it try again at some point? | 23:15 |
| kyrofa | Or have they timed out? | 23:16 |
| roadmr | kyrofa: if an upload gets held for manual review, the "intent to release" for the other ones is lost, as I remember :( | 23:18 |
| roadmr | https://bugs.launchpad.net/snapstore/+bug/1684529 | 23:18 |
| mup | Bug #1684529: Need for manual review loses intent to release to channel <Snap Store:New> <https://launchpad.net/bugs/1684529> | 23:18 |
| kyrofa | Ah yes, I remember that one | 23:18 |
| roadmr | kyrofa: sorry about that... if once the queue is clear you do another build, that one should get released properly, since the queue is clear | 23:18 |
| * roadmr said "queue is clear" twice | 23:18 | |
| roadmr | thrice! no one expects the spanish inquisition! | 23:18 |
| roadmr | kyrofa: do you accept transfer of snappy-m-o to you from elopio ? | 23:19 |
| kyrofa | roadmr, I do. Just put it into the forum for tracking purposes as well | 23:19 |
| roadmr | kyrofa: thanks, it's the proper place, I normally then e-mail the parties to verify but since elopio is a well-known user and so are you, I can check via irc :) | 23:20 |
| kyrofa | roadmr, good deal, thank you :) | 23:20 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
