| mup | PR 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 |
|---|---|---|
| cachio | jdstrand, I have requested manual review for the other architectures of snap test-snapd-gpio-memory-control | 01:50 |
| cachio | jdstrand, when you have a minute, could you please approve them | 01:50 |
| cachio | tx | 01:50 |
| jdstrand | cachio: done | 02:18 |
| cachio | jdstrand, tx | 02:47 |
| mup | PR snapd#4563 opened: tests: new spread test for gpio-memory-control interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4563> | 04:38 |
| mborzecki | morning | 06:01 |
| mborzecki | forum is down? | 06:40 |
| mborzecki | mvo: morning | 06:41 |
| mvo | mborzecki: good morning | 06:48 |
| mvo | mborzecki: yeah, looks down from here as well | 06:48 |
| * mvo still needs a review for 4342 | 06:53 | |
| zyga-ubuntu | good morning | 06:55 |
| zyga-ubuntu | https://github.com/snapcore/snapd/pull/4560 is ready for 2nd review | 06:55 |
| mup | PR #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-ubuntu | and I'll work on breakfast for kids, see you soon | 06:55 |
| mup | PR 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 |
| mvo | zyga-ubuntu: I already commented, one tiny nitpick about a comment but that should be a followup, no need to hold this PR back | 06:57 |
| mvo | zyga-ubuntu: I need a review for 4342, its blocking ~rc2 currently | 06:57 |
| zyga-ubuntu | I know, I will do your review after kids go to school | 07:00 |
| mvo | ta | 07:00 |
| mborzecki | zyga-ubuntu: morning | 07:02 |
| zyga-ubuntu | oka | 07:22 |
| zyga-ubuntu | daughter is all set and ready for school | 07:22 |
| zyga-ubuntu | mvo: thank you for the feedback, I'll update the PR and merge it | 07:23 |
| zyga-ubuntu | ah, it's merged now :) | 07:26 |
| zyga-ubuntu | k, looking at that zenity branch | 07:26 |
| zyga-ubuntu | mvo: btw, I'm very sorry for not looking at it yesterday, I saw your requests but I was busy with the feedback from gustavo | 07:27 |
| zyga-ubuntu | mvo: will you do a RC3 for 2.31? | 07:27 |
| mup | PR snapd#4564 opened: data/systemd: tweak comment <Created by zyga> <https://github.com/snapcore/snapd/pull/4564> | 07:27 |
| zyga-ubuntu | mvo: I really want to land 4471 today | 07:27 |
| zyga-ubuntu | mvo: and make it into the release | 07:27 |
| zyga-ubuntu | otherwise we should probably back out the new content interface features | 07:27 |
| zyga-ubuntu | gustavo approved the design but requested tweaks on how that code operates to drop the helper function (tryIt etc) | 07:28 |
| mvo | zyga-ubuntu: if 4471 is ready today +1, if not I think we need a revert PR | 07:28 |
| mvo | zyga-ubuntu: how was the feedback yesterday? all looking good to fix it today? | 07:28 |
| zyga-ubuntu | mvo: yes | 07:29 |
| bashfulrobot | Is the forum down for anyone else? Nginx 502 bad gateway. | 07:29 |
| zyga-ubuntu | mvo: I need to inline that function back | 07:29 |
| zyga-ubuntu | mvo: nothing major | 07:29 |
| mvo | ok | 07:29 |
| zyga-ubuntu | bashfulrobot: it's down for me too | 07:29 |
| bashfulrobot | zyga-ubuntu thanks for the confirmation! | 07:30 |
| zyga-ubuntu | woah, the wind today is very strong | 07:35 |
| zyga-ubuntu | trees are swinging like grass! | 07:35 |
| zyga-ubuntu | jdstrand: are you in US or still sprinting somewhere? | 07:52 |
| oSoMoN | good morning | 07:56 |
| oSoMoN | I'm getting a 502 on forum.snapcraft.io | 07:56 |
| oSoMoN | is it just me? | 07:56 |
| zyga-ubuntu | no, it's everyone | 07:56 |
| mvo | jdstrand: if you could moderate the updated base-18 in the store that would be great | 08:01 |
| zyga-ubuntu | mvo: what is %[1]q - is that golang syntax for fmt? | 08:08 |
| zyga-ubuntu | hey there spineau | 08:09 |
| spineau | morning zyga-ubuntu | 08:10 |
| zyga-ubuntu | mvo: nitpick 2018 in your new files | 08:11 |
| pstolowski | mornings | 08:11 |
| zyga-ubuntu | hey pawel | 08:12 |
| pstolowski | the forum is borked? | 08:12 |
| zyga-ubuntu | yes | 08:13 |
| zyga-ubuntu | mvo: so I get what \0 is but \00 ? is that the same thing or {'\0', '0'} in C syntax? | 08:13 |
| zyga-ubuntu | man, today is windy :/ | 08:14 |
| kalikiana | sliff | 08:14 |
| mvo | zyga-ubuntu: %[1]q is fmt syntax | 08:15 |
| mvo | zyga-ubuntu: \00 should be \0, let me check, maybe I made a silly mistake | 08:15 |
| zyga-ubuntu | mvo: at line ... 43 and 44 | 08:16 |
| zyga-ubuntu | mvo: so meta-comment, nothing -1, I want to play with it | 08:17 |
| zyga-ubuntu | but we need the desktop team to help and I don't know, roll this into gnome settings | 08:17 |
| zyga-ubuntu | or into other appropriate place | 08:17 |
| zyga-ubuntu | right now it feels like a hack that keeps us walking till we can run | 08:17 |
| pstolowski | mvo, hey, shall I squash #4440 for easy cherry-picking into 2.31? | 08:18 |
| mup | PR #4440: state: unknown tasks handler <Created by stolowski> <https://github.com/snapcore/snapd/pull/4440> | 08:18 |
| mvo | pstolowski: its fine as is, I looked over master this morning and all is fine for .31 | 08:18 |
| pstolowski | mvo, ok | 08:19 |
| mvo | zyga-ubuntu: aha, sorry. this should read \0\0 | 08:19 |
| mvo | zyga-ubuntu: i.e. a double \0 marks the end of a command | 08:19 |
| mvo | zyga-ubuntu: let me fix this | 08:19 |
| zyga-ubuntu | thank you! | 08:20 |
| * zyga-ubuntu reads rest | 08:20 | |
| mborzecki | zyga-ubuntu: hmm looking at 4565 i was wondering why i'm ending up with snap.mount on arch | 08:21 |
| ackk | mvo, hi, it seems there was an issue uploading the base-18 build: https://code.launchpad.net/~mvo/+snap/base-18/+build/138724 | 08:21 |
| mup | PR snapd#4440 closed: state: unknown tasks handler <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4440> | 08:21 |
| mborzecki | zyga-ubuntu: turns out i'd really like to switch data to autotools | 08:22 |
| zyga-ubuntu | mborzecki: no objection, fire a PR and let's do it | 08:22 |
| zyga-ubuntu | mvo: and in strings, is \000 just {'\0'} or is it something else | 08:36 |
| zyga-ubuntu | e.g. here: +call = strings.TrimSuffix(call, "\000") | 08:36 |
| mvo | ackk: yeah, I ask jamie to moderate the upload, it is currently stuck in the review queue | 08:45 |
| mvo | zyga-ubuntu: this should be \0 as well, sorry for this | 08:46 |
| ackk | oh ok, thanks | 08:46 |
| zyga-ubuntu | mvo: did you run it in practice? | 08:50 |
| mvo | zyga-ubuntu: just running the tests | 08:54 |
| mvo | zyga-ubuntu: but the zenity tests use \n in their args | 08:55 |
| mvo | zyga-ubuntu: so it should work | 08:55 |
| zyga-ubuntu | mvo: how about setting this thing in practice, getting the prompt and all of that | 08:55 |
| * zyga-ubuntu is still reading the code | 08:55 | |
| sparkiegeek | do we have to wait for niemeyer to get the forum back up? | 09:04 |
| zyga-ubuntu | sparkiegeek: I'm afraid so, we're not sure what caused it | 09:07 |
| mvo | zyga-ubuntu: I tested this with the brave browser | 09:10 |
| mvo | zyga-ubuntu: sorry for the delay in answering | 09:10 |
| mvo | zyga-ubuntu: if that is what you mean with "testing in practise" or do you mean something else? | 09:10 |
| zyga-ubuntu | no that's fine | 09:15 |
| zyga-ubuntu | did you test both kde and non-kde paths? | 09:15 |
| mvo | zyga-ubuntu: yeah, i tested once with kdialog and once with zenity | 09:20 |
| mvo | zyga-ubuntu: I think mborzecki has a point that ideally it would check the desktop env too, I can make a PR for that too | 09:21 |
| zyga-ubuntu | mvo: yeah, I responded to that part as well | 09:21 |
| * kalikiana coffee | 09:21 | |
| zyga-ubuntu | mvo: reviwed | 09:22 |
| zyga-ubuntu | reviewed* | 09:22 |
| zyga-ubuntu | mvo: can you have a quick look at https://github.com/snapcore/snapd/pull/4564 please | 09:23 |
| mup | PR #4564: data/systemd: tweak comment <Created by zyga> <https://github.com/snapcore/snapd/pull/4564> | 09:23 |
| zyga-ubuntu | let's either merge it or tell me to tweak the install code | 09:23 |
| mup | PR snapd#4564 closed: data/systemd: tweak comment <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4564> | 09:25 |
| mvo | zyga-ubuntu: I think its fine, we can always tweak further | 09:25 |
| zyga-ubuntu | thanks! | 09:25 |
| pedronis | hi, is the forum down (502) ? | 09:26 |
| zyga-ubuntu | yes | 09:26 |
| zyga-ubuntu | I think we need a post mortem on the forum and some plan for gustavo being on holidays | 09:26 |
| zyga-ubuntu | *cough* IS *cough* | 09:26 |
| zyga-ubuntu | kalikiana: https://regexper.com/ | 09:29 |
| mborzecki | `/home/ubuntu/goroot/pkg/tool/linux_386/link: running gcc failed: exit status 1` uhh not my lucky day | 09:31 |
| zyga-ubuntu | mborzecki: it's your NaNth lucky day | 09:32 |
| mborzecki | oh hey, also gnome-shell crashed out of the blue | 09:33 |
| mborzecki | pff strace to the rescue: [pid 8615] write(2, "/usr/bin/ld", 11) = -1 ENOSPC (No space left on device) | 09:33 |
| zyga-ubuntu | uhh | 09:34 |
| zyga-ubuntu | careful with those torrents | 09:34 |
| zyga-ubuntu | qemu can eat a lot of space on -snapshot | 09:34 |
| mborzecki | zyga-ubuntu: it's xenial cloud image | 09:35 |
| * zyga-ubuntu takes a break to look through bugs befor jumping onto PR feedback | 09:35 | |
| mborzecki | didn't know those are 2gb | 09:35 |
| zyga-ubuntu | hey Chipaca! | 09:35 |
| zyga-ubuntu | mborzecki: uh | 09:35 |
| mborzecki | Chipaca: morning | 09:35 |
| Chipaca | mborzecki: zyga-ubuntu: hiya | 09:36 |
| zyga-ubuntu | pstolowski: can you please look at https://bugs.launchpad.net/snapd/+bug/1611638 | 09:36 |
| mup | Bug #1611638: snap upgrade hook <snapd:Fix Committed> <snapd (Ubuntu):Fix Committed> <https://launchpad.net/bugs/1611638> | 09:36 |
| zyga-ubuntu | I think it's fixed so we can just update the bug but I wanted you to confimr | 09:36 |
| zyga-ubuntu | *confirm even | 09:36 |
| pstolowski | zyga-ubuntu, looking | 09:37 |
| kalikiana | zyga-ubuntu: Hmmm looks quite nice. Although it seems very "analyze afterwards". It's not live and there's no test string | 09:38 |
| zyga-ubuntu | mborzecki: I assigned a bug about testing on arch to you (since you're doing that anyway) | 09:38 |
| zyga-ubuntu | kalikiana: yeah, not perfect but it's nice to see those cute railroad diagrams | 09:39 |
| mborzecki | zyga-ubuntu: ack | 09:41 |
| pstolowski | zyga-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.31 | 09:43 |
| zyga-ubuntu | pstolowski: perfect, thank you! | 09:44 |
| * Chipaca carries on refactoring unseen code | 09:45 | |
| zyga-ubuntu | Chipaca: I do that a lot though sometimes I think I'm doing the coding version of modern art ;) | 09:49 |
| Chipaca | zyga-ubuntu: not art, but craft | 09:49 |
| Chipaca | zyga-ubuntu: the difference is mostly around how we get paid :-) | 09:50 |
| zyga-ubuntu | haha | 09:51 |
| mborzecki | art is when you don't get paid | 09:51 |
| zyga-ubuntu | I often write a piece of code and the refactor it, sometimes many many times, before sending out the first PR | 09:52 |
| zyga-ubuntu | pstolowski: another one for you https://bugs.launchpad.net/snapd/+bug/1664155 | 09:54 |
| mup | Bug #1664155: Interface hooks slots should know the name of the client snap <snapd:Triaged> <https://launchpad.net/bugs/1664155> | 09:54 |
| zyga-ubuntu | mvo: trivial conflict on https://github.com/snapcore/snapd/pull/4443 | 09:54 |
| mup | PR #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 |
| Chipaca | pedronis: you around? | 09:54 |
| mup | PR snapd#4565 opened: httputil: include Go runtime version in user agent string <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4565> | 09:55 |
| mborzecki | trivial PR ^^ | 09:55 |
| zyga-ubuntu | kalikiana: can you look at https://bugs.launchpad.net/snapd/+bug/1669291, perhaps a low hanging fruit | 09:56 |
| mup | Bug #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-ubuntu | kalikiana: at least triage it please | 09:56 |
| pstolowski | zyga-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-ubuntu | mborzecki: nie! | 09:56 |
| zyga-ubuntu | nice! | 09:56 |
| zyga-ubuntu | :) | 09:56 |
| zyga-ubuntu | pstolowski: just give some feedback on the bug report, we don't have to move the discussion elsewhere | 09:56 |
| zyga-ubuntu | mborzecki: what is the runtime string like? | 09:57 |
| mborzecki | zyga-ubuntu: added a comment in the PR | 09:57 |
| zyga-ubuntu | mborzecki: and another hint, send it in the / request so that (perhaps) snap version can show it | 09:57 |
| pstolowski | zyga-ubuntu, sure, I just need to try find that discussion | 09:57 |
| zyga-ubuntu | mborzecki: looks good | 09:57 |
| kalikiana | zyga-ubuntu: Aye | 09:58 |
| pedronis | Chipaca: yes | 09:59 |
| Chipaca | pedronis: hiya, welcome back :-) | 09:59 |
| pedronis | hi | 09:59 |
| Chipaca | pedronis: while you were away I was wondering whether a local snapd could "sign" stuff | 09:59 |
| zyga-ubuntu | kalikiana: thank you | 09:59 |
| Chipaca | pedronis: and thought you were the person to ask | 10:00 |
| pedronis | Chipaca: sign stuff in which sense? | 10:00 |
| zyga-ubuntu | pstolowski: perhaps another bug for you https://bugs.launchpad.net/snapd/+bug/1672747 -- feel free to ignore, I'm just combing the bug tracker | 10:00 |
| mup | Bug #1672747: configure hook missing reason it was invoked <snapd:Triaged> <https://launchpad.net/bugs/1672747> | 10:00 |
| mborzecki | hm good news, i can reproduce the segfault when building snapd on xenial with go1.9.3 | 10:00 |
| Chipaca | pedronis: as a way of ensuring not only the integrity of a snapshot, but also its origin | 10:00 |
| pedronis | ah | 10:01 |
| pstolowski | zyga-ubuntu, the bug makes sense, but it's slowly improving with new hooks | 10:01 |
| pedronis | Chipaca: if it has a serial yes, then it has a device key | 10:01 |
| pedronis | that can be tracked to the serial | 10:02 |
| Chipaca | pedronis: 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 host | 10:02 |
| pedronis | should be doable in some way | 10:03 |
| Chipaca | (i imagine adding a --ignore-signature or something) | 10:03 |
| Chipaca | pedronis: ok, good to know. I'll pester you about it once everything else is shipshape. | 10:03 |
| pedronis | depends on the attack you are trying to avoid, or is just not mismatching stuff? | 10:03 |
| mborzecki | guys, is #4487 good to be merged now? | 10:05 |
| mup | PR #4487: cmd/snap: snap refresh --time with new and legacy schedules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4487> | 10:05 |
| zyga-ubuntu | mborzecki: looking | 10:06 |
| zyga-ubuntu | with 4 +1s, sure! | 10:07 |
| Chipaca | pedronis: 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 somehow | 10:07 |
| mup | PR 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-ubuntu | mvo: can we do something about seccomp before 18.04? | 10:15 |
| mvo | zyga-ubuntu: do somethng about it in what sense? | 10:16 |
| pedronis | Chipaca: just saying that if you are root you can get the key that is used for signing | 10:18 |
| Chipaca | pedronis: yeah | 10:19 |
| zyga-ubuntu | mvo: make it so that on 18.04 we can enable the non-kill behavior | 10:19 |
| pedronis | Chipaca: anyway I suppose if people ship them somewhere and back it's a bit more interesting | 10:19 |
| Chipaca | pedronis: I expect snapshots will be part of a backup solution that includes remote backups, yes | 10:19 |
| Chipaca | but those things should be signed at a separate layer anyway | 10:19 |
| Chipaca | pedronis: I think I'll check with jamie, and if he agrees it's too tenuous, i'll forget it | 10:19 |
| pedronis | ok, np | 10:20 |
| Chipaca | pedronis: thanks | 10:20 |
| mvo | zyga-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 pr | 10:21 |
| ikey | idk theres something charming about a security stack that opts to commit seppuku to protect the user | 10:23 |
| zyga-ubuntu | mvo: upstream has not released it or it hasn't found its way into ubuntu? | 10:23 |
| zyga-ubuntu | ikey: did snap-confine refuse to run for you? :) | 10:23 |
| zyga-ubuntu | ikey: (hey :-) | 10:24 |
| ikey | hey :) nah not recently, i meant the seccomp thing | 10:24 |
| zyga-ubuntu | ikey: ah | 10:24 |
| zyga-ubuntu | well, that's not seppuku, IMO it's like us shooting a thread because it asked to go to the loo | 10:24 |
| zyga-ubuntu | the thread _asked_ | 10:24 |
| zyga-ubuntu | just saying no wasn't in the vocabulary | 10:24 |
| ikey | yeh but i mean, going to the loo, during class time | 10:24 |
| ikey | idk man.. | 10:24 |
| ikey | >_> | 10:24 |
| zyga-ubuntu | yeah, so mean | 10:25 |
| zyga-ubuntu | it's an _internal_ problem ;) | 10:25 |
| ikey | lol | 10:25 |
| zyga-ubuntu | I'd love to see that bug fixed, I'm wondering what we can do | 10:25 |
| zyga-ubuntu | the kernel part is done now | 10:25 |
| zyga-ubuntu | and everyting else is just userspace | 10:25 |
| ikey | so distros just need to update libseccomp? | 10:25 |
| zyga-ubuntu | it's complicated | 10:26 |
| zyga-ubuntu | yes | 10:26 |
| zyga-ubuntu | and golang bindings on top | 10:26 |
| zyga-ubuntu | and it seems it's not even out upstream yet | 10:26 |
| ikey | orite | 10:26 |
| mup | PR 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-ubuntu | mborzecki: make sure the store team can parse that ^ talk to ... perhaps noise][ ? | 10:27 |
| mvo | zyga-ubuntu: upstream has not released an new golang-seccomp | 10:27 |
| ikey | its looking likely im going to need to rework my nvidia PR to account for some fedora weirdness | 10:28 |
| zyga-ubuntu | mvo: is the upstream for the C and golang lib the same? | 10:28 |
| ikey | looks like they stuff their entire tree under /usr/lib64/nvidia-304xx/* | 10:28 |
| ikey | so idk if i need to do that as separate PR, commit or what | 10:28 |
| ikey | given the one i have is marked accepted.. | 10:28 |
| zyga-ubuntu | ikey: no, just stack on top there | 10:28 |
| zyga-ubuntu | thank you for caring about fedora! | 10:28 |
| ikey | well we're all cousins in this world | 10:29 |
| ikey | (not literally. that'd make christmas so freakin awkward) | 10:29 |
| zyga-ubuntu | with RMS and linus smiling from a family photo on the wall | 10:30 |
| zyga-ubuntu | ... | 10:31 |
| zyga-ubuntu | weird silence | 10:31 |
| ikey | XD | 10:31 |
| mborzecki | hmm no segfault with go1.8.3 | 10:33 |
| * Chipaca gives up on emacs and goes back to paper | 10:34 | |
| mvo | zyga-ubuntu: its two different people. but the upstream C is also not released yet | 10:37 |
| mvo | zyga-ubuntu: its just part of git | 10:37 |
| mvo | zyga-ubuntu: and the golang is not yet part of git because there is no libseccomp yet released with the bits needed | 10:37 |
| zyga-ubuntu | mvo: 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 snaps | 10:40 |
| zyga-ubuntu | mvo: craazy idea: what if snap-seccomp was a .. snap itself | 10:40 |
| zyga-ubuntu | and we could pull it in to build the profiles | 10:41 |
| zyga-ubuntu | (it's a bit chicken-eggy) | 10:41 |
| zyga-ubuntu | but would work around building issues | 10:41 |
| mvo | zyga-ubuntu: we distro patchi n ubuntu already, thats fine. but e.g. fedora is not distro patching | 10:41 |
| ikey | aha. smoke break granted me the wisdom to fix the gl thing.. | 10:42 |
| pedronis | zyga-ubuntu: mborzecki: that format is not standard afaik (it would need to be system/version) | 10:42 |
| mvo | zyga-ubuntu: if fedora would allow us to bundle the problem would also not exist | 10:42 |
| zyga-ubuntu | mvo: I think we can bundle but we could also patch the packages there if maintainers agree | 10:42 |
| zyga-ubuntu | pedronis: oh, thank you for noticing | 10:42 |
| zyga-ubuntu | pedronis: so golang/... | 10:42 |
| Chipaca | the forum seems very 502y today | 10:42 |
| zyga-ubuntu | (or similar) | 10:42 |
| pedronis | something like that | 10:42 |
| pedronis | yes | 10:43 |
| zyga-ubuntu | Chipaca: yes, it's 100% reliably 500s today | 10:43 |
| pedronis | Chipaca: input on #4565 | 10:43 |
| mup | PR #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 |
| pedronis | it's merged but I think it needs tweaks | 10:43 |
| mborzecki | pedronis: opening a followup with fixes in a minute | 10:44 |
| Chipaca | hmmm | 10:44 |
| Chipaca | that should be go/xyz | 10:44 |
| mborzecki | Chipaca: pedronis: runtime.Version() already returns `go1.9.3`, that would make it golang/go1.9.3 | 10:45 |
| Chipaca | mborzecki: what does it look like with gccgo? | 10:45 |
| pedronis | also a bit unclear whether it's useful? | 10:45 |
| pedronis | mborzecki: what's the goal here? | 10:46 |
| Chipaca | I'd be ok with go/goX.Y.Z if goXYZ is what runtime.Version returns | 10:46 |
| pedronis | getting this in the logs? | 10:46 |
| mborzecki | pedronis: yes | 10:46 |
| Chipaca | pedronis: it'd be in error reports also | 10:46 |
| pedronis | both could be done without changing the user agent | 10:46 |
| pedronis | it's a bit strange to put the compiler there | 10:46 |
| pedronis | otoh it's also the standard lib | 10:47 |
| pedronis | mborzecki: what does go itself does? | 10:47 |
| pedronis | it has a default user-agent afaik | 10:47 |
| mborzecki | pedronis: also stdlib carries the http client | 10:47 |
| pedronis | that we are overriding | 10:47 |
| pedronis | we probably should do something similar | 10:47 |
| mborzecki | pedronis: probably Go-http-client/1.1 (that's what they expect in the tests anyway) | 10:50 |
| pedronis | mborzecki: zyga-ubuntu: anyway I fear this will also break the store | 10:51 |
| pedronis | we need to be a bit careful | 10:51 |
| mborzecki | Chipaca: pedronis: `golang/go1.9.3` then? | 10:52 |
| pedronis | why the repeated go? | 10:52 |
| pedronis | anyway I also need to check where to put it if at all | 10:53 |
| * zyga-ubuntu -> important errand | 10:53 | |
| Chipaca | hmm | 10:54 |
| Chipaca | mborzecki: problem | 10:54 |
| mborzecki | i 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 string | 10:54 |
| Chipaca | go1.6.1 gccgo (Ubuntu 6.0.1-0ubuntu1) 6.0.0 20160414 (experimental) [trunk revision 234994] | 10:55 |
| Chipaca | ^ runtime.Version() with gccgo | 10:55 |
| pedronis | fun | 10:55 |
| mborzecki | right, and go returns go1.9.3 | 10:55 |
| mborzecki | oh, w8, that's the whole string? | 10:55 |
| Chipaca | mborzecki: "go1.6.1 gccgo (Ubuntu 6.0.1-0ubuntu1) 6.0.0 20160414 (experimental) [trunk revision 234994]" | 10:55 |
| Chipaca | mborzecki: that's printed with %q for your enjoyment | 10:56 |
| mborzecki | damn | 10:56 |
| mborzecki | ok, i'll log it in the daemon | 10:56 |
| mborzecki | and the store can keep guessing which buggy version of go http.Client was that :) | 10:56 |
| pedronis | mborzecki: anyway, indeed as it is it would break the store parsing of it | 10:57 |
| mborzecki | ok, i"ll open a pr reverting the change | 10:57 |
| pedronis | the issue there is mostly putting it at the end I think | 10:58 |
| mup | PR snapcraft#1892 opened: meta: warn if version is not a string <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1892> | 11:00 |
| mup | PR 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 |
| ikey | what do you use to format the C files in snapd? | 11:01 |
| mborzecki | ikey: indent | 11:01 |
| ikey | any sample invocation? i tried indent but it mangled the file | 11:01 |
| mborzecki | don't laugh though please :) | 11:01 |
| * ikey is only used to clang-format | 11:02 | |
| mborzecki | there's .indent in cmd | 11:02 |
| mborzecki | `make fmt` should do the trick | 11:02 |
| pedronis | mborzecki: or not, maybe I'm confused (regexps are fun that way) | 11:02 |
| ikey | ah ty | 11: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 MMCs | 11:03 |
| mup | Bug #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 (Ubuntu | 11:04 |
| mup | Bionic):Fix Released by xnox> <https://launchpad.net/bugs/1618188> | 11:04 |
| pedronis | mborzecki: https://golang.org/pkg/runtime/#Version says it could also be a hash and date | 11:05 |
| ogra_ | (oh, and indeed make sure /var/log/journal is writable | 11:05 |
| ogra_ | ) | 11:05 |
| mvo | ogra_: base-18 has everything writable | 11:06 |
| ogra_ | ouch | 11:06 |
| ogra_ | will you keep it that way ? | 11:06 |
| mvo | ogra_: we will see if it works out, but whats the downside? | 11:06 |
| niemeyer | https://forum.snapcraft.io/t/forum-offline-today-post-mortem/3760 | 11:07 |
| mvo | ogra_: thanks for the heads up, I will look into making sure this is not written to disk by default then | 11:08 |
| Chipaca | niemeyer: Apologies for any inconvenience this may have cause*d* you. | 11:11 |
| Chipaca | niemeyer: and thank you for getting it back up :-) | 11:11 |
| zyga-ubuntu | niemeyer: hey | 11:11 |
| zyga-ubuntu | niemeyer: woot, thank you for for the post morterm | 11:12 |
| niemeyer | Chipaca: Thnaks | 11:12 |
| * zyga-ubuntu makes lunch and reads | 11:12 | |
| niemeyer | Chipaca: *Thanks* :) | 11:12 |
| Chipaca | niemeyer: I thought that was on porpoise | 11:12 |
| Chipaca | :-) | 11:12 |
| zyga-ubuntu | niemeyer: it's at least very comforting to know the forum died while making a backup :) | 11:13 |
| pedronis | Chipaca: afaict runtime.Version() can be whatever :/ | 11:13 |
| niemeyer | zyga-ubuntu: Yeah | 11:13 |
| Chipaca | pedronis: well, at least we know it's a string :-D | 11:14 |
| niemeyer | zyga-ubuntu: We also have daily backups stored since August | 11:15 |
| niemeyer | of the data, plus daily and weekly backups of the whole machine | 11:17 |
| niemeyer | We have so many backups that I killed the system doing it | 11:17 |
| zyga-ubuntu | niemeyer: sweet | 11:18 |
| mborzecki | pedronis: Chipaca: #4566 | 11:32 |
| mup | PR #4566: Revert "httputil: include Go runtime version in user agent string" <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4566> | 11:32 |
| Chipaca | I could use another review on #4556 and #4557 i think | 11:33 |
| mup | PR #4556: strutil/quantity: new package that exports formatFoo (from progress) <Created by chipaca> <https://github.com/snapcore/snapd/pull/4556> | 11:33 |
| mup | PR #4557: osutil: add DirExists and IsDirNotExist <Created by chipaca> <https://github.com/snapcore/snapd/pull/4557> | 11:33 |
| mup | PR 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 | Hmmmm | 11:35 |
| kalikiana | "snap lxd cannot use current base snap core because existing process are still using the old revision" | 11:35 |
| kalikiana | That's a weird error. Was doing `lxc exec` there | 11:35 |
| Chipaca | mborzecki: I did +1 it, but zyga merged it before github took my +1 and i think it then lost it | 11:35 |
| Chipaca | ¯\_(ツ)_/¯ | 11:35 |
| zyga-ubuntu | kalikiana: that's a warning | 11:35 |
| zyga-ubuntu | kalikiana: it means you could hop onto new core | 11:35 |
| zyga-ubuntu | kalikiana: but you're using the old one because some lxc process is still alive | 11:36 |
| Chipaca | zyga-ubuntu: you're on fire :-) | 11:36 |
| mup | PR 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-ubuntu | Chipaca: _high voltage_ :) | 11:36 |
| zyga-ubuntu | kalikiana: if you restart your lxc things it should go away and you will see new core being used | 11:36 |
| zyga-ubuntu | kalikiana: all processes belonging to a given snap see consistent filesystem | 11:36 |
| kalikiana | zyga-ubuntu: I feel the message should've told me exactly that :-) | 11:37 |
| kalikiana | zyga-ubuntu: Does the error come from snapd? Or LXD? | 11:38 |
| zyga-ubu1tu | so | 11:40 |
| kalikiana | zyga-ubuntu: I'll file a bug. Let's see if it can be improved | 11:41 |
| zyga-ubu1tu | my machine crashed because when I went out of range BT went nuts | 11:41 |
| zyga-ubu1tu | kissiel: ^ | 11:41 |
| zyga-ubu1tu | kalikiana: re | 11:41 |
| zyga-ubu1tu | kalikiana: so about that, how would you rephrase that so that it's more useful | 11:41 |
| zyga-ubu1tu | kalikiana: just tell me :) | 11:42 |
| zyga-ubu1tu | or open a forum thread | 11:42 |
| zyga-ubu1tu | it's a sub-optimal situation, we could perhaps have a hook for this | 11:42 |
| zyga-ubu1tu | if there's no hook we could print a short line of text + forum link | 11:42 |
| zyga-ubu1tu | and if there's a hook we could signal snapd and not print anything | 11:42 |
| === zyga-ubu1tu is now known as zyga | ||
| kalikiana | zyga: first of all it should reveal itself as a warning, for example by starting with "Notice:" | 11:46 |
| kalikiana | zyga: although by showing me this message every single time I practically consider it an error since I can't actually ignore it | 11:46 |
| kalikiana | zyga: 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 |
| zyga | kalikiana: it's not true | 11:50 |
| zyga | kalikiana: that's the problem :) | 11:50 |
| zyga | kalikiana: the first part is okay | 11:50 |
| zyga | but the remainder is not accurate | 11:50 |
| zyga | snap restart lxd is not sufficient | 11:51 |
| zyga | _all_ processes, including non-services, must terminate | 11:51 |
| kalikiana | zyga: Well, if it's not accurate it's because I had to guess since it did not in fact tell me :-D | 11:51 |
| zyga | (I lost my log) can you paste the original message again please? | 11:51 |
| kalikiana | zyga: `snap lxd cannot use current base snap core because existing process are still using the old revision` | 11:52 |
| ikey | phew. back to working snapd.. | 11:52 |
| mvo | zyga: 4342 is ready for a re-review (cc mborzecki I addressed your comments as well iirc) | 11:53 |
| ikey | 4559 will need re-review too | 11:53 |
| zyga | kalikiana: hmm hmm | 11:53 |
| kalikiana | zyga: The "cannot use" wording makes it look like an error. And it's not telling me how to fix it. | 11:53 |
| zyga | mvo: ack | 11:53 |
| zyga | kalikiana: I don't dismiss the wording could be better | 11:53 |
| zyga | just pondering on what it should be | 11:53 |
| ikey | decided to be nice to those darn pesky fedora kids :p | 11:53 |
| kalikiana | zyga: This is why I suggested to file it, didn't expect you to fix it on the spot :-P | 11:54 |
| kalikiana | Oh, forum's back. I could also make a topic for it then | 11:55 |
| zyga | kalikiana: yeah, let's do a forum topic, we can tweak that message before 2.31 | 11:56 |
| zyga | thank you for rising this | 11:56 |
| greyback | jdstrand: 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 |
| mup | PR #4545: interfaces/x11: allow X11 slot implementations <Created by gerboland> <https://github.com/snapcore/snapd/pull/4545> | 12:02 |
| greyback | s/it's/its/ | 12:02 |
| zyga | greyback: if you put the socket in $SNAP_COMMON | 12:07 |
| zyga | you could use new content sharing features to inject that anywhe | 12:07 |
| zyga | *anywhere | 12:07 |
| zyga | so for the snap holding the socket and being the server it can be in $SNAP_COMMON | 12:08 |
| zyga | and for any client snaps it could be in /tmp/somethingappropriatethatisdefault | 12:08 |
| zyga | *magic* | 12:08 |
| ikey | does snapd expose changelog functionality? like when i publish a new revision can i inform users of changes? | 12:09 |
| zyga | you can do that in the store but I don't know if this is visible in many places | 12:09 |
| ikey | ah ok | 12:09 |
| ikey | future stuffs then | 12:09 |
| zyga | it's a nice thing if it was accessible | 12:09 |
| zyga | I mean | 12:09 |
| zyga | you can fill it for each release | 12:09 |
| ikey | sure | 12:09 |
| ikey | and at some point in the future hook up UI bits | 12:09 |
| kalikiana | zyga: https://forum.snapcraft.io/t/cannot-use-current-base-snap-core/3763 | 12:10 |
| zyga | ack | 12:11 |
| greyback | zyga: I would if I could, but I'm snapping x11. It has /tmp/.X11-unix/X* hardcoded in | 12:12 |
| kalikiana | zyga: I can't actually seem to get rid of it | 12:13 |
| kalikiana | very broad use of killall doesn't help | 12:13 |
| zyga | greyback: no, you didn't understand | 12:14 |
| zyga | greyback: you can do that without touching x11 | 12:14 |
| * greyback re-reads | 12:14 | |
| zyga | greyback: the content interface lets you do those bind mounts | 12:14 |
| zyga | greyback: I haven't tried this on a socket though so you may run into a limitation | 12:15 |
| zyga | greyback: but even a tiny patch in x11 (or config tweak) to store the socket in $SNAP_COMMON is enough | 12:15 |
| greyback | zyga: ack. I see what you mean. I'll give that a go. | 12:16 |
| zyga | greyback: you must use master though | 12:16 |
| zyga | greyback: and stick to $SNAP_COMMON for now | 12:16 |
| greyback | ok | 12:16 |
| zyga | greyback: (or edge) | 12:16 |
| zyga | greyback: try it with dummy snaps and a writable file | 12:16 |
| zyga | greyback: and the content interface | 12:17 |
| zyga | in the end we can move this into the x11 interface properly | 12:17 |
| greyback | *nod* | 12:17 |
| greyback | more toys to play with! | 12:17 |
| zyga | :D | 12:18 |
| zyga | indeed | 12:18 |
| zyga | and my child so let's see how it works, I'm eager to get feedack | 12:18 |
| zyga | *feedback | 12:18 |
| niemeyer | popey: Seen the announcement of godot 3.0 final being released yesterday.. did you ever get that to work? | 12:22 |
| pedronis | mvo: Chipaca: can the 2_32 tag be created in the forum | 12:24 |
| Chipaca | sure | 12:24 |
| Chipaca | pedronis: but i can only create it by tagging something | 12:25 |
| Chipaca | pedronis: ideally something that needs to be there for 2.32 :-D | 12:25 |
| pedronis | ok, I suppose I should talk with mvo about the when of those | 12:26 |
| mup | PR 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 |
| Chipaca | pedronis: i think i have something i can tag | 12:26 |
| Chipaca | pedronis: there | 12:27 |
| Chipaca | and now, lunch | 12:27 |
| * ogra_ grins about zygas comments on #4563 ... you should really talk to the devmem2 developers to have this fixed upstream :) | 12:36 | |
| mup | PR #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 |
| zyga | ahh | 12:40 |
| zyga | well, I'm just a C coder | 12:40 |
| ogra_ | :) | 12:41 |
| mborzecki | bisecting go toolchain, so much fun | 12:42 |
| Chipaca | pstolowski: you can't fallthrough a type switch | 12:50 |
| pstolowski | Chipaca, aha! thanks, still learning about some corners of Go | 12:51 |
| Chipaca | pstolowski: you also can't usefully enumerate things (i.e. if you do "case typeA, typeB:" you'll get the interface-y object in the case | 12:53 |
| Chipaca | ) | 12:53 |
| pstolowski | k | 12:58 |
| mup | PR 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 |
| jdstrand | greyback: 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 namespace | 13:41 |
| mup | PR 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 soon | 14:00 | |
| kalikiana | zyga_: but before I leave, great to see this extremely quick PR , you are awesome:-D | 14:01 |
| * kalikiana now really off for lunch | 14:01 | |
| greyback | jdstrand: aha. Ok. I didn't know that | 14:04 |
| Beret | can someone remind me why I have multiple (more than 2) loop devices for a snap? | 14:05 |
| Beret | I understand 2 for the theoretical purposes of rollback | 14:05 |
| Beret | but why more than 2? | 14:05 |
| mborzecki | bisecting the -linkshared segfault, the first bad commit is https://github.com/golang/go/commit/4808fc444307fa683bf3df6d55f9ad1828891a36 | 14:05 |
| mup | PR snapd#4568 opened: tests: new spead test for openvswitch-support interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4568> | 14:07 |
| Chipaca | Beret: 3, so you can always rollback even in the worst case | 14:16 |
| Chipaca | Beret: we might make it tunable at some point (there's a feature request for this already) | 14:17 |
| Chipaca | Beret: but in any case you can already remove the prior ones with "snap remove <snapname> --revision <revno>" | 14:17 |
| Chipaca | Beret: (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 |
| Chipaca | Beret: hth | 14:19 |
| cjwatson | sergiusens: 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 cracks | 14:26 |
| Beret | Chipaca, ok, thanks | 14:42 |
| mup | PR snapd#3456 opened: many: add interfaces.SystemKey() helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/3456> | 14:44 |
| zyga_ | brb | 14:51 |
| sergiusens | cjwatson no, no one is; sorry, the communication has. I did discuss this with sparkiegeek | 15:00 |
| cjwatson | sergiusens: was that today? I talked about this with sparkiegeek this morning | 15:01 |
| sergiusens | cjwatson capetown sprint | 15:02 |
| cjwatson | sergiusens: 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 work | 15:05 |
| zyga_ | re | 15:09 |
| zyga_ | sorry, small interrupt for kids | 15:09 |
| sergiusens | cjwatson that would be appreciated. I am sorry it fell through the comm cracks | 15:17 |
| cjwatson | all right, let's see what I can fit in | 15:17 |
| === zyga_ is now known as zyga | ||
| pedronis | pstolowski: sorry it took a bit, looks it's going in the right direction, did a pass over #4401 | 15:32 |
| mup | PR #4401: snapstate/ifacestate: auto-connect tasks <Created by stolowski> <https://github.com/snapcore/snapd/pull/4401> | 15:32 |
| pstolowski | pedronis, hey, no problem, and thanks! | 15:33 |
| kalikiana | sliff | 15:39 |
| * kalikiana seems to be online again, for some reason wlan didn't see any network for a while | 15:41 | |
| * kalikiana once again fell for the DENIED messages caused by the telegram snap looking for helpful logs | 15:43 | |
| pedronis | zyga: what's the status of #4471 ? | 15:43 |
| mup | PR #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 |
| zyga | pedronis: refactoring after feedback from a call, I'll push it in ~hour | 15:47 |
| pedronis | thx | 15:47 |
| mup | PR 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 |
| seb128 | jdstrand, 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/3767 | 16:07 |
| zyga | seb128: interesting, it's probably the same problem that prevented us from using overlayfs | 16:07 |
| * zyga reads | 16:07 | |
| seb128 | zyga, right | 16:08 |
| zyga | seb128: replied | 16:11 |
| seb128 | zyga, thanks | 16:11 |
| niemeyer | mvo: #4342 reviewed.. trivials only, thanks | 16:15 |
| mup | PR #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 |
| mvo | niemeyer: \o/ thank you | 16:15 |
| niemeyer | mvo: Thank you! Nice abstractions | 16:16 |
| blackboxsw | pedronis: do you know offhand about seeding --classic snaps? https://forum.snapcraft.io/t/seed-yaml-documentation/3050/4 | 16:22 |
| pedronis | blackboxsw: on a classic image? | 16:22 |
| blackboxsw | on non-snappy environments | 16:23 |
| pedronis | classic: true in the seed entry for the snap afair | 16:23 |
| blackboxsw | so stock ubuntu cloud-images | 16:23 |
| blackboxsw | ahh nice | 16:24 |
| blackboxsw | will try that | 16:24 |
| blackboxsw | thanks | 16:24 |
| blackboxsw | and will update the post with the results | 16:24 |
| pedronis | blackboxsw: I'm just back from holidays, I put looking at that post in my queue | 16:25 |
| blackboxsw | cheers. yeah I heard. Welcome back :) | 16:26 |
| zyga | hmm mhmm | 16:35 |
| jdstrand | seb128: thanks, noted and commented | 16:42 |
| * jdstrand -> travel | 16:42 | |
| Chipaca | Q: what happens if you accidentally switch the implementations of, in essence, 'rm' and 'md5sum -c'? | 16:42 |
| Chipaca | A: giggles | 16:42 |
| * Chipaca takes a break | 16:43 | |
| zyga | jdstrand: safe travels! | 16:44 |
| zyga | Chipaca: A: backups | 16:44 |
| Chipaca | zyga: dude | 16:57 |
| zyga | yes? | 16:57 |
| Chipaca | zyga: i'm implementing snapshots | 16:57 |
| Chipaca | ie backups | 16:57 |
| Chipaca | zyga: :-) | 16:57 |
| zyga | Chipaca: snap my home directory ;) | 16:57 |
| Chipaca | i had the handlers for 'lose' and 'check' reversed | 16:57 |
| Chipaca | :-) | 16:57 |
| Chipaca | happy to have tests :-) | 16:58 |
| zyga | lose drops the snapshot? | 16:58 |
| Chipaca | zyga: yes | 16:58 |
| zyga | Chipaca: just document it, it's not a bug if it's documented ;) | 16:58 |
| * Chipaca takes note | 16:58 | |
| mvo | ikey: is 4559 good to go? | 17:01 |
| ikey | em | 17:02 |
| ikey | is that the one i did today i cant remember | 17:02 |
| mvo | pr #4559 | 17:02 |
| mup | PR #4559: snap-confine/nvidia: Support legacy biarch trees for GLVND systems <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4559> | 17:02 |
| ikey | ah | 17:03 |
| ikey | so the thing i wanted clarification on from Son_Goku was the libdir stuff | 17:03 |
| ikey | like are we making this a compile time option or is it being vendor patched or what | 17:03 |
| ikey | or do we just do more of the populate calls? cheap and cheerful | 17:04 |
| Son_Goku | more of the populate calls | 17:04 |
| Son_Goku | the issue with the other two is the multi-base snap nature of things | 17:04 |
| ikey | so do you have a lib32 directory in fedora? | 17:04 |
| Son_Goku | nope | 17:04 |
| Son_Goku | and we really don't have any more permutations to worry about | 17:05 |
| ikey | so populate isnt going to be the right approach | 17:05 |
| Son_Goku | we have /usr/lib and /usr/lib64 | 17:05 |
| ikey | because you're going to get inverse libraries | 17:05 |
| ikey | 32s in the 64 | 17:05 |
| Son_Goku | ah, right | 17:05 |
| ikey | i mean it'll still technically *work* but its not "right" | 17:05 |
| ikey | and i think the rest of the world is lib64/lib32 | 17:05 |
| Son_Goku | most of the world is lib/lib64 | 17:06 |
| ikey | with lib + lib64 being the same thing | 17:06 |
| ikey | eh idk about that | 17:06 |
| ikey | even arch uses lib32 | 17:06 |
| Son_Goku | Arch and Solus are lib32 / lib64 | 17:06 |
| ikey | right | 17:06 |
| Son_Goku | Gentoo is fuck all | 17:06 |
| ikey | lol | 17:06 |
| Son_Goku | though they default to lib / lib64 | 17:06 |
| ikey | so ok we need to use --libdir as our /usr/lib there atm | 17:06 |
| Son_Goku | Fedora, SUSE, Mageia, et al are lib / lib64 | 17:06 |
| ikey | and we need a new option for emul32 | 17:06 |
| ikey | so that we no longer assume | 17:07 |
| ikey | assuming ofc on fedora you configure --libdir=/usr/lib64 | 17:07 |
| Son_Goku | right | 17:07 |
| ikey | and we add like --with-emul32-libdir=/usr/lib ? | 17:07 |
| Son_Goku | sure | 17:07 |
| ikey | alright | 17:07 |
| ikey | gimme a wee second here | 17:07 |
| ikey | ty btw :] | 17:08 |
| Son_Goku | you could also do detect-y things for this | 17:08 |
| ikey | eh | 17:08 |
| ikey | the smartest way to be smart is by not being smart | 17:08 |
| Son_Goku | just sayin' | 17:08 |
| Son_Goku | heh | 17:08 |
| ikey | hm. autotools crap. | 17:08 |
| ikey | so libdir will be wrong | 17:09 |
| zyga | what is emul32? | 17:10 |
| ikey | -m32 | 17:10 |
| Son_Goku | zyga: it's Solus' term for secondary arch | 17:10 |
| ikey | i.e. 32-bit library | 17:10 |
| ikey | no its the proper term | 17:10 |
| ikey | emul32 == -m32 :P | 17:10 |
| ikey | you're emulating 32-bit vdso on x86_64 | 17:11 |
| Son_Goku | well, -m64 also exists, are you saying that's emul64? | 17:11 |
| ikey | with -m32 | 17:11 |
| ikey | no | 17:11 |
| zyga | is that like x86 | 17:11 |
| ikey | because you have native binaries and libraries | 17:11 |
| ikey | well you guys pick a name | 17:11 |
| Son_Goku | zyga: on multiarch architectures, you can build from the same compiler for 32-bit and 64-bit | 17:11 |
| ikey | idc what its called :P | 17:11 |
| zyga | is that like x86? <- question | 17:11 |
| Son_Goku | so on x86, you have x86_64 and x86_32 | 17:11 |
| ikey | -m32 will spit out x86 on x86_64 toolchain | 17:11 |
| ikey | technically i686 | 17:12 |
| ikey | but ya | 17:12 |
| Son_Goku | on aarch64 you have aarch64 and aarch32 | 17:12 |
| zyga | ikey: sure, but but that's a compiler switch | 17:12 |
| Son_Goku | (which technically is also known as armv8hnl) | 17:12 |
| ikey | sure and we're talking about biarch here | 17:12 |
| zyga | what is the relationship to a filesystem path | 17:12 |
| ikey | not multiarch | 17:12 |
| ikey | biarch is locked to the notion of -m64 vs -m32 | 17:12 |
| Son_Goku | ikey: we could get into x32 | 17:12 |
| zyga | ikey: I see | 17:12 |
| ikey | which is why -m32 is the emulated vdso | 17:12 |
| * zyga likes multiarch | 17:12 | |
| ikey | someones gotta :P | 17:12 |
| Son_Goku | zyga: debian platform libdirs has other issues | 17:12 |
| zyga | everything has issues | 17:13 |
| ikey | so what we calling this emul32 dir | 17:13 |
| ikey | just lib32 ? | 17:13 |
| ikey | --with-lib32-dir | 17:13 |
| ikey | before i get dead cats mailed to me from gentoo devs | 17:13 |
| Son_Goku | ikey: --with-lib32-dir, --with-lib64-dir | 17:13 |
| ikey | why --with-lib64-dir? | 17:13 |
| zyga | --i-wish-we-had-fat-objects-like-apple-did-decades-ago | 17:13 |
| Son_Goku | ikey: Gentoo dev dead cat avoidance :) | 17:13 |
| ikey | but --libdir is the native arch | 17:13 |
| Son_Goku | true | 17:13 |
| zyga | back to work | 17:14 |
| ikey | lol | 17:14 |
| Son_Goku | ikey: meeeby --with-alt-libdir ? | 17:14 |
| Son_Goku | god damn naming things is hard :/ | 17:14 |
| Son_Goku | fuck it | 17:15 |
| ikey | XD | 17:15 |
| ikey | Son_Goku, "defaults" | 17:15 |
| ikey | lol | 17:15 |
| Son_Goku | --lib32dir | 17:15 |
| ikey | #define NATIVE_LIB_DIR "${exec_prefix}/lib" | 17:15 |
| ikey | i hate your face autotools | 17:15 |
| zyga | man | 17:15 |
| zyga | fat objects | 17:16 |
| zyga | that's so simple :/ | 17:16 |
| ikey | nope | 17:16 |
| Son_Goku | zyga: then make it happen | 17:16 |
| ikey | don't want your bloat :P | 17:16 |
| ikey | ah mind you i can use -D defines | 17:16 |
| ikey | for native libdir | 17:17 |
| zyga | Son_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 community | 17:17 |
| zyga | niemeyer: can you look at https://github.com/snapcore/snapd/pull/4471/files again please | 17:17 |
| mup | PR #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 |
| niemeyer | zyga: Looking | 17:18 |
| zyga | niemeyer: 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 holes | 17:18 |
| zyga | niemeyer: I can do that after this RC because it will have impact on existing unit tests | 17:18 |
| zyga | (sequence of things will change, churn, can cause bugs) | 17:18 |
| zyga | niemeyer: I'll cherry pick the spread test into this PR so that it is really tested | 17:18 |
| niemeyer | zyga: My suggestions would not involve any test changes at all | 17:18 |
| zyga | niemeyer: yes, but we also discussed the idea to look at the filesystem to see if it's read only ahead of time | 17:19 |
| zyga | and 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 |
| niemeyer | zyga: I understand.. just saying that the real goal was simplifying it | 17:20 |
| niemeyer | zyga: Rather than changing behavior | 17:20 |
| Chipaca | pedronis: do you remember in what situation a task's change could be nil? when looping over all tasks from state | 17:20 |
| zyga | yeah, I think it's shorter now, we can go further but I want to not break it | 17:20 |
| pedronis | Chipaca: looping how? | 17:20 |
| zyga | I will now look at that spread tets and then at the PR with individual new unit tests | 17:21 |
| Chipaca | pedronis: for _, tsk := range st.Tasks() {...} | 17:21 |
| pedronis | Chipaca: that should filter out tasks that have no change | 17:21 |
| pedronis | see its code | 17:21 |
| Chipaca | pedronis: i see | 17:21 |
| pedronis | it might be we are paranoid in a couple of places because historical reasons | 17:22 |
| * ikey has a potential fix for that patch now | 17:22 | |
| ikey | just gonna test it.. | 17:22 |
| * zyga runs the new tests and waits for them to finish | 17:22 | |
| zyga | tea time :) | 17:22 |
| Chipaca | pedronis: in snapstate's CheckChangeConflictMany there's an explicit check for nil which threw me :-) | 17:22 |
| Son_Goku | ikey: thank god no one here cares about /usr/libx32 right now | 17:22 |
| Chipaca | i guess that's one of the places | 17:22 |
| Son_Goku | ikey: and yes, that's a thing | 17:22 |
| pedronis | Chipaca: I don't think, it's needed nowadays | 17:22 |
| ikey | i know it is | 17:22 |
| ikey | but in our context no we dont care | 17:22 |
| Chipaca | pedronis: thanks | 17:23 |
| pedronis | we have the lock and Tasks() check for us | 17:23 |
| Son_Goku | ikey: --with-alt-libdir is the best I can come up with | 17:23 |
| ikey | doesn't make sense | 17:23 |
| ikey | its strictly for "im 64-bit and need 32-bit" | 17:24 |
| * ikey finds out if patches are borked from that | 17: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 one | 17:24 | |
| Son_Goku | ikey, fuck it, --with-32bit-libdir? | 17:25 |
| ikey | cool, didn't hose it | 17:25 |
| ikey | well my patch has --with-lib32-dir=DIR | 17:25 |
| ikey | lol | 17:26 |
| ikey | ill change | 17:26 |
| ikey | though im not sure how good autotools is with numeric prefixes? | 17:26 |
| ikey | guess we'll find out | 17:26 |
| * Son_Goku groans at autotools | 17:27 | |
| Son_Goku | why isn't this Meson already...? | 17:27 |
| ikey | --with-32bit-libdir -- Use an alternate lib32 directory | 17:27 |
| ikey | works | 17:27 |
| Son_Goku | oh right, because 14.04 isn't dead yet | 17:27 |
| zyga | Son_Goku: hold on, what are you tweaking? | 17:27 |
| ikey | ive had to safe guard this change.. | 17:27 |
| ikey | you'll see in a sec | 17:28 |
| Son_Goku | ikey: I'm guessing it defaults to lib64 and lib32? | 17:28 |
| ikey | not /quite/ | 17:28 |
| ikey | you'll also need to change autogen for fedora i imagine | 17:28 |
| Son_Goku | fuck | 17:28 |
| Son_Goku | that's going to suck | 17:28 |
| zyga | oho, linode handshake timeouts | 17:28 |
| zyga | that's fine, I'll push the spread test on top anyway | 17:29 |
| ikey | Son_Goku, https://github.com/snapcore/snapd/pull/4559/commits/c724c06a6a58e64c0a701cc78f9f5154164abe32 | 17:29 |
| mup | PR #4559: snap-confine/nvidia: Support legacy biarch trees for GLVND systems <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4559> | 17:29 |
| ikey | so instead of assuming /usr/lib, we set native libdir to `--libdir=` from configure time | 17:29 |
| ikey | i.e. host arch | 17:29 |
| ikey | if we're 64-bit, we'll then try to mount/copy the 32-bit alt set. | 17:29 |
| ikey | otherwise don't do anything | 17:30 |
| Son_Goku | right | 17:30 |
| Son_Goku | so that looks roughly sane | 17:30 |
| ikey | because we could clobber ourselves on 32-bit pure | 17:30 |
| ikey | its about the only dumb-clever way i can think of right now | 17:30 |
| Son_Goku | ikey: this means you need to add the logic to the Fedora spec :) | 17:30 |
| Son_Goku | otherwise it can't test :P | 17:30 |
| ikey | and i cant test fedora | 17:30 |
| ikey | so idk what you want me to do there | 17:30 |
| Son_Goku | spread will do that | 17:30 |
| ikey | help a brutha out | 17:30 |
| Son_Goku | I can give you a patch to add to your PR, if that helps | 17:31 |
| ikey | i wont object | 17:31 |
| ikey | lol | 17:31 |
| ikey | as long as your autogen uses libdir logic (which it should already) you should be fine | 17:31 |
| ikey | but for your packaging you'll want to expressly set 32bit-libdir now | 17:31 |
| ikey | or w/e the hell we caleld it | 17:31 |
| ikey | *called | 17:31 |
| ikey | as the day closes, so does my mind. | 17:32 |
| Son_Goku | hehe | 17:32 |
| Son_Goku | I regenerate the autofoo on every build | 17:32 |
| niemeyer | zyga: Definitely nicer.. sent another round | 17:32 |
| zyga | niemeyer: thanks, looking now | 17:33 |
| niemeyer | zyga: Sorry, please ignore my comment on the for loop | 17:36 |
| niemeyer | zyga: I removed it, but not quickly enough | 17:36 |
| niemeyer | zyga: This is much simpler as a recursive call | 17:36 |
| zyga | niemeyer: ok | 17:36 |
| zyga | niemeyer: I think you reviewed an earlier version I pushed and then I pushed the patches that dropped flags | 17:36 |
| zyga | niemeyer: so some of your questions as in places that got removed now | 17:36 |
| zyga | I'll start with the low hanging fruit and iterate, let's see what remains | 17:37 |
| niemeyer | zyga: Ouch, thanks | 17:38 |
| zyga | error: received an unexpected http response code (504) when trying to download https://api.snapcraft.io/api/v1/snaps/download/eFe8BTR5L5V9F7yHeMAPxkEr2NdUXMtw_6.snap | 17:38 |
| zyga | hmm, store hicckups | 17:38 |
| Son_Goku | ikey: http://kinginuyasha.enanocms.org/downloads/0001-Enable-support-for-handling-the-NVIDIA-proprietary-g.patch | 17:39 |
| niemeyer | zyga: I still don't understand your comment on why lowLevelPerform is there | 17:39 |
| niemeyer | zyga: It's a very awkward side effect whihc would be nice to avoid | 17:39 |
| ikey | what in the shite is that | 17:39 |
| zyga | niemeyer: mount and umount don't care if the medium is read only | 17:39 |
| zyga | niemeyer: symlink needs to drop a new inode | 17:39 |
| niemeyer | zyga: You say file creation relies on existing inodes, which doesn't make a lot of sense to me | 17:39 |
| zyga | niemeyer: it is there to triggere the read-only-filesystem fallback | 17:39 |
| ikey | Son_Goku, honestly i dont feel comfortable applying that which i dont know | 17:39 |
| Son_Goku | ikey: a patch you apply with git-am ? | 17:39 |
| ikey | alright | 17:39 |
| ikey | but everyone saw that Son_Goku made me do it | 17:40 |
| Son_Goku | ikey: unconditionally turns on nvidia-biarch | 17:40 |
| zyga | oh, did I, sorry, I meant mounting | 17:40 |
| Son_Goku | and also sets the libdir in arches that are configured for multilib | 17:40 |
| niemeyer | zyga: I realize it's there for that reason.. I don't understand why it's there for that reason | 17:40 |
| ikey | gotcha | 17:40 |
| ikey | i pushed it Son_Goku and now we'll wait for the sound of screams | 17:40 |
| Son_Goku | :D | 17:40 |
| ikey | cheers :] | 17:40 |
| Son_Goku | kanpai! | 17:40 |
| Son_Goku | well, I'm a dumbass | 17:41 |
| zyga | niemeyer: right, the reason is that the code is like <create inodes><handle read only and retry><mount> | 17:41 |
| Son_Goku | ikey: can you fix the title of the patch | 17:41 |
| Son_Goku | it should be prefixed with "packaging/fedora:" | 17:41 |
| zyga | niemeyer: both mount and create symlinks is in the low-level part | 17:41 |
| niemeyer | zyga: Again, per above, zyga: You say file creation relies on existing inodes, which doesn't make a lot of sense to me | 17:41 |
| zyga | niemeyer: now if you had a path like /rofs/symlink -> target | 17:41 |
| zyga | niemeyer: ^ (I meant *mounting*, not file creation) | 17:42 |
| ikey | Son_Goku, but | 17:42 |
| ikey | but i pushed it | 17:42 |
| Son_Goku | rewrite it :P | 17:42 |
| zyga | niemeyer: and assuming that /rofs exists | 17:42 |
| ikey | and they get angry when i force push | 17:42 |
| Son_Goku | meh | 17:42 |
| Son_Goku | just do it | 17:42 |
| ikey | but they can hear us | 17:42 |
| ikey | ._. | 17:42 |
| zyga | niemeyer: that won't do anything in the <create inodes> part | 17:42 |
| Son_Goku | XD | 17:42 |
| zyga | niemeyer: it will proceed to c.lowLevelPerform where we just create the symlink | 17:42 |
| niemeyer | zyga: Again, can we please talk about the difference between these branches | 17:42 |
| zyga | niemeyer: and that's when we will notice EROFS | 17:42 |
| niemeyer | zyga: how can +err = secureMkfileAll(path, mode, uid, gid) | 17:42 |
| ikey | zyga, humbly request permission to force push fixed patch to PR | 17:42 |
| niemeyer | zyga: do the right thing, but +err = secureMkdirAll(path, mode, uid, gid) | 17:43 |
| niemeyer | not? | 17:43 |
| ikey | Son_Goku, but now your commit message is too long | 17:43 |
| Son_Goku | fuck | 17:43 |
| ikey | ima leave it. :3 | 17:43 |
| zyga | niemeyer: 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 |
| niemeyer | zyga: I see.. so this links with the other part of the code | 17:43 |
| niemeyer | zyga: Regarding the comment below on "Curious that this isn't the case for files. What's the catch?" | 17:44 |
| zyga | hold on, I didn't read that comment yet | 17:44 |
| Son_Goku | ikey: noooo | 17:44 |
| zyga | ah | 17:44 |
| niemeyer | zyga: Looks like a special case is creating more special cases | 17:44 |
| ikey | lol @ describing hacker news | 17:45 |
| Son_Goku | ikey: http://kinginuyasha.enanocms.org/downloads/0001-packaging-fedora-Enable-support-for-the-NVIDIA-propr.patch | 17:45 |
| Son_Goku | there, fixed title | 17:45 |
| ikey | but it runs off | 17:45 |
| zyga | niemeyer: files and directories are completely created by secureMk* helpers, you end up with the complete thing, the error is correct if something goes wrong | 17:45 |
| ikey | like a terrified thomas the tank engine suddenly bereft of child to push it | 17:45 |
| niemeyer | zyga: I understand :) | 17:45 |
| Son_Goku | ikey: it won't run off in GH | 17:45 |
| zyga | niemeyer: for symlinks we don't have a helper like that, we use the secure dir helper to create the parent, that's it | 17:45 |
| Son_Goku | and that's all that matters :) | 17:45 |
| ikey | Son_Goku, but zyga didnt give me a yay | 17:46 |
| niemeyer | zyga: These comments are supposed to raise awareness and discuss ceratin things | 17:46 |
| Son_Goku | zyga: >:| | 17:46 |
| niemeyer | zyga: I can tell that createFlie creates a file :) | 17:46 |
| ikey | lol.. | 17:46 |
| Son_Goku | damn it, I've burned my entire lunch period on this :( | 17:46 |
| Son_Goku | I gotta go get food | 17:46 |
| niemeyer | zyga: 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 cases | 17:47 |
| ikey | disappear, its not like i do anything or go anywhere | 17:47 |
| niemeyer | zyga: This is part of the reason why we get white hair | 17:47 |
| zyga | niemeyer: but we reuse code that was reviewed for security, this is deliberate | 17:47 |
| niemeyer | zyga: /o | 17:47 |
| niemeyer | \ | 17:47 |
| zyga | niemeyer: I think it can be simplified but post 2.31, by doing the "look before you try" | 17:47 |
| zyga | then we can drop the low-level perform exception paths | 17:47 |
| zyga | and the special case for symlink will go away | 17:48 |
| niemeyer | zyga: We can do whatever we want later, sure.. but we want this logic to not suck to begin wiht | 17:48 |
| niemeyer | zyga: https://hangouts.google.com/hangouts/_/canonical.com/snappy-devel?authuser=1 | 17:49 |
| zyga | joining | 17:50 |
| zyga | or | 17:50 |
| zyga | joined | 17:50 |
| zyga | empty? | 17:50 |
| niemeyer | That's also part of why we get white hair | 17:50 |
| zyga | niemeyer: can you hear me | 17:50 |
| cachio | zyga, I am installing uuid-runtime package in a snap and it is not starting the uuid daemon | 17:55 |
| cachio | zyga, should it happen automatically as if I install the deb package, or I need to manually do it ? | 17:55 |
| sergiusens | how 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 |
| niemeyer | sergiusens: Looks like you have a completely broken snap | 18:05 |
| niemeyer | sergiusens: you should use snapcraft ;P | 18:05 |
| bdx | hey, random question, has the concept of "serverless snaps" ever been discussed? | 18:08 |
| zyga | cachio, ikey, Pharaoh_Atem: I if you can wait for a few quarters I would like to finish this branch for 2.31 first please | 18:09 |
| cachio | zyga, sure | 18:09 |
| ikey | quarters? | 18:09 |
| Pharaoh_Atem | quarters? | 18:09 |
| nacc | bdx: what do you mean by that? | 18:09 |
| cachio | mvo, I am installing uuid-runtime package in a snap and it is not starting the uuid daemon | 18:09 |
| ikey | like, a few quarters would be years | 18:09 |
| * ikey is puzzled | 18:09 | |
| cachio | mvo, should it happen automatically as if I install the deb package, or I need to manually do it ? | 18:09 |
| nacc | Pharaoh_Atem: ikey was responding to zyga | 18:10 |
| cachio | mvo, should I do it with the configure hook? | 18:10 |
| zyga | hmmm hmm sorry, | 18:10 |
| bdx | nacc: like a snap that is built to run on a serverless architecture | 18:10 |
| Pharaoh_Atem | nacc: I was highlighted too? | 18:10 |
| zyga | I meant few multiples of 15 minutes | 18:10 |
| ikey | oh | 18:10 |
| ikey | xD | 18:10 |
| zyga | how do I say that properly? | 18:10 |
| Pharaoh_Atem | ahhh | 18:10 |
| Pharaoh_Atem | quarters is right, it's just no one says it | 18:10 |
| Pharaoh_Atem | in that context | 18:10 |
| ikey | idk id say like "half hour" "45 minutes" "feck off im busy" | 18:11 |
| zyga | :D | 18:11 |
| ikey | etc | 18:11 |
| cachio | mvo, or in a wrapper? | 18:11 |
| * zyga hugs ikey | 18:11 | |
| zyga | ikey: yes, go push | 18:11 |
| nacc | bdx: you mean without a store? | 18:11 |
| * ikey doesn't do normal though | 18:11 | |
| ikey | lol | 18:11 |
| zyga | cachio: 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 through | 18:12 | |
| cachio | zyga, I want to test that | 18:12 |
| niemeyer | nacc: No, he's likely thinking of Google AppEngine, Amazon Lambda, etc | 18:12 |
| nacc | niemeyer: oh | 18:13 |
| nacc | niemeyer: seems like you'd have a better answer for that than me :) | 18:13 |
| niemeyer | bdx: 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 |
| nacc | heh | 18:13 |
| bdx | take aws lambda for example | 18:13 |
| niemeyer | bdx: We've been working from day one with the idea of minimalist operating systems that are built entirely around the idea of snaps | 18:14 |
| bdx | ahh I guess it wouldnt be a snap because a snap needs snapd huh | 18:14 |
| bdx | ahh I see | 18:14 |
| niemeyer | bdx: That's what Ubuntu Core is, for example.. there's very little other than snaps in the machine | 18:15 |
| ogra_ | cachio, cat /proc/sys/kernel/random/uuid | 18:15 |
| ogra_ | (if your snap has access to that node indeed) | 18:15 |
| bdx | niemeyer: totally, I see | 18:15 |
| niemeyer | bdx: Even the root filesystem itself is a snap, so read-only and mostly unchangeable | 18:15 |
| * ikey suddenly twigs that all parts of ubuntu core are segregated into domains with ACL and is impressed | 18:16 | |
| zyga | cachio: test the daemon? | 18:16 |
| bdx | niemeyer: | 18:16 |
| bdx | I see | 18:16 |
| zyga | ogra_: yep, thanks! cachio, that was my suggestion (I didn't spell it out) | 18:16 |
| cachio | zyga, I need to see if the daemon is able to read from /run/uuidd/request | 18:17 |
| ogra_ | cachio, then our snap will need an app entry for the daemon | 18:17 |
| ogra_ | in snapcraft.yaml | 18:17 |
| zyga | cachio: I see, that's for some interface test? | 18:18 |
| cachio | zyga, yes | 18:18 |
| bdx | nacc, 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 frameworks | 18:18 |
| mup | PR snapd#4569 opened: osutil: add ContextWriter and RunWithContext helpers <Created by chipaca> <https://github.com/snapcore/snapd/pull/4569> | 18:18 |
| nacc | bdx: sure, interesting question | 18:18 |
| cachio | I have the service script in /etc/init.d/uuid | 18:19 |
| ogra_ | yeah, not useful | 18:19 |
| ogra_ | check what the iit.d script calls and translate that into an app entry | 18:20 |
| ogra_ | see the bottom of https://forum.snapcraft.io/t/how-to-set-hwclock-on-a-realtime-clock/3684 | 18:20 |
| sergiusens | niemeyer 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 |
| sergiusens | I still see the issue | 18:20 |
| niemeyer | bdx: Yeah, it's a nice idea, but that kind of platform almost always requires custom coding towards it | 18:20 |
| bdx | entirely | 18:21 |
| niemeyer | bdx: Which conflicts a bit with the underlying goal of snaps.. snaps need to support people's software as their developers choose to work | 18:21 |
| niemeyer | This is also an advantage, as the approach encourages less lock in | 18:22 |
| bdx | right, 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 platform | 18:23 |
| bdx | https://github.com/Miserlou/Zappa/#how-zappa-makes-packages | 18:23 |
| niemeyer | bdx: Sure, that would work fine.. but most of the problem of creating a "serverless" platform is still there | 18:24 |
| bdx | zappa (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 |
| cachio | ogra_, trying that, tx | 18:24 |
| bdx | but other serverless frameworks will build the deps on a docker target platform and etc etc | 18:24 |
| niemeyer | bdx: I doubt it | 18:24 |
| bdx | ? | 18:25 |
| niemeyer | bdx: 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 world | 18:26 |
| bdx | ah yes | 18:26 |
| niemeyer | bdx: You can put that software inside a snap, docker image, rpm, deb, tarball.. it matters little | 18:26 |
| bdx | totally | 18:26 |
| niemeyer | bdx: It ends up just as an implementation detail on something that you need to cook for from the ground up | 18:27 |
| niemeyer | bdx: You could use snaps as a lightweight confined space for the application, but that would be 3% of the problem IMO | 18:27 |
| bdx | so 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 do | 18:28 |
| bdx | just an idea | 18:29 |
| bdx | niemeyer: thanks for the insight | 18:30 |
| bdx | nacc: ^ | 18:31 |
| niemeyer | bdx: No problem.. and yeah, the packaging is indeed the easy part of serverless, but it's also the hard part of solving software distribution | 18:31 |
| niemeyer | bdx: We focus on the latter | 18:31 |
| bdx | I see that, totally | 18:31 |
| niemeyer | bdx: As a side note, I deploy all of the services I'm responsible for as snaps in tiny machines | 18:31 |
| niemeyer | bdx: Not serverless, but cheaper than serverless, and almost as neat | 18:32 |
| niemeyer | bdx: and nicer, from the perspective of giving me freedom of technology | 18:32 |
| ikey | yay for marketing misnomers | 18:32 |
| ikey | "serverless" | 18:32 |
| bdx | neimeyer: totally | 18:32 |
| zyga | ikey: I will drop my job and work electricityless cloud | 18:33 |
| niemeyer | ikey: It's like "sugar free".. :) | 18:33 |
| zyga | I will call it "BYOM" | 18:33 |
| ikey | niemeyer, nah that one makes sense | 18:33 |
| ikey | they don't charge you any extra for the sugar | 18:33 |
| niemeyer | ikey: Until you figure what they use instead | 18:33 |
| ikey | mm | 18:33 |
| zyga | niemeyer: please have another look | 18:34 |
| zyga | niemeyer: I'll double check I didn't miss anything | 18:34 |
| niemeyer | zyga: Thanks | 18:34 |
| ikey | btw apparmor made my boot slow. :P | 18:34 |
| ikey | its half of my boot time in a VM now | 18:34 |
| zyga | I will do the proper secure symlink next, though it won't affect this code, just the implementation of secureMklinkAll | 18:34 |
| ogra_ | assertions assertions ... | 18:34 |
| zyga | ikey: caching can be improved | 18:34 |
| ikey | im tackling it this week | 18:34 |
| zyga | ikey: apparmor has a cache, maybe you're not using it? | 18:34 |
| ikey | solus isn't known for slow boot lol | 18:34 |
| zyga | ikey: each time a profile is compiled it can (optionally) be cached | 18:35 |
| zyga | ikey: also loads can use cache (even exclusively, without compilation) | 18:35 |
| ikey | ya im gonna teach usysconf to recompile them | 18:35 |
| ikey | and then an early unit to load the cache | 18:35 |
| ikey | already got plans, just wanted to complain :P | 18:35 |
| zyga | niemeyer: I think it's all done (except the ", or create" typo I didn't push to let this spread batch finish) | 18:38 |
| zyga | niemeyer: I'll work on itty bitty more secure mksymlink now that I have it un utils | 18:38 |
| zyga | niemeyer: oh, and one more thing, please look at the new spread test as well | 18:39 |
| zyga | I'll warm my tea up and be back in a moment | 18:39 |
| niemeyer | zyga: Haven't seen the test, but what I've seen look GREAT, thank you! | 18:40 |
| niemeyer | zyga: Just one final note there and LGTM | 18:40 |
| zyga | niemeyer: thank *you* :) | 18:40 |
| zyga | niemeyer: 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 |
| niemeyer | zyga: I don't understand what the code is suggesting right now | 18:46 |
| niemeyer | zyga: It surely doesn't seem sensible to create symlinks with completely wrong values | 18:47 |
| niemeyer | zyga: Sending garbage to the kernel for validation is unwise | 18:47 |
| zyga | Chipaca: problem with snap validation (CC sergiusens) | 18:49 |
| sergiusens | posted to the forum | 18:51 |
| zyga | mvo: ^ we may need rc3 if we relase with this bug | 18:52 |
| zyga | https://forum.snapcraft.io/t/snap-is-unusable-due-to-missing-files-contact-developer-i-am-the-developer-no-idea-what-to-do/3771 | 18:52 |
| zyga | now that this is approved I will pull in unit tests, too many changes for critical feature not to test this | 18:53 |
| zyga | I'll make a separate PR and mark it for 2.31 | 18:53 |
| zyga | mvo: do you plan to release tonight? | 18:53 |
| sergiusens | stgraber 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 |
| sergiusens | sorry, bad first root causing of that, there are aliases, but `lxc launch ubuntu:xenial` does not work, using `images:` does | 19:09 |
| sergiusens | confirmed that the aliases are there `lxc image info ubuntu:069b95ed3a60` | 19:10 |
| zyga | ah, I know what I broke now ^_^ | 19:13 |
| sergiusens | stgraber a reinstall of the snap solved it, but I disabled ipv6 and switched from zfs to dir | 19:14 |
| cprov | elopio: 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 |
| elopio | cprov: yes, give me a minute. I'm sorry we broke you :S | 19:31 |
| cprov | elopio: no worries, in theory, it's much simpler to do what we need now | 19:32 |
| elopio | cprov: 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 |
| elopio | maybe it's that. I'm digging into the logs. | 19:34 |
| cprov | elopio: `error: cannot open: "snaps-cache/snapcraft-prfalse.snap"` from `sudo snap install snaps-cache/snapcraft-pr$TRAVIS_PULL_REQUEST.snap --dangerous --classic`, I assume | 19:35 |
| elopio | cprov: can you show me the script that you are calling to trigger the api? | 19:36 |
| cprov | elopio: moreover I don't think we need the snapcraft snap installed to run `snapcraft/tests/integration/store` tests, do we ? | 19:37 |
| elopio | cprov: yes, it uses the snapcraft command. What you don't need is to build the snap, you could just install from edge. | 19:38 |
| elopio | cprov: 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 |
| cprov | elopio: the job you linked was the 'old' way that didn't consider stages, it was running everything and taking 4h+ | 19:40 |
| elopio | right. We could readd the skips, and make sure that we install from edge, not from cache. | 19:42 |
| elopio | cprov: so, you added that "stage" keyword? | 19:45 |
| * zyga eats supper, secure symlink helper almost done :) | 19:45 | |
| mup | PR snapcraft#1893 opened: cli: use C.UTF-8 if locale not set <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1893> | 19:46 |
| cprov | elopio: yes, I am overriding 'jobs' completely, but the 'cache' config is preserved, I think I just don't have perms to access it | 19:47 |
| elopio | cprov: what would you think about this? https://paste.ubuntu.com/26491166/ | 19:53 |
| elopio | you send SNAPCRAFT_COMMAND_INSTALL="sudo snap install snapcraft --edge --classic" | 19:53 |
| Chipaca | sergiusens: journalctl -u snapd | grep container <- should show you the errors from 'snap try' | 19:55 |
| Chipaca | sergiusens: I'll push a PR to make snap try log to stderr instead of journal, I think | 19:55 |
| Chipaca | but not today, mostly because I think it might be tricky :-) | 19:56 |
| ali1234 | is there an example of snapping a php/composer application? | 19:56 |
| cprov | elopio: looks good, let me know when it lands in trunk | 19:56 |
| zyga | re, :) | 20:05 |
| zyga | one last patch and I'm goooood :) | 20:05 |
| zyga | and I celebrate | 20:05 |
| elopio | kyrofa: cprov: https://github.com/snapcore/snapcraft/pull/1894 | 20:07 |
| mup | PR snapcraft#1894: tests: allow to overwrite the snapcraft install command <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1894> | 20:07 |
| elopio | please double check my bash ^_^ | 20:07 |
| mup | PR snapcraft#1894 opened: tests: allow to overwrite the snapcraft install command <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1894> | 20:08 |
| stgraber | sergiusens: 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 issue | 20:25 |
| zyga | SIGH | 20:25 |
| zyga | there is no syscall.Symlinkat in golang | 20:25 |
| zyga | .. but why golang, why :/ | 20:28 |
| Chipaca | zyga: because it's in x/sys/unix | 20:32 |
| Chipaca | zyga: but before you get too excited, that means it's not buildable on ppc | 20:33 |
| zyga | Chipaca: I just found https://github.com/golang/sys/blob/master/unix/zsyscall_linux_amd64.go#L111 | 20:33 |
| zyga | thank you for pointing out x/sys/unix, let me see if it works | 20:34 |
| zyga | I need it | 20:34 |
| zyga | or I need that single generated function | 20:34 |
| Chipaca | zyga: grab the generated one for now until we drop ppc | 20:34 |
| zyga | Chipaca: yeah, sounds like a plan | 20:35 |
| Chipaca | zyga: but | 20:35 |
| Chipaca | zyga: SYS_SYMLINKAT will be per-something | 20:35 |
| Chipaca | but you have a ppc box so you should be able to figure it out | 20:36 |
| zyga | hehe yes :) | 20:36 |
| zyga | it's allright | 20:36 |
| Chipaca | the weirder ones might require you go grep includes :-) | 20:37 |
| zyga | Chipaca: or ... you know... put - | 20:37 |
| zyga | -1 | 20:37 |
| zyga | not that someone will test them, right? | 20:37 |
| zyga | ;-) | 20:38 |
| Chipaca | zyga: autopackagetest is a harsh mistress | 20:38 |
| Chipaca | autopkgtest* | 20:38 |
| Chipaca | haven't seen it fail in too long, already forgetting its face | 20:38 |
| zyga | offtopic | 20:38 |
| mvo | Chipaca: 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-speed | 20:38 |
| zyga | // mksyscall.pl -tags linux,amd64 syscall_linux.go syscall_linux_amd64.go | 20:38 |
| zyga | FRELLING PERL? | 20:38 |
| Chipaca | zyga: ideal for the job | 20:39 |
| zyga | Chipaca: ... but... python | 20:39 |
| Chipaca | frobbing text? hell yeah perl | 20:39 |
| zyga | hell no cobol | 20:39 |
| Chipaca | zyga: not as widely available as perl | 20:39 |
| zyga | it's like cobol but misassociated wiht the text tool | 20:39 |
| zyga | Chipaca: not buying that | 20:39 |
| Chipaca | mvo: the snap wouldn't work with the older snapd | 20:39 |
| zyga | Chipaca: especially at google where they don't give a *** about non google arches | 20:39 |
| Chipaca | mvo: (i know not only because i wrote the verifier, i also checked :-) ) | 20:40 |
| Chipaca | zyga: ¯\_(ツ)_/¯ | 20:40 |
| mvo | Chipaca: ok, so anything that needs to be done for 2.31 there? or can I ignore it for 2.31? | 20:40 |
| Chipaca | zyga: 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 heart | 20:40 |
| zyga | Chipaca: I mean python works anywhere, BSDs, windows, macos, you name it | 20:41 |
| Chipaca | mvo: there's an argument for making 'snap try' write the errors to stderr for the same reasons 'snap pack' does | 20:41 |
| zyga | it's not like it's less portable than perl | 20:41 |
| zyga | and people who write competent perl are ... older | 20:41 |
| Chipaca | zyga: you're talking about people that worked on the implementation of plan 9 | 20:41 |
| zyga | oh | 20:42 |
| mvo | Chipaca: that sounds reasonable, is that something I should wait for? i.e. will it happen soon(ish)? | 20:42 |
| Chipaca | zyga: I don't think they think perl is for older people | 20:42 |
| zyga | that's a very valid point | 20:42 |
| mvo | Chipaca: i.e. before tomorrow lunchtime :) | 20:42 |
| zyga | Chipaca: perl is that new thing :) | 20:42 |
| Chipaca | mvo: it's not going to be a simple change | 20:42 |
| mvo | Chipaca: ok, then I will not wait | 20:42 |
| mvo | Chipaca: out of curiosity, why is it not simple? | 20:42 |
| Chipaca | mvo: there's another argument for changing the error message | 20:42 |
| Chipaca | mvo: but nobody has suggested changing it to _what_ :-) | 20:42 |
| Chipaca | mvo: 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 them | 20:43 |
| mvo | Chipaca: meh, sounds horrible. ok | 20:43 |
| zyga | Chipaca: just error with the 1st error :) | 20:44 |
| Chipaca | tasks 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 |
| mvo | Chipaca: I will ignore this for now until I'm told otherwise. especially if this is a broken snap (not a false positive) | 20:44 |
| Chipaca | I _could_ make the whole thing die, yes | 20:44 |
| zyga | Chipaca: we don't vendor x/sys/unix today, do we? | 20:44 |
| Chipaca | return strings.Join(allTheErrors, " ¯\_(ツ)_/¯ ") | 20:44 |
| zyga | it'd be a re-addition? | 20:45 |
| mvo | Chipaca: its all good, I need to rest anyway | 20:45 |
| Chipaca | zyga: it does not build on ppc | 20:45 |
| cachio_ | mvo, is rc2 comming? | 20:45 |
| zyga | meh meh | 20:45 |
| zyga | ok | 20:45 |
| mvo | cachio_: :( tomorrow, sorry | 20:45 |
| zyga | I think today is my time | 20:45 |
| Chipaca | zyga: i'm sure they take patches though | 20:45 |
| zyga | I'll watch and merge 4471 | 20:45 |
| mvo | cachio_: there is this one PR from zyga that we want in | 20:45 |
| zyga | and fight the symlinkat problem tomorrow | 20:45 |
| zyga | Chipaca: as self-documenting perl files ;) | 20:45 |
| cachio_ | mvo, sure | 20:45 |
| Chipaca | zyga: hey, i've written literate perl | 20:46 |
| Chipaca | zyga: wait | 20:46 |
| Chipaca | zyga: you called me old! | 20:46 |
| * Chipaca is old | 20:46 | |
| cachio_ | hehehe | 20: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.html | 20:47 | |
| * cachio_ laugh | 20:47 | |
| zyga | OMG :D | 20:47 |
| zyga | the journey of each generation | 20:48 |
| Chipaca | the internet does not forget | 20:48 |
| Chipaca | sadly | 20:48 |
| zyga | ok | 20:49 |
| zyga | I'll break now | 20:49 |
| zyga | travis is stuck | 20:49 |
| zyga | please merge 4471 if green | 20:49 |
| pedronis | Chipaca: did you see the original code was about java and PATH: $SNAP/... ? I suppose it doesn't change anything | 20:59 |
| Chipaca | pedronis: yes; the commands are not looked up in the path | 20:59 |
| Chipaca | that seems to be the source of the problem | 21:00 |
| Chipaca | or rather, of the misunderstanding | 21:01 |
| Chipaca | sergiusens: you around? | 21:24 |
| Chipaca | zyga: 4471 not green | 21:31 |
| Chipaca | getting lots of failed prepare project :-( | 21:31 |
| zyga | yeah :/ | 21:31 |
| zyga | I'm watching | 21:31 |
| zyga | like a western with intense action :/// | 21:32 |
| sergiusens | Chipaca at the snapcraft summit currently, might be faster if we do a call | 21:38 |
| Chipaca | sergiusens: I should be in bed. Tomorrow? | 21:39 |
| sergiusens | Chipaca 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 snap | 21:41 |
| Chipaca | sergiusens: thanks | 21:41 |
| sergiusens | tabs are for UI purposes | 21:41 |
| Chipaca | sergiusens: _vertical_ tabs? | 21:41 |
| sergiusens | Chipaca yes | 21:42 |
| Chipaca | 013 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 |
| Chipaca | ok :-) | 21:42 |
| zyga | + tar -C/ -xf /home/gopath/src/github.com/snapcore/snapd/snapd-state.tar.gz | 21:44 |
| zyga | tar: /home/gopath/src/github.com/snapcore/snapd/snapd-state.tar.gz: Cannot open: No such file or directory | 21:44 |
| zyga | hmmmmm | 21:44 |
| Chipaca | zyga: everything is terrible | 21:49 |
| zyga | Chipaca: mvo will _love_ the release tomorrow | 21:50 |
| zyga | wililupy: 11 | 21:50 |
| zyga | (also known as window 11) | 21:50 |
| wililupy | ? | 21:51 |
| zyga | wililupy: sorry, bad tab completion | 21:53 |
| zyga | THERE IS NO MISSILE INCOMING TO HAWAII | 21:53 |
| wililupy | zyga: no worries ha | 21:53 |
| mup | PR snapcraft#1895 opened: docker: beta should use beta, edge use edge <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1895> | 22:20 |
| mup | PR 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 |
| mup | PR 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 |
| mup | PR 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 |
| cprov | sergiusens: thanks, let me try the test suite hack | 22:44 |
| nacc | so i've got a snap (git-ubuntu) that builds its own python3 (we need a version more recent than 16.04's) | 23:28 |
| nacc | what is the "right" way to CI the code upstream so that our tests are running against hte version in the snap | 23:28 |
| mup | PR snapcraft#1896 opened: elf: do not strip rpaths that contain $ORIGIN <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1896> | 23:41 |
| mup | PR 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!