| mborzecki | morning | 05:19 |
|---|---|---|
| zyga | good morning | 05:55 |
| zyga | mborzecki: last week of school | 05:55 |
| zyga | any "holiday" plans? | 05:55 |
| mborzecki | yeah, i'm taking 2 weeks off in the beginning on july | 05:56 |
| zyga | and your kids/ | 05:56 |
| mborzecki | we're going away for a while together | 05:56 |
| zyga | nice | 05:56 |
| zyga | good morning mvo | 05:58 |
| mvo | hey zyga | 05:58 |
| mvo | zyga: good morning | 05:58 |
| mborzecki | damn, my emacs setup fell apart :( | 05:58 |
| mborzecki | mvo: hey | 05:58 |
| mvo | mborzecki: good morning to you as wlel | 05:58 |
| zyga | mvo: when does school finish for your family? | 05:58 |
| mvo | well | 05:58 |
| zyga | mborzecki: what happened with your emacs? | 05:58 |
| mborzecki | zyga: updated spacemacs and not it complains that there's no gocode, godef et al, probaly PATH messed up, or something special about zsh env files zshenv/zshrc | 05:59 |
| mvo | zyga: this is the last week - but its different for the different regions in germany, some finish later | 05:59 |
| mborzecki | yay, turns out i had to fix the spacemacs init file only :) | 06:04 |
| mup | PR snapd#5330 closed: snapstate: support restarting snapd from the snapd snap on core18 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5330> | 06:06 |
| mvo | getting a second review for 5324 would be great! it has one review already | 06:07 |
| zyga | mvo: looking now | 06:13 |
| zyga | mvo: we should discuss what to do today, should I finish the work on system or is that premature and it needs more review and discussion | 06:14 |
| mvo | zyga: a good question, I would love to see it but maybe worthwhile to wait until the meeting after the standup | 06:15 |
| zyga | mvo: sounds good, I have other things I can finish meanwhile | 06:16 |
| zyga | mvo: if you merge it with your WIP branch and disable tests in ifacestate you can perhaps run spread and see how "far" it can go | 06:16 |
| mvo | zyga: cool idea, with 5324 I think I can almost propose a spread PR, I think there is just one trivial change for core18 left to get very basic spread working | 06:17 |
| mvo | zyga: and yeah, will be fun to run the entire thing :) | 06:17 |
| mvo | zyga: part of the challenge will be to review the tests to see which really need core and which just pull it in for no good reason | 06:18 |
| zyga | currently core is pre-installed before tests run | 06:18 |
| zyga | so most tests just blindly assume core | 06:18 |
| zyga | but yeah, it will be interesting to review tests to see what we ought to get | 06:19 |
| * mvo nods | 06:19 | |
| zyga | I also wonder if we want to have tests/main be tests/main-on-core | 06:19 |
| zyga | that is, shall we specialise some suites for a given core | 06:19 |
| zyga | I don't know honestly | 06:19 |
| mvo | zyga: quick question about 5250 - do you think it needs an extra review? it has two +1 now, so we can (squash)merge it I think. I'm a little bit nervous about it but it looks very good and solves a real problem | 06:33 |
| zyga | hmm mhmm it's a tricky one | 06:34 |
| zyga | maybe ask someone from foundation that knows udev for a last look | 06:34 |
| mvo | zyga: yeah, I have the same feeling, tricky | 06:34 |
| mvo | zyga: good idea! | 06:34 |
| zyga | mvo: or, just ask lennart | 06:35 |
| mvo | xnox: if we needed to ask a udev expert in foundations for a review, what would be your recommendation? we would love to get a high level review of #5250 | 06:35 |
| mup | PR #5250: interfaces/udev,misc: only trigger udev events on input subsystem as needed <Reviewed> <Squash-merge> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5250> | 06:36 |
| mvo | zyga: *cough* you are joking, right? | 06:36 |
| zyga | no, really | 06:36 |
| zyga | just ask a direct question, "is this and this sequence of udev calls" a safe thing to do | 06:36 |
| zyga | mvo: reviewed | 06:59 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | mornings | 07:03 |
| mvo | zyga: yay, thank you | 07:05 |
| mvo | pstolowski: good morning | 07:05 |
| mborzecki | pstolowski: hey | 07:06 |
| mvo | zyga: I like your idea, very nice, will do that now | 07:08 |
| mvo | zyga: hm, with the change the glob becomes a bit useless, right? snap-confine.core.111* basicly? but no issue as we just write a single file anyway | 07:12 |
| mvo | zyga: right? | 07:12 |
| zyga | hmm, let me look | 07:12 |
| zyga | yeah, the glob would just match that one fine | 07:14 |
| zyga | *file | 07:14 |
| mvo | zyga: the change makes the test much nicer to read | 07:14 |
| mvo | zyga: good stuff | 07:14 |
| mvo | zyga: i.e. all this crazy "strings.Replace("/", ".") etc is gone | 07:14 |
| zyga | yeah | 07:14 |
| zyga | it's more obvious what is going on | 07:15 |
| mvo | zyga: hm, but the glob needs to be something else or than snap-confine.core.111* because .111* also matches .1111 which we don't want | 07:17 |
| zyga | the glob doesn't need to use * | 07:17 |
| mvo | zyga: aha, nice | 07:17 |
| zyga | it can be literally the name of the file you want to create | 07:17 |
| zyga | the glob is there in case we want to "own" a namespace | 07:17 |
| zyga | since (AFAIK, correct me if I'm wrong) we also have a bit of code that cleans those up when a snap is removed | 07:17 |
| zyga | ... or do we? | 07:17 |
| mvo | zyga: yeah, we clean those up | 07:18 |
| mvo | zyga: and we have tests for that | 07:18 |
| mborzecki | https://paste.ubuntu.com/p/j3g5RqxFPZ/ iirc Chipaca saw something similar | 07:28 |
| zyga | error: e-book-client-error-quark[2] Conflicting UIDs found in added contacts, hmmm | 07:29 |
| zyga | address book persists between runs? | 07:29 |
| zyga | mvo: are you sure we can use * for revision? | 07:31 |
| zyga | this means that a setup for snapd 123 will remove profiles for snapd.122 | 07:31 |
| zyga | as the system will find a file matching the glob that is not described by the content map | 07:32 |
| mvo | zyga: yes, that is was we are currently doing | 07:32 |
| mvo | zyga: its not a regression but its not great either | 07:33 |
| zyga | mmm, I see | 07:33 |
| zyga | let's do it and see | 07:33 |
| mvo | zyga: its not ideal, we need to think how to improve it | 07:33 |
| mvo | zyga: I was also thinking it might be racy because we update the current symlink and then when snap run runs it will not yet have profiles for snap-confine | 07:34 |
| mvo | zyga: but fortunately the system-key fixes this, i..e we have code in snap run that waits for profile re-generation on system key mismatch | 07:34 |
| zyga | I agree, ultimately I think the profile ought to be removed only when the snap is removed | 07:35 |
| zyga | since for various reasons it can persist longer, even while the snap is inactive | 07:35 |
| mvo | zyga: +1 | 07:36 |
| mvo | zyga: I will do a followup with this | 07:36 |
| * zyga breakfast | 07:47 | |
| Chipaca | moin moin | 08:01 |
| zyga | good day to you sir, on this lovely morning | 08:01 |
| Chipaca | finally got a test run that failed with econnreset with the new extra debug yesterday | 08:01 |
| Chipaca | if anybody's interested | 08:01 |
| Chipaca | :) | 08:02 |
| Chipaca | also didn't get more than a couple of hours of sleep last night, so i'm not seeing straight right now | 08:02 |
| mvo | Chipaca: I am interessted | 08:03 |
| Chipaca | mvo: I'll send you my paypal address | 08:03 |
| Chipaca | mvo: https://api.travis-ci.org/v3/job/393403309/log.txt | 08:04 |
| Chipaca | i also have a local copy of that if it goes away | 08:04 |
| mvo | Chipaca: the latest theory of cachio is that this happens when there is a "snap userd" leftover from previous tests | 08:05 |
| mvo | Chipaca: then "kill $(pidof snap)" fails | 08:06 |
| zyga | maybe killall instead of kill? | 08:06 |
| Chipaca | I mean, that might be one source of failures | 08:06 |
| Chipaca | but it's not this one | 08:06 |
| Chipaca | this one is definitely the 'no match' error | 08:06 |
| zyga | what I would really like is my measure patches to spread | 08:06 |
| zyga | so that we could put up walls around each test to ensure it doesn't leak | 08:06 |
| mvo | Chipaca: aha, looking | 08:07 |
| mborzecki | hm #5353 looking good so far, 5 runs, all but one green, that one was unrelated though (eds thing i pasted above) | 08:10 |
| mborzecki | #5335 | 08:10 |
| mup | PR #5335: tests: fix for the download of the big snap <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5335> | 08:11 |
| mvo | Chipaca: hm, this log does not (yet) contain the output of "ls -lh test-snapd-huge_*", right? or am I just missing it? | 08:14 |
| Chipaca | mvo: it does not contain output of that sort, no | 08:15 |
| Chipaca | mvo: where was that added? | 08:15 |
| mvo | Chipaca: thats slightly sad, it would be nice to know if the download simply finished, this is not logged yet, is it? | 08:15 |
| Chipaca | mvo: it does contain logs that say what it did though | 08:16 |
| Chipaca | mvo: yes it does say when it's finished | 08:16 |
| Chipaca | let me get that | 08:16 |
| mvo | Chipaca: is where the partial file output got added | 08:17 |
| mvo | Chipaca: https://github.com/snapcore/snapd/pull/5333 | 08:17 |
| mup | PR #5333: tests: show status of the partial test-snapd-huge snap in econnreset test <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5333> | 08:17 |
| Chipaca | mvo: that's on master, and i merged that master into thsi pr | 08:17 |
| Chipaca | mvo: so maybe i was wrong and it does include the ls | 08:17 |
| Chipaca | didn't see it tho | 08:17 |
| mvo | Chipaca: I don't see it | 08:17 |
| mvo | Chipaca: it would be good to know if the download finished successfully, I think this is what happend | 08:18 |
| mvo | Chipaca: oh nooooo | 08:20 |
| mvo | Chipaca: we have two debug: | in the test now | 08:20 |
| Chipaca | mvo: given it doesn't start downloading the assertion until the download is finished, I'd say you are correct | 08:20 |
| mvo | Chipaca: must be a double merge, this is why the debug output is missing | 08:20 |
| mvo | Chipaca: let me push a PR | 08:21 |
| Chipaca | mvo: I might add to that PR :) but yes | 08:22 |
| Chipaca | mvo: in any case: assertion download doesn't start unless snap download succeeded | 08:22 |
| Chipaca | so, fastly is _too_ good :) | 08:23 |
| * Chipaca wants to make it clear that this is not a complaint | 08:23 | |
| mvo | Chipaca: haha | 08:23 |
| Chipaca | it's downloading 500MB in less than .1 seconds | 08:23 |
| mvo | Chipaca: maybe - or iptables is really slow appying the filter | 08:23 |
| mvo | Chipaca: I push something that adds more timestamps | 08:23 |
| zyga | Chipaca: we could make another episode of "speed" with this | 08:24 |
| Chipaca | mvo: I think it's time to add a slow writer debug thing | 08:24 |
| Chipaca | e.g. have a SNAPD_DEBUG_HTTP value of 8 mean 'be slow' | 08:24 |
| Chipaca | hmmm | 08:24 |
| mup | PR snapd#5336 opened: tests: remove double debug: | entry in tests and add more checks <Created by mvo5> <https://github.com/snapcore/snapd/pull/5336> | 08:25 |
| mvo | Chipaca: lets see if the times add up. I saw 50mb/sec download speed in tests so far but that means (even if it becomes more speedy) that the download will take ~10sec, even if its actually only 5sec but still a bit strange. so I would love to see logs | 08:26 |
| mvo | Chipaca: maybe we can even add a log in httpclient "fetched %q with size %v in %v seconds" or something? | 08:27 |
| mvo | Chipaca: anyway, a fun test issue to track down :) | 08:27 |
| Chipaca | ❝fun❞ | 08:28 |
| zyga | mvo: I asked this last week but I think I missed the response if any | 08:28 |
| zyga | what is inside that 1GB snap? | 08:28 |
| zyga | is it 1GB of random data? | 08:28 |
| mvo | zyga: I think so | 08:29 |
| mvo | zyga: I don't remember, let me check | 08:29 |
| zyga | what's the name? | 08:29 |
| mvo | zyga: I think /dev/urandom because otherwise it compresses too well | 08:29 |
| mvo | zyga: test-snapd-huge | 08:29 |
| zyga | thanks | 08:30 |
| zyga | fetching now | 08:30 |
| mborzecki | hm 536MB | 08:30 |
| zyga | I"m getting ~8MB/s | 08:30 |
| mborzecki | is it an electron app? :) | 08:30 |
| zyga | mborzecki: just the splash screen featuring 4K video | 08:31 |
| mborzecki | zyga: haha wish that technology exited in the 90s :P | 08:31 |
| zyga | offtopic, I recall my Samsung times when the Samsung website, when viewed in Korea, would display a 1080P full screen feed as the _background_ | 08:32 |
| zyga | the huge snap is actually 0.5GB as mborzecki noted | 08:32 |
| mborzecki | hmm my tiny user service for tmux was supposed to remain on logout, i guess it didn't :/ | 08:34 |
| mvo | zyga: so 0.5gb is not huge enough ;) | 08:38 |
| mup | PR snapd#5324 closed: snap: run snap-confine from the re-exec location <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5324> | 08:40 |
| Chipaca | mvo: should I go ahead with the limiting writer? | 08:41 |
| mup | PR core18#27 closed: run-snapd-from-snap: start snapd after seeding <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/27> | 08:41 |
| Chipaca | that is, having httputil's logger client slow things down for us | 08:42 |
| mvo | Chipaca: I would say lets wait a tiny bit to see what logs with timestamps show, i.e. I'm keen to learn what is going on, if e.g. ipstables takes 10s to run. or if it runs and then just does nothing for whatever reason to the running tcp stream | 08:44 |
| Chipaca | mvo: | 08:45 |
| Chipaca | 2018/06/18 08:44:37.358695 logger.go:82: DEBUG: < "HTTP/1.1 200 OK\r\nContent-Length: 536875008\r\nAccept-Ranges: bytes\r\nAccept-Ranges: bytes\r\nAge: 43918\r\nCache-Control: max-age=86400\r\nConnection: keep-alive\r\nContent-Disposition: attachment; filename=YVl7fwoQCPqOE2PGt5wxZnhu1lSJhvki_1.snap\r\nContent-Type: application/octet-stream\r\nDate: Mon, 18 Jun 2018 08:44:37 GMT\r\nEtag: cee7a99d-0a0d-4981-b2d6-563c667c332c\r\nLast-Modified: Sun, 17 | 08:45 |
| Chipaca | Jun 2018 20:32:12 GMT\r\nServer: TwistedWeb/14.0.2\r\nStrict-Transport-Security: max-age=2592000\r\nVary: Accept-Encoding\r\nVia: 1.1 varnish\r\nVia: 1.1 varnish\r\nX-Bzr-Revision-Number: 7463\r\nX-Cache: MISS, HIT\r\nX-Cache-Hits: 0, 0\r\nX-Request-Id: WybFTH8AAQEAAC3@nDwAAAB61\r\nX-Served-By: cache-lcy19224-LCY, cache-iad2645-IAD\r\nX-Timer: S1529311477.354131,VS0,VE1\r\n\r\n" [ 58ms; 9.26GB/s] | 08:45 |
| Chipaca | ^^^ 9 YIGAWATTS | 08:45 |
| mvo | Chipaca: wuuuut? | 08:45 |
| mvo | Chipaca: thats crazy | 08:45 |
| Chipaca | mvo: so, er, that's faster than we'll see if we blink | 08:45 |
| Chipaca | also, hot damn, i'm moving to wherever this is :) | 08:45 |
| mvo | Chipaca: sounds like we need a limiting writer :) | 08:46 |
| Chipaca | (it's probably in the USA so heck no) | 08:46 |
| mvo | Chipaca: well, I'm sure this is fastly inside GCE | 08:46 |
| mvo | Chipaca: but even then, *amazing* | 08:46 |
| Chipaca | mvo: here's hoping it's not fastly from somebody's garage | 08:46 |
| mvo | Chipaca: I will rent that garage | 08:46 |
| mvo | Chipaca: I'm sure they make apples there | 08:46 |
| mvo | Chipaca: anyway, nice find! that is amazing | 08:47 |
| Chipaca | I'll push a PR that adds those two bits of info, as it's useful to have | 08:47 |
| Chipaca | hm, maybe together with the limiting writer | 08:47 |
| mvo | Chipaca: aha, I was wondering where it comes from | 08:47 |
| mvo | Chipaca: did you try this in a gce machine? | 08:47 |
| Chipaca | mvo: yes, this is in gce | 08:47 |
| Chipaca | this is not my home network | 08:48 |
| Chipaca | i don't even get that speed from the switch | 08:48 |
| mvo | Chipaca: so "snap download test-snapd-huge" in a fresh machine? | 08:48 |
| Chipaca | mvo: yes | 08:48 |
| mvo | Chipaca: amazing | 08:48 |
| mvo | Chipaca: thanks, I think we have the answer then to the conundrum | 08:48 |
| Chipaca | mvo: it's s till up if you want me to try anything further | 08:48 |
| * mvo hugs Chipaca and hands him the hero-of-the-day medal | 08:49 | |
| zyga | Chipaca: any chance our CDN is in google? | 08:49 |
| zyga | so two box spawn on the same rack because google updated the Borg with some AI | 08:49 |
| mvo | Chipaca: you could download some other big snaps just for fun | 08:49 |
| zyga | and then then RDMA some memory across | 08:49 |
| mvo | Chipaca: firefox, some electron apps | 08:49 |
| Chipaca | zyga: fastly.cdn.snapcraft.io is at least 3 hops away, on a different ip range | 08:50 |
| zyga | wow | 08:50 |
| zyga | then wow :) | 08:50 |
| Chipaca | zyga: still 18ms end to end | 08:50 |
| Chipaca | mtr thinks it's 5 hops | 08:50 |
| Chipaca | (18 ms ping, that is) | 08:51 |
| Chipaca | mmmmmm, maybe i was too hasty | 08:57 |
| Chipaca | mvo: ^ | 08:57 |
| Chipaca | i'm printing the response before reading the body :-( | 08:57 |
| * Chipaca needs a brown paper bag, now | 08:57 | |
| zyga | Chipaca: so google doesn't have transwarp internet links? | 08:57 |
| Chipaca | zyga: disappointed | 08:58 |
| Chipaca | drat | 08:59 |
| mvo | Chipaca: heh :) | 08:59 |
| Chipaca | shoudl've used my head | 08:59 |
| mvo | Chipaca: I think you mentioned earlier you didn't sleep enough, I would hand you a cup of tea now in a real office :) | 08:59 |
| Chipaca | 'time' says snap download takes ~15s | 09:00 |
| mvo | Chipaca: hm, that *should* be plenty of time | 09:00 |
| mvo | Chipaca: same if you run it again? | 09:00 |
| mvo | Chipaca: I mean after "rm *.snap" | 09:00 |
| Chipaca | mvo: if I run it again, _without_ removing the snap, it takes 7s | 09:00 |
| mvo | Chipaca: hm, hm, even that should be enough | 09:01 |
| * mvo scratches his head | 09:01 | |
| zyga | tcpdump | 09:01 |
| zyga | and see what happens | 09:01 |
| Chipaca | it takes ~3s to heck the hash | 09:01 |
| zyga | wow | 09:02 |
| zyga | HDD IO slow? | 09:02 |
| zyga | are we checking the hash in-flight? | 09:02 |
| Chipaca | zyga: not for the 'already there' case | 09:02 |
| Chipaca | zyga: when downloading, yes | 09:02 |
| zyga | mhm | 09:02 |
| * zyga zeroes on another layout fix | 09:09 | |
| zyga | brace for a simple but boring review (large diff) | 09:09 |
| zyga | well, *test* diff | 09:09 |
| zyga | actual diff not large :) | 09:09 |
| Chipaca | 2018/06/18 09:15:36.223438 store.go:1546: DEBUG: Download succeeded in 5.264175609s ( 102MB/s). | 09:15 |
| Chipaca | mvo: ^ a little bit more believable | 09:15 |
| mvo | Chipaca: yeah, thank you | 09:17 |
| mvo | Chipaca: still really fast | 09:17 |
| Chipaca | i still want that 9GB/s world tho | 09:17 |
| mvo | heh, indeed | 09:19 |
| zyga | this is an interesting failure | 09:35 |
| zyga | https://travis-ci.org/snapcore/snapd/builds/393533806 | 09:35 |
| zyga | "network availability confirmed" | 09:35 |
| zyga | then bzzzt and silence | 09:36 |
| ogra_ | mvo, zyga, did you guys see the last post on https://forum.snapcraft.io/t/missing-information-in-the-documentation/5969 | 09:38 |
| ogra_ | that looks very weird | 09:38 |
| ogra_ | (given he is root ... ) | 09:39 |
| zyga | I replied | 09:39 |
| ogra_ | thx | 09:39 |
| zyga | but I won't look for a while, need to focus | 09:39 |
| Chipaca | ogra_: looks like they installed lxd, have running vms, and trying to 'apt remove' everything without uninstalling lxd first | 09:39 |
| ogra_ | ah ! | 09:40 |
| Chipaca | on the other hand that's just a guess, because they're not telling us what they did | 09:40 |
| ogra_ | yeah, it would have helped if he has kept the package names in the paste | 09:40 |
| Chipaca | they purposely have edited the output of some stuff, and are hiding or altering info without saying | 09:40 |
| ogra_ | *had | 09:40 |
| Chipaca | so it's not worth my time to debug further | 09:40 |
| * Chipaca might be particularly short of patience today | 09:40 | |
| Chipaca | also, what, the 'apt remove snapd' produced no output at all? | 09:41 |
| Chipaca | it reads like a bad work of fiction | 09:41 |
| Chipaca | :shrug: | 09:42 |
| mup | PR snapd#5337 opened: store: log a nice clear "download succeeded" message <Created by chipaca> <https://github.com/snapcore/snapd/pull/5337> | 09:46 |
| mborzecki | Chipaca: would love to see those YB/s downloads | 09:49 |
| Chipaca | mborzecki: from quantity.go: // zetta and yotta are me being pedantic: maxuint64 is ~18EB | 09:50 |
| mup | PR snapd#5337 closed: store: log a nice clear "download succeeded" message <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5337> | 10:15 |
| cachio | mvo, niemeyer hey, I have a school meeting today, perhaps I'll arrive a bit late to the standup | 10:20 |
| mvo | cachio: ok | 10:21 |
| mup | PR snapd#5338 opened: interfaces: move assertions around for better failure line number <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5338> | 10:30 |
| zyga | pstolowski: ^ quick ack please | 10:32 |
| pstolowski | +1 | 10:33 |
| zyga | thnx | 10:33 |
| zyga | opensuse failed twice on zypper network operation | 10:40 |
| zyga | mborzecki: small conflicts in https://github.com/snapcore/snapd/pull/5314 | 10:43 |
| mup | PR #5314: many: rename snap.Info.Name() to snap.Info.InstanceName(), leave parallel-install TODOs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5314> | 10:43 |
| mup | PR snapd#5339 opened: tests: initial core18 spread image building <Created by mvo5> <https://github.com/snapcore/snapd/pull/5339> | 10:50 |
| zyga | mvo: ^ reviewed | 10:58 |
| zyga | 2nd review for simple https://github.com/snapcore/snapd/pull/5315 | 10:59 |
| mup | PR #5315: cmd/snap-update-ns: introduce mimicRequired helper <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5315> | 10:59 |
| mup | PR snapd#5338 closed: interfaces: move assertions around for better failure line number <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5338> | 11:00 |
| ads20000 | Wimpress: Skype segfaults on startup on my Ubuntu 18.04 Wayland install but there's no clear place to report the bug given in the `contact` field of `snap info skype`? | 11:01 |
| ads20000 | *segfaults GNOME Shell | 11:01 |
| popey | ads20000: does it work under x? | 11:02 |
| ads20000 | (so it plonks me back to the login screen) | 11:02 |
| ads20000 | I'll give it a go :) | 11:02 |
| Chipaca | I'm going to be a git and say if an app crashes your wayland (or x11), it's a wayland (or x11) bug | 11:02 |
| ads20000 | popey: seems to be OK on X, was crashed back to GDM once but I wonder if it's the Polari Flatpak... journalctl didn't seem too clear on that one | 11:08 |
| popey | ads20000: you can file a bug now you have it running :) | 11:08 |
| cjwatson | ads20000: I had the same symptom with skype on wayland, and no Polari involved | 11:08 |
| popey | Help -> Report a problem. | 11:08 |
| ads20000 | ah nice thanks popey! :) | 11:09 |
| popey | np :) | 11:09 |
| cjwatson | but I agree with Chipaca that this is surely a gnome-shell/wayland/something bug (either exclusively, or in addition) | 11:09 |
| ads20000 | ah right I can't see those messages since I was logged out | 11:10 |
| ads20000 | until they're logged in a couple of hours... | 11:10 |
| zyga | pstolowski: maybe you again, pretty please: https://github.com/snapcore/snapd/pulls/zyga | 11:10 |
| cjwatson | https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1760487 but expired for lack of requested info | 11:10 |
| zyga | the first one there | 11:11 |
| zyga | mimic required, green | 11:11 |
| mup | Bug #1760487: Shell crashes when I start skype under Wayland session <amd64> <apport-bug> <bionic> <wayland-session> <gnome-shell (Ubuntu):Expired> <https://launchpad.net/bugs/1760487> | 11:11 |
| * tomwardill -. lnch | 11:11 | |
| cjwatson | ads20000: maybe you could follow the instructions in the bug above? I do have a crash from a few days ago but am not completely sure that it was from trying to start skype and I don't want to nuke my session right now ... | 11:12 |
| mvo | zyga: woah, that was quick :) | 11:12 |
| ads20000 | here's my log https://paste.ubuntu.com/p/K8KK65ftbk/ submitted via the form in Skype :) | 11:13 |
| cjwatson | reporting to Skype isn't the same as reporting the bug in Xwayland, though | 11:14 |
| cjwatson | you should hopefully have a .crash file in /var/crash/ that you can report as per the bug above | 11:14 |
| cjwatson | (it may not be a skype bug at all ...) | 11:14 |
| ads20000 | cjwatson: on it :) | 11:15 |
| cjwatson | great | 11:15 |
| mup | PR snapd#5340 opened: cifs-mount-control interface (discussed in snapcraft.io forum post 5689) <Created by datenhahn> <https://github.com/snapcore/snapd/pull/5340> | 11:25 |
| ads20000 | cjwatson: please can you mark yourself as affected by https://bugs.launchpad.net/bugs/1777425 ? I've linked back to it in the other bug report :) | 11:27 |
| mup | Bug #1777425: Skype snap segfaults GNOME Shell on Wayland <amd64> <apport-bug> <bionic> <ubuntu> <wayland> <gnome-shell (Ubuntu):New> <wayland (Ubuntu):New> <xorg-server (Ubuntu):New> <https://launchpad.net/bugs/1777425> | 11:27 |
| cjwatson | ads20000: done | 11:28 |
| ads20000 | ty | 11:31 |
| mup | PR snapd#5315 closed: cmd/snap-update-ns: introduce mimicRequired helper <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5315> | 11:31 |
| === Son_Goku is now known as Conan_Kudo | ||
| === Conan_Kudo is now known as Son_Goku | ||
| mborzecki | that skype taking down wayland bug is awfully like the slack thing on fedora | 11:35 |
| pstolowski | pedronis: hey, added a comment to your gadget PR | 11:35 |
| mup | PR snapd#5336 closed: tests: remove double debug: | entry in tests and add more checks <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5336> | 11:35 |
| pedronis | pstolowski: they are a sort of auto-connection, we can also store the gadget flag in conns, if it will help in the future keeping this under control | 11:49 |
| om26er | Wimpress: Hi! Need review on https://github.com/snapcrafters/android-studio/pull/28 -- its mostly inspired by your similar pull request for sublime. | 11:51 |
| mup | PR snapcrafters/android-studio#28: Embed autodownloads <Created by om26er> <https://github.com/snapcrafters/android-studio/pull/28> | 11:51 |
| mup | PR snapd#5341 opened: cmd/libsnap-confine-private: intoduce helpers for validating snap instance name and instance key <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5341> | 11:51 |
| mborzecki | zyga: ^^ | 11:52 |
| zyga | yeah, looking | 11:52 |
| zyga | queued, I'll do it soon | 11:53 |
| mborzecki | zyga: thanks | 11:55 |
| mborzecki | any PRs in need of a 2nd review? | 11:55 |
| zyga | mborzecki: I don't think so, though I'm working on one more | 12:01 |
| zyga | (at least not mine) | 12:01 |
| mup | PR snapd#5081 closed: interfaces/apparmor: add chopTree <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5081> | 12:01 |
| zyga | I suspect there are some things to review around | 12:01 |
| niemeyer | Mornings | 12:02 |
| niemeyer | mvo, pedronis, zyga: Our core18 meeting in 2h today is atop a weekly cross-team one.. same time tomorrow is empty atm | 12:04 |
| niemeyer | (every week) | 12:04 |
| zyga | ok | 12:04 |
| zyga | I should break for dog/lunch | 12:04 |
| pedronis | pstolowski: I commented in the PR too, let me know what you think | 12:05 |
| pedronis | mborzecki: there are again conflicts with #5314, it's looking good otherwise | 12:08 |
| mup | PR #5314: many: rename snap.Info.Name() to snap.Info.InstanceName(), leave parallel-install TODOs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5314> | 12:08 |
| pstolowski | pedronis: yep, i saw that, thanks; why not single flags then and treat by-gadget appropriately? is it important to know it was coming from gadget at a later time? | 12:09 |
| pedronis | pstolowski: you just said it is, to do the right thing with reconnect, no? | 12:09 |
| mborzecki | pedronis: thanks, pushed again, it should merge cleanly now | 12:10 |
| pedronis | mborzecki: made a small comment now and before answered some of yours, overall +1 | 12:14 |
| pstolowski | pedronis: no, if there was no auto flag in conns on reconnect we would apply regular connect policy (which is what we want for these gadget connections). but if we decide to set auto on these connections then i think we need what you suggest about having 'by-gadget' in conns | 12:14 |
| pstolowski | pedronis: to summarize, i thinkfor gadget connections we need to either 1) set auto+bygadget in conns or 2) not set auto in conns | 12:17 |
| pstolowski | 1 sounds cleaner and more explicit | 12:17 |
| pedronis | yea, given that the want most of the behavior of "auto" and it is a kind of "autoconnection" from the POV of the user | 12:18 |
| pedronis | that seems the best | 12:18 |
| mborzecki | pedronis: thanks! | 12:19 |
| pedronis | mborzecki: it's not a blocker, but we need to discuss the snap-name == app-name case though (it has influences also on aliases checks/rules later) | 12:20 |
| mborzecki | pedronis: yes, it's a bit confusing, i think i'd go with short app name only iff snap-name == instance-name, leaving others with snap-name.app-name | 12:23 |
| mborzecki | pedronis: damn, instance-name == store-name | 12:25 |
| mborzecki | names everywhere | 12:26 |
| pedronis | I read snap-name as store-name | 12:26 |
| zyga | ok, break time, see you at the standup | 12:34 |
| mvo | niemeyer: thank you, I push it tomorrow then | 12:36 |
| pedronis | mvo: there's again an overlap for Gustavo, a new meeting | 12:46 |
| mup | PR snapd#5335 closed: tests: fix for the download of the big snap <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5335> | 12:48 |
| mvo | pedronis: aha, let me check with his calendar | 12:52 |
| mvo | pedronis: I pushed it 30min later and we can shorter it to 30min | 12:53 |
| mvo | pedronis: maybe we can talk about the model assertion question (how to specificy channels in there) during the standup | 12:53 |
| pedronis | mvo: yes, though I don't think we want channels as such, but I understand about tracks | 12:54 |
| Chipaca | brb, getting tea | 12:58 |
| mup | PR snapd#5342 opened: tests: shellchecks part 4 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5342> | 13:35 |
| ads20000 | I have an interview with a temping agency using Skype so hopefully it doesn't crash _crosses fingers_! xD | 13:57 |
| pedronis | mvo: related to the issue we discussed I created this: https://forum.snapcraft.io/t/evolving-prepare-image-syntax/5988 based on an old mail thread | 14:10 |
| mvo | pedronis: thank you | 14:13 |
| mvo | cachio: pardon my ignorance but is there a way to see the console of a machine in GCE? I pushed 5339 which runs a core18 spread test. this works locally when I run the qemu backend but for some reason it seems to not make it past the reboot and I wonder if the console gives any clues | 14:28 |
| cachio | mvo, yes | 14:28 |
| cachio | mvo, go to https://console.cloud.google.com/compute/instances | 14:29 |
| cachio | select the instance you want | 14:29 |
| smoser | hi. when using 'stage-packages' how do you indicate what distro/release will be used ? | 14:29 |
| mvo | cachio: cool, looking | 14:29 |
| cachio | thne you can see -> Serial port 1 (console) | 14:29 |
| Elion321 | Hallo. Installed the snap package "Ktube Media Downloader". it doesn't start. is this the right place for help? | 14:29 |
| smoser | and my second question.. when i try to build snap via https://build.snapcraft.io/user/smoser snapcraft.io says 'the snapcraft.yaml can't be used because it isnt valid.' | 14:31 |
| mvo | cachio: its jun181349-260204 I will try to find it in the dashboard | 14:31 |
| smoser | but local testing is fine. | 14:32 |
| mvo | cachio: hm, hm: " You do not have sufficient permissions to view this page. " | 14:32 |
| cachio | https://console.cloud.google.com/compute/instancesDetail/zones/us-east1-b/instances/jun181349-260204?project=computeengine&authuser=0&organizationId=888541318771&supportedpurview=project | 14:32 |
| smoser | branch is https://github.com/smoser/pdftk/tree/snap/snap | 14:32 |
| ogra_ | smoser, curretly you can only use 16.04 | 14:32 |
| ogra_ | (for stage-packages that is) | 14:33 |
| cachio | mvo, https://paste.ubuntu.com/p/4PmfrHnZ8W/ | 14:33 |
| mvo | cachio: looks like I have no permissions, is that something that gustavo can fix? | 14:33 |
| smoser | ogra_: ok... thanks i thought i had heard somewhere that you could use something else. i wanted to be specific though in my snapcraft. | 14:33 |
| mvo | cachio: thank you, reading the pastebin | 14:33 |
| smoser | er... snap.yaml | 14:33 |
| ogra_ | smoser, yeah, base snap support is in full flow atm | 14:33 |
| cachio | mvo, yes gustavo is the right person | 14:33 |
| smoser | but stage packages isn't really realted to base snap | 14:34 |
| ogra_ | that will allow you to get 18.04 or fedora or whatever as the backing release for the stage-packages | 14:34 |
| smoser | or maybe i'm misunderstanding how that works (quite likely) | 14:34 |
| smoser | i thoguht it essentially just grabbed a bunch of binaries and actted as if you had built all those things and then collected them up. | 14:34 |
| mvo | cachio: hm, this looks good, I wonder if there is an issue with the network, maybe the netplan config does not match for whatever reason, do you happen to have the "ifconfig" output on a gce system? | 14:34 |
| cachio | mvo, no | 14:35 |
| ogra_ | well, stage-packages currently pull in from the archive your build host uses ... but then your snap binary will run on top of the core snap (or later the base snaps) ... so your libc and stuff needs to match | 14:35 |
| smoser | ie, i should be able to pull a bunch of debs from bionic and run it on core snap of xenial. no ? | 14:35 |
| ogra_ | this is where the connection between base and stage-packages lives | 14:35 |
| cachio | mvo, which config do you need? | 14:35 |
| cachio | mvo, perhaps we can get it from other side | 14:36 |
| smoser | ogra_: ok. i can see that. | 14:36 |
| mvo | cachio: the ifconfig output (the output from the comand). I wonder if maybe the machine does not get network | 14:36 |
| mvo | cachio: aha, nevermind, found some info | 14:36 |
| cachio | mvo, you can log in and see it if you want | 14:36 |
| cachio | do you have the credentials for that? | 14:37 |
| smoser | ogra_: do you see an obvious thing i've done wrong in https://github.com/smoser/pdftk/blob/snap/snap/snapcraft.yaml such that snapcraft.io github build stuff would say 'isnt valid' (it gives no other info) | 14:37 |
| * zyga dreams of air conditioning | 14:37 | |
| ogra_ | zyga, so ameriacn of you | 14:37 |
| zyga | ogra_: is that a good thing or a bad thing | 14:37 |
| ogra_ | smoser, whats that first part supposed to do (it looks like a complete no-op) | 14:38 |
| smoser | ogra_: it is. :) | 14:38 |
| ogra_ | also i'm not sure you can have a toplevel "parts:" twice at all | 14:38 |
| smoser | if its not necessary, i can remove it. followed https://larry-price.com/blog/2016/12/07/creating-a-snap-from-existing-deb-packages/ | 14:38 |
| smoser | oh. well yeah... ok that makes sense. i didn't realize i had | 14:39 |
| ogra_ | i guess thats the thing the validator chockes on | 14:39 |
| smoser | and yeah, that is undefined behavior | 14:39 |
| smoser | in yaml | 14:39 |
| ogra_ | right | 14:39 |
| ogra_ | funny that it works locally | 14:39 |
| ogra_ | should be the same validator that runs | 14:39 |
| smoser | hm.. | 14:41 |
| smoser | it worked fine on xenial | 14:41 |
| ogra_ | are you using the snapcraft snap or the deb ? | 14:41 |
| smoser | but it coudl be that arbitrary differences make my local "find" the second 'parts' | 14:41 |
| smoser | and on the build server it does the first | 14:41 |
| ogra_ | (i'd use the snap since thats guaranteed to be the same version everywhere) | 14:41 |
| smoser | the yaml.load() | 14:41 |
| smoser | i installed snapcraft from deb | 14:42 |
| pedronis | mborzecki: could you add a note the parallel install topic about the "postgres_foo" installing the "postgres_foo" app ? | 14:42 |
| ogra_ | the snap is typically more up to date since it doesnt need to go through the whole SRU cycle | 14:42 |
| smoser | yeah.. i didn't even think of that | 14:42 |
| smoser | (using the snap for snapcraft) | 14:42 |
| ogra_ | (and you can quickly switch to the beta or edge channel and back in case you need some upcoming feature in your build) | 14:43 |
| smoser | thanks ogra_ i'm all settled now. | 14:43 |
| ogra_ | :) | 14:43 |
| mvo | cachio: I think I don't have permissions for login at this point, especially since I would have to log into a running core18 that has no netowrk - at least that is my theory. its very strange, core16 and core18 use the same kernel snap and same gadget and yet it looks like core16 loads the virtio kernel module and core18 does not for some reason | 14:47 |
| cachio | mvo, ohhh | 14:48 |
| cachio | mvo, let me check if I can login from the page | 14:49 |
| cachio | mvo, the last thing I see in the console output is "Press enter to configure" | 14:50 |
| mvo | cachio: yeah, maybe its just cloud-init missing | 14:51 |
| cachio | it is like netplan didn't run yes | 14:51 |
| cachio | yet | 14:51 |
| mup | PR core18#28 closed: Fix the UID/GID mapping <Created by sil2100> <Merged by mvo5> <https://github.com/snapcore/core18/pull/28> | 14:52 |
| mup | PR core18#29 opened: hooks: add cloud-init <Created by mvo5> <https://github.com/snapcore/core18/pull/29> | 14:53 |
| mvo | cachio: yeah, it looks like there is no network interface, the kernel output of core18 has no ens4 but classic has that. I will add cloud-init and see if that helps (we need this anyway I think) | 14:54 |
| Elion321 | Hallo. trying it again. Installed the snap package "Ktube Media Downloader". it doesn't start. is this the right place for help? OS: Ubuntu mate 18.04 x64. | 14:57 |
| Elion321 | where to report bugs for a specific snap package? | 14:57 |
| Elion321 | snap is from snapcraft.io | 14:58 |
| cachio | mvo, are we going to unify the snap names to avoid having jq and jq-core18? | 14:58 |
| zyga | cachio: I suggested to use 18 track for that | 14:59 |
| mvo | cachio: yeah, using a track seems to make sense | 14:59 |
| cachio | zyga, good | 14:59 |
| zyga | maybe use the track that matches the base | 14:59 |
| zyga | so core18 rather than core | 15:00 |
| zyga | would help with some f29 work we need to do this cycle | 15:00 |
| smoser | well, i guess i'm not all set... | 15:03 |
| smoser | ogra_: http://paste.ubuntu.com/p/dfZm7xDjwV/ the snapcraft.io build failed to publish, but it looks incorrect to me. | 15:03 |
| mup | PR core18#30 opened: hooks: clenup /etc/{passwd,shadow,group,gshadow}.orig <Created by mvo5> <https://github.com/snapcore/core18/pull/30> | 15:03 |
| smoser | (thanks for your help... sorry to pester you) | 15:03 |
| mvo | smoser: silly question, will cloud-init help with network module (kernel) loading? I am working on core18 right now and it looks like on GCE I don't get a virtio-net based network-interface but core18 has no cloud-init yet | 15:04 |
| zyga | mvo: can you add me as a co-developer of core18 | 15:05 |
| mvo | zyga: sure | 15:05 |
| ads20000 | Skype for Linux didn't work - didn't pick up my webcam, but not sure the Deb does either. Had to do it on my mum's Win10 PC... | 15:09 |
| smoser | mvo: cloud-init doesn't intenrally help at all with kernel module loading. | 15:09 |
| smoser | mvo: you're saying our kernel on gce does not recognize virtio nics ? | 15:09 |
| smoser | that is possible... but i thought that on gce nics provided *were* virtio | 15:09 |
| mvo | smoser: thats what it looks like which is very odd because its pretty much the same kernel works on core16 | 15:10 |
| smoser | so.. that'd imply that it was busted out of the gate. which is not the case (our cloud images do work there) | 15:10 |
| mvo | smoser: yeah, I think its virtio based networking that is used there | 15:10 |
| mvo | smoser: they work with 4.4-130.156 as well? | 15:10 |
| smoser | oh. | 15:11 |
| smoser | xenial i think doesn't use ga (-generic) kernel there. | 15:11 |
| smoser | i think theres is something esle. | 15:11 |
| smoser | i'd have to check to be sure | 15:11 |
| smoser | launch a gce and look | 15:11 |
| smoser | but bionic is going to use 4.15 i'd expect (but would have to check that for sure) | 15:11 |
| mvo | smoser: aha, thank you. no worries, I will dig some more | 15:11 |
| mvo | smoser: yeah, support for installing 4.15 is not there yet | 15:11 |
| mvo | smoser: and I think we also don't have kernels snaps :/ | 15:12 |
| thresh | virtio is probably in an -extra kernel package | 15:13 |
| thresh | so.. check if you have it installed | 15:13 |
| ogra_ | smoser, well, the build looks fine to me ... not sure why it would fail to upload ... thats a store team question i guess | 15:15 |
| smoser | well, it gives that error about a danling symlink | 15:17 |
| smoser | (which surely does not appear dangling to me) | 15:17 |
| smoser | er... extrenal. which still doesn't seem to be the case. | 15:17 |
| ogra_ | it dangles outside of the snap | 15:17 |
| smoser | no | 15:17 |
| ogra_ | but i dont think that will prevent the upload, it creates a snap after all | 15:18 |
| ogra_ | so the build finishes successfully | 15:18 |
| smoser | right it says | 15:18 |
| cjwatson | That sort of thing is usually due to missing build-packages: | 15:18 |
| smoser | Build failed to release: | 15:18 |
| smoser | Error:package contains external symlinks: usr/lib/security/classpath.security | 15:18 |
| cjwatson | And I think the reviewer tools do reject on dangling symlinks | 15:19 |
| ogra_ | aha | 15:19 |
| cjwatson | Yes, that | 15:19 |
| smoser | but the link is present ... didn't i show that clearly ? | 15:19 |
| ogra_ | the target too ? | 15:19 |
| smoser | its *not* dangling, nor outside the root | 15:19 |
| smoser | at least readlink -f agrees with me | 15:19 |
| ogra_ | so it points to something inside the snap ? | 15:19 |
| ogra_ | (not n core or the rootfs) | 15:19 |
| cjwatson | If you're certain it's not external, then a bug on click-reviewers-tools, I'd guess | 15:19 |
| smoser | http://paste.ubuntu.com/p/dfZm7xDjwV/ | 15:20 |
| zyga | mvo: did that check PR land? | 15:20 |
| zyga | I could use the diffs now | 15:20 |
| smoser | see lines 10 -> 22 | 15:20 |
| smoser | (ignore the confusing paste fail on line 17) | 15:20 |
| cjwatson | smoser: ls -l /mnt/var/lib/security/classpath.security ? | 15:21 |
| cjwatson | just to check | 15:21 |
| smoser | -rw-rw-r-- 1 root root 2489 Jun 18 14:53 /mnt/var/lib/security/classpath.security | 15:27 |
| mvo | zyga: unfortunately no | 15:28 |
| zyga | no worries, thank you for the PRs | 15:28 |
| zyga | I'll keep using my 27" screen to spot the diffs ;) | 15:28 |
| mup | PR core18#29 closed: hooks: add cloud-init <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/29> | 15:29 |
| smoser | interestingly enough, there *are* danling and outside symlinks | 15:30 |
| smoser | http://paste.ubuntu.com/p/ft8FBgZxj6/ | 15:30 |
| cjwatson | smoser: I am not sure how you're getting the results you claim. I downloaded your snap from the link on https://launchpad.net/~build.snapcraft.io/+snap/5f9c9f30f64adbeb1aed583265f7c8ae-xenial/+build/252508, looked at it, and it's clearly wrong. | 15:31 |
| smoser | but the one it complained about is not one of them. | 15:31 |
| cjwatson | $ ls -l /mnt/usr/lib/security/classpath.security | 15:31 |
| cjwatson | lrwxrwxrwx 1 root root 36 Feb 11 2016 /mnt/usr/lib/security/classpath.security -> /var/lib/security/classpath.security | 15:31 |
| smoser | huh. | 15:31 |
| cjwatson | smoser: I think you're checking a different snap than the one that LP built. | 15:31 |
| smoser | i am | 15:31 |
| smoser | i tested the locally built one | 15:31 |
| cjwatson | smoser: Which supports my theory that this is due to missing entries in build-packages. | 15:31 |
| cjwatson | smoser: This is usually a matter of finding the package that delivers /var/lib/security/classpath.security and adding that to build-packages, so that snapcraft can copy the contents into the snap. | 15:31 |
| smoser | cjwatson: how did you download ? | 15:33 |
| cjwatson | smoser: wget | 15:33 |
| smoser | is there a link ? i dont see that in build.snapcraft.io ur | 15:33 |
| smoser | ui | 15:33 |
| cjwatson | smoser: I gave the link above | 15:33 |
| cjwatson | smoser: The first line of the build log is a URL to the LP +build page | 15:34 |
| cjwatson | smoser: And on that there's a "Built files" section | 15:34 |
| smoser | ah. | 15:34 |
| smoser | yeah. ok. i didn't look at closely at the build logs orry. | 15:34 |
| cjwatson | I wish BSI just linked to the LP page but there's a bit of a religion going on about not having that expose the implementation | 15:35 |
| P4 | Hello. I cannot start my rocketchat-server with systemctl and snap logs reports that it sudenly started to look for configs in rocketchat-serve and not rocketchat-server... I did not intentionally renamed that and I cannot easily find any references anywhere in the config trees on my system. Do you know what to look for by that hint from logs? How to recover? I don't think the apt-get {dist-,}upgrade in the | 15:38 |
| P4 | meantime made it. I'm on Ubuntu 18.04 with kernel 4.15.0-23-generic and snap 2.32.9 :-( | 15:38 |
| zyga | P4 you can always "snap revert" to get to the previous revision (and blacklist this one). I would suggest that you get in touch with rocket chat people as well | 15:39 |
| P4 | I made backupdb and even started to symlink things, eh. | 15:39 |
| zyga | I don't think we changed anything that would cause this | 15:39 |
| zyga | can you get me some error logs you referred to? | 15:39 |
| P4 | thanks, zyga. will try | 15:40 |
| P4 | cannot revert "rocketchat-server": no revision to revert to :( but how come it got renamed hmpf. | 15:41 |
| zyga | hmm | 15:42 |
| zyga | can you look at snap changes | 15:42 |
| zyga | and see if there was anything related to that snap? | 15:42 |
| P4 | I'm pretty new to snappy. I believe I should look with git somewhere around /var/snap/rocketchat-server/current | 15:44 |
| zyga | no, don't look there | 15:44 |
| zyga | look at what snapd did | 15:44 |
| zyga | that is stored internally and exposed as "snap changes" and "snap tasks NNN" (where NNN is the number of the change) | 15:44 |
| P4 | oh | 15:46 |
| P4 | the CLI! <3 | 15:46 |
| P4 | still there are no changes found | 15:46 |
| Chipaca | P4: what's the output of 'snap list' (pastebin it) | 15:47 |
| Chipaca | P4: also, 'snap version' | 15:47 |
| P4 | it's https://paste.debian.net/1029731/ | 15:48 |
| Chipaca | P4: which snaps log say it's started looking for 'rocketchat-serve'? | 15:49 |
| Chipaca | P4: also please pastebin 'snap info rocketchat-server' | 15:50 |
| mvo | cachio: its jun181349-035780 this time, if you could paste me the dmesg output that would be great | 15:56 |
| cachio | mvo, no instance with this name | 15:57 |
| cachio | mvo, is it alive? | 15:57 |
| mvo | cachio: ups, typo jun181539-035780 | 15:59 |
| mvo | cachio: and yes, should be alive | 15:59 |
| cachio | mvo, https://paste.ubuntu.com/p/Bghqq5KCQF/ | 15:59 |
| * cachio lunch | 16:05 | |
| P4 | Chipaca: https://paste.debian.net/1029735/ there in the logs | 16:05 |
| mvo | cachio: thank you | 16:07 |
| P4 | maybe it is worth to mention that I was trying to change the listening port by adding Environment=PORT=80 in the /etc/systemd/system/snap.rocketchat-server.rocketchat-server.service file with some comments. then issued dist-upgrade and rebooted OS finding the problem. and now commenting out the line does not help. :| will try to run it by hand for a test | 16:10 |
| P4 | oh my god, the /etc/systemd/system/snap.rocketchat-server.rocketchat-server.service defined indeed ExecStart=/usr/bin/snap run rocketchat-serve and that looks totally like a user mistake... must be that. how come I oversaw it! :|||| | 16:13 |
| === pstolowski is now known as pstolowski|afk | ||
| P4 | darn, I'm sorry about the rumour. Thank you very much for your reactions, zyga && Chipaca. You are all amazing supporing great things the great way here on IRC. Thanks <33 | 16:17 |
| zyga | P4 good luck :) | 16:17 |
| zyga | Chipaca: so, question to you sir | 16:17 |
| zyga | shall snapd use ensureDirState-like functionality for services and mount units? | 16:17 |
| zyga | we could _at leats_ warn (hint hint) about discrepancy | 16:18 |
| zyga | and offer a way to "snap amend" it | 16:18 |
| zyga | how do you feel about that? | 16:18 |
| === mborzeck1 is now known as mborzecki | ||
| smoser | snaps in strict confinement can open files in ~user right ? (ie, /home/smoser) ? | 17:03 |
| kyrofa | smoser, only if using the home interface | 17:06 |
| smoser | itneed home plug. | 17:06 |
| smoser | yeah. | 17:06 |
| smoser | thanks kyrofa | 17:06 |
| kyrofa | smoser, of course | 17:06 |
| zyga | I need a break, back to apparmor rules after a shower | 17:11 |
| zyga | I actually am terrible at any break taking business | 17:49 |
| * cachio afk | 17:54 | |
| zyga | really afk | 18:09 |
| _b_b | hi | 18:31 |
| _b_b | i would like to test auto connection of gtk-theme | 18:31 |
| _b_b | i've posted a question on the forum but i don't got any anwser about it | 18:32 |
| _b_b | is it testable for now ? | 18:32 |
| _b_b | https://forum.snapcraft.io/t/supporting-desktop-themes-via-the-content-interface/4122/6?u=b_b | 18:33 |
| b_b | back with my nickname :) | 18:34 |
| Chipaca | zyga: could be | 18:40 |
| Chipaca | zyga: your 'snap amend' is probably just 'snap disable && snap enable' | 18:40 |
| zyga | Yes. I think so | 18:41 |
| zyga | Although with ensure directory state we could tell the user about the fixes | 18:41 |
| Chipaca | zyga: 'snap fsck' | 18:42 |
| Chipaca | P4: glad you figured it out, and happy to have been of assistance in getting you there! | 18:43 |
| Chipaca | and now i think i'm eod, nothing is on fire etc etc (well my local snapd is panic()ing but that's me breaking it :) ) | 18:44 |
| Luke | hey guys is there a comprehensive list of the $SNAPCRAFT_PART_BUILD/INSTALL etc variables? | 18:54 |
| Luke | also are there updated docs for the snapcraft syntax? It seems a lot of things are deprecated (like install:) in favor of override-build etc | 19:08 |
| === gurmble is now known as grumble | ||
| binarycreations | Hi | 20:18 |
| binarycreations | I am still having trouble creating a snap of the anki desktop client. Thank you to those who have taken a look at this thread already. I have recently updated it (https://forum.snapcraft.io/t/help-required-packaging-anki-desktop-client-as-a-snap/5950) with more details. | 20:19 |
| binarycreations | I am having some trouble understanding how to inspect the container environment that is created by snapcraft. | 20:20 |
| binarycreations | I don't particularly understand what shell you get from snap run --shell and how to get more detailed debugging or logging information from snapcraft and when you run your snap | 20:21 |
| binarycreations | Thanks in advance for any help or assistance. Sorry if this appears to be a desperate nag, however I do really want to snap this app. | 20:23 |
| zyga | binarycreations: hey | 20:28 |
| zyga | you get regular /bin/bash | 20:28 |
| zyga | but running inside the sandbox | 20:28 |
| zyga | so enforced permissions apply | 20:28 |
| mup | PR snapd#5343 opened: tests: adding extra check to validate journalctl is showing current test data <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5343> | 20:34 |
| binarycreations | zyga: Thanks - what seems odd is the dir I get | 20:50 |
| binarycreations | I think I found my issue - only found the desktop launch and other desktop support | 20:51 |
| binarycreations | Under the "Languages" section you might want to consider having a desktop or GUI application section | 20:52 |
| binarycreations | Or even a different section | 20:54 |
| binarycreations | I have been shooting down the wrong alley for a while now | 20:54 |
| binarycreations | zyga: I have updated the forum post again. Now I am stuck with getting libgl1-mesa-dri to install when running snapcraft. | 21:04 |
| binarycreations | I feel one step closer | 21:04 |
| binarycreations | I need some sleep so will catch up with the forum later | 21:05 |
| qwebirc28961 | I'm having problems with snapcraft handling of command line arguments containing non-ascii chars. From my research, it seems related to snap's use of "click" | 21:05 |
| qwebirc28961 | How should I handle command-line arguments in a Py3 script without getting "surrogates not allowed" errors? | 21:06 |
| qwebirc28961 | Should I set "LANG" in the snapcraft.yaml? | 21:06 |
| qwebirc28961 | As per the instructions on http://click.pocoo.org/5/python3/, print(sys.argv[1].encode('utf-8')) does not work either... | 21:15 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!