| koala_man | how does snapcraft determine the version number from a git repository? my version number is way off | 01:30 |
|---|---|---|
| diddledan | koala_man: it doesn't by default. You can set the version to "git" and it'll use the commit hash as the version string. Otherwise it uses whatever you set in the yaml. You can also use a version-script to code the rules for your application's source | 02:06 |
| diddledan | Caelum: doesn't `go build` work? | 02:07 |
| koala_man | diddledan: ok.. so where does v0.3.0 come from in https://build.snapcraft.io/user/koalaman/shellcheck/177997 ? | 02:27 |
| diddledan | weird, it looks like it's picked up v0.3.0 from git via a tag somewhere, but then appended a commit hash on it (right at the bottom of the log): | 02:30 |
| diddledan | https://www.irccloud.com/pastebin/sftr0qcu/ | 02:30 |
| koala_man | yes, but why did it pick 0.3.0 and not e.g. the latest 0.4.7 or the earliest 0.1.0? | 02:31 |
| diddledan | that I'm not sure about | 02:31 |
| diddledan | perhaps the commit history on master doesn't match any of those other tags? | 02:32 |
| diddledan | so 0.3.0 is the latest tag that is in sync with master | 02:33 |
| diddledan | in sync - I mean has a shared most recent commit in the tag with a commit that exists in master | 02:33 |
| diddledan | might have to wait till the european daytime to get some more concrete answers from sergiusens when he awakens | 02:34 |
| diddledan | or kyrofa if he's still awake? | 02:34 |
| koala_man | I'm not entirely sure what you mean but `git log master` definitely shows other tags | 02:39 |
| === verterok` is now known as verterok | ||
| mborzecki | morning | 05:13 |
| mup | PR snapd#4908 closed: [RFC] cmd/snap-confine: attempt to detect if multiarch host uses arch triplets <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4908> | 06:19 |
| === chihchun_afk is now known as chihchun | ||
| zyga | good morning | 06:57 |
| zyga | mborzecki: I see that yesterday evening was fruitful | 06:57 |
| mborzecki | zyga: hey, yes | 06:58 |
| zyga | can you please prepare a backport for 2.32 as well | 06:58 |
| mborzecki | yup, already have it, checked it on ubuntu too | 06:59 |
| zyga | great, what's the PR for that? | 07:00 |
| zyga | we could prepare another release today | 07:00 |
| mup | PR snapd#4952 opened: [2.32] cmd/snap-confine: attempt to detect if multiarch host uses arch triplets <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4952> | 07:00 |
| zyga | the media test is failing on fedora | 07:01 |
| zyga | looks like a real bug | 07:01 |
| mborzecki | zyga: might need the same treatment as media-sharing test on fedora | 07:02 |
| mborzecki | zyga: idk if you recall, that's /media vs /run/media | 07:02 |
| zyga | + test-snapd-removable-media.sh -c 'ls /media/testdir' | 07:02 |
| zyga | ls: cannot access '/media/testdir': No such file or directory | 07:02 |
| zyga | yes, I know exactly | 07:02 |
| zyga | I had to code that difference | 07:02 |
| zyga | :/ | 07:02 |
| zyga | ok, looking at what's there | 07:02 |
| zyga | I _really_ wish fedora shipped a /media -> /run/media symlink | 07:03 |
| zyga | but ... well | 07:03 |
| mborzecki | i fixed media-sharing ~3 weeks ago, but iirc removable-media test was opened long before that | 07:03 |
| zyga | mborzecki: were there any changes to the nvidia multiarch fix since I read that | 07:03 |
| mborzecki | zyga: just one commit, i dropped some debug messages per niemeyer's request | 07:04 |
| zyga | great | 07:04 |
| zyga | ok, brb for coffee (I woke up waaay to late today) | 07:04 |
| mborzecki | zyga: oh and maybe a commit with some comments (as suggested by jdstrand) | 07:04 |
| zyga | when wife and kids don't go to school | 07:04 |
| zyga | I'll review it shortly | 07:04 |
| kalikiana | moin moin | 07:12 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | mornings! | 07:21 |
| mborzecki | kalikiana: pstolowski: morning | 07:21 |
| zyga | hey kalikiana | 07:23 |
| jamesh | zyga: re. the safe bind mount branch, I had some new thoughts about simplifying it but am not sure of the security concerns | 07:37 |
| jamesh | zyga: what if we did a bind mount from /proc/self/fd/$source_fd to /proc/self/fd/$target_fd? | 07:38 |
| jamesh | it'd avoid the need for the stash directory, and it ensures the source and destination are anchored at the expected locations | 07:39 |
| zyga | jamesh: hmm, that's interesting | 07:45 |
| zyga | did you try it? | 07:45 |
| jamesh | giving it a go. | 07:45 |
| zyga | jamesh: that's pretty interesting I must say | 07:45 |
| zyga | would be awesome if it works | 07:45 |
| jamesh | it'd also handle bind mounting files | 07:46 |
| jamesh | since there's no more fchdir() | 07:46 |
| zyga | yes, iff this works it's pretty interesting | 07:49 |
| zyga | I wonder what happens to /proc/pid/fd in this scenario | 07:49 |
| zyga | open a directory with O_DIRECTORY (and with or without O_PATH) | 07:49 |
| zyga | inspect the fd in /proc | 07:49 |
| zyga | mv the directory around, replace with symlink or whatever | 07:49 |
| zyga | inspect the fd in proc | 07:50 |
| zyga | jamesh: I also found /proc/pid/root as useful thing but kernel folks broke it because OMG security :/ | 07:57 |
| zyga | jamesh: it would allow mounting from one ns to another | 07:57 |
| zyga | (it did until it was changed) | 07:57 |
| zyga | mborzecki: 4952 reviewed | 07:59 |
| zyga | mborzecki: question: what do we need to do to remove nvidia as compile time option entirely, and make it fully dynamic | 07:59 |
| mborzecki | zyga: imo we'd need to interpret data coming os-release, pick the right location based on known paths | 08:01 |
| zyga | what kind of choices would we make? can you walk me through this please? | 08:02 |
| jamesh | zyga: using a simple Python example, it mounted the expected directory after a move | 08:04 |
| zyga | that's super promising! | 08:04 |
| jamesh | so the mount followed the file descriptor rather than the name | 08:05 |
| zyga | jdstrand: ^^ FYI, I think jamesh found the holy grail of mounting | 08:05 |
| mborzecki | zyga: choosing the location where the libraries are, i.e /usr/lib/ & /usr/lib32 on arch, /usr/lib/<arch-tiplet> on debian/ubuntu, /lib64(?) on fedora (although i think this might be close to arch), historically some drivers would install under their /usr/{libdir}/nvidia{-maybe-suffix} path, that also varies from distro to distro and release to release | 08:06 |
| jamesh | zyga: here's the test program I used: https://paste.ubuntu.com/p/zvpjCcmcjm/ | 08:06 |
| mborzecki | zyga: don't recall what suse does, it's probably close to fedora (or the reference layout of systemd distros) | 08:07 |
| zyga | mborzecki: I see, thanks | 08:08 |
| zyga | mborzecki: I'm weighting this against need for nvidia-xxx snap | 08:08 |
| zyga | and the pros/cons | 08:08 |
| jamesh | zyga: I tried extending it to do the read only remount, but that fails. Presumably because dest_fd references the directory underneath the mount point rather than the mount point itself | 08:11 |
| zyga | after the mount we can open another fd | 08:11 |
| mborzecki | zyga: do you mind if i fix https://github.com/snapcore/snapd/pull/4952#discussion_r177972590 in master once we merge the release branch back? | 08:12 |
| mup | PR #4952: [2.32] cmd/snap-confine: attempt to detect if multiarch host uses arch triplets <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4952> | 08:12 |
| zyga | mborzecki: not at all | 08:12 |
| mborzecki | ok, thx | 08:13 |
| zyga | I'm looking at fedora failure now | 08:13 |
| mborzecki | removable media? | 08:13 |
| zyga | yes | 08:13 |
| mborzecki | ok | 08:13 |
| mborzecki | btw. just restarted the build on 4952 for the 2nd time now, first one failed fetching stuff from github/gopkg.in, now it failed fetching the snaps from store | 08:14 |
| zyga | noise][, hey, is the store operational again? | 08:15 |
| Caelum | zyga: the rpm build is doing a test even if I don't have a %check section, do you know how to not do that? | 08:17 |
| zyga | what kind of test? | 08:17 |
| Caelum | it's running: + /usr/lib/rpm/golang.sh test github.com/snapcore/snapd/... | 08:18 |
| zyga | ah | 08:18 |
| zyga | looks like something built into the rpm macro for golang itself | 08:18 |
| mborzecki | Caelum: maybe it's golang rpm stuff? | 08:18 |
| Caelum | yeah | 08:18 |
| zyga | no, no idea how to turn it off, you'd have to look at expansion of the macro | 08:18 |
| Caelum | ok thanks! | 08:19 |
| zyga | one question | 08:19 |
| zyga | what's the original macro in the spec file? | 08:19 |
| * zyga is rusty on that | 08:19 | |
| zyga | Caelum: are you sure it's %gobuild that is doing that | 08:24 |
| zyga | I see %gotest in %check | 08:24 |
| Caelum | I commented it out and it still happens | 08:26 |
| Caelum | that's the thing I don't get | 08:26 |
| Caelum | oh I figured it out, I need a %check section with some command | 08:27 |
| zyga | hmmm | 08:28 |
| zyga | well, not sure | 08:28 |
| zyga | maybe ask in #opensuse-buildservice, people there may be able to help more than I can | 08:28 |
| zyga | I tried to expand %gobuild with 'rpm -E' but it didn't expand | 08:28 |
| zyga | mborzecki: question about /media vs /run/media | 08:30 |
| zyga | it fails becasue snap-confine on fedora bind mounts /run/media | 08:30 |
| zyga | now my idea is as follows | 08:31 |
| zyga | inside snap execution environment we could make /media == /run/media | 08:31 |
| zyga | so | 08:31 |
| zyga | snap authors will have easier way to reason about how things work | 08:32 |
| mborzecki | zyga: sounds good | 08:33 |
| mborzecki | zyga: will both locations be avaialble? | 08:33 |
| zyga | yes | 08:34 |
| mborzecki | zyga: ok | 08:34 |
| zyga | yeah, I think this is easier than hacking the test | 08:34 |
| zyga | which should not depend on the host | 08:34 |
| mborzecki | right | 08:34 |
| mborzecki | media-sharing test will need an update then | 08:34 |
| zyga | no, actually it should work just the same | 08:35 |
| zyga | my point is that host's native $MEDIA_DIR just becomes both /media and /run/media inside the execution environment | 08:35 |
| zyga | in core18 we could perhaps make /media as symlink into /run/media | 08:36 |
| mborzecki | zyga: yes, but the test tries to figure out what host it's running on and chooses /media or /run/media, if we make those equivalent, it would make sense to update the test to either always look in /media or compare both locations (maybe the latter) | 08:39 |
| zyga | it does so on the outside | 08:39 |
| zyga | that's all fine | 08:39 |
| zyga | we'll only make things equivalent on the inside | 08:39 |
| mup | PR snapd#4931 closed: configstate: give a chance to immediately recompute the next refresh time when schedules are set <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4931> | 08:40 |
| zyga | hmm | 08:40 |
| zyga | though there may be one complication | 08:40 |
| zyga | ah, no | 08:40 |
| mup | PR snapd#4953 opened: configstate: give a chance to immediately recompute the next refresh time when schedules are set (2.32) <Created by pedronis> <https://github.com/snapcore/snapd/pull/4953> | 08:51 |
| pedronis | zyga: does #4932 needs again a master merge or a rerun ? | 08:53 |
| mup | PR #4932: interfaces/content: add rule so slot can access writable files at plug's mountpoint <Created by gerboland> <https://github.com/snapcore/snapd/pull/4932> | 08:53 |
| zyga | pedronis: I think master is broken again, let me look | 08:53 |
| zyga | (I'm fixing master now) | 08:53 |
| zyga | yes | 08:53 |
| zyga | econnreset is fixed in one PR | 08:53 |
| zyga | and removable media is in progress | 08:53 |
| zyga | so don't rerun things for now please | 08:54 |
| mup | PR snapd#4954 opened: store: Sections and WriteCatalogs need to strictly send device auth only if the device has a custom store (2.32) <Created by pedronis> <https://github.com/snapcore/snapd/pull/4954> | 08:55 |
| pedronis | ok | 08:56 |
| Caelum | zyga: so I can run %gobuild userd but I have no idea what to do with it afterwards, it doesn't get installed anywhere, do you know? | 08:57 |
| zyga | %foo is a RPM macro | 08:57 |
| Caelum | yeah | 08:57 |
| Caelum | well it does a go install | 08:57 |
| zyga | it can be expanded with rpm -E '%foo' | 08:57 |
| zyga | it installs into $GOPATH/ | 08:57 |
| zyga | but I don't know what the macros do nowadays, they changed recently | 08:57 |
| Caelum | there is a userd and userd.a | 08:57 |
| zyga | .a is an archive | 08:58 |
| Caelum | yeah | 08:58 |
| Caelum | but what do I do with userd, where do I put it | 08:58 |
| zyga | mborzecki: look at https://github.com/snapcore/snapd/pull/4955 please | 08:59 |
| mup | PR #4955: cmd/snap-confine: establish equivalence of /{,run/}media <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4955> | 08:59 |
| mup | PR snapd#4955 opened: cmd/snap-confine: establish equivalence of /{,run/}media <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4955> | 08:59 |
| zyga | Caelum: hmmm, hold on, what is userd? | 08:59 |
| zyga | pedronis: ^ this PR should fix master | 08:59 |
| zyga | but it cannot land alone because of econnreset bug with store being wonky | 09:00 |
| Caelum | there's a directory in git called userd, I was guessing this is the userd daemon you wanted me to add | 09:00 |
| zyga | no no, that's not what I meant | 09:00 |
| zyga | the userd is part of the "snap" binary | 09:00 |
| zyga | you want to package the systemd / dbus service files | 09:00 |
| zyga | that's why I hinted at missing files compared to the debian package | 09:00 |
| zyga | another point of refence is the fedora package | 09:00 |
| zyga | you can compare the list of files there | 09:00 |
| zyga | lastly we have packaging for opensuse in packaging/opensuse-42.3 | 09:01 |
| zyga | (inside the git tree) | 09:01 |
| zyga | that last packaging is what we run tests agains | 09:01 |
| Caelum | oh I see | 09:01 |
| zyga | you can use that as another reference, ideally they would be identical | 09:01 |
| zyga | (though sometimes it is not easy as test builds have some extra requirements) | 09:02 |
| zyga | but have a look at those all and see what they do differnetly | 09:02 |
| zyga | *differnetly | 09:02 |
| Caelum | ok I know what to do now | 09:02 |
| zyga | let me know if you get stuck on anything | 09:02 |
| zyga | thank you :-) | 09:02 |
| zyga | I'm running a run of fedora 27 on linode now, let's see if my fix is sufficient | 09:04 |
| pedronis | zyga: you are aware that one of the tests is now skipped on fedora? | 09:07 |
| pedronis | if it's about that you need to unskip it | 09:08 |
| zyga | pedronis: no, I wasn't | 09:08 |
| zyga | which test was that? | 09:08 |
| pedronis | zyga: https://github.com/snapcore/snapd/commit/0848363411c07c47580a6d64594911b3a5511595 | 09:09 |
| zyga | thanks | 09:09 |
| === ackkk is now known as ackk | ||
| zyga | tests passed (before re-enabling) | 09:23 |
| zyga | all of main passed | 09:23 |
| zyga | running that single test after re-enabling it now | 09:23 |
| pstolowski | zyga: do you have a moment for quick HO? i'd like to talk about udev | 09:30 |
| zyga | yes | 09:30 |
| zyga | sure, I'll join the standup HO | 09:30 |
| zyga | pstolowski: ready | 09:31 |
| zyga | you are missing a show with my daughter who tries her best to annoy me today | 09:32 |
| Caelum | zyga: currently snapd-generator is installed to /usr/lib/snapd/snapd-generator but should it be installed to /usr/lib/systemd/system-generators/snapd-generator instead? | 09:46 |
| Caelum | or is that a unit file? | 09:46 |
| zyga | Caelum: one sec, on a cal | 09:53 |
| zyga | call | 09:53 |
| Caelum | yeah it looks like that's what I need to do | 09:55 |
| zyga | yes | 09:56 |
| zyga | it should be where systemd looks for generators | 09:57 |
| zyga | pstolowski: a bit old but perhaps still relevant https://people.redhat.com/nhorman/papers/netlink.pdf | 09:57 |
| zyga | pstolowski: question | 09:58 |
| zyga | pstolowski: have we closed the previous socket correctly | 09:58 |
| zyga | it _feels_ like we did not | 09:58 |
| pstolowski | zyga: yes, I close the socket | 09:59 |
| pstolowski | zyga: ok, the doc you linked seems to be pretty clear about setting pid to own pid | 10:02 |
| mup | PR snapd#4947 closed: spread: disable StartLimitInterval option on opensuse-42.3 <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4947> | 10:11 |
| mup | PR snapcraft#2042 opened: Vendoring lxd <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/2042> | 10:13 |
| zyga | pstolowski: https://tools.ietf.org/html/rfc3549 is also interesting | 10:14 |
| Caelum | zyga: I have all the missing files now, except for the userd unit file, where do I get that? It's not in ubuntu. | 10:35 |
| zyga | Caelum: it should be made by "make install" in data/ | 10:35 |
| zyga | let me look | 10:35 |
| zyga | look at data/dbus | 10:36 |
| zyga | if you make install -C data DESTDIR=... you should get something useful out | 10:36 |
| zyga | those are the two io.snapcraft.* things there | 10:36 |
| Caelum | the dbus services? I got those. | 10:37 |
| zyga | so which file is missing still? | 10:38 |
| Caelum | I didn't know that's what the userd service was | 10:38 |
| zyga | ah | 10:38 |
| zyga | yeah | 10:38 |
| zyga | that's it | 10:38 |
| zyga | commit and I'll build and try it out :) | 10:38 |
| zyga | mborzecki: thinking about media | 10:43 |
| zyga | I think I will only do one thing | 10:43 |
| zyga | on /run/media systems /media will be a fixed alias | 10:43 |
| zyga | on /media systems /run/media will not | 10:43 |
| zyga | because host /run is shared and there's no guarantee that /run/media exists | 10:44 |
| zyga | and we should not attempt to create it just because you are using snaps | 10:44 |
| zyga | (especially that on the outside /run/media woul be empty) | 10:44 |
| zyga | we can rely on /media in ways we cannot rely on /run/media | 10:44 |
| zyga | what do you think? | 10:44 |
| mborzecki | hm, so basically, no /run/media if there was none on the host? | 10:46 |
| zyga | yes | 10:48 |
| zyga | I pushed the branch over, have a look | 10:48 |
| zyga | jamesh: hey, if still there, so do you plan to use the /proc/pid/fd idea? | 10:49 |
| zyga | jamesh: I can discuss this with jdstrand and jjohansen today | 10:49 |
| zyga | I actually totally love it | 10:49 |
| jamesh | zyga: yes. I'm integrating it into my branch and updating tests | 10:49 |
| jamesh | zyga: I added a note about it to the PR too | 10:49 |
| zyga | sweet, thank you! | 10:50 |
| Caelum | zyga: I figured out my problem with tests, you can't comment out rpm macros with # they still get expanded and run | 11:00 |
| zyga | ah :D | 11:01 |
| zyga | yes | 11:01 |
| zyga | I ran into that too, I recall now | 11:01 |
| zyga | what's the issue with the tests? | 11:01 |
| zyga | are they failing because of DNS? | 11:01 |
| Caelum | no they're fine, I was just trying to disable them while testing builds because they take a really really long time | 11:02 |
| zyga | ah | 11:02 |
| zyga | ok | 11:02 |
| Caelum | but there is one test there that randomly fails like 30% of the time | 11:02 |
| Caelum | when I see it again I'll let you know | 11:02 |
| mborzecki | zyga: i'll rebase the PR with plain make thing | 11:02 |
| zyga | mborzecki: thanks | 11:03 |
| zyga | mborzecki: I had a look already | 11:03 |
| zyga | but not in detail | 11:03 |
| === chihchun is now known as chihchun_afk | ||
| mborzecki | zyga: aand force pushed | 11:20 |
| zyga | thanks | 11:20 |
| zyga | I want to unbreak master and then work on my stuff | 11:21 |
| zyga | but I promise to build and test your PR today | 11:21 |
| zyga | pedronis: we need a 2nd review on https://github.com/snapcore/snapd/pull/4955 | 11:21 |
| mup | PR #4955: cmd/snap-confine: make /run/media an alias of /media <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4955> | 11:21 |
| zyga | please merge if you agree | 11:21 |
| === pstolowski is now known as pstolowski|lunch | ||
| pedronis | it needs a review by jamie, no? | 11:28 |
| zyga | pedronis: hmmm, yes, it should get one | 11:29 |
| zyga | I'll wait for his review to merge | 11:29 |
| mborzecki | zyga: shall we land https://github.com/snapcore/snapd/pull/4952 ? | 11:33 |
| mup | PR #4952: cmd/snap-confine: attempt to detect if multiarch host uses arch triplets (2.32) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4952> | 11:33 |
| cachio | hey zyga | 11:33 |
| zyga | hey | 11:34 |
| cachio | zyga, beta is it gonna change? | 11:35 |
| cachio | or I can promote it? | 11:35 |
| zyga | cachio: I think it's fine to promote | 11:35 |
| zyga | cachio: we will do .2 but that's unscheduled still | 11:35 |
| zyga | to candidate? | 11:35 |
| cachio | yes | 11:36 |
| cachio | to candidate | 11:36 |
| Caelum | zyga: well I updated the package, having laptop overheating issues here on linux | 11:36 |
| zyga | Caelum: ouch, sorry to hear that | 11:38 |
| zyga | I will pull and test | 11:39 |
| zyga | mborzecki, morphis: does anyone want to do a 2nd review on opensuse package refresh? | 11:39 |
| mborzecki | zyga: i can take a look | 11:40 |
| mborzecki | obs link? | 11:40 |
| zyga | https://build.opensuse.org/request/show/592282 | 11:40 |
| zyga | I'm building locally now | 11:42 |
| zyga | cachio: +1 from me | 11:42 |
| mborzecki | heh reddit witch hunt https://www.reddit.com/r/linux/comments/87ssdw/why_i_use_flatpak_for_3rd_party_apps/ | 11:43 |
| zyga | Caelum: the userd service works fine now | 11:51 |
| zyga | I'll reboot my suse box and play some more | 11:52 |
| zyga | Caelum: installation of snaps without sudo also works now | 11:56 |
| zyga | I will try a few more snaps now | 11:57 |
| zyga | Caelum: 42.2 build fails | 11:59 |
| zyga | I think you can hardcode the systemd generator location | 11:59 |
| zyga | [ 176s] File must begin with "/": %{_systemdgeneratordir}/snapd-generator | 11:59 |
| wadadli | Hi there, attempting to install. Here's the error that I am getting: error: cannot install "anbox-installer": classic confinement requires snaps under /snap or symlink from /snap to /var/lib/snapd/snap | 12:03 |
| zyga | wadadli: hey | 12:04 |
| zyga | wadadli: some distributions chose not to ship the /snap directory and on such distributions snaps that are using classic confinement cannot function | 12:04 |
| zyga | you can make a symlink from /snap to /var/lib/snapd/snap to fix this issue on your machine | 12:04 |
| leftyfb | wadadli: what version of ubuntu are you running? | 12:05 |
| wadadli | Fedora | 12:05 |
| leftyfb | :/ | 12:06 |
| zyga | leftyfb: that's expected and supported | 12:06 |
| zyga | wadadli: just make that symlink and you will be fine | 12:06 |
| leftyfb | zyga: yeah, but they originally asked for help in #ubuntu | 12:06 |
| wadadli | no luck despite running ln -s /var/lib/snapd/snap /snap | 12:06 |
| zyga | wadadli: note that anbox is not the full snap, just the installer | 12:06 |
| zyga | wadadli: what are you getting now? | 12:06 |
| mborzecki | w8, doesn't anbox require kernel modules too? | 12:07 |
| wadadli | same here. | 12:07 |
| wadadli | same thing** | 12:07 |
| mborzecki | (not to install, but to run) | 12:07 |
| zyga | mborzecki: I don't remember, I think so | 12:07 |
| mup | PR snapd#4952 closed: cmd/snap-confine: attempt to detect if multiarch host uses arch triplets (2.32) <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4952> | 12:07 |
| zyga | wadadli: same as in? | 12:07 |
| wadadli | cannot install "anbox-installer": classic confinement requires snaps under /snap or symlink from /snap to /var/lib/snapd/snap | 12:08 |
| jamesh | zyga: I've pushed the changes to remove the stash dir to https://github.com/snapcore/snapd/pull/4868 now | 12:09 |
| mup | PR #4868: cmd/snap-update-ns: add secure bind mount implementation for use with user mounts <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4868> | 12:09 |
| mborzecki | wadadli: are you using gnome software to install anbox? | 12:10 |
| wadadli | nope, anyways got the installer to install. | 12:10 |
| wadadli | now the installer complains that Fedora isn't supported. | 12:11 |
| zyga | wadadli: that's what I expected | 12:12 |
| zyga | wadadli: it requires some kernel modules AFAIR, morphis would know | 12:12 |
| zyga | jamesh: thank you | 12:12 |
| zyga | wadadli: the snap distributes just the installer, not the full application | 12:13 |
| wadadli | Would have been fun just to try. :) | 12:13 |
| wadadli | Any suggestions for running android apps on Linux? | 12:17 |
| zyga | wadadli: sorry, not a clue | 12:18 |
| zyga | maybe use ubuntu and anbox | 12:18 |
| zyga | or talk to morphis about what would it take to work on fedora | 12:18 |
| zyga | maybe the issue is just temporary | 12:18 |
| zyga | Caelum: let me know if you run into any issues | 12:20 |
| zyga | pedronis, mborzecki: trivial cleanup PR https://github.com/snapcore/snapd/pull/4956 | 12:20 |
| mup | PR #4956: cmd/snap-update-ns: rename i to segNum <Created by zyga> <https://github.com/snapcore/snapd/pull/4956> | 12:20 |
| mup | PR snapd#4956 opened: cmd/snap-update-ns: rename i to segNum <Created by zyga> <https://github.com/snapcore/snapd/pull/4956> | 12:20 |
| zyga | mborzecki: more thoughts on the media issue | 12:31 |
| zyga | mborzecki: remove the config option | 12:31 |
| zyga | mborzecki: if /run/media exists it is aliased as /media and bind mounted | 12:32 |
| zyga | mborzecki: otherwise /media is just bind mounted to /media and that's it | 12:32 |
| zyga | mborzecki: one less compile time choice | 12:32 |
| zyga | mborzecki: the only other one would be nvidia | 12:32 |
| zyga | mborzecki: WDYT? | 12:32 |
| === pstolowski|lunch is now known as pstolowski | ||
| mborzecki | zyga: sounds good, but it's probably worth double checking that for instance debian does not have both /media and /run/media, each being a different thing :) | 12:33 |
| zyga | yeah, I plan to check | 12:33 |
| zyga | HMMM | 12:34 |
| mborzecki | iirc this depends on how udisks2 was compiled | 12:34 |
| zyga | fedora 27 doesn't have /run/media | 12:34 |
| zyga | mborzecki: yes | 12:34 |
| zyga | mborzecki: it's a bit insane and sad we have this difference | 12:34 |
| zyga | opensuse tumbleweed has /run/media | 12:35 |
| mborzecki | haha | 12:35 |
| mborzecki | try installing udisks2 in fedora | 12:35 |
| zyga | drat, /run/media is created dynamically | 12:36 |
| zyga | when something is mounted | 12:36 |
| zyga | well, that's this idea then | 12:36 |
| zyga | sucks to be snapd | 12:36 |
| mborzecki | heh ;) | 12:36 |
| mborzecki | the year of linux desktop is upon us | 12:37 |
| zyga | at least we don't need to support that weird distribution that had /Applications after macos | 12:37 |
| mborzecki | we'd get /Snapd | 12:38 |
| mborzecki | or /SnapD | 12:38 |
| vidal72[m] | zyga: jdstrand : I fixed failing tests in https://github.com/snapcore/snapd/pull/4944 , hope it's ok now | 12:39 |
| mup | PR #4944: interfaces: add /var/lib/snapd/snap to @{INSTALL_DIR} <Created by Erick555> <https://github.com/snapcore/snapd/pull/4944> | 12:39 |
| zyga | vidal72[m]: thank you | 12:40 |
| zyga | vidal72[m]: we will look at merging it when master is fixed | 12:40 |
| vidal72[m] | zyga: ok | 12:40 |
| vidal72[m] | I had also fix /media on Arch https://github.com/snapcore/snapd/commit/0d69cb8015e0c42037a7cf9b27f87856e05c0a23#diff-798ce6f0668878eda67847b4ab492745R144 | 12:42 |
| pstolowski | niemeyer: i may be a few minutes late to the standup | 12:43 |
| niemeyer | Heya | 12:44 |
| niemeyer | I will be late as well, as there's a conflicting meeting | 12:44 |
| zyga | hey | 12:47 |
| zyga | niemeyer: ack | 12:47 |
| zyga | vidal72[m]: oh, interesting, looking | 12:47 |
| zyga | ah, right | 12:47 |
| zyga | vidal72[m]: thanks, that's a seprarate issue and I hope we can merge that soon | 12:48 |
| mup | PR snapd#4953 closed: configstate: give a chance to immediately recompute the next refresh time when schedules are set (2.32) <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4953> | 12:48 |
| zyga | ah, it's merged already | 12:48 |
| vidal72[m] | zyga: yeah | 12:48 |
| vidal72[m] | Arch handling of media is the same as fedora | 12:50 |
| vidal72[m] | /run/media is created dynamically | 12:51 |
| jdstrand | jamesh, zyga: it is an interesting idea, but I think it is still racy. eg, if I have /proc/self/fd/5 -> /tmp/foo, and I do from outside the process 'mv /tmp/foo /tmp/bar', then /proc/self/fd/5 -> /tmp/bar. this means that when you open /tmp/foo, you can race mount for when it resolves the fd symlink | 12:59 |
| zyga | jdstrand: we did that test | 13:00 |
| zyga | the fd follows | 13:00 |
| zyga | well | 13:00 |
| zyga | we may still see the race | 13:00 |
| zyga | I see your point | 13:00 |
| zyga | jdstrand: I agree in the sense that mount the syscall may still race | 13:03 |
| zyga | and our simple look from the ouside may be insufficient to observe that | 13:03 |
| jdstrand | zyga: feel free to try to prove me wrong, but mount() doesn't take open fds. it takes paths. therefore, at the time the mount() call is made, the symlink could point to something else. I would be surprised if the kernel kept the context for your symlink around | 13:05 |
| jdstrand | zyga: ie, I doubt that: fd = open(/tmp/foo), then from outside move /tmp/foo /tmp/bar, then mount(/proc/self/fd/<the fd>, ...) that mount() will see /tmp/foo | 13:08 |
| jdstrand | it would be easy to test with some strategic sleep() calls | 13:09 |
| zyga | James Henstridge so the mount followed the file descriptor rather than the name | 13:09 |
| zyga | jdstrand: yep | 13:09 |
| zyga | jamesh: ^ | 13:09 |
| jdstrand | if it did see that (and again, I doubt it does), I wouldn't trust that it is by design and we'd need to deeply investigate that we could trust it | 13:10 |
| kalikiana | re | 13:26 |
| zyga | jdstrand: hey, can you please have a quick look at https://github.com/snapcore/snapd/pull/4955 | 13:33 |
| mup | PR #4955: cmd/snap-confine: make /run/media an alias of /media <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4955> | 13:33 |
| jamesh | jdstrand: /proc/$pid/fd/NNN paths aren't standard symlinks though: they'll even work across separate mount namespaces | 13:33 |
| zyga | master is broken now and this is the fix | 13:33 |
| zyga | niemeyer: we're done, we can repeat the standup if you want and you are back | 13:34 |
| jamesh | jdstrand: opening that path (as opposed to doing readlink()) is directed to the inode of the file descriptor | 13:34 |
| niemeyer | zyga: Ack, thanks | 13:34 |
| niemeyer | zyga: Still going here | 13:35 |
| jdstrand | jamesh: you are saying that when mount() opens that file, it opens the inode associated with said file descriptor? | 13:37 |
| jamesh | jdstrand: I am not certain of what happens in the kernel | 13:37 |
| jamesh | jdstrand: in the simple case of moving the directory between opening the fd and calling mount() though, it uses the new location | 13:38 |
| jdstrand | right, so that is doing as I described. am I misunderstanding? | 13:38 |
| zyga | I think that there's still raciness but it not measurable with this test | 13:38 |
| zyga | the race is not between the rename and the mount | 13:38 |
| zyga | well | 13:38 |
| zyga | that's wrong | 13:39 |
| zyga | the race is not in the rename, the sleep and them ount | 13:39 |
| zyga | but with racing rename and mount | 13:39 |
| zyga | the thing that I thin _is_ averted | 13:39 |
| zyga | is symlink attack on the leaf | 13:39 |
| zyga | jdstrand: that's how I understand what the kernel is doing | 13:39 |
| jdstrand | if you can give me C code for what you want to do, I can blackbox the kernel. if it seems safe, then we can investigate if that is by design and can be relied upon | 13:40 |
| zyga | jdstrand: does this qualify https://paste.ubuntu.com/p/zvpjCcmcjm/ | 13:42 |
| zyga | it's not C but as close as you probably want | 13:42 |
| jamesh | I can put together a C example, but it'll have to wait until after the easter long weekend | 13:42 |
| jamesh | it is late here in .au | 13:43 |
| jdstrand | I guess python would be ok. this is going to be in the go code | 13:43 |
| jdstrand | it'll be a bit before I can look at this | 13:43 |
| zyga | I can make the C part if you want | 13:43 |
| zyga | jdstrand: yeah, that's fine | 13:44 |
| zyga | jdstrand, jamesh: we can use the old approach for now | 13:44 |
| * jdstrand is also busy :) | 13:44 | |
| zyga | and explore this as v2 | 13:44 |
| jdstrand | right | 13:44 |
| jdstrand | we have an approved approach | 13:44 |
| jdstrand | if this works and can be relied upon, then it would be cool | 13:44 |
| jamesh | zyga, jdstrand: I updated the PR to use this new approach, but that's just in the top revision | 13:45 |
| zyga | yep | 13:45 |
| jamesh | uncommitting that has the two step version you reviewed previously | 13:45 |
| zyga | jamesh: can you open a 2nd pr with that commit | 13:45 |
| zyga | and force push the old one to the original | 13:45 |
| jamesh | sure. | 13:45 |
| zyga | we can have two converstations separately then | 13:45 |
| zyga | thank you! | 13:45 |
| mup | PR snapd#4954 closed: store: Sections and WriteCatalogs need to strictly send device auth only if the device has a custom store (2.32) <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4954> | 13:51 |
| jamesh | zyga: here's the version with the last commit: https://github.com/snapcore/snapd/pull/4957 | 13:55 |
| mup | PR #4957: cmd/snap-update-ns: remove the need for stash directory in secure bind mount implementation <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4957> | 13:55 |
| mup | PR snapd#4957 opened: cmd/snap-update-ns: remove the need for stash directory in secure bind mount implementation <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4957> | 13:56 |
| zyga | ack | 13:56 |
| jamesh | and the old PR has been rewound | 13:56 |
| zyga | mborzecki: https://github.com/snapcore/snapd/pull/4958 (rather long but mechanical) | 14:00 |
| mup | PR #4958: cmd/snap-update-ns: allow path guardian to inspect fs ops <Created by zyga> <https://github.com/snapcore/snapd/pull/4958> | 14:00 |
| mup | PR snapd#4958 opened: cmd/snap-update-ns: allow path guardian to inspect fs ops <Created by zyga> <https://github.com/snapcore/snapd/pull/4958> | 14:01 |
| zyga | this doesn't do anything at all, just gives us an argument in the right spot, so that we can avoid the global hack I did | 14:01 |
| * zyga -> walk | 14:01 | |
| zyga | jamesh: What is the symlink path when you remove a file? | 14:17 |
| niemeyer | zyga, pedronis, cachio, pstolowski: Do you want to have a quick call? | 14:19 |
| cachio | niemeyer, sure | 14:19 |
| zyga | Ups, I’m on a walk | 14:21 |
| pedronis | niemeyer: I'm available if quick | 14:22 |
| niemeyer | Saviq: I won't be around tomorrow, and perhpas not next week either (will send an email in the latter case).. we have several backends in the code of spread itself, which should be very easy to read and follow.. would that be enough to give you an idea of what it needs? | 14:23 |
| niemeyer | pedronis, cachio: Okay, let's jump in | 14:23 |
| cachio | mborzecki, are you comming? | 14:25 |
| Saviq | niemeyer: probably, we can get through that and let's sync up week after next? | 14:27 |
| === sparkieg` is now known as sparkiegeek | ||
| zyga | jdstrand: thank you, I replied on both comments | 14:38 |
| zyga | jdstrand: I'll rename the variable but I think it's okay as-is, see my rationale please | 14:38 |
| mup | PR snapd#4819 closed: interfaces/serial: change pattern not to exclude /dev/ttymxc* <Created by bergotorino> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4819> | 14:39 |
| niemeyer | zyga: Can we please have this one in as well ^ | 14:39 |
| niemeyer | zyga: Trivial addition to the regexp pattern, so regression chance is pretty much nil | 14:40 |
| zyga | niemeyer: ack | 14:40 |
| niemeyer | zyga: and we have people on the line for that one | 14:40 |
| zyga | I'll backport it | 14:40 |
| niemeyer | Thanks | 14:40 |
| niemeyer | ! | 14:40 |
| zyga | jdstrand: pushed | 14:41 |
| * zyga gets dinner and then back to release | 14:41 | |
| niemeyer | Saviq: Yeah, happy to sync | 14:43 |
| niemeyer | Saviq: We can have a call today as well if you want | 14:43 |
| niemeyer | Saviq: That might be more productive | 14:43 |
| Saviq | niemeyer: I'm EOD in an hour, and I think we can get the most important data out of the current spread providers, so we can re-sync after to see what's missing | 14:58 |
| niemeyer | Saviq: Let's have a quick call now then | 14:59 |
| niemeyer | Saviq: Are you available? | 14:59 |
| niemeyer | Saviq: 5-10 minutes tops | 14:59 |
| Saviq | niemeyer: just getting into our team sync, are you ok 15 mins from now? your calendar says busy? | 15:00 |
| niemeyer | I'll be at lunch by then | 15:00 |
| niemeyer | Either now, or 1h from now, or 9 days from now :) | 15:00 |
| Saviq | niemeyer: ok, 1h from now then | 15:00 |
| niemeyer | Saviq: Deal | 15:00 |
| thiras | electrum package is unbelievably old and has SERIOUS security issues at the version | 15:10 |
| thiras | for maintainers instance it's not proper to have that on the market | 15:11 |
| nacc | thiras: you should contact the 'Contact" link in the info? | 15:11 |
| thiras | where can i find it? | 15:12 |
| nacc | thiras: snap info electrum | 15:13 |
| kyrofa | nacc, feel like confirming this bug? Another one that I think will help you https://bugs.launchpad.net/snapcraft/+bug/1759875 | 15:13 |
| mup | Bug #1759875: Parts should be handled in a consistent order through multiple runs <Snapcraft:New> <https://launchpad.net/bugs/1759875> | 15:13 |
| nacc | kyrofa: yeah that looks reasonable and helpful for us | 15:13 |
| thiras | also my atom has just stopped working | 15:14 |
| thiras | without a reason | 15:14 |
| thiras | no error log on console | 15:14 |
| nacc | thiras: there is also a contact url for that | 15:14 |
| mup | PR snapd#4959 opened: interfaces/serial: change pattern not to exclude /dev/ttymxc (2.32) <Created by zyga> <https://github.com/snapcore/snapd/pull/4959> | 15:15 |
| thiras | seriously... it should be universal and plugnplay | 15:15 |
| thiras | i only got 3 snap packages and seen 4 critical error in one week | 15:15 |
| nacc | thiras: what should be? | 15:15 |
| thiras | something is very very wrong with snaps for sure | 15:16 |
| mup | PR snapd#4959 closed: interfaces/serial: change pattern not to exclude /dev/ttymxc (2.32) <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/4959> | 15:16 |
| thiras | it's worse than apt | 15:16 |
| mup | PR snapd#4960 opened: interfaces/serial: change pattern not to exclude /dev/ttymxc (2.32) <Created by zyga> <https://github.com/snapcore/snapd/pull/4960> | 15:17 |
| zyga | thiras: hey | 15:17 |
| zyga | thiras: can you please open your terminal | 15:17 |
| zyga | thiras: and run: snap run atom | 15:17 |
| zyga | thiras: please tell me what happens | 15:17 |
| thiras | nothing | 15:17 |
| thiras | return to bash | 15:17 |
| thiras | instantly | 15:18 |
| thiras | i got the same issue with skype. somehow it started work this weak | 15:18 |
| thiras | week* | 15:18 |
| zyga | can you please tell me your "snap version" | 15:18 |
| thiras | snap 2.31.2 | 15:18 |
| thiras | snapd 2.31.2 | 15:18 |
| thiras | series 16 | 15:18 |
| thiras | ubuntu 17.10 | 15:18 |
| thiras | kernel 4.13.0-37-generic | 15:18 |
| zyga | ok | 15:18 |
| zyga | one sec, let me refresh my core snap | 15:19 |
| thiras | why do we love debian based distros? because it's stable as earth | 15:19 |
| roadmr | omg an earthquakeee | 15:20 |
| thiras | if it's not ready you shouldn't push into production | 15:20 |
| zyga | thiras: let's please focus on the issue at hand, we're all trying to make something better | 15:20 |
| thiras | and as i can see it's clearly not ready | 15:20 |
| zyga | roadmr: a real earthquake? | 15:20 |
| thiras | ok | 15:20 |
| zyga | thiras: so, both atom and skype are classic snaps | 15:20 |
| thiras | 99.999999% of the time its stable roadmr | 15:20 |
| roadmr | zyga: I'm joking re: debian is stable as earth :) | 15:20 |
| zyga | so they cannot use many of the benefits of the system that make it more stble | 15:20 |
| zyga | I'll switch to 3.31.2 and see if I can run them | 15:21 |
| zyga | (I'm also on 17.10) | 15:21 |
| zyga | thiras: is your atom and skype from stable channels? | 15:22 |
| zyga | (snap info skype; snap info atom) | 15:22 |
| thiras | yes i assume. directly downloaded from that "ubuntu software" | 15:22 |
| zyga | thiras: I can reproduce this | 15:22 |
| zyga | it looks like atom broke their snap | 15:22 |
| zyga | popey: ^ | 15:22 |
| zyga | flexiondotorg: ^ | 15:22 |
| thiras | tracking: stable | 15:22 |
| thiras | installed: 1.25.0 (136) 144MB classic | 15:22 |
| popey | zyga: broken how? | 15:23 |
| zyga | writev(2, [{iov_base="/snap/atom/136/usr/share/atom/at"..., iov_len=34}, {iov_base=": ", iov_len=2}, {iov_base="error while loading shared libra"..., iov_len=36}, {iov_base=": ", iov_len=2}, {iov_base="libgconf-2.so.4", iov_len=15}, {iov_base=": ", iov_len=2}, {iov_base="cannot open shared object file", iov_len=30}, {iov_base=": ", iov_len=2}, {iov_base="No such file or directory", iov_len=25}, {iov_base="\n", iov_len=1}], 10) = 149 | 15:23 |
| zyga | atom cannot find libgconf-2.so.4 | 15:23 |
| zyga | trying skype now | 15:23 |
| popey | wfm | 15:23 |
| thiras | skype is working | 15:23 |
| popey | zyga: i am on atom from edge, try that | 15:23 |
| thiras | i don't know how but few days ago it started to work magically | 15:23 |
| popey | (I added a dep) | 15:23 |
| zyga | popey: can you try stable | 15:24 |
| zyga | popey: if edge works that is gret | 15:24 |
| popey | if edge works I'll promote it | 15:24 |
| zyga | but if stable doesn't work, that's bad | 15:24 |
| zyga | ok | 15:24 |
| thiras | it was exactly like that snap run command returns nothing | 15:24 |
| zyga | thiras: you can try that with "snap refresh --edge atom" | 15:24 |
| zyga | this will let you test the more recent version | 15:24 |
| thiras | FFS at least provide some error log at the output of run command | 15:24 |
| * zyga tries as well | 15:24 | |
| thiras | it was like nightmare when i try to debug | 15:24 |
| zyga | thiras: I'm not sure why the log didn't come out TBH | 15:24 |
| zyga | normally it would show something | 15:24 |
| zyga | thiras: tip: snap run --strace atom | 15:25 |
| zyga | :-) | 15:25 |
| zyga | popey: no, edge is equally broken | 15:25 |
| thiras | still same zyga | 15:25 |
| popey | wat | 15:25 |
| zyga | I noticed new gnome runtime platform | 15:25 |
| zyga | maybe that's a factor | 15:25 |
| popey | I'm on 16.04 and it works fine here | 15:25 |
| popey | it's a classic snap | 15:25 |
| zyga | popey: on 17.10 it is broken | 15:25 |
| popey | (I am on KDE) | 15:25 |
| popey | how is that the snaps fault? | 15:26 |
| zyga | popey: nothing ships libgconf-2.so.4 | 15:26 |
| zyga | popey: the snap must ship libgconf-2.so.4 | 15:26 |
| zyga | it's a broken snap that runs on 16.04 by acciddent | 15:26 |
| zyga | *accident | 15:26 |
| popey | alan@KinkPad-K450:/snap/atom/current$ find . | grep libgconf-2.so.4 | 15:26 |
| popey | ./usr/lib/x86_64-linux-gnu/libgconf-2.so.4 | 15:26 |
| popey | it does ship it | 15:26 |
| popey | (in edge) | 15:26 |
| zyga | popey: perhaps it's not setting some flags to load it | 15:27 |
| zyga | pstolowski: ^ can you run snap run atom | 15:27 |
| zyga | pstolowski: and tell me which ubuntu release you are on | 15:27 |
| pstolowski | zyga: sure, 1 sec | 15:27 |
| zyga | popey: I confirm that the snap ships the so file | 15:27 |
| zyga | pstolowski: thank you | 15:27 |
| zyga | popey: but it still doesn't start | 15:27 |
| zyga | because it cannot load that lib | 15:27 |
| zyga | popey: looking at the command it doesn't set any environment | 15:28 |
| zyga | popey: please adjust it to set LD_LIBRARY_PATH based on $SNAP | 15:28 |
| thiras | by the way contact address of electrum is not working | 15:28 |
| zyga | popey: snap run --shell atom | 15:28 |
| popey | why should I have to do that? Surely snapd should set that correctly? | 15:29 |
| zyga | popey: no | 15:29 |
| zyga | popey: snapd _never_ did that | 15:29 |
| thiras | dude seriously do you allow everybody to craft those non working package and put it into ubuntu software? | 15:29 |
| thiras | it's a nightmare | 15:29 |
| pstolowski | zyga: works here. i'm on 16.04 | 15:29 |
| zyga | thiras: please calm down, we're doing our best, there are 100s of working snaps | 15:29 |
| zyga | pstolowski: on 16.04 it would work by accident, thank you for checking | 15:29 |
| zyga | popey: all classic snaps must alter their environment knowingly | 15:30 |
| flexiondotorg | zyga: o/ | 15:30 |
| zyga | please review the snaps we publish for this | 15:30 |
| thiras | if it's open to eveybody we have much much much more serious security issues than simple broken packages | 15:30 |
| popey | flexiondotorg: zyga is reporting atom broken in 17.10 - even edge which has the extra libgconf | 15:30 |
| zyga | flexiondotorg: tl;dr; atom doesn't set LD_LIBRARY_PATH, doesn't start on many distributioins | 15:30 |
| zyga | *distributions | 15:30 |
| zyga | the reason for that is on 16.04 it finds and loads host's libgconf | 15:31 |
| pedronis | did snapcraft switch to elf patching instead of LD_LIBRARY_PATH ? | 15:31 |
| popey | flexiondotorg: we use a very basic launcher in atom (classic remember) | 15:31 |
| zyga | as a classic snap it runs without a mount namespace | 15:31 |
| zyga | pedronis: great question | 15:31 |
| nacc | pedronis: i believe 2.40 does that | 15:31 |
| flexiondotorg | zyga: I was advised by sergio to drop desktop helpers and LD_LIBRARY_PATH munging when build classic snaps with snapcraft 2.39 and newer, since snapcraft should DTRT. | 15:32 |
| kyrofa | pedronis, yes | 15:32 |
| flexiondotorg | popey: Atom is build built by build.snapcraft.io, right? | 15:32 |
| popey | yes | 15:32 |
| flexiondotorg | So will be using snapcraft 2.35. | 15:32 |
| zyga | flexiondotorg: I see that we set rpath to $ORIGIN:$ORIGIN/lib | 15:32 |
| kyrofa | pedronis, but classic snaps haven't had LD_LIBRARY_PATH automatically set for a while | 15:32 |
| flexiondotorg | It will require a local cleanbuild using snapcraft 2.40. | 15:32 |
| zyga | flexiondotorg: but not $ORIGIN/lib/x86_64-linux-gnu/ | 15:33 |
| zyga | that's why it's not starting | 15:33 |
| nacc | flexiondotorg: why does b.s.io use 2.35? | 15:33 |
| zyga | popey, flexiondotorg: please disregard my comments about LD_LIBRARY_PATH, it's really snapcraft ORIGIN that needs the tweak | 15:33 |
| flexiondotorg | Because b.s.io use LP and LP get snapcraft via apt. | 15:33 |
| zyga | it's really broken because of multiarch path for libraries | 15:33 |
| cjwatson | (currently) | 15:33 |
| popey | cjwatson: that's changing soon. right? | 15:34 |
| zyga | thiras: sorry for the noise, the issue is understood now, I'm sure the team will publish a working atom snap shortly | 15:34 |
| cjwatson | t | 15:34 |
| kyrofa | 2.40 was SRUd, build.snapcraft.io should be using it now, no? | 15:34 |
| nacc | flexiondotorg: snapcraft is at 2.40 in all releases? | 15:34 |
| cjwatson | oh, yes, it would be 2.40 now | 15:34 |
| nacc | flexiondotorg: so it would depend on *when* it built | 15:34 |
| popey | I can certainly trigger a new edge build of atom | 15:34 |
| cjwatson | 2.39 was rolled back but 2.40 seems to have stuck for now | 15:34 |
| cjwatson | snapcraft | 2.40 | xenial-updates/universe | source, all | 15:35 |
| flexiondotorg | Yep, seem it was built before the SRU completed. | 15:35 |
| popey | latest build in edge was 2018-03-24 23:27 - 4 days, 16 hours ago | 15:35 |
| nacc | yeah, that is something I have meant to ask folks here | 15:35 |
| nacc | snapcraft chnages can really change how the snap works | 15:35 |
| nacc | (sometimes breaking it :) | 15:35 |
| nacc | i wonder if there needs to be abetter connection between snapcraft updates (that affect b.s.io/LP) and snap builds | 15:36 |
| nacc | as without changing your snap, all of a sudden your snap might change | 15:36 |
| nacc | debugging it can be a pain (hat-tip to kyrofa ) | 15:36 |
| popey | I've just pressed the "build now" button so look for a new edge build of atom shortly | 15:36 |
| cjwatson | nacc: the work in progress includes being able to control the channel used for snapcraft on a per-snap (even per-build) basis, which we plan to use to construct better QA | 15:36 |
| popey | (I wish I could tell build not to do an armhf/i386 build) | 15:37 |
| nacc | cjwatson: ah nice | 15:37 |
| nacc | cjwatson: oh right and you're switching to the snapcraft snap, right? | 15:37 |
| cjwatson | popey: waiting for the architectures work to land in snapcraft ... | 15:37 |
| popey | ok | 15:37 |
| cjwatson | nacc: that's the plan, though of course there'll be a transitional period | 15:37 |
| * popey looks at kyrofa :) | 15:37 | |
| nacc | cjwatson: yep | 15:37 |
| kyrofa | Ah, right, speaking of that: niemeyer any chance you have some time to day to meet before you leave? | 15:37 |
| thiras | zyga, let me ask something | 15:38 |
| thiras | is snap repos are open to everybody? | 15:38 |
| thiras | if so please leave that package alone and start restate security policy | 15:39 |
| thiras | it's one click away for everybody who use ubuntu | 15:39 |
| zyga | thiras: what do you mean by repos? | 15:39 |
| zyga | thiras: the snap storeis open to everyone, yes, but snaps without confinement require a public vote to approve | 15:39 |
| thiras | i don't know snap equivalent of repository | 15:39 |
| zyga | thiras: normally all snaps are confined | 15:39 |
| zyga | thiras: go ahead, make a snap, have it do something and push it to the store (or just install locally to test) | 15:40 |
| zyga | and see what happens if you try to attack the host | 15:40 |
| popey | cjwatson: is it normall that a huge number of builders are "cleaning"? | 15:40 |
| popey | (I was just looking to see what the queue for builders was like, and it looked odd) | 15:41 |
| thiras | zyga, sometimes you don't have to attack | 15:41 |
| cjwatson | popey: no, stabbing now | 15:41 |
| popey | ta | 15:41 |
| thiras | outdated software can become the problem itself | 15:41 |
| thiras | like in electrum | 15:41 |
| ogra_ | they are oreparing for easter ... showering, brushing their teeth etc | 15:41 |
| zyga | thiras: do you mean electron? | 15:41 |
| nacc | zyga: no there's an electrum app (bitcoin related) | 15:41 |
| zyga | thomi: snaps can be updated more frequently than distribution packages | 15:41 |
| thiras | if you cannot guaranteed freshness of packages then the system has major security issue | 15:41 |
| zyga | ah, I see | 15:42 |
| nacc | thiras: this is no different than outdated debs | 15:42 |
| thiras | electrum bitcoin client | 15:42 |
| nacc | thiras: but it does take someone to actually do the work, in this case the contact info link | 15:42 |
| thiras | the domain is dead | 15:42 |
| thiras | debs can be outdated too of course | 15:43 |
| thiras | but it's guaranteed by the canonical and/or the team to get fixed 99% chance | 15:43 |
| thiras | at least you have somebody you can talk | 15:44 |
| thiras | that's why we have official repos and ppa's | 15:44 |
| thiras | sorry guys but complete disaster | 15:44 |
| popey | ppa's are mostly very unofficial | 15:44 |
| thiras | yeah thats what i mean | 15:45 |
| popey | they're somewhat wild-west compared to the repo | 15:45 |
| thiras | offical repos and pps they are completey diffrent | 15:45 |
| nacc | thiras: you mean *main* ? | 15:45 |
| nacc | thiras: so you should only use canonical snaps :) | 15:45 |
| thiras | and you cannot access ppa's by mistake | 15:45 |
| pedronis | I think we will grow some policy about decayed snaps (not updated in along while) but we haven't discussed it yet (likely default snap find will not find them) | 15:45 |
| thiras | nacc, i can guaranteed 99% of the people won't notice the maintainer of tthe package you if put all of them into one place | 15:46 |
| thiras | FFS | 15:46 |
| thiras | i'm using linux since 2.4 kernel | 15:46 |
| nacc | thiras: i can't parse that sentence | 15:46 |
| thiras | even I didn't notice it's not official snapcraft package | 15:46 |
| nacc | what do you mean by official? | 15:46 |
| thiras | you guys just remove the barrier between offical repos and ppa's | 15:47 |
| thiras | do you understand that sentence? | 15:47 |
| ogra_ | well, the snap store is neither of them | 15:47 |
| popey | We spend a lot of time talking to upstream developers, to get them to "own" their own snap. | 15:47 |
| popey | So you can have confidence that the snap came from the real ISV | 15:48 |
| thiras | and the barrier has a purpose | 15:48 |
| popey | e.g. slack, skype, spotify, firefox all come from their respective 'vendors' | 15:48 |
| ogra_ | the snap store is typically "unrelated upstream packages" | 15:48 |
| popey | but sometimes that conversation doesn't pan out, such as with Atom. | 15:48 |
| thiras | so goodbye stable OS | 15:48 |
| ogra_ | ?? | 15:48 |
| popey | So we published it, because there's a demand for it. We publish the snap from upstream packages. | 15:48 |
| ogra_ | its exactly the opposite | 15:48 |
| ogra_ | this is why snaps exist | 15:48 |
| ogra_ | they are completely separate from the OS | 15:49 |
| popey | the snaps are isolated form the host OS, making it _more_ stable | 15:49 |
| thiras | yeah they said it for KVM too | 15:49 |
| thiras | and meltdown | 15:49 |
| popey | cjwatson: thanks! | 15:49 |
| cjwatson | yep, build queue is ~drained now | 15:50 |
| thiras | ok let me understand again. i just downloaded electrum bitcoin client with very very few click from ubuntu software | 15:50 |
| thiras | it wasn't maintained by the original developer but just a random guy | 15:51 |
| thiras | and i've imported my old wallet into that outdated client | 15:51 |
| thiras | can you provide guarantee that my wallet didn't stolen? | 15:52 |
| popey | zyga: can you please refresh atom from edge? | 15:52 |
| popey | revision 141 just finished building | 15:52 |
| ogra_ | thiras, ask the maintainer ... | 15:53 |
| popey | thiras: the repo version could have done the same. repo debs don't get deep code reviews. | 15:53 |
| thiras | sure | 15:53 |
| thiras | but it guaranteed original source code | 15:53 |
| cjwatson | that electrum snap should probably just be removed - it manages to be older than the version in Debian jessie, which is kind of moderately hilarious | 15:53 |
| thresh | so I've filled a forum thread on my issue with snapcraft stage packages, https://forum.snapcraft.io/t/snapcraft-stage-packages-inconsistent-behaviour/4746 | 15:53 |
| thresh | (also hello) | 15:54 |
| ogra_ | thiras, we can guarantee that nothing from that snap can take over your host and can not steal any data from it ... we can not gurantee anything for the content *inside* the snap, that is the responsibility of the maintainer | 15:54 |
| popey | thresh: hi | 15:54 |
| thiras | great | 15:54 |
| thiras | really great | 15:54 |
| nacc | cjwatson: heh | 15:54 |
| cjwatson | unless there's some kind of fork in the version numbering I suppose | 15:54 |
| thiras | you guys are crazy really i'll just close down snapd and never use it again | 15:54 |
| nacc | thiras: that is obviously your choice | 15:55 |
| popey | ok then | 15:55 |
| roadmr | +1 | 15:55 |
| thresh | hey popey I've got some poorly drawn banners for you | 15:55 |
| thiras | https://postimg.org/image/60fvg33y3/ | 15:55 |
| popey | yay! | 15:55 |
| thiras | default size of ubuntu software | 15:55 |
| popey | thresh: scroll down | 15:56 |
| popey | oops, thiras scroll down | 15:56 |
| thiras | again 99% of the users won't notice it's not from developer it's NOT guaranteed distributed source code from devs | 15:56 |
| popey | thresh: sorry :) | 15:56 |
| popey | thiras: you could file a bug against gnome-software? To highlight this problem with the developers who maintain that UI? | 15:56 |
| cjwatson | the packaging metadata for electrum was added upstream (https://github.com/spesmilo/electrum/pull/2521) | 15:56 |
| mup | PR spesmilo/electrum#2521: Add the packaging metadata to build the electrum snap <Created by elopio> <Merged by ecdsa> <https://github.com/spesmilo/electrum/pull/2521> | 15:56 |
| cjwatson | not sure what happened to it after that | 15:57 |
| thiras | do you have verification process of the maintainers like twitter verification? how can i know if it's really firefox foundation? | 15:58 |
| cjwatson | sounds like upstream merged the PR but then didn't want to deal with actually maintaining the build | 15:58 |
| ogra_ | or simply wasnt able to take over the name in the store | 15:59 |
| thiras | does bash client warns the users if package owner not verifed? | 15:59 |
| thiras | i bet it's not | 15:59 |
| cjwatson | ogra_: see the URL I posted | 16:00 |
| ogra_ | cjwatson, ah, right ... | 16:01 |
| zyga | thiras: what doe you mean by verified? | 16:01 |
| niemeyer | kyrofa: Yeah, let's talk | 16:02 |
| thiras | sorry guys but i see only fast and definatly not very well thought moniterization of package distribution. | 16:02 |
| niemeyer | Saviq: Ready? | 16:02 |
| ogra_ | well, someone should probably talk to https://forum.snapcraft.io/u/tomascw to either get the snap updated,, removed or ransferred to someone who wants to actively maintain it | 16:02 |
| popey | zyga: please update your atom :) | 16:02 |
| zyga | popey: snapd does that for me :) | 16:02 |
| zyga | but let's try | 16:02 |
| popey | eye roll emoji | 16:02 |
| thiras | i was very excited when saw snaps first | 16:02 |
| zyga | thiras: to be fair | 16:02 |
| zyga | thiras: it's all new and exciting and complex | 16:02 |
| zyga | thiras: we really get your feedback | 16:02 |
| zyga | thiras: the best way to complain about things is to report issues, discuss issues and help fixing them | 16:03 |
| thiras | obviously you are not the guys who decide because it's not a software bug or something | 16:03 |
| zyga | popey: atom runs now! | 16:03 |
| thiras | it's huge policy issue | 16:03 |
| popey | \o/ | 16:03 |
| ogra_ | thiras, you can contact the maintainer via https://forum.snapcraft.io/u/tomascw obviously ... | 16:03 |
| zyga | thiras: but notice what just happend | 16:03 |
| zyga | thiras: you just showed us how atom was broken | 16:03 |
| zyga | and it was fixed in _minutes_ | 16:03 |
| zyga | that's impossible in classic packaging | 16:04 |
| thiras | i should talk someone from canonical not you | 16:04 |
| zyga | and it was not just fixed for ubuntu | 16:04 |
| zyga | it's for everyone | 16:04 |
| popey | zyga: thanks, released | 16:04 |
| popey | flexiondotorg: ^ atom fixed | 16:04 |
| zyga | thiras: I hate to tell you that bit I'm working on snapd as my day job | 16:04 |
| popey | thiras: everyone you have been talking to so far works for canonical | 16:04 |
| thiras | oh great | 16:04 |
| zyga | thiras: run "snap refresh atom" | 16:04 |
| zyga | thiras: and enjoy :) | 16:04 |
| ogra_ | thiras, how would talking to canonical help ... the snap is outdated, the guy who owns it didnt update it | 16:04 |
| thiras | i cannot | 16:04 |
| * zyga hugs popey and flexiondotorg | 16:05 | |
| ogra_ | talking to that guy wuld be way more effective, dont you think ? | 16:05 |
| thiras | because i don't know who is maintaining that package | 16:05 |
| zyga | thankys guys | 16:05 |
| ogra_ | thiras, https://forum.snapcraft.io/u/tomascw | 16:05 |
| thiras | i could install wrong package who read my keystrokes | 16:05 |
| popey | zyga: thanks for the ping | 16:05 |
| thiras | which | 16:05 |
| * popey goes back to vacation ;) | 16:05 | |
| thiras | - | 16:05 |
| ogra_ | thiras, no. you cant | 16:05 |
| flexiondotorg | zyga: np :-) | 16:05 |
| thiras | tell me how | 16:06 |
| thiras | that was my first question anyway | 16:06 |
| zyga | popey, flexiondotorg: is there a bug to report on snapcraft about the ORIGIN and multi-arch dirs? | 16:06 |
| thiras | i confirm atom has fixed | 16:07 |
| thiras | last word. it's quite dangerous to have 3rd party maintainers packages on the store WITHOUT ANY WARNING | 16:08 |
| thiras | i just download electrum from mr nobody | 16:08 |
| thiras | it's much easier to access than PPA's | 16:08 |
| thiras | it's quite dangerous for avarage user | 16:09 |
| zyga | thiras: I think what the real issue is, is that no equivalent of "snap info package" for accounts | 16:09 |
| thiras | good day | 16:09 |
| zyga | so that people can inspect the maintainer | 16:09 |
| thiras | so until have that system | 16:10 |
| flexiondotorg | zyga: Best ask kyrofa about that. | 16:10 |
| thiras | you shouldn't put this thing into production | 16:10 |
| thiras | simple debian approach | 16:10 |
| zyga | flexiondotorg: ack, will do | 16:10 |
| zyga | kyrofa: if you are around, do you have a moment to chat about ORIGIN | 16:10 |
| zyga | thiras: there's never a good way to put something into production, IMO we are doing fine and improving rapidly | 16:11 |
| cjwatson | FWIW I've heard exactly the same criticisms levelled at .debs from Debian - plus ça change, plus c'est la même chose | 16:12 |
| thiras | zyga, we have | 16:13 |
| thiras | called apt | 16:13 |
| thiras | it worked for millions of years | 16:13 |
| thiras | since dinosours | 16:13 |
| nacc | thiras: lol, you're being ridiculous now ... stick to facts please | 16:13 |
| zyga | thiras: we know, we have some people who wrote it on the snapd team | 16:13 |
| thiras | the tech is great | 16:14 |
| nacc | thiras: also, there have been and will be broken debs too | 16:14 |
| thiras | logic is perfect | 16:14 |
| nacc | thiras: it still involves humans, so no it's not. | 16:14 |
| thiras | but until we don't have warnings about the 3rd party devs it ruins everything | 16:14 |
| nacc | thiras: which is the same problem you have with snaps | 16:14 |
| thiras | we have* | 16:14 |
| cjwatson | .debs have no warnings about third-party developers | 16:14 |
| thiras | it's signed by canonical | 16:15 |
| thiras | right? | 16:15 |
| cjwatson | which doesn't mean every line of code has been inspected by Canonical | 16:15 |
| zyga | thiras: debs are not signed | 16:15 |
| thiras | yes of course | 16:15 |
| zyga | thiras: archives are signed | 16:15 |
| cjwatson | zyga: semantics | 16:15 |
| thiras | ok can i put some snap packages into store | 16:15 |
| nacc | thiras: canonical is vouching that the file you download is what you intended to | 16:15 |
| nacc | thiras: that does not mean canonical has reviewd the content of every line of every source of every package | 16:16 |
| thiras | but please keep it private so maybe you will understand with example | 16:16 |
| thiras | yeah | 16:16 |
| thiras | but | 16:16 |
| nacc | thiras: snaps are no different | 16:16 |
| thiras | but | 16:16 |
| thiras | but | 16:16 |
| thiras | official repos doens't have EVERYTHING | 16:16 |
| thiras | usually | 16:16 |
| thiras | it has well tested | 16:16 |
| cjwatson | the majority of .debs in the Ubuntu archive come from source packages synced unmodified from Debian; it's certainly a higher barrier to entry than snaps, but you're putting them on a pedestal that's ... interesting | 16:16 |
| thiras | proven packages | 16:16 |
| nacc | thiras: lol | 16:16 |
| cjwatson | also, please could you stop using the enter key as punctuation, it's quite annoying :) | 16:17 |
| nacc | thiras: you clearly don't look at actual code quality metrics, or what is being tested in the archive (or the state of debian's CI) | 16:17 |
| thiras | that's why we have ppa | 16:17 |
| thiras | i have bitcoin client | 16:18 |
| thiras | can i put it as deb package into offical repos? | 16:18 |
| thiras | fully compromised will you accept it? | 16:19 |
| cjwatson | if you'd gone to the effort of becoming a developer first, then yes; like I say, higher barrier to entry but it's certainly no guarantee of authenticity, and | 16:19 |
| nacc | thiras: no, and neither would the snap store | 16:19 |
| thiras | thank you | 16:19 |
| cjwatson | no doubt you would have to be at least a little bit subtle about it | 16:19 |
| thiras | nacc, how so | 16:19 |
| cjwatson | but we should not delude ourselves that it is impossible | 16:19 |
| thiras | voting system? | 16:19 |
| nacc | thiras: snaps get reviewed, iirc | 16:19 |
| nacc | *new snaps | 16:19 |
| thiras | there is nothing impossible cjwatson i agreee | 16:19 |
| thiras | but we still use locks on our doors | 16:20 |
| cjwatson | the review for new packages in the Ubuntu archive doesn't include a technical cryptographic review of bitcoin protocol nonsense or whatever | 16:20 |
| nacc | heh | 16:20 |
| zyga | I figured out a nice way to find classic snaps that depend on host libs at runtime | 16:24 |
| zyga | I will implement that tomorrow | 16:24 |
| nacc | zyga: nice! | 16:24 |
| nacc | that would be helpful too | 16:24 |
| thiras | do you have plans to have that accounts info thingy? | 16:26 |
| thiras | like you said in snap info xxx | 16:26 |
| zyga | I found some more | 16:27 |
| zyga | thiras: I think it is sensible, pedronis would know if the store proviees enough meta-data today | 16:27 |
| thiras | i would close down the store until have that IMO. quite critical. | 16:28 |
| * kalikiana wrapping up for the week | 16:29 | |
| thiras | i hope see it live soon | 16:29 |
| zyga | flexiondotorg, popey: run atom on your machines | 16:31 |
| zyga | cat $(for pid in $(pgrep atom); do echo /proc/$pid/maps; done) | grep -v -E '/snap/(core|atom)/' | grep '/usr/lib' | awk '{ print $6 }' | sort -u | 16:31 |
| zyga | this shows which host libs they depend on | 16:31 |
| zyga | repeat for classic snaps | 16:31 |
| zyga | kyrofa: ^ | 16:32 |
| zyga | (fun, no?) | 16:32 |
| popey | -> afk | 16:32 |
| zyga | cat $(for pid in $(pgrep atom); do echo /proc/$pid/maps; done) | grep -v -E '/snap/.*/' | grep '/usr/lib' | awk '{ print $6 }' | sort -u | 16:32 |
| nacc | zyga: nice | 16:32 |
| zyga | this is generalized for not just atom, replace atom in the first part | 16:32 |
| kyrofa | zyga, I'm around, but you're third in the queue, give me a few | 16:32 |
| zyga | kyrofa: just enqueue this, ORIGIN replacement should handle multiarch | 16:33 |
| kyrofa | It does. Well, should anyway | 16:33 |
| zyga | the long shell thing above is a nice way to test against real-world snaps at runtime | 16:33 |
| zyga | kyrofa: apparently not in atom, sync with popey for details | 16:33 |
| kyrofa | Will do | 16:33 |
| mup | PR snapd#4956 closed: cmd/snap-update-ns: rename i to segNum <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4956> | 16:34 |
| zyga | jdstrand: can you please do a 2nd look on https://github.com/snapcore/snapd/pull/4955 - I think I addressed your concerns there | 16:34 |
| mup | PR #4955: cmd/snap-confine: make /run/media an alias of /media <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4955> | 16:34 |
| Anthaas | Anywhere to view popular snaps? | 16:35 |
| zyga | Anthaas: gnome-software shows featured snaps on some distributions | 16:36 |
| zyga | pstolowski: around? | 16:50 |
| zyga | pstolowski: I need a simple review for 4958 | 16:50 |
| zyga | I just add an argument in lots of places | 16:50 |
| zyga | pedronis: if you can as well | 16:51 |
| zyga | pedronis: this is the helper to remove the global variable hack from that other pR | 16:51 |
| pedronis | zyga: I'm looking at it, the code org feels a bit strange | 16:55 |
| niemeyer | kyrofa: Wanna talk now? | 16:57 |
| kyrofa | niemeyer, sure! | 16:57 |
| niemeyer | kyrofa: https://hangouts.google.com/hangouts/_/canonical.com/snap-architectures | 16:58 |
| pedronis | zyga: it feels like there should be something carrying state that exposes the secure* instead of passing this in this way and then passing it in to the secure* functions | 17:00 |
| zyga | pedronis: so making them all instances of some type | 17:01 |
| pedronis | well methods of some stateful struct | 17:02 |
| zyga | right | 17:02 |
| pedronis | I mean, so far they didn't need state | 17:02 |
| pedronis | now it seems they do | 17:02 |
| pedronis | is it the only state they will need? | 17:03 |
| pedronis | a bit unclear | 17:03 |
| zyga | it seems so | 17:03 |
| zyga | we never assumed mkdir would need state | 17:03 |
| pedronis | now it does though | 17:03 |
| pedronis | anyway my 2cts | 17:04 |
| zyga | pedronis: I can do as you said | 17:04 |
| zyga | pedronis: or we could iterate on this concept, it's fine either way | 17:04 |
| zyga | thanks! | 17:04 |
| zyga | mborzecki: hey, can I grab you for a moment | 17:08 |
| cachio | zyga, when you have any time #4832 | 17:12 |
| mup | PR #4832: tests: move fedora 27 to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4832> | 17:12 |
| cachio | it is to close the fedora one | 17:13 |
| zyga | looking | 17:13 |
| zyga | cachio: have a look | 17:14 |
| cachio | tx | 17:15 |
| * zyga breaks until the 2.32.2 release can be made | 17:18 | |
| zyga | Caelum: hey | 17:18 |
| zyga | Caelum: if you don't have time to update the leap builds I can do that too | 17:19 |
| zyga | I'd like to release your package to tumbleweed | 17:19 |
| zyga | aand I just did | 17:19 |
| * zyga goes to fix LEAP | 17:20 | |
| cachio | zyga, fedora branch updated | 17:23 |
| cachio | thanks for reviewing this | 17:23 |
| zyga | thanks, approved | 17:24 |
| cachio | \o/ | 17:25 |
| * zyga wonders where the sublime-text snap is | 17:29 | |
| zyga | om26er: do I recall correctly you were interested in that? | 17:29 |
| om26er | zyga: its uploaded but there is a bug | 17:36 |
| om26er | ...in the snap. I fixed that, there is a pending PR | 17:36 |
| om26er | https://github.com/snapcrafters/sublime-text/pull/9 | 17:41 |
| mup | PR snapcrafters/sublime-text#9: ship gtk2 and fix desktop file shortcuts <Created by om26er> <https://github.com/snapcrafters/sublime-text/pull/9> | 17:41 |
| om26er | @zyga: ^^ | 17:41 |
| om26er | the bug is because something changed in latest version of snapd (?) for classic snaps | 17:43 |
| kyrofa | niemeyer, just realized we didn't discuss the `ignore-failure` bit-- does that seem okay? | 17:45 |
| niemeyer | kyrofa: Hmm.. | 17:45 |
| zyga | OH | 17:46 |
| niemeyer | kyrofa: We should probably refactor it a bit so it can be expanded.. hmm | 17:46 |
| zyga | looking | 17:46 |
| niemeyer | I think we can do something like "build-errors: ignore" | 17:47 |
| niemeyer | kyrofa: | 17:47 |
| kyrofa | niemeyer, ah, in case we want an option besides ignore in the future? | 17:48 |
| niemeyer | kyrofa: But there's a detail here.. it's awkward to see the third-person verb next to a noun | 17:48 |
| niemeyer | Or an adjective I guess | 17:48 |
| niemeyer | kyrofa: So maybe we should say "build-on" and "run-on" | 17:48 |
| niemeyer | kyrofa: So that "build-foo" looks nice | 17:49 |
| niemeyer | build-on: blah | 17:49 |
| niemeyer | build-errors: foo | 17:49 |
| kyrofa | niemeyer, yeah I'm fine with that. A little more... functional instead of sentence-y | 17:49 |
| niemeyer | Right | 17:49 |
| zyga | om26er: that's interesting, that change was in snapcraft though as snapd didn't change how classic snaps run in ages | 17:50 |
| niemeyer | Imperative.. do this! | 17:50 |
| kyrofa | Indeed | 17:50 |
| kyrofa | Okay, build-error: ignore it is | 17:50 |
| pedronis | zyga: btw release/2.32 is read atm, not quite sure why, it seems a build error on fedora | 17:51 |
| pedronis | *is red | 17:51 |
| zyga | pedronis: yeah, we're not lucky :/ | 17:52 |
| zyga | pedronis: I think the media thing is a factor | 17:52 |
| pedronis | it's not an test error | 17:52 |
| pedronis | is failing on prepare | 17:52 |
| zyga | oh, what was the error? | 17:53 |
| pedronis | something building godbus and os/signal | 17:53 |
| pedronis | zyga: let me give you the end | 17:54 |
| pedronis | zyga: https://pastebin.ubuntu.com/p/d6rgHVVXSK/ I'm not quite sure what the error is | 17:54 |
| zyga | hmm, is it that thing that failed, maybe the error is earlier? | 17:56 |
| pedronis | maybe fedora prepare is super verbose | 17:57 |
| pedronis | zyga: full log is here: https://api.travis-ci.org/v3/job/359849295/log.txt | 17:59 |
| zyga | reading | 18:01 |
| zyga | hmm | 18:03 |
| zyga | indeed | 18:03 |
| pedronis | it seems a genuine like it's failing to make an archive fail | 18:03 |
| pedronis | *file | 18:03 |
| zyga | I wonder what "pack" there is | 18:03 |
| pedronis | not sure why now, in that branch | 18:03 |
| zyga | is that gong internal stuff? | 18:04 |
| pedronis | yes | 18:04 |
| zyga | so yeah, looks real, needs some investigation | 18:04 |
| pedronis | https://golang.org/cmd/pack/ | 18:06 |
| pedronis | it's also exploding far away from the what the PR changed (code in store) | 18:07 |
| zyga | I wonder why it started exploding | 18:07 |
| zyga | especially on linode | 18:07 |
| zyga | cachio: did we move anything on our linode fedora images? | 18:07 |
| pedronis | zyga: we don't know if https://github.com/snapcore/snapd/commit/eed6d62f9eb1d02af8e65927ae844aff31b69f55 built cleanly though | 18:11 |
| pedronis | because it was cancelled | 18:11 |
| pedronis | on 2.32 | 18:11 |
| zyga | I can run and reproduce | 18:11 |
| pedronis | I mean, at least that one is changing build stuff | 18:12 |
| pedronis | still not clear the relation though | 18:12 |
| zyga | I'm doing -debug on the release branch now | 18:12 |
| zyga | let's see | 18:12 |
| zyga | I think release tonight is unlikely | 18:12 |
| zyga | travis is starving us | 18:13 |
| zyga | and there are open PRs | 18:13 |
| koala_man | diddledan: my version issues were because snapcraft only looked for annotated tags, while all my later tags were lightweight | 18:13 |
| pedronis | zyga: it's not only the release, I got the same on my PR for master | 18:14 |
| zyga | on master on google? | 18:14 |
| pedronis | zyga: did fedora get a new golang version? | 18:14 |
| zyga | F27 would not but let me check | 18:15 |
| zyga | well | 18:15 |
| pedronis | no still linode | 18:15 |
| zyga | I'll check | 18:15 |
| zyga | go version go1.9.4 linux/amd64 | 18:15 |
| zyga | checking changeling now | 18:15 |
| pedronis | anyway failure is the same as on release/2.32 | 18:16 |
| zyga | hum | 18:16 |
| zyga | I just got this on F27 on a casual go test ./... | 18:16 |
| zyga | https://www.irccloud.com/pastebin/tD6mlgYu/ | 18:16 |
| pedronis | master is now also red | 18:18 |
| pedronis | same error | 18:18 |
| pedronis | zyga: you need gcc-multiarch to run those tests | 18:18 |
| pedronis | sorry | 18:19 |
| pedronis | gcc-multilib | 18:19 |
| zyga | there's no such thing apparently | 18:20 |
| pedronis | that's been there since a long while | 18:22 |
| pedronis | that's the name of the ubuntu package | 18:22 |
| pedronis | I don't think it relates to the current error | 18:22 |
| zyga | hmm, yeah | 18:26 |
| zyga | I got to the same error in -debug build | 18:26 |
| pedronis | what did change? | 18:27 |
| pedronis | it seems master was green until this morning ~ 2h ago | 18:27 |
| zyga | no idea what changed, I don't know how to find the changelogs in RPM world | 18:28 |
| zyga | let me update the VM and see if I can reproduce it | 18:28 |
| zyga | Pharaoh_Atem: ping | 18:29 |
| zyga | if you are around, we could use some help | 18:29 |
| Pharaoh_Atem | zyga: pong? | 18:30 |
| zyga | hey | 18:30 |
| zyga | golang started to fail on us recently | 18:30 |
| zyga | any idea if there's widespread fire in F27? | 18:30 |
| zyga | or some major changes to golnag | 18:30 |
| zyga | or how to find a changelog for the toolchain | 18:30 |
| zyga | to reproduce just run: spread -debug -v linode:fedora-27-64/tests/main/ | 18:30 |
| zyga | it will fail on rpmbuild -ba ... | 18:31 |
| zyga | rpmbuild --with testkeys -ba packaging/fedora-27/snapd.spec | 18:31 |
| * zyga runs a build with updated fedora VM | 18:31 | |
| Pharaoh_Atem | there's the revamp of the golang macros | 18:31 |
| Pharaoh_Atem | but that shouldn't break snapd... I think | 18:31 |
| zyga | Pharaoh_Atem: in F28 or F27 too? | 18:31 |
| Pharaoh_Atem | everything | 18:31 |
| zyga | ok | 18:31 |
| zyga | reproduced on up-to-date F27 | 18:32 |
| zyga | https://www.irccloud.com/pastebin/G2rCOdVh/ | 18:32 |
| Pharaoh_Atem | go has the worst debug messages | 18:32 |
| pedronis | as in no message | 18:33 |
| pedronis | is just dieing there | 18:33 |
| zyga | to be fair, I don't know what's really happening in the rpm build macros | 18:33 |
| zyga | going to src/os/signal I can "go build" | 18:33 |
| pedronis | pack r $WORK/os/signal.a $WORK/os/signal/_obj/sig.o # internal shows up also normally | 18:33 |
| pedronis | is not an error message | 18:33 |
| pedronis | alone | 18:34 |
| pedronis | it might be what dies (maybe) | 18:34 |
| zyga | interestingly | 18:35 |
| zyga | sig.o is from sig.s | 18:35 |
| zyga | and sig.s is empty | 18:35 |
| zyga | well | 18:35 |
| zyga | https://www.irccloud.com/pastebin/mEogC2QN/ | 18:35 |
| zyga | maybe some of the rpm build macros dont handle this correctly? | 18:36 |
| pedronis | that hasn't change recently I think | 18:36 |
| zyga | the .s file? yeah | 18:36 |
| zyga | but the macros | 18:36 |
| jdstrand | zyga: it seems you didn't see that I already responded to 4955 a while ago: https://github.com/snapcore/snapd/pull/4955#discussion_r178084121 | 18:37 |
| mup | PR #4955: cmd/snap-confine: make /run/media an alias of /media <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4955> | 18:37 |
| pedronis | sig.s is like that also in go 1.6 | 18:37 |
| zyga | Pharaoh_Atem: can you point us to a changelog or some description of what is changing? | 18:37 |
| pedronis | that's from the stdlib | 18:37 |
| pedronis | btw | 18:37 |
| zyga | jdstrand: oh, looking | 18:37 |
| zyga | jdstrand: no, github didn't show that :/ | 18:37 |
| zyga | thanks | 18:37 |
| jdstrand | I don't know why github comments are sometimes lossy | 18:37 |
| jdstrand | it is annoying | 18:37 |
| zyga | jdstrand: yeah, no disagreement there | 18:38 |
| zyga | so I'll just check that altpath is not a symlink | 18:38 |
| zyga | that's easy, thank you | 18:38 |
| zyga | (if only everything was not on fire :) | 18:38 |
| zyga | pedronis: yes, I think rpm side broke, not the go side | 18:38 |
| pedronis | yes, what I'm saying is that that thing is not an obscure | 18:39 |
| pedronis | 3rd party package | 18:39 |
| pedronis | is a piece of the stdlib | 18:39 |
| zyga | ack, right | 18:40 |
| zyga | Pharaoh_Atem: I will take any ideas or patches you can give me | 18:40 |
| zyga | I think the release plan for today is to EOD and rest | 18:41 |
| zyga | and read a book about something not work related | 18:41 |
| zyga | jdstrand: https://github.com/snapcore/snapd/pull/4955/commits/7ef58f6c315e13557f2e8c318980e7bcdfc8d316 | 18:50 |
| mup | PR #4955: cmd/snap-confine: make /run/media an alias of /media <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4955> | 18:50 |
| jdstrand | zyga: approved with comment | 19:02 |
| zyga | reading | 19:02 |
| jdstrand | it's only a nitpick | 19:03 |
| zyga | sure, will tweak in a sec, rebooting VMs | 19:03 |
| mup | PR snapd#4961 opened: cmd: make fmt (indent 2.2.11) <Created by zyga> <https://github.com/snapcore/snapd/pull/4961> | 19:11 |
| cachio | zyga, https://travis-ci.org/snapcore/snapd/builds/359989484#L2706 | 19:50 |
| cachio | could be cause because we set selinux permissive | 19:50 |
| cachio | ? | 19:50 |
| cachio | it starting failing after last chnage that was totally unrelated | 19:51 |
| zyga | cachio: no | 19:53 |
| zyga | cachio: it's some golang bug, we don't know yet | 19:53 |
| zyga | cachio: to be precise, according to Pharaoh_Atem rpm macros changed recently, not sure what to do | 19:53 |
| cachio | zyga, ah, ok | 19:55 |
| cachio | zyga, I'll wait so | 19:55 |
| cachio | zyga, tell me if you need any help to fix/validate that | 19:55 |
| zyga | i took a break for today | 19:55 |
| zyga | Ideas welcome | 19:56 |
| zyga | I’ll try tomorrow | 19:56 |
| cachio | zyga, sure | 19:56 |
| cachio | I'll be off tomorrow but I'll be connected | 19:56 |
| pedronis | zyga: so I tried to run of that by hand, interestingly is not pack that fails, afaict the sig.o is added to the archive | 20:00 |
| pedronis | is the wrapper program or whatever comes next | 20:00 |
| pedronis | it produces no output of its own though :/ | 20:00 |
| pedronis | *run some of that | 20:01 |
| pedronis | apparently it dies just before building snapd itself | 20:05 |
| pedronis | it makes no sense | 20:11 |
| kyrofa | Snapd 2.31.2 has been in xenial-proposed for a while, is something holding it up? | 21:04 |
| nacc | kyrofa: http://people.canonical.com/~ubuntu-archive/pending-sru.html bunch of test regressions? | 21:05 |
| nacc | and in dep-wait for 14.04, it seems | 21:05 |
| kyrofa | I suppose that'd do it | 21:05 |
| nacc | kyrofa: i'd get all of that green :) | 21:06 |
| vidal72[m] | I wonder how daemon snap package integrate with system - i.e. when I install network-manager snap - can I manage it from systemd services? | 21:41 |
| popey | vidal72[m]: systemctl status snap.network-manager | 21:46 |
| popey | or similar | 21:46 |
| vidal72[m] | popey: thx | 21:46 |
| kyrofa | zyga, I don't suppose you're still around | 22:02 |
| kyrofa | On trusty I'm getting "error: unable to contact snap store" | 22:03 |
| kyrofa | Whenever I try to refresh or install anything | 22:03 |
| noise][ | kyrofa: network outage | 22:04 |
| noise][ | generally, not just store | 22:04 |
| kyrofa | noise][, oh, what a coincidence! | 22:04 |
| jdstrand | zyga, jamesh: fyi, I approved the approach of https://github.com/snapcore/snapd/pull/4957. I'm eod now-- I'll respond to comments in the PR as needed | 22:19 |
| mup | PR #4957: cmd/snap-update-ns: remove the need for stash directory in secure bind mount implementation <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4957> | 22:19 |
| kyrofa | niemeyer, the lxd backend in spread fails every time for be with 17.10 and 18.04, always giving me this: | 22:50 |
| kyrofa | 2018-03-29 15:47:11 Discarding lxd:ubuntu-18.04 (spread-31-ubuntu-18-04), cannot connect: cannot connect to lxd:ubuntu-18.04 (spread-31-ubuntu-18-04): ssh: handshake failed: ssh: unable to authenticate, attempted methods [none password], no supported methods remain | 22:50 |
| kyrofa | 2018-03-29 15:48:03 Discarding lxd:ubuntu-17.10 (spread-33-ubuntu-17-10), cannot connect: cannot connect to lxd:ubuntu-17.10 (spread-33-ubuntu-17-10): ssh: handshake failed: ssh: unable to authenticate, attempted methods [password none], no supported methods remain | 22:50 |
| kyrofa | Curious if that rings any bells. 16.04 works fine | 22:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!