| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| zyga | o/ | 06:07 |
|---|---|---|
| zyga | good morning | 06:08 |
| mvo | hey zyga | 06:08 |
| zyga | hey :) | 06:08 |
| mborzecki | zyga: mvo: morning guys | 06:09 |
| zyga | good morning | 06:09 |
| mvo | hey mborzecki | 06:09 |
| zyga | mborzecki: please wait on the opens use review, I found some things to change last night that I didn't address yet | 06:10 |
| mborzecki | zyga: ok | 06:10 |
| mvo | zyga: your opensuse build update shows "+ echo 'Package build incorrect, '\''snap --version'\'' mentions '\''unknown'\'''" | 06:16 |
| mvo | zyga: in the spread tests | 06:16 |
| zyga | yeah, I saw that | 06:16 |
| zyga | that's what I meant :) | 06:17 |
| mvo | ok | 06:17 |
| mvo | zyga: oh, sorry, missed that I guess | 06:17 |
| zyga | it works fine in casual testing but I wanted to see spread run before releasing this | 06:17 |
| zyga | no worries, thank you for looking | 06:17 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| mborzecki | https://github.com/snapcore/snapd/pull/6094 could use another review | 07:35 |
| mup | PR #6094: wrappers: fix generating of service units with multiple `before` dependencies <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6094> | 07:36 |
| mborzecki | then we can land it and pick it for 2.36 | 07:36 |
| zyga | yep | 07:49 |
| zyga | mborzecki: interesting, in my local build I see the correct version on "snap version" | 07:51 |
| pstolowski | good morning! | 08:07 |
| === chihchun is now known as chihchun_afk | ||
| zyga | --debug session shows unknown | 08:09 |
| zyga | so odd, let's see why | 08:09 |
| zyga | ah | 08:10 |
| zyga | because of how we build in spread | 08:10 |
| zyga | normal builds are fine | 08:11 |
| mborzecki | hm i'm debugging why #5896 spread test for device keys seeminglly doesn't work | 08:14 |
| mup | PR #5896: snapcraft.yaml: set grade to stable <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5896> | 08:14 |
| mborzecki | the test snap finds a device /dev/input/by-path/platform-i8042-serio-0-event-kbd which as it turns out has all the attributes that make it match with device-buttons interface :/ | 08:15 |
| mborzecki | hm no it doesn't match, but the snap can still access it | 08:23 |
| mborzecki | zyga: any clues, there's a device /dev/input/event2 maj:min is 13:66, it's not listed in devices.list for that snap, but when running under --shell i can still open it | 08:24 |
| zyga | mborzecki: _hmm_ | 08:36 |
| zyga | mborzecki: when you open shell can you see the process listed in the control group? | 08:36 |
| mborzecki | zyga: heh, no cgroup.procs is empty | 08:38 |
| zyga | what system is that? | 08:39 |
| zyga | is that devmode system? | 08:39 |
| mborzecki | zyga: 18.04 | 08:39 |
| zyga | that's interesting | 08:40 |
| zyga | ah | 08:40 |
| zyga | well | 08:40 |
| zyga | there's this one old odd behavior | 08:40 |
| zyga | if you have no device tags for a given security tag | 08:40 |
| zyga | then we don't use cgroups | 08:40 |
| zyga | no tagging == no device cgroup | 08:40 |
| mborzecki | zyga: sounds like a problem, with this interface you could get access to all /dev/input/* | 08:42 |
| zyga | yes, it feels like we should make it unconditional | 08:43 |
| zyga | can you check if that's still the case | 08:43 |
| zyga | the code is in snap-confine/ in udev-support AFAIR | 08:43 |
| mborzecki | zyga: feels like this is going to be fun, i need some coffee first | 08:45 |
| zyga | uh, I forgot about dentist appointment | 08:47 |
| zyga | need to go | 08:47 |
| mvo | pstolowski: quick question: we only run the post-refresh hook on refreshes, right? not on a fresh install? so if I want something that run on a fresh install and a refresh I need to install two hook hanlders? | 08:50 |
| pstolowski | mvo: correct, pre- and post-refresh hooks run only on refreshes. and install hook is run only on fresh install | 08:53 |
| doko | mvo, zyga: the snapd autopkg tests are not happy with python 3.7 in disco. please fix | 08:54 |
| mvo | pstolowski: ta | 08:54 |
| mvo | doko: sure, looking | 08:55 |
| zyga | Thank you doko | 09:10 |
| * zyga is at the dentist | 09:10 | |
| doko | is snapd such a pain? | 09:13 |
| mwhudson | zyga: thanks for https://bugs.launchpad.net/ubuntu/+source/plainbox/+bug/1801687 | 09:15 |
| mup | Bug #1801687: Please remove the plainbox package <plainbox (Ubuntu):New> <https://launchpad.net/bugs/1801687> | 09:15 |
| Chipaca | morning from the summit | 09:19 |
| mborzecki | Chipaca: hey, what's the turnout? | 09:28 |
| Chipaca | mborzecki: ~100,000 people | 09:29 |
| mborzecki | Chipaca: over 9000 ;) | 09:29 |
| Chipaca | mborzecki: :-) | 09:29 |
| mvo | Chipaca: good morning! how are things there? anything exciting happening already? | 09:33 |
| diddledan | mvo: popey is playing with his nipple already | 09:46 |
| popey | ! | 09:47 |
| ogra | in public ?!?! | 09:47 |
| diddledan | INORITE | 09:47 |
| mvo | diddledan: *cough* | 09:48 |
| === iliv_ is now known as ivan_CMD | ||
| mup | PR snapd#6096 opened: spread.yaml: add more systems to the autopkgtest and qemu backends <Created by mvo5> <https://github.com/snapcore/snapd/pull/6096> | 09:59 |
| mup | PR snapd#6097 opened: interfaces/tests: MockHotplugSlot test helper <Hotplug 🔌> <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6097> | 10:00 |
| mvo | doko: I uploaded a new snapd into disco that should now run the adt tests, will be interessting to see if they fail or pass so maybe there is more work needed but this should at least unblock things | 10:06 |
| zyga | Dentist over, heading home | 10:06 |
| mvo | zyga: welcome back | 10:06 |
| zyga | What was the issue with python 3.7? | 10:06 |
| mvo | zyga: pr is 6096 | 10:07 |
| mvo | zyga: its an internal issue might be worth reworking how we drive adt | 10:07 |
| doko | I love it when you have to do things like that for every release ... maybe just do the reverse, where it's *not* supported? | 10:08 |
| mvo | doko: sure, let me look what we can do to make this simpler | 10:08 |
| mvo | doko: thanks for approving it though | 10:09 |
| * mvo looks into reworking that code | 10:09 | |
| popey | degville: https://snapcraft.io/docs/reference/env is referenced in a few places and redirects to a 410 page https://docs.snapcraft.io/reference/env | 10:15 |
| degville | ooh, thanks popey. | 10:21 |
| pedronis | mvo: what's the status of 2.36? is there anything immediately blocked on me? | 10:23 |
| mvo | pedronis: we need confirmation about the 2.36 API of "system" vs "core" | 10:24 |
| mvo | pedronis: I sent a mail about this but no reply yet | 10:25 |
| mup | PR snapd#6098 opened: interfaces/builtin: support hotplug for camera interface <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6098> | 10:25 |
| mborzecki | zyga: about that cgroup & apparmor, i think now with the process ending up in devices cgroup always, accessing /dev/input/event2 is blocked before lsm gets to have a say on this | 10:27 |
| zyga | and back home now | 10:28 |
| zyga | mborzecki: that's correct | 10:28 |
| mborzecki | zyga: ok, i'll push the change for s-c as separate PR, some tests may need to be updated, especially the ones where we check between EPERM and EACCESS | 10:29 |
| zyga | aha, that makes sense | 10:30 |
| zyga | thank you | 10:30 |
| ogra | mvo, i'm recently working a lot with x86 images ... was there any actual reason that we show the grub menu there ? | 10:30 |
| ogra | i mean ... you normally dont select anything there anyway ... | 10:31 |
| mvo | ogra: no real reason, it may become more interessting once we provide recovery via this mechanism but even then its not a huge reason | 10:33 |
| mvo | ogra: also kind of nice to show people what system they use but *shrug* really no strong reason :) | 10:33 |
| ogra | it feel like wasted boot time | 10:34 |
| ogra | *feels | 10:34 |
| zyga | I built the package locally out of a release tarball and the version is correct | 10:51 |
| zyga | the issue must be related to how we build the tarball inside spread | 10:51 |
| mup | PR snapd#6099 opened: cmd/snap-confine: always put the snap process under a device cgroup <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6099> | 11:02 |
| zyga | mborzecki: interesting, let's see what we get | 11:06 |
| zyga | (from tests) | 11:06 |
| mborzecki | zyga: yeah, much fun | 11:07 |
| Chipaca | hmm | 11:08 |
| Chipaca | mborzecki: https://forum.snapcraft.io/t/parallel-installs/7679 | 11:08 |
| Chipaca | mborzecki: says 1. parallel installs are experimental and you need to 'snap set hose-my-system=very-yes' | 11:09 |
| Chipaca | mborzecki: but also, 2. you need 2.36 | 11:09 |
| mborzecki | Chipaca: yes | 11:09 |
| mborzecki | Chipaca: 2*yes | 11:09 |
| Chipaca | mborzecki: I thought 2.36 marked them non-experimental? | 11:09 |
| mborzecki | Chipaca: no, we delayed that to 2.37 | 11:09 |
| Chipaca | ah, missed that | 11:09 |
| Chipaca | ok | 11:09 |
| Chipaca | mborzecki: are the store-side limitations still true? | 11:10 |
| mborzecki | Chipaca: no, there's a note from wgrant, i should probably update the first message | 11:10 |
| Chipaca | mborzecki: yes please :-) | 11:11 |
| mborzecki | Chipaca: aand done | 11:12 |
| mborzecki | Chipaca: are you guys actively trying to break it? :) | 11:12 |
| Chipaca | mborzecki: 👍 | 11:12 |
| Chipaca | mborzecki: people are being told it works /o\ | 11:12 |
| mborzecki | Chipaca: good, good, ping me if there are any questions | 11:13 |
| Chipaca | will do :-) | 11:13 |
| mborzecki | zyga: that device cgroup change, i think it's more of a 2.37 material, wdyt? | 11:15 |
| zyga | mborzecki: not for 2.36 for sure | 11:16 |
| zyga | we need to discuss with jdstrand and pedronis | 11:16 |
| mup | PR snapd#5946 closed: cmd/snap: unhide --name parameter to snap install, tweak help message <Parallel installs ⛓> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5946> | 11:18 |
| pedronis | zyga: I'm going a bit through my email etc backlog and some travel admin stuff, but I should be available later in the week to discuss things | 11:24 |
| Chipaca | mvo: https://pastebin.ubuntu.com/p/4hpHK8MRHq/ | 11:24 |
| Chipaca | niemeyer: ^ i really wish we could do smarter formatting of tables on the terminal :-( | 11:26 |
| mvo | Chipaca: woah | 11:26 |
| Chipaca | (granted that message is longer than it needs to be :) ) | 11:26 |
| zyga | pedronis: thank you | 11:29 |
| zyga | Chipaca: use case for those ultra crazy wide monitors ;) | 11:29 |
| ogra | 80 chars are enough for everyone ! | 11:39 |
| mup | PR snapd#5916 closed: data: run snapd.autoimport.service only after seeding <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5916> | 11:49 |
| mborzecki | zyga: a bunch of tests failed in 6099 | 11:49 |
| Chipaca | zyga: I see your wide monitor use case, and I raise you a use case for in-snap sub-mount namespaces | 11:50 |
| zyga | Chipaca: whaaat? | 11:50 |
| Chipaca | zyga: also in-snap network namespaces | 11:50 |
| Chipaca | zyga: you started! this is all your fault | 11:50 |
| zyga | that I actually want | 11:50 |
| zyga | app firewall | 11:50 |
| zyga | looking at logs there maciej | 11:51 |
| zyga | eh | 11:51 |
| zyga | log too long | 11:51 |
| zyga | mborzecki: Ensure we can run a statically linked binary from an empty base <- this failed, interesting | 11:51 |
| mborzecki | zyga: yeah, the log hit travis limits | 11:51 |
| zyga | mborzecki: I think at this point you need to see what happens until you can run the statically linked echo test | 11:52 |
| mborzecki | zyga: anyways, Operation not permitted popping up quite frequently, must have been blocked by device cgroups then | 11:52 |
| zyga | yeah | 11:53 |
| Chipaca | pedronis: o/ | 11:57 |
| mborzecki | Chipaca: error: invalid argument for flag `--id' (expected main.snapshotID): strconv.ParseUint: parsing "": invalid syntax, is this something you were looking for? | 12:07 |
| Chipaca | mborzecki: you should have logs | 12:09 |
| Chipaca | mborzecki: if it's amazon telling you about id -2, take its vodka away | 12:10 |
| Chipaca | mborzecki: uid -2 that is | 12:10 |
| mborzecki | Chipaca: yes, it is https://paste.ubuntu.com/p/Ms9jXqvH6V/ | 12:10 |
| Chipaca | bah | 12:10 |
| Chipaca | bah² | 12:10 |
| Chipaca | bah³ | 12:10 |
| Chipaca | bah⁹⁹ | 12:10 |
| Chipaca | mborzecki: i'm not sure i can handle it better than just failing | 12:11 |
| Chipaca | mborzecki: but also i don't know why i'm getting that -2 | 12:11 |
| Chipaca | mborzecki: I do know why it's a -2 :-) | 12:11 |
| Chipaca | mborzecki: amazon linux 2, yes? | 12:11 |
| mborzecki | Chipaca: yes | 12:11 |
| mborzecki | hm we could dump /etc/passwd in debug | 12:12 |
| Chipaca | mborzecki: AIUI it's a manifestation of https://github.com/golang/go/issues/22739 | 12:13 |
| Chipaca | mborzecki: the -2, i mean | 12:13 |
| zyga | Chipaca: it is an off-by-one issue :) | 12:14 |
| Chipaca | nope, it's golang's syscall return value munging | 12:14 |
| Chipaca | so | 12:14 |
| Chipaca | that -2 comes from os.Getuid() returning something too big | 12:14 |
| Chipaca | for go | 12:14 |
| pedronis | Chipaca: hi | 12:15 |
| Chipaca | which doesn't make sense on itself | 12:15 |
| Chipaca | but ¯\_(ツ)_/¯ | 12:15 |
| mborzecki | Chipaca: although it's globbed, the path i mean | 12:15 |
| Chipaca | pedronis: hi! welcome back. Random question about aliases (from a user at the summit): are multiple snaps having the same alias supported ok store-side? | 12:15 |
| mborzecki | Chipaca: some stat maybe? uid/gid handled incorrectly | 12:15 |
| Chipaca | pedronis: i assume yes but dunno how tested it is :-) | 12:15 |
| Chipaca | mborzecki: i literally just remembered where the -2 comes from today, so i need to comb it | 12:16 |
| pedronis | Chipaca: yes, you'll need to use snap prefer and --unaliased in case you want them both on the same system | 12:16 |
| Chipaca | pedronis: yep | 12:18 |
| niemeyer | Chipaca: Yeah, that looks pretty bad | 12:19 |
| niemeyer | Chipaca: We need something significantly more polished | 12:19 |
| Chipaca | niemeyer: I can make it shorter, but I can't make it short enough without giving the user context about why they're being warned | 12:19 |
| Chipaca | i mean, short, or with context | 12:20 |
| Chipaca | just saying "this app is devmode" isn't enough imo | 12:20 |
| niemeyer | Chipaca: The date formating is also breaking our old rule about having no spaces before the last item | 12:20 |
| cachio | niemeyer, hey, when you have some time, could you please take a look to this PR? https://github.com/snapcore/spread/pull/70 | 12:20 |
| mup | PR spread#70: Reboot on backgraound to avoid spread wait for long time <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/70> | 12:20 |
| niemeyer | Making it even harder to read | 12:20 |
| niemeyer | cachio: Sure | 12:20 |
| niemeyer | I have some time now, but it'll be hard to review it while in line at the border :) | 12:21 |
| niemeyer | Chipaca: We might have a short description and a link | 12:22 |
| Chipaca | niemeyer: i was thinking of "snap help devmode" | 12:22 |
| Chipaca | ie having topics | 12:22 |
| Chipaca | as well as commands | 12:23 |
| niemeyer | That sounds nice! | 12:23 |
| niemeyer | Chipaca: Perhaps just some twist on it so it doesn't look like a command? | 12:23 |
| niemeyer | Do we support that today? | 12:24 |
| niemeyer | snap help <cmd>? | 12:24 |
| Chipaca | niemeyer: yes | 12:24 |
| niemeyer | Yeah, so we need to disambiguate | 12:24 |
| Chipaca | niemeyer: and snap help --all is how you get the long list of everything | 12:24 |
| Chipaca | so 'snap' on its own tells you to 'snap help --all' for ex | 12:24 |
| cachio | niemeyer, great, thanks | 12:25 |
| niemeyer | snap about devmode | 12:25 |
| Chipaca | niemeyer: wrt the timestamp, i'll change it to use the shorter format we discussed for 'snap saved' | 12:25 |
| niemeyer | Chipaca: Sounds good | 12:25 |
| Chipaca | that one doesn't have spaces | 12:26 |
| niemeyer | Chipaca: Or we could really use the link for the detailing of an issue | 12:26 |
| niemeyer | Chipaca: Or alternatively, transform the output of warnings into yaml | 12:27 |
| niemeyer | So we can actually read it | 12:27 |
| mup | PR snapd#6100 opened: overlord/ifacestate: hotplug-remove-slot task handler <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6100> | 12:33 |
| mup | PR snapd#6101 opened: switch travis unit tests to xenial <Created by chipaca> <https://github.com/snapcore/snapd/pull/6101> | 12:34 |
| zyga | sigh | 12:35 |
| * zyga tries again | 12:35 | |
| pedronis | Chipaca: I remember we do line wrapping for some errors, either way the super informative warning is good if it's are, but will get annoying if the warning is very common | 12:35 |
| mup | PR snapd#5963 closed: tests/hotplug: spread test for hotplug based on dummy interface <Hotplug 🔌> <⛔ Blocked> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/5963> | 12:35 |
| pedronis | s/it's are/it's rare/ | 12:35 |
| Chipaca | pedronis: agreed about that | 12:41 |
| zyga | https://www.irccloud.com/pastebin/mEgjLBWg/ | 12:42 |
| zyga | mborzecki: ^ weird, right? | 12:42 |
| zyga | info file is correct too | 12:43 |
| mborzecki | zyga: 1337 version is better than none :) | 12:43 |
| mborzecki | 31337 | 12:43 |
| mborzecki | zyga: the one i have here locally is ok | 12:44 |
| zyga | yeah | 12:44 |
| mborzecki | zyga: from what i see we change it in prepare when bulding rpms | 12:45 |
| zyga | I think I know what's wrong now | 12:45 |
| zyga | copy | 12:46 |
| mborzecki | zyga: are you calling go generate as part of the build? | 12:46 |
| zyga | I call mkversion.sh in prepare | 12:46 |
| zyga | google:opensuse-42.3-64 /# find -name version_generated.go | 12:46 |
| zyga | ./usr/src/packages/BUILD/snapd-1337.2.36/gopath/src/github.com/snapcore/snapd/cmd/version_generated.go | 12:46 |
| zyga | so this file is good | 12:46 |
| Chipaca | niemeyer: some cool people from travis-ci are here | 12:47 |
| Chipaca | niemeyer: it turns out we can throw money at them and get more concurrent runs | 12:47 |
| mborzecki | zyga: then why it's unknown in snap version output? | 12:47 |
| Chipaca | niemeyer: it's just a bit messy and requires a human, because we're using .org | 12:47 |
| zyga | ./usr/src/packages/BUILD/snapd-1337.2.36/gopath/src/github.com/snapcore/snapd/cmd/VERSION | 12:47 |
| Chipaca | niemeyer: let's chat | 12:47 |
| zyga | there's also this which is equally correct | 12:47 |
| zyga | mborzecki: now I'm confused :/ | 12:48 |
| * zyga looks | 12:48 | |
| Chipaca | grr, unit tests are 8 minutes again :-( | 12:49 |
| mborzecki | zyga: in arch i'm calling ./mkversion.sh $pkgver-$pkgrel | 12:49 |
| mborzecki | zyga: so it's not guessing the version | 12:49 |
| pedronis | mborzecki: hi, was https://forum.snapcraft.io/t/cross-snap-service-ordering/8319 discussed with niemeyer, it doesn't seem to match the brief discussion we had in SLC | 12:49 |
| zyga | the version is fine in VERSION and in go so it's not that | 12:50 |
| mborzecki | pedronis: hi, no hence the forum topic, could you leave a comment with what you discussed in slc there? | 12:50 |
| zyga | must be something I'm missing :/ | 12:50 |
| zyga | I was thinking it must be a copy | 12:50 |
| zyga | C and Go are built differently | 12:50 |
| zyga | C picks up the version okay | 12:50 |
| zyga | go uses import paths to build stuff | 12:50 |
| zyga | so I was thinking there must be a bit of copy that was not changed with mkversion somewhere | 12:51 |
| pedronis | mborzecki: I'll try to put something there today or tomorrow, we just sketched some ideas | 12:51 |
| pedronis | it will need further discussion | 12:51 |
| zyga | google:opensuse-42.3-64 /root# GOPATH=/usr/src/packages/BUILD/snapd-1337.2.36/gopath go build -buildmode=pie github.com/snapcore/snapd/cmd/snap | 12:51 |
| zyga | https://www.irccloud.com/pastebin/szuxkg0r/ | 12:51 |
| zyga | so this worked okay | 12:51 |
| mborzecki | pedronis: fair enough, i'm out to conference on wed and thu so no rush | 12:51 |
| niemeyer | Chipaca: Ack | 12:51 |
| zyga | I'll add a sanity check in %build to see what version we se | 12:51 |
| zyga | mborzecki: ah, there _is_ a copy | 12:53 |
| zyga | wtf? | 12:53 |
| zyga | we have /home/gopath | 12:53 |
| zyga | and /usr/src/ | 12:53 |
| * zyga looks | 12:53 | |
| zyga | but this is why this happened | 12:53 |
| mborzecki | src.rpm got installed? | 12:53 |
| zyga | no, I think that's our spread hacking magic | 12:54 |
| zyga | aka mess | 12:54 |
| zyga | hmm | 12:55 |
| zyga | mborzecki: what is GOHOME? | 12:55 |
| mborzecki | GOHOME? | 12:56 |
| zyga | it's set in spread.yaml | 12:56 |
| zyga | git grep GOHOME | 12:56 |
| zyga | looks like our invention | 12:56 |
| mborzecki | zyga: right, but we set GOPATH using that | 12:56 |
| zyga | that's fine though | 12:56 |
| zyga | I wonder where /usr/src came from | 12:56 |
| zyga | specifically usr/src/packages/BUILD | 12:57 |
| zyga | doesn't feel like something out of srcrpm | 12:57 |
| * zyga looks | 12:58 | |
| zyga | quick coffee while spread starts up | 12:58 |
| Chipaca | zyga: /usr/src is GOROOT | 12:59 |
| Chipaca | I'm guessing | 12:59 |
| zyga | Chipaca: nope, suse sets GOROOT in the environment to something like /usr/lib64/go/1.11 | 13:02 |
| zyga | there is no match for /usr/src in our tree so I'm puzzled | 13:02 |
| pedronis | mvo: I pinged you from a couple of unanswered forum topics | 13:03 |
| mborzecki | off to pick up the kids | 13:05 |
| zyga | I see what's going on now | 13:13 |
| zyga | just not sure how /usr/share/packages is defined | 13:14 |
| zyga | but that's fine | 13:14 |
| zyga | got it! | 13:14 |
| zyga | # rpm -E '%{_topdir}' | 13:14 |
| zyga | /usr/src/packages | 13:14 |
| zyga | so | 13:14 |
| zyga | we have a copy there in BUILD | 13:14 |
| zyga | and we have a copy in /home/gopath | 13:15 |
| zyga | now just to untangle that | 13:15 |
| Son_Goku | zyga, it's /usr/lib/rpm/macros | 13:18 |
| Son_Goku | SUSE patches rpm to force that | 13:18 |
| zyga | yeah, I know now :) | 13:18 |
| Son_Goku | what it does is that if ~/rpmbuild doesn't exist, it will use that directory instead | 13:19 |
| Son_Goku | (IMO, that's broken, but whatever...) | 13:19 |
| Son_Goku | also... zyga: https://twitter.com/fedora/status/1059728342666989568 | 13:19 |
| Son_Goku | looky, you're in the picture :D | 13:19 |
| zyga | Niiiice :) | 13:20 |
| Son_Goku | as am I! weee! :D | 13:20 |
| ogra | seems he surrenders | 13:20 |
| ogra | :) | 13:20 |
| Son_Goku | yep, he's now a Fedora man | 13:21 |
| Son_Goku | no more Ubuntu for him :D | 13:21 |
| ogra | go IBM ! | 13:21 |
| ogra | :P | 13:21 |
| Son_Goku | :S | 13:22 |
| jdstrand | mborzecki: fyi, the fuse-support test in your cgroup PR is failing cause you're checking for Permission Denied (as you said above) | 13:32 |
| Son_Goku | zyga, mborzecki, you guys will want to look into this: https://bugzilla.redhat.com/show_bug.cgi?id=1438079#c4 | 13:34 |
| Son_Goku | I have a feeling we're switching the unified hierarchy for cgroups (aka cgroups v2) very soon | 13:35 |
| mvo | pedronis: thanks for the pings, I'm replying now | 13:35 |
| zyga | Son_Goku: I know about it, I talked to zbyszek | 13:35 |
| zyga | I think that v2 is not ready yet | 13:35 |
| zyga | it doesn't have the controllers we need | 13:35 |
| Son_Goku | ok | 13:36 |
| mborzecki | jdstrand: a couple of tests fail the same way, and i have some issues with devmode, we do not generate udev rules in that case but with the PR s-c will still put the snap under a cgroup | 13:38 |
| mborzecki | Son_Goku: thanks for the heads up | 13:38 |
| mborzecki | zyga: iirc we're only missing freezer at this point, aren't we? | 13:39 |
| zyga | mborzecki: haha, not sure if only but the freezer is the first one I noticed | 13:39 |
| Son_Goku | zyga, need karma for this: https://bodhi.fedoraproject.org/updates/FEDORA-2018-48cc10ba1d | 13:40 |
| zyga | ack, I'll test it today | 13:40 |
| mborzecki | zyga: maybe it'd be a good idea to check what's in there already and what we're missing | 13:40 |
| mborzecki | zyga: switching will be proobably held for as long as docker dones not support v2 | 13:41 |
| zyga | mborzecki: based on my discussion with zbyszek there is really no rush for this, it will likely take years | 13:41 |
| ogra | ppisati, did you take a look at the pi3 b+ NIC-LED isues described in https://forum.snapcraft.io/t/support-for-raspberry-pi-3-model-b/4509 ? | 13:42 |
| ogra | (i think the patchset i pointed to initially had fixes for that too) | 13:42 |
| jdstrand | mborzecki: I understand the PR and the motivation. Please see my comments in both PR 5897 and PR 6099. 5897 can land if we force the use of the cgroup, like we did with joystick (see comment) | 13:44 |
| mup | PR #5897: interfaces/builtin: add device-buttons interface for accessing events <⛔ Blocked> <Created by bergotorino> <https://github.com/snapcore/snapd/pull/5897> | 13:44 |
| mup | PR #6099: cmd/snap-confine: always put the snap process under a device cgroup <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6099> | 13:44 |
| mborzecki | jdstrand: thanks! will do | 13:51 |
| zyga | mborzecki: fixed, I think | 13:51 |
| zyga | just quick local spread run before pushing | 13:52 |
| mborzecki | zyga: what was it? | 13:52 |
| zyga | mborzecki: GOPATH takes priority over what we want to build | 13:52 |
| mup | PR snapd#6094 closed: wrappers: fix generating of service units with multiple `before` dependencies <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6094> | 13:52 |
| zyga | I swapped GOPATH with indigo_gopath | 13:52 |
| zyga | https://www.irccloud.com/pastebin/wYHe3zeU/ | 13:52 |
| zyga | mborzecki: ^ my notes from this session | 13:52 |
| ppisati | ogra: i'm looking into it - the led patches are already there, but one of the function (lan78xx_otp_read()) is buggy, or to better - if i apply the correct fix, then leds are working but the entire chip stops working (we don't get any phy interrupt when packate arrives at the interface) | 13:55 |
| ppisati | *packets | 13:55 |
| ogra | ok ... | 13:56 |
| * ogra comments in the forum thread | 13:56 | |
| ppisati | ogra: IOW, the lan78xx driver in 4.4 relies on the buggy behaviour of that function | 13:56 |
| zyga | mborzecki: in distro builds this doesn't happen because osc uses a chroot and controls GOPATH | 13:57 |
| Chipaca | zyga: pstolowski: using a serial port on classic, does it need hotplug or is it alredy there? | 13:59 |
| zyga | Chipaca: you need hotplug | 13:59 |
| pedronis | mvo: thanks for answering those topics | 14:00 |
| mborzecki | mvo: can you cherry pic https://github.com/snapcore/snapd/pull/6094 to 2.36? | 14:01 |
| jdstrand | mborzecki: ok, and now you have my code review for 6099. thanks again for picking that up | 14:01 |
| mup | PR #6094: wrappers: fix generating of service units with multiple `before` dependencies <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6094> | 14:01 |
| zyga | (new old standup time) | 14:01 |
| mborzecki | jdstrand: thanks, it was fun to look into this :) | 14:01 |
| zyga | Chipaca mvo pstolowski pedronis ^ | 14:01 |
| ogra | mvo, couldnt you just remove the state.json to get back into console-conf (effectively doing a fake "factory reset") ? | 14:03 |
| zyga | mborzecki: can you look at https://github.com/snapcore/snapd/pull/6095 after the call please | 14:09 |
| zyga | I think it should pass now | 14:09 |
| mup | PR #6095: packaging/opensuse: stop using golang-packaging <Created by zyga> <https://github.com/snapcore/snapd/pull/6095> | 14:09 |
| Chipaca | pedronis: another question | 14:10 |
| pedronis | Chipaca: in the standup, but do ask, I will come back later | 14:11 |
| mvo | ogra: yeah, that should work as well, I didn't suggest it in the forum because I wasn't sure if there were any "precious" things on the system, maybe he has some snaps he does not want to lose, but yeah, if not its a solution too | 14:11 |
| Chipaca | pedronis: ok | 14:12 |
| mvo | mborzecki: 6094 is cherry-picked | 14:12 |
| mborzecki | mvo: thanks! | 14:12 |
| Chipaca | pedronis: if somebody wanted to use snaps in a cloudy context where they want the image to boot and have a number of snaps already installed | 14:13 |
| Chipaca | pedronis: they feel they could just install them, snapshot the disk, and then just run with it | 14:13 |
| Chipaca | pedronis: seeding is too slow, installing from zero is too slow | 14:14 |
| mvo | I wonder if we could put things on disk in the prepare image state and just run the hooks at "seeding" time. probably needs careful thinking but my gut feeling is that everyone wants faster seeding | 14:16 |
| Chipaca | ye | 14:18 |
| Chipaca | mborzecki: also also | 14:18 |
| Chipaca | mborzecki: you lied to me: the " Due to the current limitations in the store, multiple instances of a snap need to be installed from the same single command, as shown above." thing is still on https://forum.snapcraft.io/t/parallel-installs/7679 | 14:18 |
| cachio | Chipaca, https://paste.ubuntu.com/p/XjP3hcFr4P/ | 14:19 |
| cachio | I saw this one today | 14:19 |
| Chipaca | cachio: yes | 14:19 |
| Chipaca | cachio: thank you | 14:19 |
| Chipaca | cachio: it's the -2 user id, i need to look into it | 14:19 |
| Chipaca | not today | 14:19 |
| cachio | sure | 14:19 |
| Chipaca | cachio: restart, but thank you for the paste (is it set to expire?) | 14:19 |
| cachio | no | 14:20 |
| cachio | Chipaca, | 14:20 |
| Chipaca | cachio: tks | 14:21 |
| Chipaca | mborzecki: i edited | 14:23 |
| mborzecki | Chipaca: thanks | 14:31 |
| mborzecki | Chipaca: does it work so far for you guys? :) | 14:31 |
| Chipaca | mborzecki: i have not been lynched yet | 14:32 |
| Chipaca | mborzecki: and i get to keep _most_ of my fingers! | 14:32 |
| mborzecki | Chipaca: maybe they're still building the pyre | 14:32 |
| Chipaca | mborzecki: they're still drunk from guy fawkes last night | 14:32 |
| zyga | Pharaoh_Atem: what's the difference between %{!?... and %{?!...} ? | 14:45 |
| Pharaoh_Atem | preference, mainly | 14:46 |
| Pharaoh_Atem | some broken spec parsers handle them differently | 14:46 |
| Pharaoh_Atem | both otherwise they should behave the same | 14:46 |
| zyga | why do we use both? | 14:46 |
| zyga | should we use the same syntax or is there a good reason to keep the difference | 14:46 |
| zyga | I just noticed because of a bug that affected leap | 14:47 |
| Pharaoh_Atem | I just switched everything in the fedora spec to %{!?...} | 14:48 |
| zyga | thanks | 14:48 |
| zyga | I'll do the same | 14:48 |
| Pharaoh_Atem | it makes more sense in my head anyway | 14:49 |
| Pharaoh_Atem | "does not exist" vs "exists, not?" | 14:49 |
| mup | PR snapcraft#2392 opened: ci: update travis.yaml to use xenial <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2392> | 14:49 |
| Chipaca | chesty: https://bugs.libssh.org/T118 | 14:55 |
| pedronis | Chipaca: if they use a prebooted image the serial number would be wrong, we don't have an answer at the moment except you do need to do seeding, but is an open question, we discussed about it a bit with mvo etc in SLC | 14:58 |
| Chipaca | pedronis: yeah, seeding is going to be too slow | 15:00 |
| Chipaca | pedronis: we're talking about a 14 seconds boot being omg slow | 15:00 |
| Chipaca | pedronis: not a blocker but we really need to address this soonish | 15:01 |
| chesty | Chipaca, nice. why struct passwd *pwdbuf = NULL; ? is extra precaution in case of a bug in getpwuid_r ? | 15:07 |
| Chipaca | chesty: i guess so yes | 15:08 |
| jdstrand | roadmr: fyi, finally got all the revisions before r79 of pivx and now I was able to run the automated tools again on 79 | 15:22 |
| roadmr | \o/ | 15:22 |
| roadmr | thanks for checking. | 15:22 |
| Chipaca | hmmmmmmmmmmmmₘₘₘₘₘₘₘₘₘₘ | 15:24 |
| mvo | Chipaca: well, I think we should thing about putting things on disk in prepare image and just running the hooks but its a bigger change and needs careful investigation | 15:25 |
| Chipaca | mvo: ₘₘₘₘₘₘ | 15:25 |
| Chipaca | mvo: :-) | 15:25 |
| Chipaca | mvo: why run the hooks? | 15:26 |
| mvo | Chipaca: running the hooks in prepare image is going to be a challenge - we may create an arm image with a amd64 host | 15:27 |
| Chipaca | mvo: we could also not support doing the whole fast boot set up on an m×n arch grid | 15:33 |
| Chipaca | anyway i figured out where the snapshot -2 uid error comes from, probably™ | 15:34 |
| pedronis | Chipaca: we can add some constraints, but we cannot be fully arbitrary or hackish either | 15:34 |
| pedronis | it needs some toughts | 15:34 |
| Chipaca | pedronis: yes | 15:34 |
| === JanC_ is now known as JanC | ||
| ogra | zyga, are layouts on by default in 2.36 ? | 15:42 |
| zyga | yes | 15:44 |
| ogra | so i can drop the passthrough in my snapcraft.yaml ? | 15:45 |
| roadmr | ogra: try dropping it; if snapcraft complains, then you'll still need it :) | 15:45 |
| pedronis | the passthrough is about snapcraft, not snapd | 15:45 |
| roadmr | ^^ this | 15:45 |
| ogra | hahaha | 15:45 |
| zyga | ogra: that's a question for kyrofa and sergiusens | 15:46 |
| zyga | roadmr: processing... | 15:46 |
| roadmr | zyga: yay! | 15:46 |
| zyga | it worked! | 15:46 |
| roadmr | of course ;) thanks to the work jdstrand did yesterday | 15:46 |
| zyga | and released! | 15:48 |
| zyga | (to beta) | 15:48 |
| kyrofa | zyga, ogra layouts are supported in 3.0 as long as you specify a base | 15:52 |
| zyga | woot | 15:52 |
| kyrofa | Otherwise passthrough is still required | 15:52 |
| ogra | urgh | 15:52 |
| roadmr | zyga: yay \o/ | 15:52 |
| ogra | kyrofa, how does that work for all my exiting snaps ... is a default base picked when i do a rebuild ? | 15:52 |
| ogra | *existing (even though some are exciting :P ) | 15:53 |
| zyga | ogra: you need to pick base: core | 15:54 |
| zyga | ogra: or core18 | 15:54 |
| ogra | zyga, so i need to update all exiting snapcraft.yamls ?!?! | 15:55 |
| zyga | yes | 15:55 |
| zyga | that's intentional | 15:55 |
| ogra | sigh ... | 15:55 |
| zyga | to opt into the new build semantics | 15:55 |
| kyrofa | zyga, no, "core" is not a valid base, "core16" is. But that isn't really a thing yet | 15:55 |
| ogra | you mean build.s.io will fall back to snapcraft 2.x if i dont ? | 15:55 |
| kyrofa | Bingo | 15:56 |
| ogra | phew | 15:56 |
| ogra | k | 15:56 |
| zyga | kyrofa: why core is not a valid base? | 15:56 |
| kyrofa | ogra, we really didn't want to break folks | 15:56 |
| zyga | (core is a valid base in snapd) | 15:56 |
| kyrofa | zyga, isn't core going to only contain snapd? | 15:56 |
| zyga | no | 15:56 |
| kyrofa | Eh? | 15:57 |
| zyga | kyrofa: you are talking about the snapd snap | 15:57 |
| ogra | kyrofa, yeah, i would have been surprised if you did ... i trust you and sergio blindly normally ;) | 15:57 |
| zyga | kyrofa: core will contain snapd and core16 | 15:57 |
| zyga | (and does so today) | 15:57 |
| zyga | kyrofa: core16 is just core sans snapd | 15:57 |
| kyrofa | zyga, core isn't being renamed to core16, then? | 15:57 |
| zyga | kyrofa: no | 15:57 |
| zyga | kyrofa: core16, core and core18 are separate snaps | 15:57 |
| ogra | they dropped that renaming idea | 15:57 |
| zyga | kyrofa: core16 and core18 don't have snapd anymore | 15:57 |
| kyrofa | Yikes. All three will need to be maintained? | 15:57 |
| zyga | kyrofa: snapd snap is a separate required snap in that case | 15:57 |
| zyga | kyrofa: for now yes | 15:57 |
| zyga | kyrofa: we will transition people from core to core16 | 15:58 |
| zyga | (that is core to core16 + snapd) | 15:58 |
| kyrofa | Okay, I wasn't clued into the dropping of the rename. Still though, I think "core" shouldn't be used as a base | 15:58 |
| zyga | pedronis: ^ in case I'm mistaken | 15:58 |
| kyrofa | We should steer people toward core16 | 15:58 |
| zyga | pedronis: core, core16 and core18 will be maintained until we complete the transition | 15:58 |
| zyga | kyrofa: sync with pedronis and mvo on timing please | 15:59 |
| zyga | kyrofa: core16 can be used as a base AFAIK (correctly) | 15:59 |
| zyga | kyrofa: as can core18 | 15:59 |
| kyrofa | Which means the only supported bases for now (at least in snapcraft, given that it's a new feature) should be core16 and core18 | 15:59 |
| kyrofa | zyga, it's not stable yet though, no? | 15:59 |
| zyga | the transition is moving people away from core as the holder of snapd | 15:59 |
| kyrofa | (core16, I mean) | 15:59 |
| zyga | kyrofa: I think it is equally stable | 15:59 |
| zyga | kyrofa: we just don't have the migration code in place | 15:59 |
| zyga | but operationally it is just like core | 16:00 |
| kyrofa | zyga, I mean it literally isn't in the stable channel | 16:00 |
| kyrofa | It's edge only | 16:00 |
| pedronis | kyrofa: I don't think core can be used as a base explicitly | 16:00 |
| zyga | kyrofa: note that core16 and core18 are AFAIK maintained by foundations | 16:00 |
| zyga | kyrofa: I see | 16:00 |
| kyrofa | pedronis, agreed | 16:00 |
| kyrofa | As it should be | 16:00 |
| kyrofa | Any ETA for when core16 will be stable? | 16:01 |
| zyga | kyrofa: I honestly don't know | 16:03 |
| zyga | it probably should be now | 16:03 |
| zyga | but it depends on the transition process | 16:03 |
| zyga | (perhaps) | 16:03 |
| ogra | so if i want to use layouts in my snaps that are built specifically for Ubuntu Core 16, what would i do (and note in no casse ever i want core18 to end up on a core16 install) | 16:03 |
| pedronis | ogra: the decision to connect layouts to 3.0 and base is a bit strange, not sure what was the rationale there | 16:06 |
| ogra | yeah | 16:07 |
| ogra | we'll definitely want to use it for existing customer ... and many of them will never go to 18 ... (and wont want an additional core18 base nasp installed either) | 16:08 |
| ogra | *cusstomerss | 16:08 |
| ogra | (GRRR ... broken kbd) | 16:08 |
| sparkiegeek | sergiusens: https://paste.ubuntu.com/p/ZFKJXbVMSj/ | 16:13 |
| sparkiegeek | sergiusens: 95% sure that's not related to my change | 16:14 |
| sergiusens | pedronis: we did not have anyone request it, it can be done | 16:14 |
| sergiusens | pedronis: that said, folks can still use passthrough and should be fine for the time being | 16:15 |
| pedronis | sergiusens: I understand but given it might take a bit fore core16 to go stable, first class support might make sense | 16:22 |
| * cachio lunch | 16:23 | |
| zyga | ogra: for ubuntu core 16 - can you use core18 base? | 16:23 |
| ogra | zyga, i personally might ... 90% of our customers wont want to yet | 16:24 |
| mup | PR snapd#6102 opened: overlord/snapshots: survive an unknown user <Created by chipaca> <https://github.com/snapcore/snapd/pull/6102> | 16:24 |
| zyga | ogra: note that it doesn't imply booting core18 | 16:24 |
| Chipaca | ^ that should fix the weird amazon issue | 16:24 |
| zyga | ogra: but sure, I'm just curious | 16:24 |
| Chipaca | I still don't know _why_ amazon would trigger it, nor why with -2, but, there ya go | 16:24 |
| zyga | Chipaca: do you know why the uid is unknown? | 16:24 |
| ogra | zyga, it talke disk space on a already size limited device | 16:25 |
| Chipaca | zyga: so there's a /home/foo/snap directory owned by uid -2 | 16:25 |
| Chipaca | zyga: that bit, i have no idea why | 16:25 |
| zyga | aha... | 16:25 |
| zyga | hmm | 16:25 |
| Chipaca | zyga: espeially because the uid comes from stat | 16:25 |
| zyga | that's indeed curious | 16:25 |
| Chipaca | zyga: so it's not the syscall.Getuid bug | 16:25 |
| zyga | I mean, if you stat it in a shell you see -2? | 16:25 |
| zyga | ! | 16:25 |
| Chipaca | zyga: I haven't been able to reproduce it wiht -debug, but if I could, I'd see the big uid | 16:26 |
| bashfulrobot | niemeyer: | 16:31 |
| Chipaca | bashfulrobot: ssh | 16:31 |
| Chipaca | :-) | 16:31 |
| ogra | Chipaca, he should ssh into gustavo ?! | 16:32 |
| ogra | is there a pub-key available for that ? | 16:32 |
| Chipaca | bashfulrobot: g.ustavo is presenting and has irc on | 16:32 |
| Chipaca | bashfulrobot: what could go wrong | 16:32 |
| bashfulrobot | Chipaca: sorry accidental. Apologies. | 16:33 |
| * zyga dinner | 16:33 | |
| mup | PR snapcraft#2393 opened: lifecycle: make snapcraft init template use > not | <Created by sparkiegeek> <https://github.com/snapcore/snapcraft/pull/2393> | 16:58 |
| mup | PR snapcraft#2388 closed: project: early snapcraft.yaml validation <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2388> | 17:31 |
| mup | PR snapcraft#2391 closed: runtests: run black with --diff <Created by abitrolly> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2391> | 17:31 |
| zyga | re | 17:32 |
| pedronis | mvo: https://github.com/snapcore/snapd/pull/6093 , is this really for 2.36 ? | 18:19 |
| mup | PR #6093: daemon: spool sideloaded snap into blob dir <Created by chipaca> <https://github.com/snapcore/snapd/pull/6093> | 18:19 |
| mvo | pedronis: yeah, we got a message from field (CE) that it affected a customer | 18:20 |
| pedronis | ah, ok | 18:20 |
| mvo | pedronis: if you feel uneasy about this please let me know | 18:20 |
| mvo | pedronis: it seems relatively harmless (famous last words) | 18:21 |
| pedronis | mvo: I haven't actually looked at it yet, just wondered to see something still under 2.36 | 18:21 |
| mvo | pedronis: ok | 18:22 |
| pedronis | mvo: I can look at it in the morning | 18:55 |
| mvo | pedronis: as you wish - I will leave it until then | 18:56 |
| zyga | urgh | 19:07 |
| zyga | rpm -q --whatprovides /usr/share/pkgconfig/systemd.pc | 19:07 |
| === kali_ is now known as kaliy | ||
| zyga | and now all three suse releases have working snapd | 19:36 |
| zyga | cachio: hey, do we have opensuse leap 15? | 19:49 |
| zyga | cachio: and opensuse tumbleweed | 19:49 |
| zyga | leap 42.3 is a bit dated now | 19:50 |
| sunesito | hi all | 20:01 |
| sunesito | i have installed snapd on ubuntu and when i try to run an app i have that error:Gtk-Message: Failed to load module "gail" Gtk-Message: Failed to load module "atk-bridge" Gtk-Message: Failed to load module "unity-gtk-module" (acestreamplayer:5130): GLib-GIO-ERROR **: No GSettings schemas are installed on the system | 20:02 |
| sunesito | what am i missing? | 20:02 |
| zyga | sunesito: hey | 20:11 |
| zyga | I assume the app doesn't start at all | 20:11 |
| zyga | what is the name of that app? | 20:11 |
| sunesito | no | 20:11 |
| sunesito | acestreamplayer | 20:12 |
| ogra | you should be using a desktop launcher part for snapcraft | 20:14 |
| zyga | ogra: I'm not sure if sunesito is the developer of that app | 20:14 |
| ogra | oh | 20:14 |
| ogra | yeah, ignore me then (giving developer tips :) ) | 20:14 |
| sunesito | ¿? ill try it | 20:15 |
| ogra | well, are you the developer of that snap ? | 20:15 |
| ogra | (i was refrerring to code changes in the snap package) | 20:16 |
| sunesito | ahhh...no...im not the developer...only a user | 20:16 |
| ogra | https://snapcraft.io/acestreamplayer ... | 20:17 |
| ogra | Last updatedFeb 21 2017 | 20:17 |
| ogra | hmm | 20:17 |
| sunesito | sorry...is this a developers chanel? | 20:17 |
| ogra | hasnt been touched in nearly two years | 20:17 |
| ogra | sunesito, no, not at all | 20:17 |
| ogra | (well ... too ... but as well for user questions/support) | 20:17 |
| sunesito | thanks...i will investigate under ubuntu problem...because i have running it on debian os | 20:18 |
| ogra | the snap ? | 20:19 |
| sunesito | no....the error | 20:20 |
| ogra | do you have the snap running on debian ? | 20:20 |
| sunesito | @ogra sorry....yes, the snap with acestreamplayer | 20:20 |
| ogra | aha | 20:20 |
| ogra | thats an interesting datapoint | 20:20 |
| ogra | whats the output of: snap version | 20:21 |
| ogra | on your ubuntu | 20:21 |
| sunesito | 2.35.5 | 20:21 |
| ogra | the full output please | 20:21 |
| sunesito | ok | 20:21 |
| sunesito | ubuntu_1604:~$ snap version snap 2.35.5 snapd 2.35.5 series 16 ubuntu 16.04 kernel 4.2.8 | 20:21 |
| ogra | where does that kernel come from ? | 20:22 |
| ogra | thats not an ubuntu kernel | 20:22 |
| ogra | (and likely the reason for your issue) | 20:22 |
| ogra | zyga, wasnt there a fix in snapd that warns you if you use an unsupported kernel ? or is that not in stable yet ?? (see above) | 20:23 |
| sunesito | this is an qnap | 20:23 |
| sunesito | NAS | 20:23 |
| zyga | ogra: not exactly, there's only one specific version we warn about | 20:23 |
| ogra | ah | 20:23 |
| zyga | on 14.04 that is still on 3.14 | 20:23 |
| sunesito | but i have running snap correctly in this system | 20:23 |
| zyga | sunesito: interesting, did you install snapd yourself or did it come with it? | 20:23 |
| zyga | and wait, didn't you say this is a desktop app? | 20:24 |
| sunesito | i install via apt-get | 20:24 |
| zyga | is this a NAS with a screen? | 20:24 |
| sunesito | yes... | 20:24 |
| sunesito | hdmi port | 20:24 |
| zyga | :D | 20:24 |
| zyga | nice, so a nas / desktop :) | 20:24 |
| sunesito | yes | 20:24 |
| sunesito | i need to reinstall the ubuntu....and now i have this problem...but i think the problem is in the ubuntu packages | 20:25 |
| mup | PR snapd#6103 opened: tests: split nested vm suite on core and classic and new snapshots test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6103> | 21:15 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!