mupPR snapcraft#1891 closed: lifecycle: use in-snap mksquashfs if running from snap <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1891>00:46
cachiojdstrand, I have requested manual review for the other architectures of snap test-snapd-gpio-memory-control01:50
cachiojdstrand, when you have a minute, could you please approve them01:50
jdstrandcachio: done02:18
cachiojdstrand,  tx02:47
mupPR snapd#4563 opened: tests: new spread test for gpio-memory-control interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4563>04:38
mborzeckiforum is down?06:40
mborzeckimvo: morning06:41
mvomborzecki: good morning06:48
mvomborzecki: yeah, looks down from here as well06:48
* mvo still needs a review for 434206:53
zyga-ubuntugood morning06:55
zyga-ubuntuhttps://github.com/snapcore/snapd/pull/4560 is ready for 2nd review06:55
mupPR #4560: cmd/snap-confine,data/systemd: fix removal of snaps inside LXD <Created by zyga> <https://github.com/snapcore/snapd/pull/4560>06:55
zyga-ubuntuand I'll work on breakfast for kids, see you soon06:55
mupPR snapd#4560 closed: cmd/snap-confine,data/systemd: fix removal of snaps inside LXD <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4560>06:57
mvozyga-ubuntu: I already commented, one tiny nitpick about a comment but that should be a followup, no need to hold this PR back06:57
mvozyga-ubuntu: I need a review for 4342, its blocking ~rc2 currently06:57
zyga-ubuntuI know, I will do your review after kids go to school07:00
mborzeckizyga-ubuntu: morning07:02
zyga-ubuntudaughter is all set and ready for school07:22
zyga-ubuntumvo: thank you for the feedback, I'll update the PR and merge it07:23
zyga-ubuntuah, it's merged now :)07:26
zyga-ubuntuk, looking at that zenity branch07:26
zyga-ubuntumvo: btw, I'm very sorry for not looking at it yesterday, I saw your requests but I was busy with the feedback from gustavo07:27
zyga-ubuntumvo: will you do a RC3 for 2.31?07:27
mupPR snapd#4564 opened: data/systemd: tweak comment <Created by zyga> <https://github.com/snapcore/snapd/pull/4564>07:27
zyga-ubuntumvo: I really want to land 4471 today07:27
zyga-ubuntumvo: and make it into the release07:27
zyga-ubuntuotherwise we should probably back out the new content interface features07:27
zyga-ubuntugustavo approved the design but requested tweaks on how that code operates to drop the helper function (tryIt etc)07:28
mvozyga-ubuntu: if 4471 is ready today +1, if not I think we need a revert PR07:28
mvozyga-ubuntu: how was the feedback yesterday? all looking good to fix it today?07:28
zyga-ubuntumvo: yes07:29
bashfulrobotIs the forum down for anyone else? Nginx 502 bad gateway.07:29
zyga-ubuntumvo: I need to inline that function back07:29
zyga-ubuntumvo: nothing major07:29
zyga-ubuntubashfulrobot: it's down for me too07:29
bashfulrobotzyga-ubuntu thanks for the confirmation!07:30
zyga-ubuntuwoah, the wind today is very strong07:35
zyga-ubuntutrees are swinging like grass!07:35
zyga-ubuntujdstrand: are you in US or still sprinting somewhere?07:52
oSoMoNgood morning07:56
oSoMoNI'm getting a 502 on forum.snapcraft.io07:56
oSoMoNis it just me?07:56
zyga-ubuntuno, it's everyone07:56
mvojdstrand: if you could moderate the updated base-18 in the store that would be great08:01
zyga-ubuntumvo: what is %[1]q - is that golang syntax for fmt?08:08
zyga-ubuntuhey there spineau08:09
spineaumorning zyga-ubuntu08:10
zyga-ubuntumvo: nitpick 2018 in your new files08:11
zyga-ubuntuhey pawel08:12
pstolowskithe forum is borked?08:12
zyga-ubuntumvo: so I get what \0 is but \00 ? is that the same thing or {'\0', '0'} in C syntax?08:13
zyga-ubuntuman, today is windy :/08:14
mvozyga-ubuntu: %[1]q is fmt syntax08:15
mvozyga-ubuntu: \00 should be \0, let me check, maybe I made a silly mistake08:15
zyga-ubuntumvo: at line ... 43 and 4408:16
zyga-ubuntumvo: so meta-comment, nothing -1, I want to play with it08:17
zyga-ubuntubut we need the desktop team to help and I don't know, roll this into gnome settings08:17
zyga-ubuntuor into other appropriate place08:17
zyga-ubunturight now it feels like a hack that keeps us walking till we can run08:17
pstolowskimvo, hey, shall I squash #4440 for easy cherry-picking into 2.31?08:18
mupPR #4440: state: unknown tasks handler <Created by stolowski> <https://github.com/snapcore/snapd/pull/4440>08:18
mvopstolowski: its fine as is, I looked over master this morning and all is fine for .3108:18
pstolowskimvo, ok08:19
mvozyga-ubuntu: aha, sorry. this should read \0\008:19
mvozyga-ubuntu: i.e. a double \0 marks the end of a command08:19
mvozyga-ubuntu: let me fix this08:19
zyga-ubuntuthank you!08:20
* zyga-ubuntu reads rest08:20
mborzeckizyga-ubuntu: hmm looking at 4565 i was wondering why i'm ending up with snap.mount on arch08:21
ackkmvo, hi, it seems there was an issue uploading the base-18 build: https://code.launchpad.net/~mvo/+snap/base-18/+build/13872408:21
mupPR snapd#4440 closed: state: unknown tasks handler <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4440>08:21
mborzeckizyga-ubuntu: turns out i'd really like to switch data to autotools08:22
zyga-ubuntumborzecki: no objection, fire a PR and let's do it08:22
zyga-ubuntumvo: and in strings, is \000 just {'\0'} or is it something else08:36
zyga-ubuntue.g. here:  +call = strings.TrimSuffix(call, "\000")08:36
mvoackk: yeah, I ask jamie to moderate the upload, it is currently stuck in the review queue08:45
mvozyga-ubuntu: this should be \0 as well, sorry for this08:46
ackkoh ok, thanks08:46
zyga-ubuntumvo: did you run it in practice?08:50
mvozyga-ubuntu: just running the tests08:54
mvozyga-ubuntu: but the zenity tests use \n in their args08:55
mvozyga-ubuntu: so it should work08:55
zyga-ubuntumvo: how about setting this thing in practice, getting the prompt and all of that08:55
* zyga-ubuntu is still reading the code08:55
sparkiegeekdo we have to wait for niemeyer to get the forum back up?09:04
zyga-ubuntusparkiegeek: I'm afraid so, we're not sure what caused it09:07
mvozyga-ubuntu: I tested this with the brave browser09:10
mvozyga-ubuntu: sorry for the delay in answering09:10
mvozyga-ubuntu: if that is what you mean with "testing in practise" or do you mean something else?09:10
zyga-ubuntuno that's fine09:15
zyga-ubuntudid you test both kde and non-kde paths?09:15
mvozyga-ubuntu: yeah, i tested once with kdialog and once with zenity09:20
mvozyga-ubuntu: I think mborzecki has a point that ideally it would check the desktop env too, I can make a PR for that too09:21
zyga-ubuntumvo: yeah, I responded to that part as well09:21
* kalikiana coffee09:21
zyga-ubuntumvo: reviwed09:22
zyga-ubuntumvo: can you have a quick look at https://github.com/snapcore/snapd/pull/4564 please09:23
mupPR #4564: data/systemd: tweak comment <Created by zyga> <https://github.com/snapcore/snapd/pull/4564>09:23
zyga-ubuntulet's either merge it or tell me to tweak the install code09:23
mupPR snapd#4564 closed: data/systemd: tweak comment <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4564>09:25
mvozyga-ubuntu: I think its fine, we can always tweak further09:25
pedronishi, is the forum down (502) ?09:26
zyga-ubuntuI think we need a post mortem on the forum and some plan for gustavo being on holidays09:26
zyga-ubuntu*cough* IS *cough*09:26
zyga-ubuntukalikiana: https://regexper.com/09:29
mborzecki`/home/ubuntu/goroot/pkg/tool/linux_386/link: running gcc failed: exit status 1` uhh not my lucky day09:31
zyga-ubuntumborzecki: it's your NaNth lucky day09:32
mborzeckioh hey, also gnome-shell crashed out of the blue09:33
mborzeckipff strace to the rescue: [pid  8615] write(2, "/usr/bin/ld", 11) = -1 ENOSPC (No space left on device)09:33
zyga-ubuntucareful with those torrents09:34
zyga-ubuntuqemu can eat a lot of space on -snapshot09:34
mborzeckizyga-ubuntu: it's xenial cloud image09:35
* zyga-ubuntu takes a break to look through bugs befor jumping onto PR feedback09:35
mborzeckididn't know those are 2gb09:35
zyga-ubuntuhey Chipaca!09:35
zyga-ubuntumborzecki: uh09:35
mborzeckiChipaca: morning09:35
Chipacamborzecki: zyga-ubuntu: hiya09:36
zyga-ubuntupstolowski: can you please look at https://bugs.launchpad.net/snapd/+bug/161163809:36
mupBug #1611638: snap upgrade hook <snapd:Fix Committed> <snapd (Ubuntu):Fix Committed> <https://launchpad.net/bugs/1611638>09:36
zyga-ubuntuI think it's fixed so we can just update the bug but I wanted you to confimr09:36
zyga-ubuntu*confirm even09:36
pstolowskizyga-ubuntu, looking09:37
kalikianazyga-ubuntu: Hmmm looks quite nice. Although it seems very "analyze afterwards". It's not live and there's no test string09:38
zyga-ubuntumborzecki: I assigned a bug about testing on arch to you (since you're doing that anyway)09:38
zyga-ubuntukalikiana: yeah, not perfect but it's nice to see those cute railroad diagrams09:39
mborzeckizyga-ubuntu: ack09:41
pstolowskizyga-ubuntu, commented on the bug, it's implemented, although now as I checked only on of those was released (post-refresh) and pre-refresh will come with 2.3109:43
zyga-ubuntupstolowski: perfect, thank you!09:44
* Chipaca carries on refactoring unseen code09:45
zyga-ubuntuChipaca: I do that a lot though sometimes I think I'm doing the coding version of modern art ;)09:49
Chipacazyga-ubuntu: not art, but craft09:49
Chipacazyga-ubuntu: the difference is mostly around how we get paid :-)09:50
mborzeckiart is when you don't get paid09:51
zyga-ubuntuI often write a piece of code and the refactor it, sometimes many many times, before sending out the first PR09:52
zyga-ubuntupstolowski: another one for you https://bugs.launchpad.net/snapd/+bug/166415509:54
mupBug #1664155: Interface hooks slots should know the name of the client snap <snapd:Triaged> <https://launchpad.net/bugs/1664155>09:54
zyga-ubuntumvo: trivial conflict on https://github.com/snapcore/snapd/pull/444309:54
mupPR #4443: [RFC] snap: improve error for snaps not available in the given context <Created by mvo5> <https://github.com/snapcore/snapd/pull/4443>09:54
Chipacapedronis: you around?09:54
mupPR snapd#4565 opened: httputil: include Go runtime version in user agent string <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4565>09:55
mborzeckitrivial PR ^^09:55
zyga-ubuntukalikiana: can you look at https://bugs.launchpad.net/snapd/+bug/1669291, perhaps a low hanging fruit09:56
mupBug #1669291: 'snap info' does not handle versions that end in 0 well <Snapcraft:New> <snapd:In Progress> <https://launchpad.net/bugs/1669291>09:56
zyga-ubuntukalikiana: at least triage it please09:56
pstolowskizyga-ubuntu, k, will comment on it when forum is back, I think it was discussed long time ago (and Gustavo was against doing it)09:56
zyga-ubuntumborzecki: nie!09:56
zyga-ubuntupstolowski: just give some feedback on the bug report, we don't have to move the discussion elsewhere09:56
zyga-ubuntumborzecki: what is the runtime string like?09:57
mborzeckizyga-ubuntu: added a comment in the PR09:57
zyga-ubuntumborzecki: and another hint, send it in the / request so that (perhaps) snap version can show it09:57
pstolowskizyga-ubuntu, sure, I just need to try find that discussion09:57
zyga-ubuntumborzecki: looks good09:57
kalikianazyga-ubuntu: Aye09:58
pedronisChipaca: yes09:59
Chipacapedronis: hiya, welcome back :-)09:59
Chipacapedronis: while you were away I was wondering whether a local snapd could "sign" stuff09:59
zyga-ubuntukalikiana: thank you09:59
Chipacapedronis: and thought you were the person to ask10:00
pedronisChipaca: sign stuff in which sense?10:00
zyga-ubuntupstolowski: perhaps another bug for you https://bugs.launchpad.net/snapd/+bug/1672747 -- feel free to ignore, I'm just combing the bug tracker10:00
mupBug #1672747: configure hook missing reason it was invoked <snapd:Triaged> <https://launchpad.net/bugs/1672747>10:00
mborzeckihm good news, i can reproduce the segfault when building snapd on xenial with go1.9.310:00
Chipacapedronis: as a way of ensuring not only the integrity of a snapshot, but also its origin10:00
pstolowskizyga-ubuntu, the bug makes sense, but it's slowly improving with new hooks10:01
pedronisChipaca: if it has a serial yes, then it has a device key10:01
pedronisthat can be tracked to the serial10:02
Chipacapedronis: snapshots have a metadata file with hashsums of the archives themselves, so AFAIUI if I signed that (relatively small) file and included the signature, I'd be able to warn or block people from restoring snapshots that weren't created by their own host10:02
pedronisshould be doable in some way10:03
Chipaca(i imagine adding a --ignore-signature or something)10:03
Chipacapedronis: ok, good to know. I'll pester you about it once everything else is shipshape.10:03
pedronisdepends on the attack you are trying to avoid, or is just not mismatching stuff?10:03
mborzeckiguys, is #4487 good to be merged now?10:05
mupPR #4487: cmd/snap: snap refresh --time with new and legacy schedules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4487>10:05
zyga-ubuntumborzecki: looking10:06
zyga-ubuntuwith 4 +1s, sure!10:07
Chipacapedronis: the attack is fairly contrived, in that you'd have to either be able to write to the spool directory where snapshots live (and in a properly configured system users won't even be able to read it), or convince an admin to accept a snapshot file somehow10:07
mupPR snapd#4487 closed: cmd/snap: snap refresh --time with new and legacy schedules <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4487>10:07
zyga-ubuntumvo: can we do something about seccomp before 18.04?10:15
mvozyga-ubuntu: do somethng about it in what sense?10:16
pedronisChipaca: just saying that if you are root you can get the key that is used for signing10:18
Chipacapedronis: yeah10:19
zyga-ubuntumvo: make it so that on 18.04 we can enable the non-kill behavior10:19
pedronisChipaca: anyway I suppose if people ship them somewhere and back it's a bit more interesting10:19
Chipacapedronis: I expect snapshots will be part of a backup solution that includes remote backups, yes10:19
Chipacabut those things should be signed at a separate layer anyway10:19
Chipacapedronis: I think I'll check with jamie, and if he agrees it's too tenuous, i'll forget it10:19
pedronisok, np10:20
Chipacapedronis: thanks10:20
mvozyga-ubuntu: its tricky the updated libseccomp  is not out, but we might be able to split out this part of the work in a separate pr10:21
ikeyidk theres something charming about a security stack that opts to commit seppuku to protect the user10:23
zyga-ubuntumvo: upstream has not released it or it hasn't found its way into ubuntu?10:23
zyga-ubuntuikey: did snap-confine refuse to run for you? :)10:23
zyga-ubuntuikey: (hey :-)10:24
ikeyhey :) nah not recently, i meant the seccomp thing10:24
zyga-ubuntuikey: ah10:24
zyga-ubuntuwell, that's not seppuku, IMO it's like us shooting a thread because it asked to go to the loo10:24
zyga-ubuntuthe thread _asked_10:24
zyga-ubuntujust saying no wasn't in the vocabulary10:24
ikeyyeh but i mean, going to the loo, during class time10:24
ikeyidk man..10:24
zyga-ubuntuyeah, so mean10:25
zyga-ubuntuit's an _internal_ problem ;)10:25
zyga-ubuntuI'd love to see that bug fixed, I'm wondering what we can do10:25
zyga-ubuntuthe kernel part is done now10:25
zyga-ubuntuand everyting else is just userspace10:25
ikeyso distros just need to update libseccomp?10:25
zyga-ubuntuit's complicated10:26
zyga-ubuntuand golang bindings on top10:26
zyga-ubuntuand it seems it's not even out upstream yet10:26
mupPR snapd#4565 closed: httputil: include Go runtime version in user agent string <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4565>10:26
zyga-ubuntumborzecki: make sure the store team can parse that ^ talk to ... perhaps noise][ ?10:27
mvozyga-ubuntu: upstream has not released an new golang-seccomp10:27
ikeyits looking likely im going to need to rework my nvidia PR to account for some fedora weirdness10:28
zyga-ubuntumvo: is the upstream for the C and golang lib the same?10:28
ikeylooks like they stuff their entire tree under /usr/lib64/nvidia-304xx/*10:28
ikeyso idk if i need to do that as separate PR, commit or what10:28
ikeygiven the one i have is marked accepted..10:28
zyga-ubuntuikey: no, just stack on top there10:28
zyga-ubuntuthank you for caring about fedora!10:28
ikeywell we're all cousins in this world10:29
ikey(not literally. that'd make christmas so freakin awkward)10:29
zyga-ubuntuwith RMS and linus smiling from a family photo on the wall10:30
zyga-ubuntuweird silence10:31
mborzeckihmm no segfault with go1.8.310:33
* Chipaca gives up on emacs and goes back to paper10:34
mvozyga-ubuntu: its two different people. but the upstream C is also not released yet10:37
mvozyga-ubuntu: its just part of git10:37
mvozyga-ubuntu: and the golang is not yet part of git because there is no libseccomp yet released with the bits needed10:37
zyga-ubuntumvo: aha, I see; we can ask them to release or distro patch in ubuntu but I wonder how that complicates building the packages and the snaps10:40
zyga-ubuntumvo: craazy idea: what if snap-seccomp was a .. snap itself10:40
zyga-ubuntuand we could pull it in to build the profiles10:41
zyga-ubuntu(it's a bit chicken-eggy)10:41
zyga-ubuntubut would work around building issues10:41
mvozyga-ubuntu: we distro patchi n ubuntu already, thats fine. but e.g. fedora is not distro patching10:41
ikeyaha. smoke break granted me the wisdom to fix the gl thing..10:42
pedroniszyga-ubuntu: mborzecki:  that format is not standard afaik  (it would need to be system/version)10:42
mvozyga-ubuntu: if fedora would allow us to bundle the problem would also not exist10:42
zyga-ubuntumvo: I think we can bundle but we could also patch the packages there if maintainers agree10:42
zyga-ubuntupedronis: oh, thank you for noticing10:42
zyga-ubuntupedronis: so golang/...10:42
Chipacathe forum seems very 502y today10:42
zyga-ubuntu(or similar)10:42
pedronissomething like that10:42
zyga-ubuntuChipaca: yes, it's 100% reliably 500s today10:43
pedronisChipaca: input on #456510:43
mupPR #4565: httputil: include Go runtime version in user agent string <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4565>10:43
pedronisit's merged but I think it needs tweaks10:43
mborzeckipedronis: opening a followup with fixes in a minute10:44
Chipacathat should be go/xyz10:44
mborzeckiChipaca: pedronis: runtime.Version() already returns `go1.9.3`, that would make it golang/go1.9.310:45
Chipacamborzecki: what does it look like with gccgo?10:45
pedronisalso a bit unclear whether it's useful?10:45
pedronismborzecki: what's the goal here?10:46
ChipacaI'd be ok with go/goX.Y.Z if goXYZ is what runtime.Version returns10:46
pedronisgetting this in the logs?10:46
mborzeckipedronis: yes10:46
Chipacapedronis: it'd be in error reports also10:46
pedronisboth could be done without changing the user agent10:46
pedronisit's a bit strange to put the compiler there10:46
pedronisotoh it's also the standard lib10:47
pedronismborzecki: what does go itself does?10:47
pedronisit has a default user-agent afaik10:47
mborzeckipedronis: also stdlib carries the http client10:47
pedronisthat we are overriding10:47
pedroniswe probably should do something similar10:47
mborzeckipedronis: probably Go-http-client/1.1 (that's what they expect in the tests anyway)10:50
pedronismborzecki: zyga-ubuntu: anyway I fear this will also break the store10:51
pedroniswe need to be a bit careful10:51
mborzeckiChipaca: pedronis: `golang/go1.9.3` then?10:52
pedroniswhy the repeated go?10:52
pedronisanyway I also need to check where to put it if at all10:53
* zyga-ubuntu -> important errand10:53
Chipacamborzecki: problem10:54
mborzeckii can always move the go runtime version string to daemon.go and log it there, after all i just want to see the version somewhere, don't really care if it's the user agent string10:54
Chipacago1.6.1 gccgo (Ubuntu 6.0.1-0ubuntu1) 6.0.0 20160414 (experimental) [trunk revision 234994]10:55
Chipaca^ runtime.Version() with gccgo10:55
mborzeckiright, and go returns go1.9.310:55
mborzeckioh, w8, that's the whole string?10:55
Chipacamborzecki: "go1.6.1 gccgo (Ubuntu 6.0.1-0ubuntu1) 6.0.0 20160414 (experimental) [trunk revision 234994]"10:55
Chipacamborzecki: that's printed with %q for your enjoyment10:56
mborzeckiok, i'll log it in the daemon10:56
mborzeckiand the store can keep guessing which buggy version of go http.Client was that :)10:56
pedronismborzecki: anyway, indeed as it is it would break the store parsing of it10:57
mborzeckiok, i"ll open a pr reverting the change10:57
pedronisthe issue there is mostly putting it at the end I think10:58
mupPR snapcraft#1892 opened: meta: warn if version is not a string <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1892>11:00
mupPR snapd#4566 opened: Revert "httputil: include Go runtime version in user agent string" <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4566>11:00
ikeywhat do you use to format the C files in snapd?11:01
mborzeckiikey: indent11:01
ikeyany sample invocation? i tried indent but it mangled the file11:01
mborzeckidon't laugh though please :)11:01
* ikey is only used to clang-format11:02
mborzeckithere's .indent in cmd11:02
mborzecki`make fmt` should do the trick11:02
pedronismborzecki: or not, maybe I'm confused (regexps are fun that way)11:02
ikeyah ty11:03
ogra_mvo, i see xnox just made systewmd default to persistent journald logging ... https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1618188 for your base 18 you might want to turn it off to not wear out MMCs11:03
mupBug #1618188: systemd journal should be persistent by default: /var/log/journal should be created <upgrade-software-version> <systemd (Ubuntu):Fix Released by xnox> <systemd (Ubuntu Xenial):Confirmed> <systemd (Ubuntu Zesty):Confirmed> <systemd (Ubuntu Artful):Confirmed> <systemd (Ubuntu11:04
mupBionic):Fix Released by xnox> <https://launchpad.net/bugs/1618188>11:04
pedronismborzecki: https://golang.org/pkg/runtime/#Version  says it could also be a hash and date11:05
ogra_(oh, and indeed make sure /var/log/journal is writable11:05
mvoogra_: base-18 has everything writable11:06
ogra_will you keep it that way ?11:06
mvoogra_: we will see if it works out, but whats the downside?11:06
mvoogra_: thanks for the heads up, I will look into making sure this is not written to disk by default then11:08
Chipacaniemeyer: Apologies for any inconvenience this may have cause*d* you.11:11
Chipacaniemeyer: and thank you for getting it back up :-)11:11
zyga-ubuntuniemeyer: hey11:11
zyga-ubuntuniemeyer: woot, thank you for for the post morterm11:12
niemeyerChipaca: Thnaks11:12
* zyga-ubuntu makes lunch and reads11:12
niemeyerChipaca: *Thanks* :)11:12
Chipacaniemeyer: I thought that was on porpoise11:12
zyga-ubuntuniemeyer: it's at least very comforting to know the forum died while making a backup :)11:13
pedronisChipaca: afaict runtime.Version() can be whatever :/11:13
niemeyerzyga-ubuntu: Yeah11:13
Chipacapedronis: well, at least we know it's a string :-D11:14
niemeyerzyga-ubuntu: We also have daily backups stored since August11:15
niemeyerof the data, plus daily and weekly backups of the whole machine11:17
niemeyerWe have so many backups that I killed the system doing it11:17
zyga-ubuntuniemeyer: sweet11:18
mborzeckipedronis: Chipaca: #456611:32
mupPR #4566: Revert "httputil: include Go runtime version in user agent string" <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4566>11:32
ChipacaI could use another review on #4556 and #4557 i think11:33
mupPR #4556: strutil/quantity: new package that exports formatFoo (from progress) <Created by chipaca> <https://github.com/snapcore/snapd/pull/4556>11:33
mupPR #4557: osutil: add DirExists and IsDirNotExist <Created by chipaca> <https://github.com/snapcore/snapd/pull/4557>11:33
mupPR snapd#4566 closed: Revert "httputil: include Go runtime version in user agent string" <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4566>11:34
kalikiana"snap lxd cannot use current base snap core because existing process are still using the old revision"11:35
kalikianaThat's a weird error. Was doing `lxc exec` there11:35
Chipacamborzecki: I did +1 it, but zyga merged it before github took my +1 and i think it then lost it11:35
zyga-ubuntukalikiana: that's a warning11:35
zyga-ubuntukalikiana: it means you could hop onto new core11:35
zyga-ubuntukalikiana: but you're using the old one because some lxc process is still alive11:36
Chipacazyga-ubuntu: you're on fire :-)11:36
mupPR snapd#4556 closed: strutil/quantity: new package that exports formatFoo (from progress) <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4556>11:36
zyga-ubuntuChipaca: _high voltage_ :)11:36
zyga-ubuntukalikiana: if you restart your lxc things it should go away and you will see new core being used11:36
zyga-ubuntukalikiana: all processes belonging to a given snap see consistent filesystem11:36
kalikianazyga-ubuntu: I feel the message should've told me exactly that :-)11:37
kalikianazyga-ubuntu: Does the error come from snapd? Or LXD?11:38
kalikianazyga-ubuntu: I'll file a bug. Let's see if it can be improved11:41
zyga-ubu1tumy machine crashed because when I went out of range BT went nuts11:41
zyga-ubu1tukissiel: ^11:41
zyga-ubu1tukalikiana: re11:41
zyga-ubu1tukalikiana: so about that, how would you rephrase that so that it's more useful11:41
zyga-ubu1tukalikiana: just tell me :)11:42
zyga-ubu1tuor open a forum thread11:42
zyga-ubu1tuit's a sub-optimal situation, we could perhaps have a hook for this11:42
zyga-ubu1tuif there's no hook we could print a short line of text + forum link11:42
zyga-ubu1tuand if there's a hook we could signal snapd and not print anything11:42
=== zyga-ubu1tu is now known as zyga
kalikianazyga: first of all it should reveal itself as a warning, for example by starting with "Notice:"11:46
kalikianazyga: although by showing me this message every single time I practically consider it an error since I can't actually ignore it11:46
kalikianazyga: It'd also be nice if it was phrased more like 'Notice: The "lxd" snap will continue to use "core" 3958 as a base until all its processes have been restarted via "snap restart lxd".'11:49
zygakalikiana: it's not true11:50
zygakalikiana: that's the problem :)11:50
zygakalikiana: the first part is okay11:50
zygabut the remainder is not accurate11:50
zygasnap restart lxd is not sufficient11:51
zyga_all_ processes, including non-services, must terminate11:51
kalikianazyga: Well, if it's not accurate it's because I had to guess since it did not in fact tell me :-D11:51
zyga(I lost my log) can you paste the original message again please?11:51
kalikianazyga: `snap lxd cannot use current base snap core because existing process are still using the old revision`11:52
ikeyphew. back to working snapd..11:52
mvozyga: 4342 is ready for a re-review (cc mborzecki I addressed your comments as well iirc)11:53
ikey4559 will need re-review too11:53
zygakalikiana: hmm hmm11:53
kalikianazyga: The "cannot use" wording makes it look like an error. And it's not telling me how to fix it.11:53
zygamvo: ack11:53
zygakalikiana: I don't dismiss the wording could be better11:53
zygajust pondering on what it should be11:53
ikeydecided to be nice to those darn pesky fedora kids :p11:53
kalikianazyga: This is why I suggested to file it, didn't expect you to fix it on the spot :-P11:54
kalikianaOh, forum's back. I could also make a topic for it then11:55
zygakalikiana: yeah, let's do a forum topic, we can tweak that message before 2.3111:56
zygathank you for rising this11:56
greybackjdstrand: hey, thank for the review of https://github.com/snapcore/snapd/pull/4545 Question on the AppArmorConnectedSlot advice - each snap has it's own /tmp - I was stuck on how a file in x11's /tmp is made available to another snap's /tmp. Is the rule label causing snapd doing some fancy /tmp combining? Or is it up to the plug's launch script to dig into the slot's /tmp and find the socket it needs?12:02
mupPR #4545: interfaces/x11: allow X11 slot implementations <Created by gerboland> <https://github.com/snapcore/snapd/pull/4545>12:02
zygagreyback: if you put the socket in $SNAP_COMMON12:07
zygayou could use new content sharing features to inject that anywhe12:07
zygaso for the snap holding the socket and being the server it can be in $SNAP_COMMON12:08
zygaand for any client snaps it could be in /tmp/somethingappropriatethatisdefault12:08
ikeydoes snapd expose changelog functionality? like when i publish a new revision can i inform users of changes?12:09
zygayou can do that in the store but I don't know if this is visible in many places12:09
ikeyah ok12:09
ikeyfuture stuffs then12:09
zygait's a nice thing if it was accessible12:09
zygaI mean12:09
zygayou can fill it for each release12:09
ikeyand at some point in the future hook up UI bits12:09
kalikianazyga: https://forum.snapcraft.io/t/cannot-use-current-base-snap-core/376312:10
greybackzyga: I would if I could, but I'm snapping x11. It has /tmp/.X11-unix/X* hardcoded in12:12
kalikianazyga: I can't actually seem to get rid of it12:13
kalikianavery broad use of killall doesn't help12:13
zygagreyback: no, you didn't understand12:14
zygagreyback: you can do that without touching x1112:14
* greyback re-reads12:14
zygagreyback: the content interface lets you do those bind mounts12:14
zygagreyback: I haven't tried this on a socket though so you may run into a limitation12:15
zygagreyback: but even a tiny patch in x11 (or config tweak) to store the socket in $SNAP_COMMON is enough12:15
greybackzyga: ack. I see what you mean. I'll give that a go.12:16
zygagreyback: you must use master though12:16
zygagreyback: and stick to $SNAP_COMMON for now12:16
zygagreyback: (or edge)12:16
zygagreyback: try it with dummy snaps and a writable file12:16
zygagreyback: and the content interface12:17
zygain the end we can move this into the x11 interface properly12:17
greybackmore toys to play with!12:17
zygaand my child so let's see how it works, I'm eager to get feedack12:18
niemeyerpopey: Seen the announcement of godot 3.0 final being released yesterday.. did you ever get that to work?12:22
pedronismvo: Chipaca: can the 2_32 tag be created in the forum12:24
Chipacapedronis: but i can only create it by tagging something12:25
Chipacapedronis: ideally something that needs to be there for 2.32 :-D12:25
pedronisok, I suppose I should talk with mvo about the when of those12:26
mupPR snapd#4558 closed: cmd/snap-mgmt: fix out of source tree build <Created by bboozzoo> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4558>12:26
Chipacapedronis: i think i have something i can tag12:26
Chipacapedronis: there12:27
Chipacaand now, lunch12:27
* ogra_ grins about zygas comments on #4563 ... you should really talk to the devmem2 developers to have this fixed upstream :)12:36
mupPR #4563: tests: new spread test for gpio-memory-control interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4563>12:36
ogra_(that c file is just devmem2.c renamed ;) )12:37
zygawell, I'm just a C coder12:40
mborzeckibisecting go toolchain, so much fun12:42
Chipacapstolowski: you can't fallthrough a type switch12:50
pstolowskiChipaca, aha! thanks, still learning about some corners of Go12:51
Chipacapstolowski: you also can't usefully enumerate things (i.e. if you do "case typeA, typeB:" you'll get the interface-y object in the case12:53
mupPR snapd#4567 opened: cmd/snap-confine,tests: hide message about stale base snap <Created by zyga> <https://github.com/snapcore/snapd/pull/4567>13:22
jdstrandgreyback: you're right about the per-snap /tmp. if these were named sockets, there would be a problem, but they are abstract sockets (path starts with '@') so they aren't file backed and not affected by the mount namespace13:41
mupPR snapd#4567 closed: cmd/snap-confine,tests: hide message about stale base snap <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4567>13:54
* kalikiana off for lunch, back soon14:00
kalikianazyga_: but before I leave, great to see this extremely quick PR , you are awesome:-D14:01
* kalikiana now really off for lunch14:01
greybackjdstrand: aha. Ok. I didn't know that14:04
Beretcan someone remind me why I have multiple (more than 2) loop devices for a snap?14:05
BeretI understand 2 for the theoretical purposes of rollback14:05
Beretbut why more than 2?14:05
mborzeckibisecting the -linkshared segfault, the first bad commit is https://github.com/golang/go/commit/4808fc444307fa683bf3df6d55f9ad1828891a3614:05
mupPR snapd#4568 opened: tests: new spead test for openvswitch-support interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4568>14:07
ChipacaBeret: 3, so you can always rollback even in the worst case14:16
ChipacaBeret: we might make it tunable at some point (there's a feature request for this already)14:17
ChipacaBeret: but in any case you can already remove the prior ones with "snap remove <snapname> --revision <revno>"14:17
ChipacaBeret: (the worst case is: you're on a "good" revision, you refresh to something newer, but it's a dud so you manually revert back to the known-good one; because we keep 3, you can still revert from there as well)14:18
ChipacaBeret: hth14:19
cjwatsonsergiusens: is anyone on your team in fact working on the project to convert LP to be able to consume snapcraft as a snap?  I'm concerned about that having possibly fallen between the cracks14:26
BeretChipaca, ok, thanks14:42
mupPR snapd#3456 opened: many: add interfaces.SystemKey() helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/3456>14:44
sergiusenscjwatson no, no one is; sorry, the communication has. I did discuss this with sparkiegeek15:00
cjwatsonsergiusens: was that today?  I talked about this with sparkiegeek this morning15:01
sergiusenscjwatson capetown sprint15:02
cjwatsonsergiusens: must have slipped his mind.  I can take it over if it will otherwise end up not being done, just didn't want to duplicate work15:05
zyga_sorry, small interrupt for kids15:09
sergiusenscjwatson that would be appreciated. I am sorry it fell through the comm cracks15:17
cjwatsonall right, let's see what I can fit in15:17
=== zyga_ is now known as zyga
pedronispstolowski: sorry it took a bit,  looks it's going in the right direction, did a pass over #440115:32
mupPR #4401: snapstate/ifacestate: auto-connect tasks <Created by stolowski> <https://github.com/snapcore/snapd/pull/4401>15:32
pstolowskipedronis, hey, no problem, and thanks!15:33
* kalikiana seems to be online again, for some reason wlan didn't see any network for a while15:41
* kalikiana once again fell for the DENIED messages caused by the telegram snap looking for helpful logs15:43
pedroniszyga: what's the status of #4471 ?15:43
mupPR #4471: cmd/snap-update-ns: refactor and improve Change.Perform to handle EROFS <Created by zyga> <https://github.com/snapcore/snapd/pull/4471>15:43
zygapedronis: refactoring after feedback from a call, I'll push it in ~hour15:47
mupPR snapd#4550 closed: cmd/snap: improve output when snaps were found in a section or the section is invalid <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4550>15:47
seb128jdstrand, hey, just for info I started as topic as discussed in CT, https://forum.snapcraft.io/t/confined-snaps-dont-work-on-live-images-due-to-apparmor-path-mapping/376716:07
zygaseb128: interesting, it's probably the same problem that prevented us from using overlayfs16:07
* zyga reads16:07
seb128zyga, right16:08
zygaseb128: replied16:11
seb128zyga, thanks16:11
niemeyermvo: #4342 reviewed.. trivials only, thanks16:15
mupPR #4342: userd: add support for a simple UI that can be used from userd <Created by mvo5> <https://github.com/snapcore/snapd/pull/4342>16:15
mvoniemeyer: \o/ thank you16:15
niemeyermvo: Thank you!  Nice abstractions16:16
blackboxswpedronis: do you know offhand about seeding --classic snaps? https://forum.snapcraft.io/t/seed-yaml-documentation/3050/416:22
pedronisblackboxsw: on a classic image?16:22
blackboxswon non-snappy environments16:23
pedronisclassic: true  in the seed entry for the snap  afair16:23
blackboxswso stock ubuntu cloud-images16:23
blackboxswahh nice16:24
blackboxswwill try that16:24
blackboxswand will update the post with the results16:24
pedronisblackboxsw: I'm just back from holidays,  I put looking at that post in my queue16:25
blackboxswcheers. yeah I heard. Welcome back :)16:26
zygahmm mhmm16:35
jdstrandseb128: thanks, noted and commented16:42
* jdstrand -> travel16:42
ChipacaQ: what happens if you accidentally switch the implementations of, in essence, 'rm' and 'md5sum -c'?16:42
ChipacaA: giggles16:42
* Chipaca takes a break16:43
zygajdstrand: safe travels!16:44
zygaChipaca: A: backups16:44
Chipacazyga: dude16:57
Chipacazyga: i'm implementing snapshots16:57
Chipacaie backups16:57
Chipacazyga: :-)16:57
zygaChipaca: snap my home directory ;)16:57
Chipacai had the handlers for 'lose' and 'check' reversed16:57
Chipacahappy to have tests :-)16:58
zygalose drops the snapshot?16:58
Chipacazyga: yes16:58
zygaChipaca: just document it, it's not a bug if it's documented ;)16:58
* Chipaca takes note16:58
mvoikey: is 4559 good to go?17:01
ikeyis that the one i did today i cant remember17:02
mvopr #455917:02
mupPR #4559: snap-confine/nvidia: Support legacy biarch trees for GLVND systems <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4559>17:02
ikeyso the thing i wanted clarification on from Son_Goku was the libdir stuff17:03
ikeylike are we making this a compile time option or is it being vendor patched or what17:03
ikeyor do we just do more of the populate calls? cheap and cheerful17:04
Son_Gokumore of the populate calls17:04
Son_Gokuthe issue with the other two is the multi-base snap nature of things17:04
ikeyso do you have a lib32 directory in fedora?17:04
Son_Gokuand we really don't have any more permutations to worry about17:05
ikeyso populate isnt going to be the right approach17:05
Son_Gokuwe have /usr/lib and /usr/lib6417:05
ikeybecause you're going to get inverse libraries17:05
ikey32s in the 6417:05
Son_Gokuah, right17:05
ikeyi mean it'll still technically *work* but its not "right"17:05
ikeyand i think the rest of the world is lib64/lib3217:05
Son_Gokumost of the world is lib/lib6417:06
ikeywith lib + lib64 being the same thing17:06
ikeyeh idk about that17:06
ikeyeven arch uses lib3217:06
Son_GokuArch and Solus are lib32 / lib6417:06
Son_GokuGentoo is fuck all17:06
Son_Gokuthough they default to lib / lib6417:06
ikeyso ok we need to use --libdir as our /usr/lib there atm17:06
Son_GokuFedora, SUSE, Mageia, et al are lib / lib6417:06
ikeyand we need a new option for emul3217:06
ikeyso that we no longer assume17:07
ikeyassuming ofc on fedora you configure --libdir=/usr/lib6417:07
ikeyand we add like --with-emul32-libdir=/usr/lib ?17:07
ikeygimme a wee second here17:07
ikeyty btw :]17:08
Son_Gokuyou could also do detect-y things for this17:08
ikeythe smartest way to be smart is by not being smart17:08
Son_Gokujust sayin'17:08
ikeyhm. autotools crap.17:08
ikeyso libdir will be wrong17:09
zygawhat is emul32?17:10
Son_Gokuzyga: it's Solus' term for secondary arch17:10
ikeyi.e. 32-bit library17:10
ikeyno its the proper term17:10
ikeyemul32 == -m32 :P17:10
ikeyyou're emulating 32-bit vdso on x86_6417:11
Son_Gokuwell, -m64 also exists, are you saying that's emul64?17:11
ikeywith -m3217:11
zygais that like x8617:11
ikeybecause you have native binaries and libraries17:11
ikeywell you guys pick a name17:11
Son_Gokuzyga: on multiarch architectures, you can build from the same compiler for 32-bit and 64-bit17:11
ikeyidc what its called :P17:11
zygais that like x86? <- question17:11
Son_Gokuso on x86, you have x86_64 and x86_3217:11
ikey-m32 will spit out x86 on x86_64 toolchain17:11
ikeytechnically i68617:12
ikeybut ya17:12
Son_Gokuon aarch64 you have aarch64 and aarch3217:12
zygaikey: sure, but but that's a compiler switch17:12
Son_Goku(which technically is also known as armv8hnl)17:12
ikeysure and we're talking about biarch here17:12
zygawhat is the relationship to a filesystem path17:12
ikeynot multiarch17:12
ikeybiarch is locked to the notion of -m64 vs -m3217:12
Son_Gokuikey: we could get into x3217:12
zygaikey: I see17:12
ikeywhich is why -m32 is the emulated vdso17:12
* zyga likes multiarch17:12
ikeysomeones gotta :P17:12
Son_Gokuzyga: debian platform libdirs has other issues17:12
zygaeverything has issues17:13
ikeyso what we calling this emul32 dir17:13
ikeyjust lib32 ?17:13
ikeybefore i get dead cats mailed to me from gentoo devs17:13
Son_Gokuikey: --with-lib32-dir, --with-lib64-dir17:13
ikeywhy --with-lib64-dir?17:13
Son_Gokuikey: Gentoo dev dead cat avoidance :)17:13
ikeybut --libdir is the native arch17:13
zygaback to work17:14
Son_Gokuikey: meeeby --with-alt-libdir ?17:14
Son_Gokugod damn naming things is hard :/17:14
Son_Gokufuck it17:15
ikeySon_Goku, "defaults"17:15
ikey#define NATIVE_LIB_DIR "${exec_prefix}/lib"17:15
ikeyi hate your face autotools17:15
zygafat objects17:16
zygathat's so simple :/17:16
Son_Gokuzyga: then make it happen17:16
ikeydon't want your bloat :P17:16
ikeyah mind you i can use -D defines17:16
ikeyfor native libdir17:17
zygaSon_Goku: impossible, no way to reach consensus on something that is x10 nicer and x0.1 slower or more "computer has to do work" vs "humans need to do work" in our our community17:17
zyganiemeyer: can you look at https://github.com/snapcore/snapd/pull/4471/files again please17:17
mupPR #4471: cmd/snap-update-ns: refactor and improve Change.Perform to handle EROFS <Created by zyga> <https://github.com/snapcore/snapd/pull/4471>17:17
niemeyerzyga: Looking17:18
zyganiemeyer: I'm trying to balance it so that I don't have to re-architect my stacked unit tests heavily and we can ship it in 2.31 with confidence; I postponed the idea to check if we need to poke holes17:18
zyganiemeyer: I can do that after this RC because it will have impact on existing unit tests17:18
zyga(sequence of things will change, churn, can cause bugs)17:18
zyganiemeyer: I'll cherry pick the spread test into this PR so that it is really tested17:18
niemeyerzyga: My suggestions would not involve any test changes at all17:18
zyganiemeyer: yes, but we also discussed the idea to look at the filesystem to see if it's read only ahead of time17:19
zygaand those would (we test the syscalls we do)17:19
zyga(the order of syscalls would change and that's churn I want to avoid for 2.31)17:19
niemeyerzyga: I understand.. just saying that the real goal was simplifying it17:20
niemeyerzyga: Rather than changing behavior17:20
Chipacapedronis: do you remember in what situation a task's change could be nil? when looping over all tasks from state17:20
zygayeah, I think it's shorter now, we can go further but I want to not break it17:20
pedronisChipaca: looping how?17:20
zygaI will now look at that spread tets and then at the PR with individual new unit tests17:21
Chipacapedronis: for _, tsk := range st.Tasks() {...}17:21
pedronisChipaca: that should filter out tasks that have no change17:21
pedronissee its code17:21
Chipacapedronis: i see17:21
pedronisit might be we are paranoid in a couple of places because historical reasons17:22
* ikey has a potential fix for that patch now17:22
ikeyjust gonna test it..17:22
* zyga runs the new tests and waits for them to finish17:22
zygatea time :)17:22
Chipacapedronis: in snapstate's CheckChangeConflictMany there's an explicit check for nil which threw me :-)17:22
Son_Gokuikey: thank god no one here cares about /usr/libx32 right now17:22
Chipacai guess that's one of the places17:22
Son_Gokuikey: and yes, that's a thing17:22
pedronisChipaca: I don't think, it's needed nowadays17:22
ikeyi know it is17:22
ikeybut in our context no we dont care17:22
Chipacapedronis: thanks17:23
pedroniswe have the lock and Tasks() check for us17:23
Son_Gokuikey: --with-alt-libdir is the best I can come up with17:23
ikeydoesn't make sense17:23
ikeyits strictly for "im 64-bit and need 32-bit"17:24
* ikey finds out if patches are borked from that17:24
* kalikiana wrapping up for today, can't decide if this was a productive day where trying to fix one bug lead to several other bug reports without solving the first one17:24
Son_Gokuikey, fuck it, --with-32bit-libdir?17:25
ikeycool, didn't hose it17:25
ikeywell my patch has --with-lib32-dir=DIR17:25
ikeyill change17:26
ikeythough im not sure how good autotools is with numeric prefixes?17:26
ikeyguess we'll find out17:26
* Son_Goku groans at autotools17:27
Son_Gokuwhy isn't this Meson already...?17:27
ikey--with-32bit-libdir       -- Use an alternate lib32 directory17:27
Son_Gokuoh right, because 14.04 isn't dead yet17:27
zygaSon_Goku: hold on, what are you tweaking?17:27
ikeyive had to safe guard this change..17:27
ikeyyou'll see in a sec17:28
Son_Gokuikey: I'm guessing it defaults to lib64 and lib32?17:28
ikeynot /quite/17:28
ikeyyou'll also need to change autogen for fedora i imagine17:28
Son_Gokuthat's going to suck17:28
zygaoho, linode handshake timeouts17:28
zygathat's fine, I'll push the spread test on top anyway17:29
ikeySon_Goku, https://github.com/snapcore/snapd/pull/4559/commits/c724c06a6a58e64c0a701cc78f9f5154164abe3217:29
mupPR #4559: snap-confine/nvidia: Support legacy biarch trees for GLVND systems <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4559>17:29
ikeyso instead of assuming /usr/lib, we set native libdir to `--libdir=` from configure time17:29
ikeyi.e. host arch17:29
ikeyif we're 64-bit, we'll then try to mount/copy the 32-bit alt set.17:29
ikeyotherwise don't do anything17:30
Son_Gokuso that looks roughly sane17:30
ikeybecause we could clobber ourselves on 32-bit pure17:30
ikeyits about the only dumb-clever way i can think of right now17:30
Son_Gokuikey: this means you need to add the logic to the Fedora spec :)17:30
Son_Gokuotherwise it can't test :P17:30
ikeyand i cant test fedora17:30
ikeyso idk what you want me to do there17:30
Son_Gokuspread will do that17:30
ikeyhelp a brutha out17:30
Son_GokuI can give you a patch to add to your PR, if that helps17:31
ikeyi wont object17:31
ikeyas long as your autogen uses libdir logic (which it should already) you should be fine17:31
ikeybut for your packaging you'll want to expressly set 32bit-libdir now17:31
ikeyor w/e the hell we caleld it17:31
ikeyas the day closes, so does my mind.17:32
Son_GokuI regenerate the autofoo on every build17:32
niemeyerzyga: Definitely nicer.. sent another round17:32
zyganiemeyer: thanks, looking now17:33
niemeyerzyga: Sorry, please ignore my comment on the for loop17:36
niemeyerzyga: I removed it, but not quickly enough17:36
niemeyerzyga: This is much simpler as a recursive call17:36
zyganiemeyer: ok17:36
zyganiemeyer: I think you reviewed an earlier version I pushed and then I pushed the patches that dropped flags17:36
zyganiemeyer: so some of your questions as in places that got removed now17:36
zygaI'll start with the low hanging fruit and iterate, let's see what remains17:37
niemeyerzyga: Ouch, thanks17:38
zygaerror: received an unexpected http response code (504) when trying to download https://api.snapcraft.io/api/v1/snaps/download/eFe8BTR5L5V9F7yHeMAPxkEr2NdUXMtw_6.snap17:38
zygahmm, store hicckups17:38
Son_Gokuikey: http://kinginuyasha.enanocms.org/downloads/0001-Enable-support-for-handling-the-NVIDIA-proprietary-g.patch17:39
niemeyerzyga: I still don't understand your comment on why lowLevelPerform is there17:39
niemeyerzyga: It's a very awkward side effect whihc would be nice to avoid17:39
ikeywhat in the shite is that17:39
zyganiemeyer: mount and umount don't care if the medium is read only17:39
zyganiemeyer: symlink needs to drop a new inode17:39
niemeyerzyga: You say file creation relies on existing inodes, which doesn't make a lot of sense to me17:39
zyganiemeyer: it is there to triggere the read-only-filesystem fallback17:39
ikeySon_Goku, honestly i dont feel comfortable applying that which i dont know17:39
Son_Gokuikey: a patch you apply with git-am ?17:39
ikeybut everyone saw that Son_Goku made me do it17:40
Son_Gokuikey: unconditionally turns on nvidia-biarch17:40
zygaoh, did I, sorry, I meant mounting17:40
Son_Gokuand also sets the libdir in arches that are configured for multilib17:40
niemeyerzyga: I realize it's there for that reason.. I don't understand why it's there for that reason17:40
ikeyi pushed it Son_Goku and now we'll wait for the sound of screams17:40
ikeycheers :]17:40
Son_Gokuwell, I'm a dumbass17:41
zyganiemeyer: right, the reason is that the code is like <create inodes><handle read only and retry><mount>17:41
Son_Gokuikey: can you fix the title of the patch17:41
Son_Gokuit should be prefixed with "packaging/fedora:"17:41
zyganiemeyer: both mount and create symlinks is in the low-level part17:41
niemeyerzyga: Again, per above, zyga: You say file creation relies on existing inodes, which doesn't make a lot of sense to me17:41
zyganiemeyer: now if you had a path like /rofs/symlink -> target17:41
zyganiemeyer: ^ (I meant *mounting*, not file creation)17:42
ikeySon_Goku, but17:42
ikeybut i pushed it17:42
Son_Gokurewrite it :P17:42
zyganiemeyer: and assuming that /rofs exists17:42
ikeyand they get angry when i force push17:42
Son_Gokujust do it17:42
ikeybut they can hear us17:42
zyganiemeyer: that won't do anything in the <create inodes> part17:42
zyganiemeyer: it will proceed to c.lowLevelPerform where we just create the symlink17:42
niemeyerzyga: Again, can we please talk about the difference between these branches17:42
zyganiemeyer: and that's when we will notice EROFS17:42
niemeyerzyga: how can  +err = secureMkfileAll(path, mode, uid, gid)17:42
ikeyzyga, humbly request permission to force push fixed patch to PR17:42
niemeyerzyga: do the right thing, but  +err = secureMkdirAll(path, mode, uid, gid)17:43
ikeySon_Goku, but now your commit message is too long17:43
ikeyima leave it. :317:43
zyganiemeyer: those both do the right thing, the problem is not between directories and files but between the actual symlink at the end of some directories;17:43
niemeyerzyga: I see.. so this links with the other part of the code17:43
niemeyerzyga: Regarding the comment below on "Curious that this isn't the case for files. What's the catch?"17:44
zygahold on, I didn't read that comment yet17:44
Son_Gokuikey: noooo17:44
niemeyerzyga: Looks like a special case is creating more special cases17:44
ikeylol @ describing hacker news17:45
Son_Gokuikey: http://kinginuyasha.enanocms.org/downloads/0001-packaging-fedora-Enable-support-for-the-NVIDIA-propr.patch17:45
Son_Gokuthere, fixed title17:45
ikeybut it runs off17:45
zyganiemeyer: files and directories are completely created by secureMk* helpers, you end up with the complete thing, the error is correct if something goes wrong17:45
ikeylike a terrified thomas the tank engine suddenly bereft of child to push it17:45
niemeyerzyga: I understand :)17:45
Son_Gokuikey: it won't run off in GH17:45
zyganiemeyer: for symlinks we don't have a helper like that, we use the secure dir helper to create the parent, that's it17:45
Son_Gokuand that's all that matters :)17:45
ikeySon_Goku, but zyga didnt give me a yay17:46
niemeyerzyga: These comments are supposed to raise awareness and discuss ceratin things17:46
Son_Gokuzyga: >:|17:46
niemeyerzyga: I can tell that createFlie creates a file :)17:46
Son_Gokudamn it, I've burned my entire lunch period on this :(17:46
Son_GokuI gotta go get food17:46
niemeyerzyga: In this case, we have a special case that chains up into more special cases, which cause functions to be called in different places, which creates more special cases17:47
ikeydisappear, its not like i do anything or go anywhere17:47
niemeyerzyga: This is part of the reason why we get white hair17:47
zyganiemeyer: but we reuse code that was reviewed for security, this is deliberate17:47
niemeyerzyga: /o17:47
zyganiemeyer: I think it can be simplified but post 2.31, by doing the "look before you try"17:47
zygathen we can drop the low-level perform exception paths17:47
zygaand the special case for symlink will go away17:48
niemeyerzyga: We can do whatever we want later, sure.. but we want this logic to not suck to begin wiht17:48
niemeyerzyga: https://hangouts.google.com/hangouts/_/canonical.com/snappy-devel?authuser=117:49
niemeyerThat's also part of why we get white hair17:50
zyganiemeyer: can you hear me17:50
cachiozyga, I am installing uuid-runtime package in a snap and it is not starting the uuid daemon17:55
cachiozyga, should it happen automatically as if I install the deb package, or I need to manually do it ?17:55
sergiusenshow do I debug this error "error: cannot install snap file: snap is unusable due to missing files; contact developer"... I am the developer :-)18:03
niemeyersergiusens: Looks like you have a completely broken snap18:05
niemeyersergiusens: you should use snapcraft ;P18:05
bdxhey, random question, has the concept of "serverless snaps" ever been discussed?18:08
zygacachio, ikey, Pharaoh_Atem: I if you can wait for a few quarters I would like to finish this branch for 2.31 first please18:09
cachiozyga, sure18:09
naccbdx: what do you mean by that?18:09
cachiomvo,  I am installing uuid-runtime package in a snap and it is not starting the uuid daemon18:09
ikeylike, a few quarters would be years18:09
* ikey is puzzled18:09
cachiomvo, should it happen automatically as if I install the deb package, or I need to manually do it ?18:09
naccPharaoh_Atem: ikey was responding to zyga18:10
cachiomvo, should I do it with the configure hook?18:10
zygahmmm hmm sorry,18:10
bdxnacc: like a snap that is built to run on a serverless architecture18:10
Pharaoh_Atemnacc: I was highlighted too?18:10
zygaI meant few multiples of 15 minutes18:10
zygahow do I say that properly?18:10
Pharaoh_Atemquarters is right, it's just no one says it18:10
Pharaoh_Atemin that context18:10
ikeyidk id say like "half hour" "45 minutes" "feck off im busy"18:11
cachiomvo, or in a wrapper?18:11
* zyga hugs ikey 18:11
zygaikey: yes, go push18:11
naccbdx: you mean without a store?18:11
* ikey doesn't do normal though18:11
zygacachio: dunno, I will check soon, if you need uuid's you don't need a daemon tho, maybe there's a cheaper way?18:11
* ikey coughs while -f goes through18:12
cachiozyga, I want to test that18:12
niemeyernacc: No, he's likely thinking of Google AppEngine, Amazon Lambda, etc18:12
naccniemeyer: oh18:13
naccniemeyer: seems like you'd have a better answer for that than me :)18:13
niemeyerbdx: The purpose of snaps is to install software on a machine, so it's not a great fit for the idea of not having a machine. With that said, ...18:13
bdxtake aws lambda for example18:13
niemeyerbdx: We've been working from day one with the idea of minimalist operating systems that are built entirely around the idea of snaps18:14
bdxahh I guess it wouldnt be a snap because a snap needs snapd huh18:14
bdxahh I see18:14
niemeyerbdx: That's what Ubuntu Core is, for example.. there's very little other than snaps in the machine18:15
ogra_cachio, cat /proc/sys/kernel/random/uuid18:15
ogra_(if your snap has access to that node indeed)18:15
bdxniemeyer: totally, I see18:15
niemeyerbdx: Even the root filesystem itself is a snap, so read-only and mostly unchangeable18:15
* ikey suddenly twigs that all parts of ubuntu core are segregated into domains with ACL and is impressed18:16
zygacachio: test the daemon?18:16
bdxI see18:16
zygaogra_: yep, thanks! cachio, that was my suggestion (I didn't spell it out)18:16
cachiozyga, I need to see if the daemon is able to read from /run/uuidd/request18:17
ogra_cachio, then our snap will need an app entry for the daemon18:17
ogra_in snapcraft.yaml18:17
zygacachio: I see, that's for some interface test?18:18
cachiozyga, yes18:18
bdxnacc, niemeyer: it was just a wild idea, I've been using lambda quite a bit lately, and getting to put my eyes on how the packaging is done via different serverless frameworks18:18
mupPR snapd#4569 opened: osutil: add ContextWriter and RunWithContext helpers <Created by chipaca> <https://github.com/snapcore/snapd/pull/4569>18:18
naccbdx: sure, interesting question18:18
cachioI have the service script in /etc/init.d/uuid18:19
ogra_yeah, not useful18:19
ogra_check what the iit.d script calls and translate that into an app entry18:20
ogra_see the bottom of  https://forum.snapcraft.io/t/how-to-set-hwclock-on-a-realtime-clock/368418:20
sergiusensniemeyer thanks for getting back to me, I stripped everything and even simplified the command https://paste.ubuntu.com/26490731/ (I am beta for core btw)18:20
sergiusensI still see the issue18:20
niemeyerbdx: Yeah, it's a nice idea, but that kind of platform almost always requires custom coding towards it18:20
niemeyerbdx: Which conflicts a bit with the underlying goal of snaps.. snaps need to support people's software as their developers choose to work18:21
niemeyerThis is also an advantage, as the approach encourages less lock in18:22
bdxright, i see that, but what if there was a "snap type"18:22
bdx lets say, a "serverless" snap type, would package for a targeted serverless platform18:23
niemeyerbdx: Sure, that would work fine.. but most of the problem of creating a "serverless" platform is still there18:24
bdxzappa (though young) has an interesting approach of just swapping out the packages with ones for the target serverless platform (just aws right now)18:24
cachioogra_, trying that, tx18:24
bdxbut other serverless frameworks will build the deps on a docker target platform and etc etc18:24
niemeyerbdx: I doubt it18:24
niemeyerbdx: The hard problem in serverless is the software lifecycle.. you want something lightweight, and you need to control when it comes and goes very tightly.. often you need to be in the loop for controlling sockets, etc, because you don't want these aspects to be visible to the world18:26
bdxah yes18:26
niemeyerbdx: You can put that software inside a snap, docker image, rpm, deb, tarball.. it matters little18:26
niemeyerbdx: It ends up just as an implementation detail on something that you need to cook for from the ground up18:27
niemeyerbdx: You could use snaps as a lightweight confined space for the application, but that would be 3% of the problem IMO18:27
bdxso I have snap/ dir in my projects now, and also a serverless.yml file ... I feel like the packaging the serverless frameworks are doing is such small subset of what snapcraft can do18:28
bdxjust an idea18:29
bdxniemeyer: thanks for the insight18:30
bdxnacc: ^18:31
niemeyerbdx: No problem.. and yeah, the packaging is indeed the easy part of serverless, but it's also the hard part of solving software distribution18:31
niemeyerbdx: We focus on the latter18:31
bdxI see that, totally18:31
niemeyerbdx: As a side note, I deploy all of the services I'm responsible for as snaps in tiny machines18:31
niemeyerbdx: Not serverless, but cheaper than serverless, and almost as neat18:32
niemeyerbdx: and nicer, from the perspective of giving me freedom of technology18:32
ikeyyay for marketing misnomers18:32
bdxneimeyer: totally18:32
zygaikey: I will drop my job and work electricityless cloud18:33
niemeyerikey: It's like "sugar free".. :)18:33
zygaI will call it "BYOM"18:33
ikeyniemeyer, nah that one makes sense18:33
ikeythey don't charge you any extra for the sugar18:33
niemeyerikey: Until you figure what they use instead18:33
zyganiemeyer: please have another look18:34
zyganiemeyer: I'll double check I didn't miss anything18:34
niemeyerzyga: Thanks18:34
ikeybtw apparmor made my boot slow. :P18:34
ikeyits half of my boot time in a VM now18:34
zygaI will do the proper secure symlink next, though it won't affect this code, just the implementation of secureMklinkAll18:34
ogra_assertions assertions ...18:34
zygaikey: caching can be improved18:34
ikeyim tackling it this week18:34
zygaikey: apparmor has a cache, maybe you're not using it?18:34
ikeysolus isn't known for slow boot lol18:34
zygaikey: each time a profile is compiled it can (optionally) be cached18:35
zygaikey: also loads can use cache (even exclusively, without compilation)18:35
ikeyya im gonna teach usysconf to recompile them18:35
ikeyand then an early unit to load the cache18:35
ikeyalready got plans, just wanted to complain :P18:35
zyganiemeyer: I think it's all done (except the ", or create" typo I didn't push to let this spread batch finish)18:38
zyganiemeyer: I'll work on itty bitty more secure mksymlink now that I have it un utils18:38
zyganiemeyer: oh, and one more thing, please look at the new spread test as well18:39
zygaI'll warm my tea up and be back in a moment18:39
niemeyerzyga: Haven't seen the test, but what I've seen look GREAT, thank you!18:40
niemeyerzyga: Just one final note there and LGTM18:40
zyganiemeyer: thank *you* :)18:40
zyganiemeyer: that's not an error there, it's a "was it present" flag, I guess we can just error out if it's empty but we don't usually do that kind of validation here (we just try and fail)18:44
niemeyerzyga: I don't understand what the code is suggesting right now18:46
niemeyerzyga: It surely doesn't seem sensible to create symlinks with completely wrong values18:47
niemeyerzyga: Sending garbage to the kernel for validation is unwise18:47
zygaChipaca: problem with snap validation (CC sergiusens)18:49
sergiusensposted to the forum18:51
zygamvo: ^ we may need rc3 if we relase with this bug18:52
zyganow that this is approved I will pull in unit tests, too many changes for critical feature not to test this18:53
zygaI'll make a separate PR and mark it for 2.3118:53
zygamvo: do you plan to release tonight?18:53
sergiusensstgraber Odd_Bloke the simplestream images on Ubuntu seem to have lost their aliases (lxc launch ubuntu:xenial works no longer, does by hash)19:06
sergiusenssorry, bad first root causing of that, there are aliases, but `lxc launch ubuntu:xenial` does not work, using `images:` does19:09
sergiusensconfirmed that the aliases are there `lxc image info ubuntu:069b95ed3a60`19:10
zygaah, I know what I broke now ^_^19:13
sergiusensstgraber a reinstall of the snap solved it, but I disabled ipv6 and switched from zfs to dir19:14
cprovelopio: when you have a minute, can you take a look at https://travis-ci.org/snapcore/snapcraft/jobs/335296918 ? I am trying to fix the snapstore pre-rollout checks (broken since snapcraft started using stages). Apparently I have no access to the cache where the snapcraft is stored.19:23
elopiocprov: yes, give me a minute. I'm sorry we broke you :S19:31
cprovelopio: no worries, in theory, it's much simpler to do what we need now19:32
elopiocprov: I'm not quite sure, because we were able to use the cache by not using the environment variables. I totally forgot that you sent environment variables to set the credentials.19:33
elopiomaybe it's that. I'm digging into the logs.19:34
cprovelopio: `error: cannot open: "snaps-cache/snapcraft-prfalse.snap"` from `sudo snap install snaps-cache/snapcraft-pr$TRAVIS_PULL_REQUEST.snap --dangerous --classic`, I assume19:35
elopiocprov: can you show me the script that you are calling to trigger the api?19:36
cprovelopio: moreover I don't think we need the snapcraft snap installed to run `snapcraft/tests/integration/store` tests, do we ?19:37
elopiocprov: yes, it uses the snapcraft command. What you don't need is to build the snap, you could just install from edge.19:38
elopiocprov: but this one is different than the one you linked: https://travis-ci.org/snapcore/snapcraft/builds/335153368 I was wondering if you are doing something to select the stage.19:38
cprovelopio: the job you linked was the 'old' way that didn't consider stages, it was running everything and taking 4h+19:40
elopioright. We could readd the skips, and make sure that we install from edge, not from cache.19:42
elopiocprov: so, you added that "stage" keyword?19:45
* zyga eats supper, secure symlink helper almost done :)19:45
mupPR snapcraft#1893 opened: cli: use C.UTF-8 if locale not set <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1893>19:46
cprovelopio: yes, I am overriding 'jobs' completely, but the 'cache' config is preserved, I think I just don't have perms to access it19:47
elopiocprov: what would you think about this? https://paste.ubuntu.com/26491166/19:53
elopioyou send SNAPCRAFT_COMMAND_INSTALL="sudo snap install snapcraft --edge --classic"19:53
Chipacasergiusens: journalctl -u snapd | grep container <- should show you the errors from 'snap try'19:55
Chipacasergiusens: I'll push a PR to make snap try log to stderr instead of journal, I think19:55
Chipacabut not today, mostly because I think it might be tricky :-)19:56
ali1234is there an example of snapping a php/composer application?19:56
cprovelopio: looks good, let me know when it lands in trunk19:56
zygare, :)20:05
zygaone last patch and I'm goooood :)20:05
zygaand I celebrate20:05
elopiokyrofa: cprov: https://github.com/snapcore/snapcraft/pull/189420:07
mupPR snapcraft#1894: tests: allow to overwrite the snapcraft install command <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1894>20:07
elopioplease double check my bash ^_^20:07
mupPR snapcraft#1894 opened: tests: allow to overwrite the snapcraft install command <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1894>20:08
stgrabersergiusens: hmm, might have been a bad cache of the streams, would have self-corrected after an hour, restarting the daemon (systemctl reload snap.lxd.daemon) would also have done the job if that was the issue20:25
zygathere is no syscall.Symlinkat in golang20:25
zyga.. but why golang, why :/20:28
Chipacazyga: because it's in x/sys/unix20:32
Chipacazyga: but before you get too excited, that means it's not buildable on ppc20:33
zygaChipaca: I just found https://github.com/golang/sys/blob/master/unix/zsyscall_linux_amd64.go#L11120:33
zygathank you for pointing out x/sys/unix, let me see if it works20:34
zygaI need it20:34
zygaor I need that single generated function20:34
Chipacazyga: grab the generated one for now until we drop ppc20:34
zygaChipaca: yeah, sounds like a plan20:35
Chipacazyga: but20:35
Chipacazyga: SYS_SYMLINKAT will be per-something20:35
Chipacabut you have a ppc box so you should be able to figure it out20:36
zygahehe yes :)20:36
zygait's allright20:36
Chipacathe weirder ones might require you go grep includes :-)20:37
zygaChipaca: or ... you know... put -20:37
zyganot that someone will test them, right?20:37
Chipacazyga: autopackagetest is a harsh mistress20:38
Chipacahaven't seen it fail in too long, already forgetting its face20:38
mvoChipaca: hey, this `snap try` issue from the forum, what is your take on it? sorry, missed some discussion so just want to get up-to-speed20:38
zyga // mksyscall.pl -tags linux,amd64 syscall_linux.go syscall_linux_amd64.go20:38
Chipacazyga: ideal for the job20:39
zygaChipaca: ... but... python20:39
Chipacafrobbing text? hell yeah perl20:39
zygahell no cobol20:39
Chipacazyga: not as widely available as perl20:39
zygait's like cobol but misassociated wiht the text tool20:39
zygaChipaca: not buying that20:39
Chipacamvo: the snap wouldn't work with the older snapd20:39
zygaChipaca: especially at google where they don't give a *** about non google arches20:39
Chipacamvo: (i know not only because i wrote the verifier, i also checked :-) )20:40
Chipacazyga: ¯\_(ツ)_/¯20:40
mvoChipaca: ok, so anything that needs to be done for 2.31 there? or can I ignore it for 2.31?20:40
Chipacazyga: you work for a company that doesn't give a flying asterisk for some architectures, but you still don't paint yourself into a corner just in case the company has a change of heart20:40
zygaChipaca: I mean python works anywhere, BSDs, windows, macos, you name it20:41
Chipacamvo: there's an argument for making 'snap try' write the errors to stderr for the same reasons 'snap pack' does20:41
zygait's not like it's less portable than perl20:41
zygaand people who write competent perl are ... older20:41
Chipacazyga: you're talking about people that worked on the implementation of plan 920:41
mvoChipaca: that sounds reasonable, is that something I should wait for? i.e. will it happen soon(ish)?20:42
Chipacazyga: I don't think they think perl is for older people20:42
zygathat's a very valid point20:42
mvoChipaca: i.e. before tomorrow lunchtime :)20:42
zygaChipaca: perl is that new thing :)20:42
Chipacamvo: it's not going to be a simple change20:42
mvoChipaca: ok, then I will not wait20:42
mvoChipaca: out of curiosity, why is it not simple?20:42
Chipacamvo: there's another argument for changing the error message20:42
Chipacamvo: but nobody has suggested changing it to _what_ :-)20:42
Chipacamvo: because 'snap try' is async, meaning the logs would need to get shipped, and it might mean we need to make the roundrobin logs in tasks be bigger, and some tweaks to how 'wait' prints them20:43
mvoChipaca: meh, sounds horrible. ok20:43
zygaChipaca: just error with the 1st error :)20:44
Chipacatasks have logs, but they're either informational (in which case if you miss printing them, oh well), or errors in which case they're not changing (because the thing died)20:44
mvoChipaca: I will ignore this for now until I'm told otherwise. especially if this is a broken snap (not a false positive)20:44
ChipacaI _could_ make the whole thing die, yes20:44
zygaChipaca: we don't vendor x/sys/unix today, do we?20:44
Chipacareturn strings.Join(allTheErrors, " ¯\_(ツ)_/¯ ")20:44
zygait'd be a re-addition?20:45
mvoChipaca: its all good, I need to rest anyway20:45
Chipacazyga: it does not build on ppc20:45
cachio_mvo, is rc2 comming?20:45
zygameh meh20:45
mvocachio_: :( tomorrow, sorry20:45
zygaI think today is my time20:45
Chipacazyga: i'm sure they take patches though20:45
zygaI'll watch and merge 447120:45
mvocachio_: there is this one PR from zyga  that we want in20:45
zygaand fight the symlinkat problem tomorrow20:45
zygaChipaca: as self-documenting perl files ;)20:45
cachio_mvo, sure20:45
Chipacazyga: hey, i've written literate perl20:46
Chipacazyga: wait20:46
Chipacazyga: you called me old!20:46
* Chipaca is old20:46
* zyga is old 20:46
* zyga hugs Chipaca 20:46
* mvo hugs Chipaca and zyga 20:47
* Chipaca hides http://ftp.tudelft.nl/cpan/authors/00whois.html20:47
* cachio_ laugh20:47
zygaOMG :D20:47
zygathe journey of each generation20:48
Chipacathe internet does not forget20:48
zygaI'll break now20:49
zygatravis is stuck20:49
zygaplease merge 4471 if green20:49
pedronisChipaca: did you see the original code was about java and PATH: $SNAP/... ? I suppose it doesn't change anything20:59
Chipacapedronis: yes; the commands are not looked up in the path20:59
Chipacathat seems to be the source of the problem21:00
Chipacaor rather, of the misunderstanding21:01
Chipacasergiusens: you around?21:24
Chipacazyga: 4471 not green21:31
Chipacagetting lots of failed prepare project :-(21:31
zygayeah :/21:31
zygaI'm watching21:31
zygalike a western with intense action :///21:32
sergiusensChipaca at the snapcraft summit currently, might be faster if we do a call21:38
Chipacasergiusens: I should be in bed. Tomorrow?21:39
sergiusensChipaca ok; also tired the completer changes using the snap name and it still doesn't work; I'll send you the link to the built snap21:41
Chipacasergiusens: thanks21:41
sergiusenstabs are for UI purposes21:41
Chipacasergiusens: _vertical_ tabs?21:41
sergiusensChipaca yes21:42
Chipaca013 is \v is vertical tabs; a very strange choice (but then, if that's indeed what they're doing, it should be fine)21:42
Chipacaok :-)21:42
zyga+ tar -C/ -xf /home/gopath/src/github.com/snapcore/snapd/snapd-state.tar.gz21:44
zygatar: /home/gopath/src/github.com/snapcore/snapd/snapd-state.tar.gz: Cannot open: No such file or directory21:44
Chipacazyga: everything is terrible21:49
zygaChipaca: mvo will _love_ the release tomorrow21:50
zygawililupy: 1121:50
zyga(also known as window 11)21:50
zygawililupy: sorry, bad tab completion21:53
wililupyzyga: no worries ha21:53
mupPR snapcraft#1895 opened: docker: beta should use beta, edge use edge <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1895>22:20
mupPR snapcraft#1894 closed: tests: allow to overwrite the snapcraft install command <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1894>22:32
mupPR snapcraft#1893 closed: cli: use C.UTF-8 if locale not set <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1893>22:38
mupPR snapcraft#1895 closed: docker: beta should use beta, edge use edge <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1895>22:41
cprovsergiusens: thanks, let me try the test suite hack22:44
naccso i've got a snap (git-ubuntu) that builds its own python3 (we need a version more recent than 16.04's)23:28
naccwhat is the "right" way to CI the code upstream so that our tests are running against hte version in the snap23:28
mupPR snapcraft#1896 opened: elf: do not strip rpaths that contain $ORIGIN <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1896>23:41
mupPR snapcraft#1897 opened: docker: user proper tags in Readme.md <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1897>23:56

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!