| mup | PR # closed: snapd#3734, snapd#3916, snapd#3963, snapd#3992, snapd#3994, snapd#3998, snapd#4013, snapd#4040, snapd#4049, snapd#4059, snapd#4063, snapd#4064, snapd#4068, snapd#4073, snapd#4076, snapd#4078, snapd#4100, snapd#4102, snapd#4103, snapd#4104, snapd#4106 | 00:03 |
|---|---|---|
| mup | PR # opened: snapd#3734, snapd#3916, snapd#3963, snapd#3992, snapd#3994, snapd#3998, snapd#4013, snapd#4040, snapd#4049, snapd#4059, snapd#4063, snapd#4064, snapd#4068, snapd#4073, snapd#4076, snapd#4078, snapd#4100, snapd#4102, snapd#4103, snapd#4104, snapd#4106 | 00:04 |
| Son_Goku | that's... a lot of pulls | 01:13 |
| === ikey is now known as ikey|zzz | ||
| === JoshStrobl is now known as JoshStrobl|Away | ||
| === JoshStrobl|Away is now known as JoshStrobl | ||
| zyga-ubuntu | good morning | 07:28 |
| zyga-ubuntu | man, it's a nice and sunny 1C day over here :) | 07:28 |
| zyga-ubuntu | quiet day... | 08:03 |
| zyga-ubuntu | /exit | 08:19 |
| zyga-solus | one IRC is enough today | 08:19 |
| === LarreaMikel1 is now known as LarreaMikel | ||
| mup | PR snapd#4108 opened: repo: ConnectedPlug and ConnectedSlot types <Created by stolowski> <https://github.com/snapcore/snapd/pull/4108> | 09:01 |
| zyga-solus | pstolowski: hey, thank you for 4108 | 09:05 |
| zyga-solus | pstolowski: do you think you could write some text in the PR description to help reviewers understand what is going on more clearly? | 09:05 |
| pstolowski | zyga-solus, added a few more info to the second paragraph of the description, not sure if there is anything else unclear (the link to the forum topic is also helpful) | 09:11 |
| zyga-solus | pstolowski: "add new data types for connected plugs/slots"? | 09:12 |
| zyga-solus | this is a bit terse for ~1K diff | 09:12 |
| pedronis | pstolowski: hi, what's blocking #4013 ? | 09:13 |
| mup | PR #4013: repo, daemon: use PlugInfo, SlotInfo <Created by stolowski> <https://github.com/snapcore/snapd/pull/4013> | 09:13 |
| pstolowski | zyga-solus, see pt. 5 of the plan | 09:13 |
| zyga-solus | pstolowski: I think that kind of stuff should be in the PR | 09:13 |
| pedronis | it will not be that big in 4013 gets in | 09:14 |
| pedronis | s/in 4013/if 4013/ | 09:14 |
| pstolowski | zyga-solus, ah, sorry. i was still referring to the description of 4013. you're talking about 4108. | 09:16 |
| zyga-solus | pstolowski: yes, sorry :) | 09:16 |
| pstolowski | zyga-solus, will expand it, yes | 09:16 |
| zyga-solus | thank you! | 09:16 |
| pstolowski | pedronis, i hope three is nothing blocking 4013 once zyga-solus approves | 09:16 |
| pedronis | pstolowski: tests are red though? | 09:17 |
| zyga-solus | I will look at 4013 soon | 09:17 |
| pstolowski | pedronis, linode:ubuntu-core-16-64:tests/main/snap-seccomp failed, 1369 passed, 1 failure. it failed on matching libs with ldd. | 09:20 |
| pstolowski | pedronis, will restart them | 09:20 |
| pstolowski | zyga-solus, and yes, as pedronis said, 4108 will actually be small | 09:21 |
| pedronis | no mvo today? | 09:37 |
| zyga-solus | pedronis: no, he is off today and tomorrow | 09:38 |
| pedronis | ah | 09:39 |
| ogra_ | pedronis, germany is celebrating nailing of paper to a church door today ... | 09:41 |
| Son_Goku | ? | 09:42 |
| pedronis | https://en.wikipedia.org/wiki/Reformation_Day (I think) | 09:43 |
| ogra_ | Son_Goku, google martin luther ... | 09:43 |
| Son_Goku | oh right | 09:43 |
| Son_Goku | we don't recognize it in the USA | 09:44 |
| Son_Goku | but I knew it was a thing | 09:44 |
| ogra_ | the northern parts of germany are all protestant (that is why we complain so much i guess) | 09:46 |
| pedronis | Chipaca: hi, a review of #4106 would be appreciated when you have time | 10:16 |
| mup | PR #4106: many: lookup and use the URL from a store assertion if one is set for use <Created by pedronis> <https://github.com/snapcore/snapd/pull/4106> | 10:16 |
| zyga-solus | man, logging | 10:38 |
| zyga-solus | on the upside I get to the point where tmpfs is usable | 10:39 |
| zyga-solus | but I found another place where logging breaks | 10:39 |
| zyga-solus | and what I do now feels like laying a set of extension cords across the stac k | 10:39 |
| === LarreaMikel1 is now known as LarreaMikel | ||
| * zyga-solus lunch | 11:26 | |
| jdstrand | mwhudson: there have been a lot of issues with nvidia (re https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880174). I'm not sure who has been focusing on those issues lately. historically it's been zyga-solus and mvo iirc | 12:30 |
| jdstrand | I know oSoMoN has been affected of late. I don't know if he has looked at it in depth | 12:31 |
| === wgrant_ is now known as wgrant | ||
| zyga-solus | I think debian needs updates | 12:31 |
| * sergiusens goes for a walk | 12:32 | |
| oSoMoN | jdstrand, I have tried to get feedback from users with nvidia hw (I don't have any myself), but nothing conclusive so far | 12:46 |
| flexiondotorg | om26er: Would you like to move Android Studio to Snapcrafters? | 12:50 |
| om26er | sure @flexiondotorg | 12:55 |
| flexiondotorg | Cool. | 12:55 |
| flexiondotorg | Just reply on the fourm. | 12:55 |
| flexiondotorg | Oops. | 12:55 |
| flexiondotorg | I'm just replying on the forum :-) | 12:55 |
| flexiondotorg | @om26er I've not used ANdroid Studio myself. Do you know if it interfaces with fastboot or adb? | 12:57 |
| nothal | flexiondotorg: No such command! | 12:57 |
| pedronis | Chipaca: standup? | 13:01 |
| Chipaca | oh hello 2fa | 13:08 |
| Chipaca | no not even 2fa | 13:08 |
| om26er | flexiondotorg: it does ship adb/fastboot with it, yes. | 13:08 |
| om26er | when you say "interfaces" is that in the terminologies of snapd ? | 13:08 |
| om26er | (and sorry for the late reply, I was driving) | 13:08 |
| flexiondotorg | om26er: Thanks. I suspected as much. | 13:08 |
| flexiondotorg | Yes, in the forum post I am referring to snap interfaces. | 13:09 |
| === ikey|zzz is now known as ikey | ||
| flexiondotorg | @om26er No problem. I just got round to this on my job list :-) | 13:09 |
| nothal | flexiondotorg: No such command! | 13:09 |
| om26er | flexiondotorg: replied. | 13:12 |
| flexiondotorg | Cheers. I'll import it when you've had the chance to add the README :-) | 13:12 |
| zyga-solus | cachio: so about debian, as I said I don't see the thing in sysfs but I didn't google or search in the kernel tree to see what makes that sysfs available | 13:16 |
| cachio | zyga-solus, ok, I'll try to see what is missing | 13:17 |
| Chipaca | pedronis: AFAICT we are not doing gzip | 13:18 |
| zyga-solus | pstolowski: I'll get a coffee/tea and I'll do one more pass through 4013 | 13:18 |
| pedronis | Chipaca: is it worth it? something to look into? | 13:18 |
| pedronis | at least for this API | 13:18 |
| pstolowski | zyga-solus, thanks! | 13:18 |
| Chipaca | pedronis: AFAICT², golang's standard library doesn't do it -- i guess they figure you should just use http2? | 13:19 |
| zyga-solus | jdstrand: I have a tmpfs+bindmount fallback now but I need to address a few shortcomings (files and broken undo) | 13:19 |
| zyga-solus | jdstrand: I ran into a number of odd cases where denials are not logged | 13:19 |
| zyga-solus | jdstrand: what do I need to do to enable that? | 13:19 |
| pedronis | Chipaca: fun | 13:19 |
| Chipaca | pedronis: there was something about https + gzip == bad, but i don't remember | 13:19 |
| pedronis | Chipaca: https://en.wikipedia.org/wiki/BREACH ? | 13:22 |
| zyga-solus | 21st century, the day where security exploits are commonplace but at least we give a random one cool name, icon and website | 13:23 |
| * sergiusens is back | 13:31 | |
| Chipaca | pedronis: sounds like it | 13:32 |
| Chipaca | zyga-solus: we are tribal animals; names and stories are how we learn | 13:32 |
| pedronis | Chipaca: anyway not clear the attack is relevant for the content of here, anyway in this case the request doesnt' strictly need to be https, that's just our default | 13:33 |
| Chipaca | zyga-solus: also punches to the face, but i'd rather names and stories | 13:33 |
| zyga-solus | Chipaca: we need to paint those cave walls with shellcode | 13:33 |
| zyga-solus | Chipaca: don't forget chanting and smoking various substances ;) | 13:33 |
| Chipaca | zyga-solus: sshhh | 13:34 |
| om26er | flexiondotorg: added the README, we can improve from there: https://github.com/om26er/android-studio-snap | 13:37 |
| om26er | so whats the update story for this ? When a new version arrives would I need to notify snapcrafters ? | 13:47 |
| sergiusens | stgraber do you know if that snapd/systemd nice issue is gone with the latest snapd requiring privileged containers? | 13:49 |
| zyga-solus | pstolowski: about 4013, can you please add docstrings to all the new public things? | 13:49 |
| pstolowski | zyga-solus, ok, doing | 13:50 |
| zyga-solus | pstolowski: I'll provide ideas | 13:50 |
| zyga-solus | pstolowski: if you wait ~20 min | 13:50 |
| pstolowski | zyga-solus, let me push something, just let me know if you have better descriptions | 13:52 |
| zyga-solus | kk | 13:52 |
| zyga-solus | on the upside, I found the missing SNAPD_DEBUG bridge | 13:54 |
| Facu | sergiusens, elopio, may I get re-reviews on this? https://github.com/snapcore/snapcraft/pull/1634 thanks! | 14:01 |
| mup | PR snapcraft#1634: Push metadata to the Store <Created by facundobatista> <https://github.com/snapcore/snapcraft/pull/1634> | 14:01 |
| Facu | roadmr, ^ | 14:01 |
| mup | PR snapcraft#1644 closed: lxd: fix the push in container builds <bug> <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1644> | 14:01 |
| zyga-solus | pstolowski: done | 14:03 |
| zyga-solus | and I fixed a silly bug in my code, swapped mount args :D | 14:04 |
| jdstrand | zyga-solus: if there are explicit deny rules, prepend them with 'audit' to log them (eg: audit deny /path/to/... r,). or disable rate limiting: sudo sysctl -w kernel.printk_ratelimit=0 | 14:08 |
| zyga-solus | ah | 14:09 |
| zyga-solus | rate limiting fixed it | 14:09 |
| zyga-solus | thank you! | 14:09 |
| zyga-solus | :) | 14:09 |
| zyga-solus | man, I feel like turning the light on | 14:09 |
| zyga-solus | working in the blind was annoying | 14:09 |
| zyga-solus | jdstrand: so, any reason not to disable rate limiting in spread in general? | 14:11 |
| jdstrand | zyga-solus: I thought we were. istr sending something up that did that | 14:12 |
| zyga-solus | nope, I just got the logs to work when I ran the command myself | 14:12 |
| zyga-solus | I'll include this as a RFC PR to consider | 14:13 |
| jdstrand | zyga-solus: it is commented out of tests/lib/prepare.sh | 14:13 |
| zyga-solus | I see | 14:13 |
| zyga-solus | reading the forum | 14:13 |
| zyga-solus | thank you, I'll check that out after this PR | 14:14 |
| zyga-solus | jdstrand: do you hae time to look at one function today? | 14:14 |
| zyga-solus | jdstrand: not a security review, just a sanity check | 14:14 |
| jdstrand | zyga-solus: I can do that | 14:15 |
| zyga-solus | jdstrand: can you please fetch my remote and look at feature/transparent-tmpfs, look at cmd/snap-update-ns/utils.go createWritableMimic | 14:17 |
| roadmr | Facu: yay thanks! | 14:17 |
| sergiusens | Facu we are trying to wrap up our 2.35 milestone, I've marked that as 2.36 so it might be something for next week | 14:17 |
| stgraber | sergiusens: pretty sure the systemd SRU has been published | 14:19 |
| Facu | sergiusens, perfect, thanks! | 14:20 |
| * Chipaca needs to step out for a while, will bbl | 14:21 | |
| sergiusens | stgraber great, I will try and remove our workarounds for travis and see how it goes | 14:26 |
| zyga-ubuntu | "cannot parse mountinfo of the current process | 14:39 |
| zyga-solus | well | 14:43 |
| zyga-solus | nobody said it would be boring :) | 14:43 |
| zyga-solus | ha | 14:50 |
| zyga-solus | found a cute mountinfo parsing bug now :) | 14:50 |
| zyga-solus | but also, kernel is not hepful here :) | 14:50 |
| kyrofa | elopio, how is autopkgtest looking this morning? | 15:07 |
| kyrofa | snappy-m-o, autopkgtest 1583 xenial:amd64 | 15:08 |
| snappy-m-o | kyrofa: I've just triggered your test. | 15:08 |
| elopio | kyrofa: I really really hope it's good. I'll update the one for adt-lxd, It's so close... | 15:09 |
| kyrofa | Good deal. Everything I know about has been merged, so let's see... | 15:10 |
| kyrofa | sergiusens, are you around? Can you create https://github.com/snapcraft-docs/ros2-talker-listener for me? | 15:11 |
| sergiusens | kyrofa sure | 15:22 |
| sergiusens | kyrofa done | 15:25 |
| kyrofa | sergiusens, thank you! | 15:25 |
| zyga-ubuntu | woot | 15:35 |
| zyga-ubuntu | it works :D | 15:35 |
| zyga-ubuntu | jdstrand: it works :) | 15:38 |
| zyga-ubuntu | I'll break it down and start sending PRs up :) | 15:38 |
| zyga-ubuntu | I also worked aournd an apparent kernel bug | 15:39 |
| zyga-ubuntu | *around | 15:39 |
| zyga-ubuntu | jdstrand: I found that mount() can be called with empty source and it will not be quoted in any way, resulting in weird (and harder to parse) mountinfo | 15:39 |
| zyga-ubuntu | I now generate 'none' tmpfs so it's okay and no tools break but I will send a patch anyway | 15:40 |
| zyga-ubuntu | after the cleanup I'll send my early tmpfs PR and start working on unit tests as there are none for the new code yet | 15:40 |
| pstolowski | and now 4013 failed with error: cannot perform the following tasks: | 15:42 |
| pstolowski | - Download snap "test-snapd-tools" (6) from channel "stable" (Get https://api.snapcraft.io/api/v1/snaps/download/eFe8BTR5L5V9F7yHeMAPxkEr2NdUXMtw_6.snap: dial tcp 91.189.92.20:443: i/o timeout | 15:42 |
| pstolowski | grr | 15:42 |
| zyga-ubuntu | pstolowski: store woes | 15:42 |
| zyga-ubuntu | we had a lot over weekend | 15:42 |
| jdstrand | zyga-ubuntu: ack, cool | 15:45 |
| === genii is now known as genii-zombii | ||
| zyga-ubuntu | jdstrand: small one for you https://github.com/snapcore/snapd/pull/4109 | 16:03 |
| mup | PR #4109: cmd/libsnap: fix parsing of empty mountinfo fields <Created by zyga> <https://github.com/snapcore/snapd/pull/4109> | 16:03 |
| mup | PR snapd#4109 opened: cmd/libsnap: fix parsing of empty mountinfo fields <Created by zyga> <https://github.com/snapcore/snapd/pull/4109> | 16:04 |
| om26er | is there a way to refer the value gathered from `version-script` in snapcraft.yaml ? Think of $SNAPCRAFT_PROJECT_VERSION but for version-script | 16:14 |
| om26er | sergiusens: ^ | 16:14 |
| om26er | So I think that might be a bug, hmm. | 16:16 |
| zyga-ubuntu | pstolowski: hey, I also pushed https://github.com/snapcore/snapd/pull/4104 if you want to have a quick look, it's very short and simple | 16:18 |
| mup | PR #4104: cmd/snap-update-ns: add logging to snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/4104> | 16:18 |
| pstolowski | zyga-solus, yep, looking | 16:21 |
| zyga-ubuntu | thank you :) | 16:25 |
| zyga-ubuntu | pstolowski: https://github.com/snapcore/snapd/pull/4109#discussion_r148051564 :-) | 16:31 |
| mup | PR #4109: cmd/libsnap: fix parsing of empty mountinfo fields <Created by zyga> <https://github.com/snapcore/snapd/pull/4109> | 16:31 |
| pstolowski | zyga-solus, thanks! reading | 16:31 |
| zyga-ubuntu | pstolowski: if you think something is wrong please ask, maybe I'm confused myself | 16:38 |
| zyga-ubuntu | offtopic, tests seem rapid today | 16:43 |
| sergiusens | om26er no there isn't, it is for setting things, not reading | 16:44 |
| om26er | sergiusens: I have a use case: I want to dynamically read the latest version number of my software from a server url (version-script is fine for that). I then want that same version to be used by my source url in the `dump` plugin. | 16:46 |
| om26er | I would generally expect the value returned to from version-script to be exported as $SNAPCRAFT_PROJECT_VERSION not the fallback `version` that I have in place. | 16:47 |
| om26er | my snap here could definitely use that: https://github.com/om26er/sublime-text-3-snap/blob/master/snap/snapcraft.yaml | 16:48 |
| pstolowski | zyga-solus, i find it hard to digest it at this late hour tbh ;) | 16:50 |
| zyga-ubuntu | pstolowski: no worries, it's not urgent :) | 16:50 |
| zyga-ubuntu | thank you for looking | 16:50 |
| zyga-ubuntu | cachio: hey, can you have a 2nd look at 4102 please? | 16:56 |
| pstolowski | zyga-solus, is it possible for 2 adjacent fields to be empty like that? | 16:56 |
| cachio | zyga-ubuntu, sure | 16:56 |
| zyga-ubuntu | thank you :) | 16:56 |
| pstolowski | zyga-ubuntu, , is it possible for 2 adjacent fields to be empty like that? | 16:59 |
| zyga-ubuntu | pstolowski: I honestly don't know, this feels like a kernel bug | 16:59 |
| zyga-ubuntu | pstolowski: the only case I encountered was tmpfs with "" mount source | 17:00 |
| zyga-ubuntu | pstolowski: proc(5) doesn't mention this | 17:00 |
| pstolowski | zyga-ubuntu, yes, that would be unexepected but i'm curious if it deserver a test for the behavior of the parser (i.e. make sure we don't crash) | 17:00 |
| pstolowski | *deserves | 17:00 |
| zyga-ubuntu | ah, sure, I can add more tests | 17:00 |
| zyga-ubuntu | good idea | 17:00 |
| pstolowski | thanks | 17:01 |
| om26er | are build.snapcraft builders on maintenance of something ? My build haven't started for quite a bit. | 17:15 |
| kyrofa | om26er, things tend to slow down when a new Ubuntu release opens | 17:24 |
| kyrofa | elopio, all our tests use testtools nowadays, right? Is there a reason we're still running them with unittest? | 17:26 |
| kyrofa | I'm digging into this weird BlockingIOError thing. It seems to be coming from unittest, particularly a section of it that has been re-implemented by testtools, but we | 17:27 |
| kyrofa | 're not using testtools to run | 17:27 |
| elopio | kyrofa all should be using testtools. Changing the runner sounds worth a try. | 17:29 |
| kyrofa | elopio, alright, I'm trying it | 17:29 |
| kyrofa | Just wanted to make sure I wasn't insane, thanks elopio :) | 17:29 |
| sergiusens | om26er well, version-script is only analyzed after prime so that won't be possible anyways | 17:30 |
| om26er | that's an implementation detail :) As a developer I expected $SNAPCRAFT_PROJECT_VERSION to behave differently. | 17:31 |
| sergiusens | om26er well, the docs for version-script says it affects only the resulting metadata | 17:32 |
| sergiusens | kyrofa if that's it, nice find | 17:33 |
| kyrofa | sergiusens, no guarantees, testing now | 17:33 |
| * zyga-ubuntu is too tired now | 17:35 | |
| zyga-ubuntu | back demands a break | 17:35 |
| zyga-ubuntu | ttyl | 17:35 |
| kyrofa | sergiusens, what I actually think is happening is that the test runners don't handle EAGAIN properly | 17:36 |
| kyrofa | Which means we have a few options assuming testtools has the same issue: try to stay under whatever threshold we're hitting that's causing the EAGAIN, or fix the runner to handle it properly. It just so happens that one seems like a short-term fix and another seems like a long-term, so I'm looking into both | 17:41 |
| === cachio is now known as cachio_afk | ||
| sergiusens | got it | 17:46 |
| stokachu | anyone seen this error before "- Run configure hook of "conjure-up" snap if present (run hook "configure": / not root-owned 66094:40918)." | 17:50 |
| stokachu | this is from a snap install conjure-up --classic on arm64 | 17:50 |
| stokachu | wililupy: ^ is the one having the issue | 17:51 |
| wililupy | stokachu: yes | 17:51 |
| kyrofa | stokachu, yuck. jdstrand any idea what that ^ may be? | 18:00 |
| jdstrand | kyrofa: I have not | 18:03 |
| * sergiusens is commuting on a bus | 18:11 | |
| wililupy | kyrofa,jdstrand: I can give you access to the server if that helps? | 18:17 |
| kyrofa | wililupy, sure, I'm curious. pubkey: https://pastebin.ubuntu.com/25860353/ | 18:18 |
| kyrofa | wililupy, what the heck is wrong with this machine :P | 18:28 |
| kyrofa | $ ls -ld / | 18:28 |
| kyrofa | drwxr-xr-x 24 66094 40918 4096 Oct 31 16:23 / | 18:28 |
| kyrofa | wililupy, there's a weird mixture of that in / as well | 18:28 |
| kyrofa | wililupy, bin looks good, but boot is weird, etc. | 18:28 |
| genii-zombii | odd UID/GID | 18:29 |
| kyrofa | Indeed | 18:29 |
| kyrofa | wililupy, not sure what the deal is, but snap-confine barfs at it definitely | 18:30 |
| kyrofa | Fix that up and I bet it'll start working | 18:30 |
| wililupy | Thats good info. I'll try to re-install the OS and see what happens. I'll keep you posted. Thanks | 18:31 |
| kyrofa | Sure thing | 18:33 |
| kyrofa | stokachu, FYI ^ | 18:36 |
| jdstrand | kyrofa: probably 'owner' in the apparmor rules | 18:43 |
| jdstrand | </guess> | 18:43 |
| kyrofa | jdstrand, it's an explicit check in snap-confine | 18:44 |
| kyrofa | jdstrand, ensuring the bpfpath is owned by root, presumably to ensure tampering would be difficult | 18:45 |
| jdstrand | oh yes | 18:45 |
| jdstrand | kyrofa: I should've remembered that from the error, but for some reason it didn't trigger in my head | 18:46 |
| mup | PR snapd#4102 closed: tests: refactor and expand content interface test <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4102> | 18:47 |
| kyrofa | jdstrand, I imagine you have a few other things vying for space ;) | 18:47 |
| jdstrand | heh | 18:47 |
| om26er | sergiusens: Hey! Have you considered renaming telegram-sergiusens to telegram ? | 18:58 |
| * Pharaoh_Atem sighs | 19:06 | |
| * zyga-ubuntu hugs Pharaoh_Atem | 19:06 | |
| zyga-ubuntu | what's up? | 19:06 |
| Pharaoh_Atem | I want proper SELinux support in snapd already :( | 19:06 |
| zyga-ubuntu | I don't even know where to begin on that | 19:07 |
| zyga-ubuntu | snap-confine should probably do something but that is a deep-dive sprint | 19:07 |
| * zyga-ubuntu goes to fix his manual pages | 19:09 | |
| * zyga-ubuntu tries to learn manual page syntax | 19:10 | |
| === cachio_afk is now known as cachio | ||
| * zyga-ubuntu reads groff source code | 19:21 | |
| nacc | zyga-ubuntu: good luck :) | 19:22 |
| zyga-ubuntu | nacc: man, what is .tmac? | 19:31 |
| nacc | zyga-ubuntu: troff macros | 19:33 |
| zyga-ubuntu | mmm | 19:33 |
| zyga-ubuntu | I'm trying to understand why I'm getting a warning: | 19:33 |
| zyga-ubuntu | mdoc warning: .Lb: no description for library `libkeep' available (#8) | 19:33 |
| mup | PR #8: launchpad.net/snappy -> github.com/ubuntu-core/snappy <Created by chipaca> <Merged by elopio> <https://github.com/snapcore/snapd/pull/8> | 19:33 |
| nacc | silly mup | 19:34 |
| nacc | zyga-ubuntu: can you pastebin the source? | 19:34 |
| zyga-ubuntu | of the man page? | 19:34 |
| nacc | zyga-ubuntu: yeah | 19:34 |
| zyga-ubuntu | I'm a bit shy, it's my pet project | 19:34 |
| zyga-ubuntu | the relevant part is | 19:34 |
| zyga-ubuntu | .Sh LIBRARY | 19:34 |
| zyga-ubuntu | .Lb libkeep | 19:34 |
| nacc | zyga-ubuntu: does that possibly mean there is no libkeep manpage? | 19:35 |
| zyga-ubuntu | that depends, it's in my source tree | 19:36 |
| zyga-ubuntu | in section .3 | 19:36 |
| nacc | http://web.mit.edu/freebsd/head/contrib/groff/tmac/doc-syms | 19:36 |
| nacc | it looks like it can't find it locally as it's running? | 19:36 |
| nacc | ie d doc-str-Lb-\*[doc-arg\n[doc-arg-ptr]] | 19:36 |
| zyga-ubuntu | aha, I probably need to install that | 19:36 |
| zyga-ubuntu | I read that file but I didn't undetstand the syntax yet | 19:37 |
| nacc | it's rough :) | 19:37 |
| zyga-ubuntu | I found this by grepping, following from man source, looking for --warnings | 19:37 |
| zyga-ubuntu | I use this command to run the "checker" | 19:37 |
| nacc | zyga-ubuntu: ah, see `man groff_mdoc` for valid .Lb values | 19:38 |
| zyga-ubuntu | PAGER=cat LANG='en_US.UTF-8' MANWIDTH=80 man --warnings -E UTF-8 -l keep_alloc_free.3 >/dev/null | 19:38 |
| zyga-ubuntu | thank you | 19:38 |
| nacc | zyga-ubuntu: you might need a mdoc.local? | 19:38 |
| nacc | and need to defien a str-Lb-libkeep, i think | 19:39 |
| zyga-ubuntu | yeah | 19:39 |
| zyga-ubuntu | where does mdoc.local live? | 19:39 |
| nacc | zyga-ubuntu: /etc/groff/mdoc.local apparently | 19:40 |
| nacc | so that doesn't help you much :/ | 19:40 |
| zyga-ubuntu | well, man page looks ok, that's one I'm willing to ignore | 19:40 |
| nacc | yeah | 19:41 |
| zyga-ubuntu | thank you for teaching me about tihs | 19:42 |
| zyga-ubuntu | *this | 19:42 |
| nacc | zyga-ubuntu: np, learninng right alongside you :) | 19:43 |
| kyrofa | Hrmm... setuptools masks output | 19:52 |
| kyrofa | Er, I mean testtools | 19:53 |
| kyrofa | Too many tools | 19:53 |
| wililupy | kyrofa: I re-installed the OS and I was able to install conjure-up. Good thing too. There were a bunch of updates that system wasn't seeing as well. | 19:53 |
| kyrofa | wililupy, good deal, yeah I imagine that would cause all sorts of issues | 19:53 |
| kyrofa | wililupy, thanks for getting back to me! | 19:53 |
| wililupy | kyrofa: np. thanks for the help. | 19:54 |
| kyrofa | Of course | 19:54 |
| stokachu | wililupy: good to hear! | 20:04 |
| kyrofa | sergiusens, elopio testtools.run -h lies about the options supported-- there is no verbose mode :P | 20:18 |
| kyrofa | Just look at this bug, how embarrassing https://bugs.launchpad.net/testtools/+bug/872906 | 20:19 |
| mup | Bug #872906: python -m testtools.run discover -v doesn't set verbosity <runner> <testtools:Triaged> <https://launchpad.net/bugs/872906> | 20:19 |
| kyrofa | So we of course timeout | 20:20 |
| kyrofa | The investigation continues | 20:23 |
| elopio | kyrofa: we can easily make our own runner, printing whatever we want. For example, I combined some things from unittest and testtools to make the concurrent runner. | 20:23 |
| sergiusens | oh well, you know, maybe thomi can give you some ideas on your issue | 20:23 |
| thomi | I have been summoned! | 20:24 |
| elopio | kyrofa also, once we move all the tests into snapcraft/tests, we don't need discover. We can just run the module. | 20:25 |
| thomi | kyrofa: yeah, the 'discover' command is a bit of a hack, and ideally shouldn't be used on the command line | 20:26 |
| kyrofa | Actually, thomi if you have a sec, could you give me your thoughts on the bug that's sucking the lifeblood out of me? | 20:27 |
| thomi | sure thing | 20:28 |
| kyrofa | https://bugs.launchpad.net/snapcraft/+bug/1717921 | 20:28 |
| mup | Bug #1717921: CI: BlockingIOError about 50% of the time <Snapcraft:Confirmed> <https://launchpad.net/bugs/1717921> | 20:28 |
| kyrofa | thomi, note that the error always seems to come from unittest's runner | 20:28 |
| * thomi reads | 20:29 | |
| kyrofa | thomi, I was hoping the testtools runner would fare better, but without verbose mode Travis just times out thinking it died | 20:30 |
| thomi | kyrofa: Travis requires some output on stdout or it kills the job? | 20:31 |
| kyrofa | thomi, yep | 20:31 |
| kyrofa | Fun times | 20:31 |
| kyrofa | There are ways to hack around it, but without output it's difficult to track progress as well | 20:32 |
| thomi | huh, and the individual tests are longer than the timeout? Even in non-verbose mode, testtools will print a '.' after every test | 20:32 |
| kyrofa | Some, yeah | 20:32 |
| thomi | kyrofa: Are you able to point me to the code where you setup the subprocess calls? I think you're correct that this is related, and I suspect what's happening is that the Process stdout or stderr pipes are filling up | 20:34 |
| kyrofa | thomi, most subprocess calls go through common.run{_output}, defined here https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/common.py#L66 | 20:36 |
| thomi | thanks | 20:36 |
| kyrofa | thomi, we're using check_call or check_output though, each of which handle reading off their own stdout/stderr | 20:38 |
| kyrofa | (at least I thought) | 20:38 |
| thomi | hmmm, yes, it seems it should | 20:44 |
| thomi | I was pretty sure there was a warning in the python docs about ensuring process stdout pipes didn't get full, but I can't see it now, maybe it was a python2 consideration only | 20:49 |
| kyrofa | thomi, that's for setting stdout or stderr=PIPE with check_call | 20:50 |
| kyrofa | In which case the caller is responsible to emptying them | 20:50 |
| thomi | check_output simply calls run with stdout=PIPE. Does the same consideration not apply there as well? | 20:51 |
| kyrofa | thomi, run is fine assuming it also called communicate afterward, no? | 20:51 |
| kyrofa | Yeah here's the warning on check_call: " | 20:51 |
| kyrofa | Note | 20:51 |
| kyrofa | Do not use stdout=PIPE or stderr=PIPE with this function. The child process will block if it generates enough output to a pipe to fill up the OS pipe buffer as the pipes are not being read from. " | 20:51 |
| kyrofa | Here: https://docs.python.org/3/library/subprocess.html#subprocess.check_call | 20:51 |
| thomi | I see - check_call is implemented by calling `call()`, but `check_output` is implemented in terms of `run` and `Popen` | 20:52 |
| thomi | kyrofa: this only happens on travis? | 20:54 |
| kyrofa | thomi, yeah | 20:54 |
| kyrofa | Super weird | 20:54 |
| kyrofa | Although I'm not running the entire suite locally, maybe there's something odd that happens when the whole shebang runs | 20:55 |
| kyrofa | s/not/now/ | 20:55 |
| === JoshStrobl is now known as JoshStrobl|zzz | ||
| thomi | I'd be tempted at this point to try and create a minimal reproducer in a separate repo. It'd be interesting to see what's required to trigger it consistently | 20:56 |
| kyrofa | Yeah that's not a bad idea | 20:56 |
| kyrofa | I wonder if lxc might be involved as well | 20:56 |
| thomi | if it is, that's at least easy to test locally | 20:57 |
| kyrofa | thomi, anyway, I don't mean to suck your lifeblood too, but if you could mull it over in the back of your mind I'd be thankful | 20:57 |
| thomi | yeah - I will - let me know if you make any progress, you've got me interested now. | 20:57 |
| kyrofa | Will do! I'll set up a test repo shortly and see if I can manage to get it happening | 20:58 |
| thomi | If you want an easy way to create lots of tests (assuming for the moment that lots of tests running in parallel is part of what's required to trigger this) look at `testscenarios` - you can programmatically multiply a single test N times. | 20:58 |
| mup | PR snapcraft#1641 closed: lxd: catch CalledProcessError in _container_run <bug> <Created by kalikiana> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1641> | 20:59 |
| mup | PR snapcraft#1647 opened: lxd: better surfacing of errors <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1647> | 20:59 |
| sergiusens | elopio kyrofa ^ | 21:00 |
| jdstrand | tyhicks: hey, I noticed in https://github.com/snapcore/snapd/pull/3998 that you are using EPERM. this is consistent with all of our conversations, but I forgot until recently that apparmor and DAC return EACCES. I wonder if it would make sense to use EACCES instead? note that device cgroup uses EPERM | 21:21 |
| mup | PR #3998: snap-confine, snap-seccomp: utilize new seccomp logging features <Created by tyhicks> <https://github.com/snapcore/snapd/pull/3998> | 21:21 |
| elopio | snappy-m-o autopkgtest 1647 xenial:amd64 xenial:arm64 xenial:armhf | 21:24 |
| snappy-m-o | elopio: I've just triggered your test. | 21:25 |
| tyhicks | jdstrand: I don't really have an opinion on the matter but I'll be happy to talk through it | 21:33 |
| tyhicks | jdstrand: it may require a case-by-case evaluation per syscall | 21:34 |
| tyhicks | jdstrand: the man pages for setuid(), setresuid(), etc., don't mention EACCES as a possible return value but do mention EPERM | 21:36 |
| jdstrand | tyhicks: oh hmm | 21:36 |
| jdstrand | tyhicks: does apparmor retrun !EACCES depending on the access? | 21:37 |
| tyhicks | jdstrand: I don't think it is possible for an LSM to cause EACESS to be returned for those syscalls (I may be wrong about that...) | 21:37 |
| tyhicks | jdstrand: I'm not sure off the top of my head | 21:37 |
| zyga-ubuntu | jdstrand: I recall -13 | 21:41 |
| zyga-ubuntu | which is indeed EACCES | 21:41 |
| jdstrand | zyga-ubuntu: yes, I looked at this recently for open, but I hadn't considered that they might set errno differently depending on syscall | 21:42 |
| jdstrand | tyhicks: well, ultimately it doesn't matter. I was asking for consistency | 21:42 |
| jdstrand | tyhicks: and I did notice that apparmor and device cgroup were different with open | 21:43 |
| tyhicks | jdstrand: I don't necessarily think that they do set errno different depending on the syscall | 21:43 |
| jdstrand | EACCES vs EPERM | 21:43 |
| tyhicks | jdstrand: rather, I think there's a subset of syscalls that don't have LSM hooks | 21:44 |
| jdstrand | right... | 21:44 |
| jdstrand | tyhicks: so, you're saying that if there is a hook, the LSM can set it to whatever it wants (eg, apparmor uses EACCES) | 21:46 |
| jdstrand | tyhicks: I don't quite understand if there isn't a hook... I mean, if there isn't a hook, there isn't a mediation point for the LSM | 21:46 |
| tyhicks | just a sec, I'm tracing some apparmor hooks | 21:48 |
| tyhicks | jdstrand: AppArmor return EPERM in a couple instances (capability checks and profile transitions) | 21:50 |
| jdstrand | tyhicks: seccomp is different in that it doesn't use the LSM hooks though. why wouldn't it set errno to something else? I guess I could understand with setuid and friends cause setting it to something else might lead to programs not behaving correctly since they might be checking for EPERM | 21:50 |
| tyhicks | jdstrand: sometimes those EPERMS are passed on and they're ignored in other cases | 21:50 |
| jdstrand | tyhicks: ok, good to know | 21:51 |
| tyhicks | jdstrand: when you say, why wouldn't it set errno to something else?" | 21:51 |
| tyhicks | bah | 21:51 |
| tyhicks | jdstrand: what errno value are you talking about when you say, "why wouldn't it set errno to something else?" | 21:51 |
| jjohansen | tyhicks, jdstrand: yep EACCESS when policy says no, EPERM in a couple of places when its not so much policy as some other violation | 21:52 |
| jdstrand | tyhicks: if we use SECCOMP_RET_ERRNO() and set it to EACCES, why would the kernel return something else? | 21:53 |
| tyhicks | jdstrand: it won't (we must have misunderstood each other somewhere) | 21:53 |
| jdstrand | (that was my question. I may have answered myself with setuid and friends) | 21:53 |
| jdstrand | tyhicks: you said something about not being able to set EACCES for setuid. or did I misunderstand? | 21:54 |
| tyhicks | jdstrand: I was just saying that I don't think an LSM can intervene in a setuid() syscall and, if that's true, no applications are going to expect EACCES to be returned from setuid() | 21:55 |
| tyhicks | maybe jjohansen can correct me if I'm wrong there | 21:55 |
| jdstrand | tyhicks: I didn't think seccomp was a true LSM in that regard. as for setuid and whether we should set EACCEs for it, that is worth considering for sure | 21:56 |
| jdstrand | I think I can test that real quick | 21:56 |
| tyhicks | jdstrand: I'm not talking about seccomp when I say LSM | 21:57 |
| tyhicks | jdstrand: I'm talking about selinux, apparmor, smack when I say LSM | 21:57 |
| jdstrand | tyhicks: ok. well, I was only talking about your seccomp PR :) | 21:57 |
| jdstrand | so I was a bit confused when you started talking about LSMs :) | 21:57 |
| tyhicks | wut? you mentioned AppArmor in your first message on this topic :) | 21:58 |
| tyhicks | we're just talking in circles at this point :) | 21:58 |
| jdstrand | oh pfft | 21:58 |
| jdstrand | I wasn't clear | 21:58 |
| jdstrand | "I wonder if it would make sense to use EACCES instead?" | 21:59 |
| tyhicks | I think we both feel like EPERM is the right thing for snapd's seccomp filter to return, right? | 21:59 |
| jdstrand | s/EACCES in your PR instead" | 21:59 |
| jdstrand | my question was wondering if your PR should be changed to EACCES for consistency with apparmor | 22:00 |
| jdstrand | but there is a very good argument against doing that with setuid | 22:00 |
| tyhicks | I think EPERM is a good default to go with for now. There may be some specific syscalls where we prefer to return EACCES instead of EPERM once we start widely testing a number a snaps with the new confinement. | 22:01 |
| jdstrand | tyhicks: that's fair. thanks and sorry for the extra circle or two | 22:04 |
| tyhicks | jdstrand: no problem - I'm a bit anxious to see how existing snaps will react to the change | 22:06 |
| jdstrand | I suspect most will eventually die in weird ways with cascading failures | 22:07 |
| jdstrand | I suspect setpriority will be the one that isn't so bad | 22:07 |
| jdstrand | from what I've seen, the return code is often not checked for that, but that isn't at all fatal | 22:08 |
| tyhicks | yeah, that'll be nice to not result in a kill | 22:08 |
| jjohansen | jdstrand: an LSM certainly can interfere with the setuid syscall, I think the hook has been removed atm but it could be reintroduced | 22:08 |
| tyhicks | (that was me that said that) | 22:09 |
| tyhicks | jjohansen: I was just going off of the hooks that currently exist | 22:09 |
| tyhicks | jjohansen: how long ago was that? | 22:09 |
| jjohansen | tyhicks: hrmm, a couple years ago, when there was some unused hook cleanup, it is one I would like back for apparmor | 22:10 |
| jjohansen | I'm not the only one who wants a couple of the user related hooks to return | 22:10 |
| jjohansen | its hard to argue for them without the code to do something with them though | 22:10 |
| tyhicks | interesting, thanks | 22:12 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!