| Son_Goku | TingPing, you might want to try with the 2.31.1 snapd | 00:41 |
|---|---|---|
| Son_Goku | it is in testing for Fedora | 00:41 |
| Son_Goku | https://bodhi.fedoraproject.org/updates/?packages=snapd | 00:41 |
| TingPing | Son_Goku, i tested on ubuntu 16.04, which honestly is the only version i particularly care about | 00:41 |
| Son_Goku | ah | 00:42 |
| Son_Goku | I thought you were a Fedora user... | 00:42 |
| TingPing | i am | 00:42 |
| Son_Goku | apologies for assuming | 00:42 |
| Son_Goku | snapd in Ubuntu 16.04 has had a tumultuous time getting updated | 00:43 |
| Son_Goku | so they've been lagging behind Fedora on updates | 00:44 |
| TingPing | funny | 01:05 |
| Son_Goku | well, I try to keep things fresh ;) | 01:06 |
| Son_Goku | Fedora also beat Ubuntu to getting an updated Mir, too ;) | 01:07 |
| Son_Goku | despite all the issues caused by gcc8 | 01:07 |
| Son_Goku | and fweimer's change to the distro compiler flags | 01:07 |
| TingPing | sounds masochistic | 01:07 |
| TingPing | while i'm here are there any download "badges" for snap? | 01:08 |
| Son_Goku | badges? | 01:08 |
| Son_Goku | what do you mean? | 01:08 |
| TingPing | like a standardize logo to indicate a snap download | 01:08 |
| Son_Goku | ah | 01:08 |
| Son_Goku | you mean like the things Apple/Google do? | 01:09 |
| TingPing | yea | 01:09 |
| Son_Goku | yeah | 01:10 |
| Son_Goku | there's a "snap|built and released" button | 01:10 |
| Son_Goku | you can get it through build.snapcraft.io when you connect your GitHub account to the build system | 01:10 |
| Son_Goku | but a regular button? I don't think so | 01:11 |
| Son_Goku | an example badge: https://github.com/snapcrafters/atom/blob/master/README.md | 01:11 |
| * TingPing is working on this https://i.imgur.com/XP2i53v.png | 01:11 | |
| Son_Goku | snaps have an official logo | 01:12 |
| Son_Goku | and generally speaking, the usage of the ubuntu logo isn't permitted in association with snaps, jfyi | 01:12 |
| TingPing | link to their logo? | 01:13 |
| Son_Goku | TingPing, yep, trying to find it | 01:14 |
| Son_Goku | one sec | 01:14 |
| Son_Goku | TingPing: https://assets.ubuntu.com/v1/d24ea71e-10.+SNAPCRAFT_LOGO_AW.zip | 01:15 |
| Son_Goku | you'll want {PNG,SVG}_stacked/snapcraft_green-red_st_hex.{png,svg} | 01:16 |
| Son_Goku | hmm | 01:16 |
| Son_Goku | TIL that cloud-init has a logo | 01:16 |
| TingPing | bit annoyingly sized | 01:18 |
| mborzecki | morning | 05:46 |
| * mborzecki is afk for ~1h | 06:31 | |
| === akash_ is now known as akash | ||
| === oh4__ is now known as oh4_ | ||
| === davdunc_ is now known as davdunc | ||
| === lfaraone_ is now known as lfaraone | ||
| === doko_ is now known as doko | ||
| zyga-ubuntu | good morning | 07:18 |
| mborzecki | aand i'm back | 07:38 |
| mborzecki | zyga-ubuntu: morning | 07:38 |
| zyga-ubuntu | hey | 07:38 |
| zyga-ubuntu | it's good to be home :-) | 07:38 |
| mborzecki | yay ;) | 07:38 |
| mvo | hey zyga-ubuntu and mborzecki ! | 07:41 |
| zyga-ubuntu | hey mvo! :) | 07:41 |
| mborzecki | mvo: hey | 07:41 |
| * zyga-ubuntu updates his fedora system | 07:43 | |
| mborzecki | zyga-ubuntu: some intersting fedora work coming up? | 07:44 |
| zyga-ubuntu | I wanted to fix a build issue on newer gcc's | 07:47 |
| zyga-ubuntu | and since I have ubuntu on my laptop now I could play on fedora on my desktop for some time | 07:47 |
| mborzecki | zyga-ubuntu: what build issue on newer gcc? i have 7.3 here and rebuilt the package yesterday | 07:56 |
| zyga-ubuntu | I don't remember; Neal said there are some issues | 07:56 |
| zyga-ubuntu | I just rebooted and I'll make a rawhide chroot | 07:56 |
| mborzecki | zyga-ubuntu: maybe that's the media-sharing interace thing? | 07:58 |
| mborzecki | zyga-ubuntu: /media vs /run/media | 07:59 |
| zyga-ubuntu | I'll find out soon | 07:59 |
| zyga-ubuntu | that one was supported for long time now | 07:59 |
| zyga-ubuntu | but maybe it regressed | 07:59 |
| mborzecki | zyga-ubuntu: ok, ping me if you need help | 08:00 |
| mborzecki | hah, had to do blood tests in the morning, now i can make up for the lost blood with some chocolate :P | 08:01 |
| zyga-ubuntu | yum yum | 08:07 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | morning! | 08:11 |
| mvo | hey pstolowski ! good morning | 08:13 |
| mborzecki | pstolowski: hey | 08:20 |
| zyga-ubuntu | mvo: hey, did you try the tea by any chance? :-) | 08:27 |
| user9445 | hello everyone! I am not a linux expert and I have a question. Can I turn any program into a snap package if I can get its source code? I was thinking about virtualbox. | 08:28 |
| user9445 | the official tutorial looks quite easy | 08:28 |
| zyga-ubuntu | user9445: hey, | 08:28 |
| zyga-ubuntu | user9445: virtual box may be a bit harder to snap unless you want to make the kernel modules optional | 08:29 |
| zyga-ubuntu | user9445: but in general, with enough persistence, yes you can snap anything, it's just a format for packaging | 08:29 |
| zyga-ubuntu | mborzecki: do you know how to get a fedora chroot? | 08:29 |
| zyga-ubuntu | I'd rather have a chroot with rawhide than a VM with one | 08:30 |
| mborzecki | systemd-nspawn is probably the easiest way, but you'll probably need dnf to install everything, maybe they still publis the raw rootfs images, so this might be a second way to try | 08:31 |
| zyga-ubuntu | oh, I didn't think about that | 08:32 |
| zyga-ubuntu | the host if F27 | 08:32 |
| mvo | zyga-ubuntu: yeah, its interessting. pretty strong flavor, not what I am used to but I will drink it a bit and see if it clicks :) | 08:32 |
| mborzecki | zyga-ubuntu: https://download.fedoraproject.org/pub/fedora/linux/releases/27/CloudImages/x86_64/images/Fedora-Cloud-Base-27-1.6.x86_64.raw.xz raw image | 08:32 |
| mvo | zyga-ubuntu: I will definitely get you some for the next sprint as well :) | 08:32 |
| zyga-ubuntu | mvo: not sure how many leaves did you use, I usually use a few for a sizable mug (~1L) | 08:33 |
| kalikiana | o/ | 08:40 |
| pstolowski | how was your travel back home guys? | 08:47 |
| mborzecki | pstolowski: short :P | 08:47 |
| mborzecki | pstolowski: and we got a chance to do some sightseeing on Saturday morning (at least me, zyga-ubuntu and koza, the rest were leaving earlier) | 08:49 |
| mvo | zyga-ubuntu: ok, I try a smaller one then :) | 08:52 |
| pstolowski | mborzecki: nice! | 08:54 |
| morphis | mvo: zyga-ubuntu: any idea about https://forum.snapcraft.io/t/nvidia-gl-libs-access-broken-on-ubuntu-18-04/4440 ? | 08:56 |
| zyga-ubuntu | morphis: ah, interesting | 09:05 |
| zyga-ubuntu | I will respond on the forum | 09:05 |
| zyga-ubuntu | morphis: done | 09:08 |
| morphis | zyga-ubuntu: thanks! | 09:09 |
| === __chip__ is now known as Chipaca | ||
| Chipaca | moin moin | 09:21 |
| Chipaca | mborzecki: would you mind doing the fuzzing thing again on the puritan pr? | 09:22 |
| Chipaca | mborzecki: I lopped a bunch of checks off | 09:22 |
| Chipaca | which should be fine, given they were unreachable :-) | 09:22 |
| mborzecki | Chipaca: ok, will try in a couple of minutes | 09:23 |
| Chipaca | mborzecki: thanks! | 09:23 |
| mvo | Chipaca: hey, good morning! do you think 4805 can be merged? or because of it being api we need a gustavo review? | 09:30 |
| Chipaca | mvo: I don't think rob addressed my concerns | 09:30 |
| Chipaca | let me check | 09:30 |
| Chipaca | mvo: "the correct behaviour is if the field is omitted to assume that classic is supported." <- that's not what we do for eveyr other boolean | 09:32 |
| mvo | Chipaca: please mark as "request change" then, just to ensure it does not get merged accidently | 09:32 |
| pstolowski | mvo: is https://github.com/pilebones/go-udev the udev implementation you found last week? | 09:34 |
| mvo | pstolowski: yes | 09:35 |
| mup | PR snapd#4811 opened: tests/main/media-sharing: improve the test to cover /media and /run/media <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4811> | 09:35 |
| mborzecki | nice & easy PR ^^ | 09:35 |
| pstolowski | mborzecki: commented | 09:42 |
| pstolowski | hey Chipaca! | 09:44 |
| Chipaca | pstolowski: hi! | 09:45 |
| mborzecki | pstolowski: cmd/snap-confine/spread-tests/main/media-visible-in-devmode this test? | 09:45 |
| pstolowski | mborzecki: yes | 09:45 |
| mborzecki | pstolowski: i don't think these are run at all | 09:46 |
| pstolowski | mborzecki: nb I misread the systems clause there, it's run everywhere but debian it seems; what makes you think it's not executed? | 09:46 |
| mborzecki | pstolowski: cmd/snap-confine/spread-tests is not referenced in the top level spread test file | 09:50 |
| zyga-ubuntu | mborzecki: it's not used | 09:53 |
| zyga-ubuntu | man, we should drop most of those tetsts | 09:53 |
| zyga-ubuntu | those are from when snap-confine was in a separate repository by itself | 09:53 |
| Chipaca | mborzecki: it's left there by zyga to catch the unwary | 09:53 |
| pstolowski | mborzecki: allright | 09:53 |
| pstolowski | +1 | 09:54 |
| mborzecki | haha, are those kept for reference or shall we make them go away then? :) | 09:54 |
| zyga-ubuntu | one by one either enable and port or drop | 09:55 |
| Chipaca | zyga-ubuntu: every seen this? | 09:58 |
| Chipaca | execl failed: Permission denied | 09:58 |
| Chipaca | child exited with status 1: File exists | 09:58 |
| Chipaca | zyga-ubuntu: https://api.travis-ci.org/v3/job/352240343/log.txt | 09:58 |
| zyga-ubuntu | Chipaca: yes, on Friday | 09:59 |
| zyga-ubuntu | is this against master or release? | 09:59 |
| Chipaca | zyga-ubuntu: master | 09:59 |
| zyga-ubuntu | hmmm | 09:59 |
| Chipaca | zyga-ubuntu: not a new master though, it's probably a few commits behind | 09:59 |
| zyga-ubuntu | perfect, 14.04, no logs | 10:00 |
| zyga-ubuntu | so what we saw in the release branch on Friday is that apparently something mixes old profile and new profile on disk | 10:01 |
| mvo | zyga-ubuntu: can you remind me again why 2.32 is broken and also why it seems not to be broken when I run an isolated 2.32 test in qemu? | 10:01 |
| zyga-ubuntu | great question mvo, still investigating that | 10:01 |
| zyga-ubuntu | so I don't really know yet | 10:02 |
| mvo | zyga-ubuntu: aha, great. can you reproduce it somehow? | 10:02 |
| zyga-ubuntu | yes | 10:02 |
| mvo | zyga-ubuntu: how? | 10:02 |
| zyga-ubuntu | I mean, I just ran it in qemu | 10:02 |
| zyga-ubuntu | was I just lucky? | 10:02 |
| mvo | zyga-ubuntu: I don't know :) did you run just a single failing test or the full ting? I just did the former and do the later now | 10:02 |
| zyga-ubuntu | I ran tests/main | 10:03 |
| zyga-ubuntu | my goals today are to fix that, fix the bug that manifests itself as /etc and get back to the bigger bug of /etc being writable | 10:04 |
| mvo | zyga-ubuntu: ok | 10:05 |
| Chipaca | zyga-ubuntu: should I just restart this particular test? | 10:05 |
| zyga-ubuntu | hmm hmm | 10:06 |
| zyga-ubuntu | there's nothing in the debug log there | 10:06 |
| zyga-ubuntu | yeah, restart it for now | 10:06 |
| zyga-ubuntu | I need to get this under control | 10:06 |
| mborzecki | Chipaca: got some panics | 10:18 |
| Chipaca | mborzecki: woo | 10:18 |
| Chipaca | mborzecki: show me :-) | 10:18 |
| mborzecki | Chipaca: i can let it run for a bit and then upload the corpus | 10:18 |
| Chipaca | mborzecki: ok | 10:19 |
| mvo | zyga-ubuntu: as a data point - tests seem to be ok if run in isolation so something is bleeding into it | 10:22 |
| zyga-ubuntu | yeah, I'm mid way and nothing failed now | 10:22 |
| zyga-ubuntu | :-( | 10:23 |
| mborzecki | Chipaca: https://paste.ubuntu.com/p/v45xJKWvSY/ | 10:23 |
| zyga-ubuntu | do you have the seed with a failure by any chance? | 10:23 |
| mvo | mborzecki: one of the errors in 4811 looks real | 10:26 |
| Chipaca | mborzecki: can i see the fuzz function? | 10:26 |
| Chipaca | mborzecki: (i suspect you're calling marshal directly :-) ) | 10:26 |
| mborzecki | Chipaca: yes i do | 10:27 |
| Chipaca | *unmarshal | 10:27 |
| mvo | zyga-ubuntu: maybe, let me try | 10:27 |
| Chipaca | mborzecki: ah, yes that won't work, now -- it's called on things that json already knows is valid json | 10:27 |
| zyga-ubuntu | mvo: I'm looping through this on my laptop | 10:27 |
| zyga-ubuntu | it did fail on Friday | 10:27 |
| mvo | zyga-ubuntu: 1520606008 is what travis was using | 10:28 |
| zyga-ubuntu | thanks, I will try that with another backend | 10:28 |
| zyga-ubuntu | not sure if this is reliable | 10:29 |
| mborzecki | Chipaca: https://paste.ubuntu.com/p/ngFTQqvD4Y/ corpus https://send.firefox.com/download/d3fc9b236a/#CmR2CZR9_Ej7kx3qLjX_JQ | 10:29 |
| Chipaca | mborzecki: ah! hm! oh! | 10:31 |
| Chipaca | mborzecki: thanks | 10:32 |
| mborzecki | Chipaca: that's the tool(ing) https://github.com/dvyukov/go-fuzz | 10:32 |
| Chipaca | mborzecki: so maybe I should put those checks back in; the bad data needs to be fed to UnmarshalJSON directly, but that's a public function so why wouldn't it | 10:34 |
| * Chipaca feels dumber and wiser at the same time | 10:34 | |
| mborzecki | haha :) anyways, the fuzzer is a nice thing to play with | 10:36 |
| Chipaca | mborzecki: on the next run I got two of them: https://api.travis-ci.org/v3/job/352240343/log.txt | 10:36 |
| Chipaca | um | 10:36 |
| Chipaca | zyga-ubuntu: you ^ | 10:37 |
| Chipaca | zyga-ubuntu: one on 16.04 | 10:37 |
| zyga-ubuntu | wow | 10:37 |
| zyga-ubuntu | that's master + stuff right? | 10:37 |
| mborzecki | hm device cgroups stopped working or what? | 10:37 |
| Chipaca | zyga-ubuntu: master up to 275d1cac4a774fe784f764c0788a689e60cc9d0a | 10:38 |
| zyga-ubuntu | man | 10:38 |
| Chipaca | zyga-ubuntu: then it's jsonutil/puritan and using it from store; at the opposite end from cgroups :-) | 10:38 |
| mvo | this might be a race, I saw those failing sometimes (just saying) | 10:38 |
| zyga-ubuntu | it would be way better if spread would say which machine is running a given test | 10:38 |
| zyga-ubuntu | to show a trace of failure on a given machine | 10:39 |
| mvo | (I mean, we need to look into this but I wonder if its consistent) | 10:39 |
| zyga-ubuntu | reproducing this takes tons of time :/ | 10:39 |
| mborzecki | catching --strace='--raw' would be useful | 10:39 |
| zyga-ubuntu | I mean | 10:40 |
| zyga-ubuntu | I know what happens | 10:40 |
| zyga-ubuntu | not sure why it happens | 10:40 |
| zyga-ubuntu | what happens is that snap-confine doesn't have permission to run snap-update-ns | 10:40 |
| mborzecki | zyga-ubuntu: shouldn't the denial be logged? | 10:41 |
| zyga-ubuntu | yes | 10:41 |
| zyga-ubuntu | it should | 10:41 |
| zyga-ubuntu | and it's not | 10:41 |
| * Chipaca -> physio gym thing | 10:51 | |
| mborzecki | mvo: i'll into tests/main/snap-service-refresh-mode as it's still failing randomly | 10:52 |
| mborzecki | look into | 10:52 |
| === pstolowski is now known as pstolowski|lunch | ||
| * Chipaca -> really leaves | 10:57 | |
| mvo | mborzecki: \o/ thank you | 10:59 |
| mvo | mborzecki: maybe its a real issue :( | 10:59 |
| mvo | (even though its hard for me to see from the code how this could be) | 11:00 |
| mvo | zyga-ubuntu: slightly frustrating, I have no luck reproducing the 2.32 failure in qemu so far, I did two runs, one with random seed and one with seed from a failing PR against qemu:ubuntu-16.04-64 but no failures so far (and almost finished) | 11:02 |
| zyga-ubuntu | could it be, perhaps, caused, by any changes in core that landed since? | 11:03 |
| * zyga-ubuntu looks at the logic in prepare code | 11:03 | |
| pedronis | #4789 needs a 2nd review | 11:03 |
| zyga-ubuntu | for me it's not failing anymore either | 11:03 |
| mup | PR #4789: many: support holding refreshes by setting refresh.hold <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4789> | 11:03 |
| zyga-ubuntu | mvo: are you running all of it or just some | 11:08 |
| zyga-ubuntu | maybe the update test leaks something into the system? | 11:08 |
| mvo | all of main | 11:08 |
| cachio | mvo, hey | 11:09 |
| mvo | cachio: hey | 11:09 |
| mvo | cachio: hope you are well! | 11:09 |
| === BlackDex_ is now known as BlackDex | ||
| mvo | zyga-ubuntu: *cough* 2.32 is green again | 11:33 |
| zyga-ubuntu | :/ yeah same here | 11:33 |
| zyga-ubuntu | it's driving me nuts | 11:33 |
| zyga-ubuntu | so what changed since friday | 11:33 |
| zyga-ubuntu | is it just bad luck | 11:34 |
| zyga-ubuntu | what's the real problem we're not seeing | 11:34 |
| mvo | zyga-ubuntu: also green in travis | 11:34 |
| zyga-ubuntu | 1st world problems, tests are green but WHY :) | 11:34 |
| mvo | zyga-ubuntu: indeed, very peculiar | 11:36 |
| zyga-ubuntu | ok, I'll keep running and look at our prepare/restore code | 11:37 |
| zyga-ubuntu | and maybe, just maybe, something will come up | 11:37 |
| zyga-ubuntu | how come there's no shellcheck snap yet | 11:40 |
| zyga-ubuntu | mvo: I found a small bug in spread.yaml | 11:58 |
| zyga-ubuntu | mvo: the tests/completion suite's restore code doesn't remove snap-confine | 11:58 |
| zyga-ubuntu | it's not a big deal (maybe) | 11:58 |
| zyga-ubuntu | I've patched it locally now | 11:59 |
| zyga-ubuntu | snap-confine is supposed to be just transitional now | 11:59 |
| mvo | zyga-ubuntu: ta | 11:59 |
| mup | PR snapd#4639 closed: store: enable deltas for core devices too <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4639> | 11:59 |
| zyga-ubuntu | same with the regression suite | 12:00 |
| zyga-ubuntu | mvo: I just got a failure on the 2.32 branch | 12:00 |
| zyga-ubuntu | [Mon Mar 12 12:57:05 2018] audit: type=1400 audit(1520855826.802:795346): apparmor="DENIED" operation="exec" profile="/snap/core/4224/usr/lib/snapd/snap-confine" name="/usr/lib/snapd/snap-device-helper" pid=31151 comm="snap-confine" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 | 12:01 |
| zyga-ubuntu | I have a debug shell | 12:01 |
| mvo | zyga-ubuntu: what test is that? | 12:01 |
| zyga-ubuntu | https://www.irccloud.com/pastebin/47FjVl3F/ | 12:02 |
| zyga-ubuntu | security-device-cgroups | 12:02 |
| zyga-ubuntu | with the uinput sub-test | 12:02 |
| zyga-ubuntu | the previous one was validate-container | 12:02 |
| zyga-ubuntu | this is on a single-machine qemu | 12:02 |
| mvo | zyga-ubuntu: thanks, looking | 12:03 |
| zyga-ubuntu | the profile on disk is: http://paste.ubuntu.com/p/BNBk4526cC/ | 12:03 |
| zyga-ubuntu | this is /etc/apparmor.d/snap.core.4224.usr.lib.snapd.snap-confine | 12:03 |
| zyga-ubuntu | there is no snap-device-helper here | 12:04 |
| mvo | zyga-ubuntu: hm, yeah | 12:04 |
| zyga-ubuntu | looking at the core snap | 12:04 |
| zyga-ubuntu | maybe the core snap got repackaged | 12:04 |
| zyga-ubuntu | with some broken stuff inside | 12:04 |
| mvo | zyga-ubuntu: oh, I think this is the snapd that uses the symlink, so looks like one more thing to cherry pick | 12:05 |
| zyga-ubuntu | this is the profile in the core snap there: http://paste.ubuntu.com/p/tcQ42chRQK/ | 12:05 |
| zyga-ubuntu | /usr/lib/snapd/snap-device-helper ixr, # drop | 12:05 |
| zyga-ubuntu | it _has_ permission to run this | 12:05 |
| zyga-ubuntu | so this is clearly broken | 12:06 |
| * zyga-ubuntu diffs the two files | 12:06 | |
| mvo | zyga-ubuntu: meh, how can this happen? this looks like test prepare is broken | 12:06 |
| zyga-ubuntu | https://www.irccloud.com/pastebin/KmbgETkf/ | 12:06 |
| zyga-ubuntu | hum | 12:07 |
| zyga-ubuntu | this makes no sense | 12:07 |
| zyga-ubuntu | - /usr/lib/snapd/snap-device-helper ixr, # drop | 12:07 |
| zyga-ubuntu | + /lib/udev/snappy-app-dev ixr, # drop | 12:07 |
| zyga-ubuntu | how did we go from - snap-device-helper (from the core snap) to + snappy-app-dev from the apparmor.d dir? | 12:08 |
| * zyga-ubuntu looks at the preserved test tarball helper thing | 12:08 | |
| zyga-ubuntu | mvo: I bet you this will show the prepare/restore is wrong | 12:08 |
| mvo | zyga-ubuntu: yeah, I need to get lunch now, biab | 12:08 |
| mborzecki | zyga-ubuntu: are you running just this test or the whole bunch? | 12:10 |
| zyga-ubuntu | mvo: confirmed, the tarball has junk inside | 12:10 |
| zyga-ubuntu | mborzecki: all of main each time | 12:10 |
| zyga-ubuntu | let me give you the seed | 12:11 |
| zyga-ubuntu | this is on top of release/2.32 | 12:11 |
| zyga-ubuntu | zyga@t470:~/snapd$ spread -debug -v qemu:ubuntu-16.04-64:tests/main/ | 12:11 |
| zyga-ubuntu | 2018-03-12 12:07:55 Found /home/zyga/snapd/spread.yaml. | 12:11 |
| zyga-ubuntu | 2018-03-12 12:07:58 Project content is packed for delivery (3.88MB). | 12:11 |
| zyga-ubuntu | 2018-03-12 12:07:58 Sequence of jobs produced with -seed=1520852878 | 12:11 |
| zyga-ubuntu | mborzecki: can you please run that and see if you get the exact same bug? | 12:11 |
| zyga-ubuntu | I will look at why this happens | 12:11 |
| zyga-ubuntu | I have an idea now | 12:11 |
| zyga-ubuntu | and man | 12:11 |
| zyga-ubuntu | mborzecki: I can send you my spread binary if that is a factor | 12:13 |
| zyga-ubuntu | 2018-03-12 12:16:21 Preparing qemu:ubuntu-16.04-64:tests/main/interfaces-many... | 12:18 |
| zyga-ubuntu | # ls -ld $SPREAD_PATH/snapd-state.tar.gz | 12:18 |
| zyga-ubuntu | -rw-r--r-- 1 root root 366991360 Mar 12 12:16 /home/gopath/src/github.com/snapcore/snapd/snapd-state.tar.gz | 12:18 |
| zyga-ubuntu | so at around the time when we ran interfaces-many test, the state tarball was made | 12:18 |
| zyga-ubuntu | and it wasn't touched since | 12:18 |
| zyga-ubuntu | and it contains _wrong_ code | 12:18 |
| zyga-ubuntu | as in, it captures a state that is wrong | 12:19 |
| zyga-ubuntu | and much much later | 12:19 |
| zyga-ubuntu | 2018-03-12 12:57:06 Error executing qemu:ubuntu-16.04-64:tests/main/security-device-cgroups:uinput : | 12:19 |
| zyga-ubuntu | this test failed because of that | 12:19 |
| zyga-ubuntu | that test doesn't fiddle with snapd | 12:20 |
| zyga-ubuntu | now | 12:20 |
| zyga-ubuntu | we have code that detects this and writes a correct profile | 12:20 |
| zyga-ubuntu | but when I inspected the system it wasn't apparent it ran | 12:21 |
| === pstolowski|lunch is now known as pstolowski | ||
| zyga-ubuntu | aha | 12:22 |
| zyga-ubuntu | but this code only runs when we install core | 12:22 |
| zyga-ubuntu | and if none of the preceeding tests tired to run snap-devce-helper / snappy-app-whatever it was | 12:22 |
| zyga-ubuntu | it would not trigger | 12:22 |
| zyga-ubuntu | mvo: so we still have an issue that may need addressing | 12:23 |
| zyga-ubuntu | apart from 1) how did we get there we have the problem that on startup we 2) may run with stale profile for snap-confine because it is only remade when we install "core" | 12:23 |
| zyga-ubuntu | I also looked at the backend initialize function and I doubt it is loading the stale profile because it would only do so on system-key like events (nfs or overlay) | 12:26 |
| zyga-ubuntu | the system-key file also looks sensible | 12:26 |
| zyga-ubuntu | I added some debug and I will try to reproduce that with the same seed ( -seed=1520852878) | 12:27 |
| zyga-ubuntu | mvo: one thing that _may_ be related is that /var/cache/apparmor is full of things | 12:29 |
| zyga-ubuntu | as is /etc/apparmor.d/cache | 12:31 |
| zyga-ubuntu | the biggest question is if the seed will reproduce the issue | 12:31 |
| cachio | niemeyer, hey, when you have a time | 12:32 |
| cachio | https://github.com/snapcore/spread/pull/52 | 12:32 |
| mup | PR spread#52: Add storage option for google <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/52> | 12:32 |
| cachio | that shoul fix the issue that savic was reporting about out of space | 12:33 |
| cachio | tx | 12:33 |
| mup | PR snapd#4812 opened: tests/main/snap-service-refresh-mode: refactor the test to rely on comparing PIDs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4812> | 12:46 |
| zyga-ubuntu | so, I wonder about an idea | 12:48 |
| zyga-ubuntu | let's say I get a failure again, and that -seed works | 12:48 |
| zyga-ubuntu | how can we make spread bisect the test suite to find what breaks | 12:48 |
| zyga-ubuntu | that is, run the failing test after running half of the preceding tests, etc | 12:49 |
| cachio | mvo, niemeyer I am waiting for a doctor at home, perhaps I'll be starting later the standup | 12:54 |
| zyga-ubuntu | excellent, I can reproduce the issue reliably now mvo | 13:19 |
| mborzecki | zyga-ubuntu: my test run is still in progress, should i abort? | 13:25 |
| zyga-ubuntu | no sure, why? | 13:25 |
| mborzecki | zyga-ubuntu: thought that maybe reuse the seed, and only use those 2 tests that you mentioned | 13:26 |
| zyga-ubuntu | aga | 13:26 |
| zyga-ubuntu | aha | 13:26 |
| zyga-ubuntu | well, which test are you on now? | 13:26 |
| * kalikiana will go try and have lunch without being too soaked in the rain | 13:26 | |
| mborzecki | (143/234) | 13:26 |
| zyga-ubuntu | no, please wait then | 13:26 |
| zyga-ubuntu | it's on 155 AFAIR | 13:26 |
| zyga-ubuntu | so "soon" | 13:26 |
| mborzecki | taking ages :/ | 13:26 |
| zyga-ubuntu | mborzecki: when did you start it? | 13:28 |
| mborzecki | 12:40, but then it got stuck in a debug shell in a test i was working on, and took a while before i noticed | 13:29 |
| zyga-ubuntu | ah | 13:29 |
| zyga-ubuntu | for me it's ~30 minutes | 13:29 |
| zyga-ubuntu | +/- 15 minutes | 13:30 |
| mvo | zyga-ubuntu: part of the problem is that edge is not really edge | 13:30 |
| mvo | zyga-ubuntu: I just pushed a pr | 13:30 |
| zyga-ubuntu | oh? | 13:30 |
| zyga-ubuntu | mvo: can you explain please | 13:30 |
| zyga-ubuntu | I see | 13:30 |
| mup | PR snapd#4813 opened: release: snapd 2.31.2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4813> | 13:30 |
| mvo | zyga-ubuntu: snap info core :/ its on 2.31.2 in edge right now | 13:30 |
| zyga-ubuntu | mvo: but how would it be a factor | 13:30 |
| zyga-ubuntu | mvo: since we change the version to leet | 13:31 |
| mvo | zyga-ubuntu: 2.31 is still using snappy-app-dev | 13:31 |
| zyga-ubuntu | I mean, is it a factor? | 13:31 |
| mvo | zyga-ubuntu: so that explains why the profiles are strange | 13:31 |
| zyga-ubuntu | yes but whatever is in whatever channel we start with | 13:31 |
| zyga-ubuntu | we are repackaging core, no? | 13:31 |
| mvo | yes | 13:32 |
| Son_Goku | mvo, can we get this merged so I can rebase? https://github.com/snapcore/snapd/pull/4811 | 13:32 |
| mup | PR #4811: tests/main/media-sharing: improve the test to cover /media and /run/media <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4811> | 13:32 |
| mborzecki | Son_Goku: merged | 13:33 |
| mup | PR snapd#4811 closed: tests/main/media-sharing: improve the test to cover /media and /run/media <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4811> | 13:33 |
| mup | PR snapcraft#1985 closed: tests: document arm testing setup <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1985> | 13:39 |
| zyga-ubuntu | mborzecki: did it fail? | 13:42 |
| mborzecki | zyga-ubuntu: nope, (214/234) | 13:42 |
| zyga-ubuntu | so it's past that test | 13:42 |
| zyga-ubuntu | were you on release/2.32 | 13:42 |
| mborzecki | zyga-ubuntu: i used the same seed as you | 13:42 |
| mborzecki | yes | 13:42 |
| zyga-ubuntu | and on qemu of xenial? | 13:42 |
| zyga-ubuntu | that's not great then :/ | 13:42 |
| zyga-ubuntu | thank you, I wonder what this says then | 13:43 |
| mborzecki | yes, tip of release/2.32 branch | 13:43 |
| pstolowski | niemeyer: so, the interface is named "dummy" atm, with a description saying "snapd dummy test interface" | 13:51 |
| niemeyer | pstolowski: What's the PR? | 13:52 |
| niemeyer | pstolowski: After the conversation we just had, that's not too bad actually.. perhaps "snapd-dummy".. I'd just like to have a look at the code first | 13:54 |
| pstolowski | niemeyer: #4358 | 13:54 |
| mup | PR #4358: interfaces: interface hooks implementation <Created by stolowski> <https://github.com/snapcore/snapd/pull/4358> | 13:54 |
| pstolowski | niemeyer: look for dummy.go | 13:54 |
| niemeyer | Thanks | 13:54 |
| zyga-ubuntu | niemeyer: no-op interface? | 13:55 |
| mborzecki | Chipaca: #4800 is the same as #4799 and the title suggests it ought to be a different thing | 13:59 |
| mup | PR #4800: cmd/snap: in changes and tasks, default to human-friendly times <Created by chipaca> <https://github.com/snapcore/snapd/pull/4800> | 13:59 |
| mup | PR #4799: cmd/snap: use timeutil.Human to show times in `snap refresh --time` <Created by chipaca> <https://github.com/snapcore/snapd/pull/4799> | 13:59 |
| * Chipaca looks | 14:00 | |
| Chipaca | wtf | 14:00 |
| mborzecki | Chipaca: bad rebase? | 14:01 |
| Chipaca | mborzecki: thanks, i'll take a look | 14:01 |
| Chipaca | mborzecki: shouldn't be, but maybe? 'tis a mystery | 14:01 |
| Chipaca | :-) | 14:02 |
| Chipaca | mborzecki: probably fat fingers of some sort | 14:02 |
| mborzecki | Chipaca: hopefully nothing that cannot be fixed with the reflog :P | 14:03 |
| mborzecki | zyga-ubuntu: sorry to disappoint you, found this in my shell history 'git checkout -b release/2.32', i'm restarting the tests | 14:04 |
| zyga-ubuntu | :D | 14:04 |
| mborzecki | if i use the same -seed=.. and list jus 2 tests, will they be run in the same order as if i used tests/main/ ? | 14:06 |
| zyga-ubuntu | mborzecki: I don't think so | 14:06 |
| zyga-ubuntu | not sure | 14:06 |
| zyga-ubuntu | niemeyer: ^ | 14:06 |
| niemeyer | pstolowski: This is not a dummy interface, because it actually has expectations in its logic | 14:07 |
| niemeyer | pstolowski: People in general will expect "dummy" or "nil" or "no-op" or anything similar to actually not do anything | 14:07 |
| niemeyer | So we need a name to represent that | 14:07 |
| zyga-ubuntu | sunshine | 14:17 |
| pstolowski | niemeyer: it's dummy in a sense that it doesn't provide any functionality; it's only useful to test against | 14:24 |
| * Chipaca brb | 14:28 | |
| niemeyer | pstolowski: Yeah, maybe that's fine, and then we can expose this as a general dummy interface that any snap can use.. I'm adding some comments to the PR | 14:30 |
| mvo | zyga-ubuntu: *maybe* I found the issue with the 2.32 tests, its tests only, I'm running a test now | 14:30 |
| zyga-ubuntu | mvo: I'm all ears | 14:34 |
| zyga-ubuntu | I'm iterating on narrowing down the set of tests that causes it | 14:34 |
| pstolowski | niemeyer: thanks | 14:35 |
| kalikiana | re | 14:37 |
| niemeyer | pstolowski: Please have a look | 14:41 |
| mup | PR snapd#4814 opened: tests: fix re-exec profile generation in tests on classic <Created by mvo5> <https://github.com/snapcore/snapd/pull/4814> | 14:41 |
| mvo | zyga-ubuntu: just pushed a PR that hopefully explains it (for 2.32) and will also push one for master | 14:41 |
| zyga-ubuntu | ack | 14:41 |
| mvo | zyga-ubuntu: its essentially a race | 14:42 |
| zyga-ubuntu | what's racing? | 14:42 |
| mvo | zyga-ubuntu: between us modifying the core and the auto-generated snap-profiles for the core. because we have the system key now we need to make sure to re-generate them | 14:42 |
| mvo | zyga-ubuntu: so your idea about ensure-dir-state was correct, its just that the system-key now prevents security profile generation if nothing has changed | 14:43 |
| mvo | zyga-ubuntu: (nothing in the inputs) | 14:43 |
| pstolowski | niemeyer: looking, thanks | 14:43 |
| zyga-ubuntu | I see | 14:45 |
| zyga-ubuntu | mvo: any ideas why this would explain why I can reproduce the problem with a given seed? | 14:45 |
| mup | PR snapd#4815 opened: tests: fix re-exec profile generation in tests on classic <Created by mvo5> <https://github.com/snapcore/snapd/pull/4815> | 14:45 |
| cachio | jdstrand, hey, I see this denial executing the security-device-cgroups:uinput | 14:46 |
| cachio | https://paste.ubuntu.com/p/gDqTw7JPrp/ | 14:46 |
| zyga-ubuntu | cachio: jamie is off this week | 14:46 |
| zyga-ubuntu | cachio: and this is the issue we are discussing with mvo now | 14:47 |
| cachio | zyga-ubuntu, ah, ok, good to know, thanks | 14:47 |
| mvo | zyga-ubuntu: maybe, its a mystery why it is not reproducible with the seed. however the race is that for some tests the profile is close enough, so if for whatever reason we force re-generation of security profiles in any test and that happens before the failing test things are good | 14:48 |
| zyga-ubuntu | mvo: I managed to reproduce it by running one test now | 14:49 |
| zyga-ubuntu | mvo: maybe it depends on my CPU speed or something like that? | 14:49 |
| zyga-ubuntu | I'll try your patch on my system, thank you for pushing the fix and finding the problem | 14:51 |
| mup | PR snapd#4816 opened: Tests move xenial i386 to google <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4816> | 14:53 |
| mvo | zyga-ubuntu: thank you! | 15:04 |
| zyga-ubuntu | I will try -resend next | 15:20 |
| zyga-ubuntu | now that I can essentially iterate on one test | 15:20 |
| mup | PR snapd#4812 closed: tests/main/snap-service-refresh-mode: refactor the test to rely on comparing PIDs <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4812> | 15:23 |
| mvo | Chipaca: how do you feel about 4486? it will run `snap advise` when `snap run not-installed-command` is used. but given our command-not-found work I think we can kill this. wdyt? | 15:24 |
| mup | PR snapd#4799 closed: cmd/snap: use timeutil.Human to show times in `snap refresh --time` <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4799> | 15:28 |
| mvo | Chipaca: and one more silly question, why does https://github.com/snapcore/snapd/pull/4800/files#diff-dbcb08a7fd2e809c90019780f0ae6cf6R562 change the format in the tests? | 15:29 |
| mup | PR #4800: cmd/snap: in changes and tasks, default to human-friendly times <Created by chipaca> <https://github.com/snapcore/snapd/pull/4800> | 15:29 |
| mup | PR snapd#4817 opened: overlord: implement policy of holding refreshes for up to 6h since seeding on classic <Created by pedronis> <https://github.com/snapcore/snapd/pull/4817> | 15:29 |
| mup | PR snapd#4486 closed: snap: make `snap run not-install` output advise for not installed commands <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4486> | 15:32 |
| Chipaca | mvo: kill it :-) | 15:33 |
| Chipaca | mvo: i mean, #4486 | 15:33 |
| mup | PR #4486: snap: make `snap run not-install` output advise for not installed commands <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4486> | 15:33 |
| Chipaca | mvo: i messed up a rebase and need to fix it | 15:34 |
| pedronis | Chipaca: seems you landed something that conflicts with 4789 | 15:34 |
| pedronis | bit of a mess given that we probably want to cherry pick the latter | 15:34 |
| Chipaca | #4789 | 15:34 |
| mup | PR #4789: many: support holding refreshes by setting refresh.hold <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4789> | 15:34 |
| pedronis | for 2.32 | 15:34 |
| Chipaca | in my defense, it was mvo that landed it :-) | 15:34 |
| Chipaca | mvo: the rebase I messed up was the 'changes' one, fwiw | 15:35 |
| pedronis | mvo: ^^^ | 15:35 |
| * zyga-ubuntu feels he's getting sick :/ | 15:35 | |
| zyga-ubuntu | this sucks | 15:35 |
| Chipaca | digging in the reflog as i type | 15:35 |
| Chipaca | well, not as i type | 15:35 |
| mvo | Chipaca: uuhhh, what pr was that? | 15:35 |
| pedronis | mvo: it's a bit of a mess if we land cosmetics over things we want for 2.32 | 15:35 |
| Chipaca | mvo: #4800 | 15:35 |
| mup | PR #4800: cmd/snap: in changes and tasks, default to human-friendly times <Created by chipaca> <https://github.com/snapcore/snapd/pull/4800> | 15:35 |
| mvo | pedronis: yes, sorry for that | 15:36 |
| pedronis | I'm quite sure we already we will have fun with the changes to store tests | 15:36 |
| Chipaca | mvo: I'd recommend removing #4799 from master | 15:36 |
| mup | PR #4799: cmd/snap: use timeutil.Human to show times in `snap refresh --time` <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4799> | 15:36 |
| Chipaca | mvo: make your life easier | 15:36 |
| Chipaca | (and by removing i mean 'git revert --hard && git push --force' :-) | 15:36 |
| mvo | Chipaca: not sure we can do that, but an old fashioned revert seems to be ok | 15:37 |
| Chipaca | mvo: we can (we just need to untick the --force protection around it) | 15:37 |
| Chipaca | (bah, that might involve niemeyer) | 15:37 |
| mvo | zyga-ubuntu: it looks like spread is disagreeing with my fix :( | 15:38 |
| pedronis | anyway a 2nd review for #4789 so it can land would also help | 15:39 |
| mup | PR #4789: many: support holding refreshes by setting refresh.hold <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4789> | 15:39 |
| zyga-ubuntu | mvo: my results will come up soon, | 15:39 |
| zyga-ubuntu | mvo: I'm still looking | 15:39 |
| mvo | zyga-ubuntu: its very annoying, it all made sense. I hope to get a debug shell soon | 15:40 |
| zyga-ubuntu | Thank you | 15:40 |
| mvo | zyga-ubuntu: maybe its something silly and I can cling on to my theory | 15:40 |
| zyga-ubuntu | I hope the tea will help you on the way :) | 15:40 |
| zyga-ubuntu | added more debug, with your patch and restarted | 15:43 |
| mup | PR snapd#4818 opened: Revert "cmd/snap: use timeutil.Human to show times in `snap refresh -…-time`" <Created by mvo5> <https://github.com/snapcore/snapd/pull/4818> | 15:51 |
| Chipaca | mvo: about changing the format in the tests, which one do you mean? I presume it's something in https://github.com/snapcore/snapd/pull/4799/files | 15:52 |
| mup | PR #4799: cmd/snap: use timeutil.Human to show times in `snap refresh --time` <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4799> | 15:52 |
| Chipaca | mvo: (i changed a few formats for different reasons...) | 15:53 |
| mvo | Chipaca: let me just ask in the PR that is easier | 15:53 |
| Chipaca | mvo: ok :-) | 15:53 |
| Chipaca | mvo: but I _think_ the one you're asking about is because before it just blatted whatever came in the json, and the json in the test was not kosher | 15:53 |
| pedronis | mvo: did you just review #4789 ? | 15:54 |
| mup | PR #4789: many: support holding refreshes by setting refresh.hold <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4789> | 15:54 |
| Chipaca | pedronis: yes he did | 15:54 |
| pedronis | thx | 15:54 |
| mvo | Chipaca: aha, ok. that was my question - i.e. if the json was incorrect or something changed | 15:55 |
| mvo | pedronis: yes, sorry that it took so long | 15:55 |
| Chipaca | mvo: the json was fanciful | 15:55 |
| Chipaca | :-) | 15:55 |
| pedronis | mvo: np, was confused by the fix reference, is that about the last change there? | 15:55 |
| Muravey | Hi | 15:55 |
| Chipaca | Muravey: hi | 15:56 |
| zyga-ubuntu | hey hey | 15:56 |
| mvo | pedronis: the fix reference to zyga-ubuntu ? that was about the test failures on master and 2.32. I thought I had found the issue (race with the core profile rewrite) | 15:56 |
| mvo | pedronis: but then spread failed in a similar way so there must be more to it | 15:57 |
| Muravey | Can anyone help me? I tring to make snap package for cataclysm dda game | 15:57 |
| pedronis | mvo: no, the fix in your +1 comment to 4789 | 15:57 |
| * zyga-ubuntu is still looking | 15:57 | |
| mvo | pedronis: oh, I mean, thanks for fixing this issue, i.e. thanks for this new feature :) | 15:58 |
| Chipaca | Muravey: sure (but if it gets long we might ask you to take it to the forum instead) | 15:58 |
| Muravey | After install package i cant run game and it's crashed with file not found | 15:59 |
| pedronis | mvo: ah | 16:00 |
| pedronis | :) | 16:00 |
| zyga-ubuntu | Muravey: run snap run --shell yoursnapname | 16:00 |
| zyga-ubuntu | and explore the environment | 16:00 |
| zyga-ubuntu | that may explain some things to you | 16:00 |
| zyga-ubuntu | mvo: it didn't fail with your patch now :// | 16:02 |
| Muravey | zyga-ubuntu: sorry for my english | 16:02 |
| zyga-ubuntu | I'll try again with all of main | 16:03 |
| zyga-ubuntu | and the same seed as before | 16:03 |
| Muravey | zyga-ubuntu: what environments i need see? PATH? | 16:03 |
| zyga-ubuntu | Muravey: no, I mean more than that, the whole filesystem | 16:03 |
| Chipaca | Muravey: tell us more about your snap | 16:03 |
| zyga-ubuntu | your snap is mounted at /snap/yoursnapname/somenumber/ | 16:03 |
| zyga-ubuntu | and if you open a file, say from /usr/share/yourapp/foo | 16:03 |
| zyga-ubuntu | that won't work | 16:04 |
| Chipaca | Muravey: for example, show us your snapcraft.yaml, and your snap.yaml (use pastebin.ubuntu.com) | 16:04 |
| zyga-ubuntu | it's a typical problem in snapping software | 16:04 |
| Muravey | zyga-ubuntu: will you here in an hour? I'm driving. | 16:07 |
| zyga-ubuntu | Muravey: probably not | 16:08 |
| zyga-ubuntu | I need to leave soon | 16:08 |
| mvo | zyga-ubuntu: yeah, my patch seems to be not sufficient | 16:08 |
| zyga-ubuntu | I'll look at what exactly happens on restore in this test | 16:08 |
| cachio | mvo, hey | 16:15 |
| cachio | I ran some tests for 2.32.2 today in my dragonboard and I see an error | 16:15 |
| mup | PR snapd#4819 opened: interfaces/serial: change pattern not to exclude valid devices <Created by bergotorino> <https://github.com/snapcore/snapd/pull/4819> | 16:15 |
| cachio | https://paste.ubuntu.com/p/zwRWvmx4GZ/ | 16:15 |
| cachio | mvo, it is strange because I did not see that error when I executed the tests in testflinger devices for beta validation | 16:16 |
| Chipaca | mborzecki: mvo: fwiw #4800 is now what it should've been (probably) | 16:16 |
| mup | PR #4800: cmd/snap: in changes and tasks, default to human-friendly times <Created by chipaca> <https://github.com/snapcore/snapd/pull/4800> | 16:16 |
| cachio | any idea what be causing that? | 16:16 |
| Chipaca | cachio: you don't have policykit installed | 16:17 |
| Chipaca | cachio: try again with sudo | 16:17 |
| mvo | cachio: what Chipaca said, the error is quite confusing though, it should indicate that it is systemd not the unit that has the problem | 16:17 |
| Chipaca | cachio: is tht 14.04? | 16:18 |
| cachio | core-16-arm-64 | 16:18 |
| niemeyer | mvo, Chipaca: Anything I can help with or is it sorted? | 16:19 |
| Chipaca | cachio: do we ship policykit in core? | 16:20 |
| cachio | Chipaca, with sudo is working | 16:20 |
| cachio | the test suite is failing to save the state | 16:21 |
| cachio | the snapd service is not running | 16:21 |
| Chipaca | cachio: AFAICT we don't ship policykit in core, but I don't know how to improve that error message | 16:21 |
| cachio | but I can't see why | 16:21 |
| Chipaca | cachio: what happens if you run: SNAPD_DEBUG=1 /usr/lib/snapd/snapd | 16:22 |
| mvo | Chipaca: that is coming from systemctl/systemd, right? | 16:22 |
| Chipaca | cachio: (as root) | 16:22 |
| Chipaca | mvo: yes | 16:22 |
| mup | PR snapcraft#1866 closed: lxd: setup LXD remote for multipass <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1866> | 16:22 |
| cachio | Chipaca, mvo https://paste.ubuntu.com/p/yM5Tz2qFMw/ | 16:23 |
| cachio | I found that | 16:23 |
| cachio | it is causing snapd doesn't start | 16:23 |
| Chipaca | cachio: where is that coming from? | 16:24 |
| Chipaca | cachio: and what snapd are you running? | 16:24 |
| Chipaca | that change _just_ landed on master | 16:24 |
| cachio | + systemctl stop snapd.refresh.timer | 16:24 |
| cachio | Failed to stop snapd.refresh.timer: Unit snapd.refresh.timer not loaded. | 16:24 |
| cachio | sorry, this was the real proble | 16:24 |
| cachio | m | 16:24 |
| Chipaca | the abs-time change is on master only | 16:25 |
| mvo | cachio: oh? I thought we fixed that everywhere, what branch are you on? | 16:25 |
| Chipaca | the snapd.refresh.timer, i thought that was fixed | 16:25 |
| cachio | 2.32.2 | 16:25 |
| Chipaca | yeah something is awry | 16:25 |
| Chipaca | cachio: where did the abs-time message come from? | 16:25 |
| cachio | Chipaca, sorry, that was from another tests executed on master | 16:26 |
| cachio | this is what I see in 2.32.2 | 16:26 |
| cachio | Failed to stop snapd.refresh.timer: Unit snapd.refresh.timer not loaded. | 16:26 |
| cachio | on my device | 16:26 |
| Chipaca | cachio: and that is stopping snapd from starting? | 16:27 |
| cachio | Chipaca, no, it is making fail the step to create the initial state | 16:27 |
| cachio | Chipaca, then the suite fails because the initial state was not created | 16:29 |
| mvo | cachio: could you please pastebin "git status" and "git rev-parse HEAD"? | 16:31 |
| mvo | cachio: I really though we fixed this timer issue :/ | 16:32 |
| cachio | mvo, you are right | 16:33 |
| cachio | was my fault | 16:33 |
| mvo | cachio: no worries | 16:34 |
| cachio | mvo, I used 2.32.2 instead of 2.31.2 | 16:34 |
| cachio | that's why all the tests passed on testflinger | 16:34 |
| mvo | cachio: yeah, that is confusing | 16:34 |
| cachio | and failed on my device | 16:34 |
| cachio | Chipaca, mvo sorry | 16:34 |
| cachio | mvo, that happens when I don't sleep well :( | 16:36 |
| Chipaca | mvo: speaking of sleeping well, when're you swapping | 16:36 |
| Chipaca | ? | 16:36 |
| mvo | cachio: with release/2.32:bb05e2fe9539b8728b9d219858125e5f98aed2d5 things should be good in there. 2.31 should be ok as well | 16:37 |
| mvo | Chipaca: friday | 16:37 |
| Chipaca | mvo: ok | 16:37 |
| cachio | Chipaca, my dauther is seek so I could not sleep last night | 16:40 |
| mvo | cachio: I hope she gets well soon | 16:40 |
| cachio | Chipaca, I planned to rest :( | 16:40 |
| cachio | mvo, yes, she is better today | 16:40 |
| mvo | cachio: double hard with jetlag I suppose :( | 16:40 |
| cachio | mvo, yes, I think I'm not buying chacolates anymore during the sprints | 16:41 |
| pedronis | Chipaca: mvo: I'll very likely swap Wed | 16:41 |
| mup | PR snapd#4818 closed: Revert "cmd/snap: use timeutil.Human to show times in `snap refresh -…-time`" <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4818> | 16:45 |
| * Chipaca hugs cachio | 16:47 | |
| Chipaca | cachio: take care dude | 16:47 |
| cachio | Chipaca, :) tx | 16:49 |
| cachio | mvo, last thing today for you | 16:49 |
| Chipaca | mvo: pedronis: any reason not to merge #4789? | 16:49 |
| mup | PR #4789: many: support holding refreshes by setting refresh.hold <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4789> | 16:49 |
| cachio | mvo, we need the user assertion | 16:50 |
| cachio | to run again in nightly the core revert test | 16:50 |
| Muravey | zyga-ubuntu: i thought that app in snap package after installing get it's own mount name space. | 16:52 |
| pedronis | Chipaca: no, was waiting for ther revert | 16:59 |
| Chipaca | pedronis: already there | 16:59 |
| mup | PR snapd#4789 closed: many: support holding refreshes by setting refresh.hold <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4789> | 17:00 |
| pedronis | saw that now, merged | 17:00 |
| Chipaca | who was it I chatted with about shipping an empty squashfs? zyga-ubuntu and mvo? or was niemeyer also involved | 17:05 |
| niemeyer | Chipaca: Not me | 17:05 |
| Chipaca | FYI, https://people.canonical.com/~john/bare.squashfs <- 4k, including a README | 17:05 |
| Chipaca | niemeyer: ok | 17:05 |
| Chipaca | niemeyer: FWIW it's about not having a good way of detecting / pulling in squashfs support in some situations | 17:06 |
| Chipaca | easiest way being to just try to mount something | 17:06 |
| niemeyer | Chipaca: Not sure I understand what's the advantage vs. trying to actually mount the thing you indeed want to mount | 17:07 |
| Chipaca | niemeyer: 'snap install foo -> download core -> cryptic message because mount failed' vs 'snap install foo' -> 'no squashfs support lolz' | 17:08 |
| Chipaca | making it easy and cheap to detect before downloading stuff | 17:09 |
| Chipaca | (especially as the error is currently cryptic, but even fixing that knowing in advance the install isn't going to work has value) | 17:09 |
| niemeyer | Chipaca: Yes, I understand that part. The question is why is it easier to have a good message when mounting something empty fails, vs. when mounting the real thing you in fact want to mount. In both cases we're mounting a filesystem, and can introspect the result. | 17:10 |
| niemeyer | Chipaca: Also, when do we do that? Every time we're trying to install anything? Everytime we start? What if the kernel changes and squashfs stops being supported? | 17:11 |
| niemeyer | Chipaca: My gut feeling is to introspect the system and have good feedback on the real operation, instead of the fake one preceding it | 17:11 |
| Chipaca | niemeyer: that would still come after the download (and is a rather large amount of work) | 17:12 |
| Chipaca | i mean, it's not just looking errno codes up in the manpage | 17:12 |
| Chipaca | it's looking at 'systemd show', probably | 17:13 |
| Chipaca | ('systemctl show' i meant -- 'systemctl status's machine-friendly cousin) | 17:13 |
| Chipaca | - Mount snap "core" (4110) ([start var-lib-snapd-snap-core-4110.mount] failed with exit status 1: Job for var-lib-snapd-snap-core-4110.mount failed. | 17:15 |
| Chipaca | See "systemctl status var-lib-snapd-snap-core-4110.mount" and "journalctl -xe" for details. | 17:15 |
| Chipaca | ) | 17:15 |
| Chipaca | ^ that's what's there now | 17:15 |
| niemeyer | Chipaca: [niemeyer@nomad ~]% sudo mount -t squashfs /tmp /tmp | 17:16 |
| niemeyer | mount: /tmp is not a block device | 17:16 |
| niemeyer | [niemeyer@nomad ~]% sudo mount -t blah /tmp /tmp | 17:16 |
| niemeyer | mount: unknown filesystem type 'blah | 17:16 |
| Chipaca | niemeyer: we don't call mount ourselves | 17:17 |
| Chipaca | niemeyer: if we were doing so, getting the error reason would be easier | 17:17 |
| niemeyer | Chipaca: The point is that it seems rather simple to tell whether the system supports it or not | 17:17 |
| Chipaca | niemeyer: 'exit status 1' is a lot less information than checking errno == ENODEV | 17:18 |
| Chipaca | niemeyer: I'm assuming there is more information somewhere in the guts of systemctl, such that 'systemctl show' with the appropriate --property would let us figure out that it's ENODEV | 17:20 |
| Chipaca | niemeyer: if not, then ¯\_(ツ)_/¯ | 17:20 |
| niemeyer | Chipaca: Sorry.. I don't really understand what the goal is anymore.. | 17:20 |
| Chipaca | niemeyer: did you see the error we're currently giving users when their system doesn't support squashfs | 17:21 |
| niemeyer | Chipaca: Are you saying that shipping a dummy squashfs and performing real system calls ot mount it and checking the result is simpler than calling a function and checking its result? | 17:21 |
| Chipaca | niemeyer: which function? | 17:21 |
| niemeyer | mount("/tmp", "/tmp", "squashfs", MS_MGC_VAL, NULL) = -1 ENOTBLK (Block device required) | 17:22 |
| Chipaca | where would we do that? | 17:22 |
| niemeyer | Chipaca: Wherever you want? | 17:22 |
| niemeyer | Chipaca: release.SupportsSquashfs? | 17:22 |
| Chipaca | niemeyer: on the snap itself, once downloaded? to be umounted immediately after? | 17:23 |
| niemeyer | Chipaca: Which snap? Download what? I'm lost... | 17:23 |
| niemeyer | Chipaca: Isn't the goal to check if squashfs is supported? | 17:24 |
| Chipaca | niemeyer: what are you mounting? | 17:24 |
| niemeyer | Chipaca: Nothing... /tmp | 17:24 |
| niemeyer | Chipaca: /not-something-relevant-or-dangerous | 17:24 |
| Chipaca | niemeyer: but it's not going to be a squashfs | 17:24 |
| niemeyer | Chipaca: It does not matter what it is.. this is checking whether squashfs is supported | 17:25 |
| niemeyer | Chipaca: The result when it is supported is different from when it is not supported | 17:25 |
| niemeyer | If that's the goal, that's a handful of lines in a function | 17:26 |
| zyga-ubuntu | re (briefly) | 17:27 |
| niemeyer | Chipaca: Or so I assume.. I haven't tested this on a system that does not in fact support squashfs.. I assume the metadata that describes how to mount the filesystem lives in its module. | 17:28 |
| Chipaca | niemeyer: so, there's a more minor issue, and that's that this won't tell you if it supports xz | 17:29 |
| Chipaca | niemeyer: but you're right that this would work if that's good enough | 17:29 |
| Chipaca | (we've had people not enabling xz, but it's probably an order of magnitude less than people without squashfs) | 17:29 |
| niemeyer | Chipaca: For that I'd indeed resort to checking the result of the operation instead of preempting what the operation supposedly looks like ahead of itme | 17:30 |
| Chipaca | niemeyer: I'm not sure what you mean, there | 17:30 |
| niemeyer | Chipaca: If we change the compression format (or more likely, support many), we don't want to have an empty squash per compression format | 17:30 |
| niemeyer | Chipaca: Or per whatever feature | 17:30 |
| pedronis | what about /proc/filesystems | 17:30 |
| Chipaca | pedronis: not there if the module exists but isn't loaded | 17:30 |
| niemeyer | pedronis: !!! | 17:31 |
| pedronis | Chipaca: well if nobody loads it we fail anyway, no? | 17:31 |
| pedronis | mount() would have the same problem I suppose | 17:31 |
| Chipaca | pedronis: mount knows to load modules, if you specify the type | 17:31 |
| niemeyer | Ah | 17:32 |
| pedronis | mount the syscall? | 17:32 |
| Chipaca | yes | 17:32 |
| Chipaca | I think it's via an alias (metadata in the .ko) to "fs-<the argument to -t>", but i'm not 100% on that | 17:33 |
| Chipaca | a bit like how pci modules have aliases to some gibberish 'pci:v00001180d00000822sv*sd*bc*sc*i*' so they get picked up automatically | 17:34 |
| pedronis | Chipaca: I think basically it seems we can use mount to detect if squashfs is there, but if the compression is not right | 17:34 |
| pedronis | we still need to dig into the systemd job errors | 17:34 |
| niemeyer | Chipaca, pedronis: Still sounds nice to go through the actual method: | 17:34 |
| Chipaca | I need to see if that still works with the module-exists-but-not-loaded | 17:34 |
| niemeyer | 1. Does it exist in /proc/filesystems => do nothing, works | 17:34 |
| Chipaca | but sounds good | 17:35 |
| niemeyer | 2. insmod squashfs => works? okay | 17:35 |
| niemeyer | 3. unsupported | 17:35 |
| Chipaca | eh.. i wouldn't have snapd doing insmod, no (but i'm fine with triggering it via mount) | 17:35 |
| niemeyer | modprobe actually, not insmod, sorry | 17:36 |
| niemeyer | Chipaca: Yeah, that's likely cleaner | 17:37 |
| mup | PR snapcraft#2000 opened: elf: remove dead code <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2000> | 17:37 |
| muravey_omsk | zyga-ubuntu: My snapcraft.yaml https://pastebin.com/sKkUBwDd | 17:37 |
| muravey_omsk | what about add "organize" key to snapcraft.yaml with replace /usr/share/game to $SNAP/usr/share ? | 17:38 |
| zyga-ubuntu | re, sorry, my system crashed on kernel bug | 17:38 |
| zyga-ubuntu | muravey_omsk: can that game be modified to load things from a config file, variable of some kind? | 17:39 |
| === pstolowski is now known as pstolowski|afk | ||
| zyga-ubuntu | muravey_omsk: if not we will have a new feature in snapd 2.32 that you can use to put those files in /usr/share/game | 17:41 |
| muravey_omsk | zyga-ubuntu: i don't know. It's need to read man or Compiling.md | 17:41 |
| zyga-ubuntu | muravey_omsk: you can read about it here: https://forum.snapcraft.io/t/layouts-re-mapping-snap-directories/1471 | 17:41 |
| zyga-ubuntu | muravey_omsk: today edge is "busy" with release process but you can use it in edge soon | 17:42 |
| zyga-ubuntu | mvo: I will be home soon, my system crashed and took all the debug state along with it | 17:43 |
| zyga-ubuntu | mvo: darn kernel :-( | 17:43 |
| zyga-ubuntu | Chipaca: remember about the container use case | 17:49 |
| zyga-ubuntu | Chipaca: where squashfs is present but we cannot use it | 17:49 |
| zyga-ubuntu | Chipaca: and we must use the internal fuse helper | 17:49 |
| Chipaca | zyga-ubuntu: I've forgotten already | 17:49 |
| cachio | zyga-ubuntu, selinux is showing denials for the fakestore in the google instace of fedora 27 | 17:49 |
| zyga-ubuntu | cachio: are those breaking or just warning? | 17:49 |
| cachio | zyga-ubuntu, should add a rule to allow it in data/selinux? | 17:49 |
| cachio | zyga-ubuntu, giving permission denied | 17:50 |
| zyga-ubuntu | cachio: I don't know really, someone needs to sit down and see what the warnings are about | 17:50 |
| cachio | type=AVC msg=audit(1520876348.249:536): avc: denied { execute } for pid=31385 comm="(akestore)" name="fakestore" dev="sda1" ino=23835 scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file permissive=0 | 17:50 |
| zyga-ubuntu | cachio: yes but we have some special things that make all the denials into warnings | 17:50 |
| zyga-ubuntu | I don't really know the details | 17:50 |
| zyga-ubuntu | cachio: is this a new thing? | 17:50 |
| cachio | zyga-ubuntu, yes | 17:50 |
| cachio | it is the new image we have in google backend | 17:51 |
| * kalikiana heading out o/ | 17:51 | |
| Chipaca | zyga-ubuntu: what container does this? so i can play with it | 17:51 |
| cachio | the config is the same that the one in linode | 17:51 |
| zyga-ubuntu | do we know how is this different from the old image? | 17:51 |
| zyga-ubuntu | Chipaca: just LXD is fine | 17:51 |
| Chipaca | zyga-ubuntu: ah, not fedora-cloud-in-lxc-trusty? :-) | 17:51 |
| zyga-ubuntu | cachio: something about it is wrong but not sure what | 17:51 |
| zyga-ubuntu | well | 17:51 |
| zyga-ubuntu | not wrong, just different | 17:51 |
| zyga-ubuntu | Chipaca: no I mean just xenial+xenial is fine to show this | 17:52 |
| zyga-ubuntu | the fedora cloud issue was different | 17:52 |
| cachio | the image in linode is created upgrading an old one | 17:52 |
| zyga-ubuntu | we just had no module for the kernel we booted on | 17:52 |
| Chipaca | Ill need to write this down | 17:52 |
| Chipaca | … tomorrow | 17:52 |
| zyga-ubuntu | Chipaca: :-) | 17:52 |
| cachio | zyga-ubuntu, the one in google was downloded | 17:52 |
| * zyga-ubuntu resumes debugging | 17:52 | |
| * Chipaca is wrapping up for the day | 17:52 | |
| cachio | so I think could be many differences | 17:52 |
| zyga-ubuntu | cachio: sure I'm saying I don't know what's the real problem and this needs some investigation | 17:53 |
| zyga-ubuntu | perhaps in the old image the fake store ran unconfined | 17:53 |
| zyga-ubuntu | no idea | 17:53 |
| cachio | zyga-ubuntu, ok, I'll take a look in that case, it is only only one issue remaining for fedora | 17:53 |
| zyga-ubuntu | cachio: ack, I'm sorry I'm not of much help | 17:54 |
| cachio | zyga-ubuntu, np | 17:54 |
| zyga-ubuntu | cachio: perhaps Pharaoh_Atem can help you faster, he wrote all of the selinux support code | 17:54 |
| Pharaoh_Atem | wut? | 17:55 |
| zyga-ubuntu | Pharaoh_Atem: selinux denial from fakestore (go implementation of trivial store for tests) | 17:55 |
| Pharaoh_Atem | what's the denial? | 17:56 |
| zyga-ubuntu | Pharaoh_Atem: they stated showing up when we switched away from linode to google cloud | 17:56 |
| zyga-ubuntu | type=AVC msg=audit(1520876348.249:536): avc: denied { execute } for pid=31385 comm="(akestore)" name="fakestore" dev="sda1" ino=23835 scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file permissive=0 | 17:56 |
| zyga-ubuntu | cachio knows the details | 17:56 |
| mup | PR snapcraft#1998 closed: pluginhandler: add {pre,post}-build scriptlets <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1998> | 17:58 |
| cachio | Pharaoh_Atem, hey | 17:59 |
| cachio | Pharaoh_Atem, https://paste.ubuntu.com/p/Gby6tcmsQn/ | 18:01 |
| cachio | Pharaoh_Atem, sorry, it is the denial https://paste.ubuntu.com/p/dvBtrhvbKj/ | 18:01 |
| cachio | it happens running in a google mashine | 18:02 |
| cachio | which I recently created downloading from here https://alt.fedoraproject.org/cloud/ | 18:02 |
| zyga-ubuntu | I suspect it's a config difference | 18:03 |
| zyga-ubuntu | but we should check if the kernel is the same as before as well (apart from things like micro release updates) | 18:03 |
| cachio | zyga-ubuntu, both configs are identical | 18:03 |
| zyga-ubuntu | kernel configs? | 18:03 |
| cachio | SELINUX=enforcing SELINUXTYPE=targeted | 18:03 |
| zyga-ubuntu | did you compare all of the kernel config of the two running kernels? | 18:04 |
| cachio | zyga-ubuntu, sorryselinux configs | 18:04 |
| zyga-ubuntu | ah | 18:04 |
| zyga-ubuntu | well | 18:04 |
| zyga-ubuntu | maybe some other changes then | 18:04 |
| cachio | I could do that | 18:04 |
| zyga-ubuntu | yeah | 18:04 |
| zyga-ubuntu | essentially try to guess what is different now | 18:04 |
| zyga-ubuntu | maybe the build config is different | 18:05 |
| zyga-ubuntu | maybe some selinux policy is custom | 18:05 |
| zyga-ubuntu | it's a cloud image after all | 18:05 |
| zyga-ubuntu | but really no idea | 18:05 |
| cachio | zyga-ubuntu, selinux configuration in kernel config is the same | 18:09 |
| cachio | :( | 18:09 |
| cachio | zyga-ubuntu, I know | 18:11 |
| cachio | which is the diff | 18:11 |
| cachio | linode:fedora-27-64 .../tests/main/interfaces-snapd-control-with-manage# sestatus -v | 18:11 |
| cachio | SELinux status: disabled | 18:11 |
| cachio | google:fedora-27-64 .../tests/main/interfaces-snapd-control-with-manage# sestatus -v | 18:11 |
| cachio | SELinux status: enabled | 18:11 |
| cachio | :s | 18:11 |
| cachio | zyga-ubuntu, is it on porpouse? | 18:12 |
| zyga-ubuntu | mvo: this issue is driving me crazy | 18:15 |
| Pharaoh_Atem | cachio: it's because of this: https://pagure.io/Fedora-Council/tickets/issue/99 | 18:16 |
| Pharaoh_Atem | our images are based on the version of the image with no SELinux support | 18:17 |
| cachio | Pharaoh_Atem, ok | 18:20 |
| cachio | Pharaoh_Atem, so is it possible to add a rule to make the fakestore run unconfined? | 18:21 |
| Pharaoh_Atem | so this means that for the first time ever, we're going to see failures consistent with users | 18:21 |
| Pharaoh_Atem | is fakestore a snap or something else? | 18:21 |
| cachio | it is a systremd service | 18:21 |
| Pharaoh_Atem | I mean, how is it getting on there? | 18:22 |
| cachio | it is not a snap | 18:22 |
| Pharaoh_Atem | ah | 18:22 |
| Pharaoh_Atem | is the code somewhere? | 18:22 |
| cachio | exactly | 18:22 |
| cachio | in the snapd project | 18:22 |
| Pharaoh_Atem | guh | 18:22 |
| Pharaoh_Atem | it's not part of snapd itself, is it? | 18:23 |
| cachio | https://github.com/snapcore/snapd/tree/master/tests/lib/fakestore | 18:23 |
| cachio | Pharaoh_Atem, no | 18:23 |
| cachio | Pharaoh_Atem, we setup it for each test when it is required | 18:25 |
| cachio | https://github.com/snapcore/snapd/blob/master/tests/lib/store.sh#L50 | 18:25 |
| Pharaoh_Atem | the systemd service needs the following added | 18:25 |
| Pharaoh_Atem | SELinuxContext=unconfined_t | 18:26 |
| cachio | Pharaoh_Atem, great, I'll try with that | 18:27 |
| Pharaoh_Atem | ah sorry | 18:27 |
| Pharaoh_Atem | it needs fully qualified context | 18:27 |
| Pharaoh_Atem | that's "system_u:system_r:unconfined_t:s0", I believe | 18:29 |
| Pharaoh_Atem | cachio: if "unconfined_t" doesn't work, try the above | 18:29 |
| cachio | SELinuxContext=system_u:system_r:unconfined_t:s0 | 18:30 |
| Pharaoh_Atem | the documentation isn't clear if just declaring the type is enough | 18:30 |
| cachio | Pharaoh_Atem, I'll try one by one in that case | 18:30 |
| Pharaoh_Atem | thanks | 18:31 |
| om26er | popey: could you please merge this https://github.com/snapcrafters/sublime-text/pull/8 -- flexiondotorg seems away. | 18:31 |
| mup | PR snapcrafters/sublime-text#8: Remove '3' from snap name <Created by om26er> <https://github.com/snapcrafters/sublime-text/pull/8> | 18:31 |
| Pharaoh_Atem | normally, just defining the type is enough, because everything else is inherited | 18:31 |
| muravey_omsk | hey, how to debug or find a problem with fonts at my snap app? | 18:32 |
| * zyga-ubuntu looks at sublime-text-3 PR | 18:36 | |
| popey | om26er: is that really desired? I mean, we already have sublime-text-3, why not just create sublime-text-2? | 18:36 |
| om26er | popey: the suggestion from zyga-ubuntu (and others) was to use a single name and make use of 'tracks' | 18:37 |
| zyga-ubuntu | yes | 18:38 |
| popey | Not sure it's worth it, given how few updates there are. Having two snaps also means you can have both installed should you want to | 18:38 |
| zyga-ubuntu | popey: that will be available too | 18:38 |
| zyga-ubuntu | though I doubt that is something that people really want in _this_ case | 18:38 |
| zyga-ubuntu | popey: I think it's better to use 2.x track for the old sublime-text and the latest track for what's out there now | 18:39 |
| popey | I am unconvinced. | 18:39 |
| zyga-ubuntu | (especially since we could use edge for the dev builds) | 18:39 |
| zyga-ubuntu | popey: I think this also shows the nice features of snap design | 18:39 |
| zyga-ubuntu | where developers can release multiple tracks nicely | 18:40 |
| popey | flexiondotorg: ^ what do you think? | 18:40 |
| om26er | (side question: is there no change needed to snapcraft.yaml for a track ?) | 18:40 |
| popey | if we use build.snapcraft.io we can only push to edge, and then release to tracks/channels | 18:41 |
| om26er | popey: in case of sublime, we have two separate download urls, so how do we upload the _old_ version (aka 2.X) ? | 18:42 |
| zyga-ubuntu | om26er: just release to other track | 18:42 |
| zyga-ubuntu | om26er: snap info mysql (the same way) | 18:42 |
| om26er | cool but how do I update a version 2 snap ? Do I change my yaml file manually, create a build and upload it with snapcraft cli ? | 18:44 |
| om26er | s/update/upload | 18:44 |
| popey | you can have two projects in github | 18:44 |
| popey | one for 3, one for 2 | 18:44 |
| popey | both push to the same edge channel though | 18:44 |
| zyga-ubuntu | re | 19:15 |
| zyga-ubuntu | my kernel crashed again :/ | 19:15 |
| zyga-ubuntu | bionic is not happy | 19:15 |
| mup | PR snapd#4820 opened: cmd/snap: use timeutil.Human to show times in `snap refresh --time` <Created by chipaca> <https://github.com/snapcore/snapd/pull/4820> | 19:30 |
| mup | PR snapd#4817 closed: overlord: implement policy of holding refreshes for up to 6h since seeding on classic <Critical> <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/4817> | 19:52 |
| === __chip__ is now known as Chipaca | ||
| Chipaca | slangasek: question about today's live cd | 19:55 |
| Chipaca | zyga-ubuntu: you still around? | 19:55 |
| zyga-ubuntu | Yes | 20:05 |
| zyga-ubuntu | Chipaca: how can I help | 20:06 |
| Chipaca | zyga-ubuntu: ah drat, i just closed it, give me a bit to start it up again | 20:07 |
| Chipaca | zyga-ubuntu: snap-confine error on today's live cd, about it not running to prevent escalation attacks or sth | 20:08 |
| pedronis | Chipaca: which snapd version is on that? | 20:09 |
| Chipaca | 2.31.sth iirc | 20:09 |
| zyga-ubuntu | Hmmmm | 20:09 |
| Chipaca | booting still | 20:09 |
| muravey_omsk | hey, could you help me, again? | 20:09 |
| pedronis | there were some fixes for livecd but I don't know if they are related/when then landed | 20:09 |
| muravey_omsk | smirnovav@techadm03:/home/smirnovav/snap/cataclysm-dda$ locale | 20:09 |
| muravey_omsk | locale: Cannot set LC_CTYPE to default locale: No such file or directory | 20:09 |
| muravey_omsk | locale: Cannot set LC_MESSAGES to default locale: No such file or directory | 20:09 |
| zyga-ubuntu | I think that doesn’t have the fix yet | 20:09 |
| muravey_omsk | locale: Cannot set LC_ALL to default locale: No such file or directory | 20:09 |
| zyga-ubuntu | Only master has that fix Chipaca | 20:10 |
| Chipaca | zyga-ubuntu: ah ok | 20:10 |
| pedronis | Chipaca: in other news I should have squashed #4789 when merging and didn't :/ | 20:10 |
| mup | PR #4789: many: support holding refreshes by setting refresh.hold <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4789> | 20:10 |
| * muravey_omsk interesting in how to paste small command output? Pastebin? | 20:11 | |
| Chipaca | pedronis: and now? | 20:11 |
| zyga-ubuntu | Yes | 20:11 |
| zyga-ubuntu | Pastebin | 20:11 |
| pedronis | Chipaca: I don't know, will not be fun to merge into 2.32 I suppose | 20:11 |
| * Chipaca hugs mvo | 20:12 | |
| pedronis | I'll see in the morning, anyway I also saw I can simplify the follow-up | 20:15 |
| muravey_omsk | https://pastebin.com/vy1WB7Hk | 20:15 |
| muravey_omsk | What am I doing wrong? | 20:17 |
| muravey_omsk | my program do not see my locale and don't show messages on my language | 20:18 |
| fireclawTheFox | Hey everyone, can someone help me get the desktopfile of my snap package show up in the dash? I've tried quite a lot of things but none have helped so far. | 20:48 |
| popey | fireclawTheFox: hiya | 20:51 |
| popey | fireclawTheFox: can you link to your yaml maybe? | 20:51 |
| popey | Note that some desktops have bugs that require you to logout/back in to make the icon appear | 20:51 |
| fireclawTheFox | Hey popey, sure, here's the yaml: https://bazaar.launchpad.net/~fireclawthefox/thetravelingfox/snap/view/head:/snap/snapcraft.yaml | 20:52 |
| popey | fireclawTheFox: ah, easy one, name your .desktop file the same as the snap | 20:52 |
| popey | so thetravelingfox.desktop | 20:52 |
| mup | PR snapd#4813 closed: release: snapd 2.31.2 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4813> | 20:52 |
| fireclawTheFox | popey: I thought it already fits the name as the snap also is also named the-traveling-fox | 20:53 |
| popey | oh, you're right. huh. | 20:54 |
| fireclawTheFox | I've also tried naming it the-traveling-fox_the-traveling-fox as well as directly add it in the yaml file using desktop: | 20:56 |
| popey | lemme take a better look, one moment | 20:57 |
| mvo | zyga-ubuntu: yeah, its rather unfortunate | 20:57 |
| mvo | zyga-ubuntu: my latest PR seems to get a step further, but it now fails in interfaces-content-mkdir-writable:snap | 20:57 |
| popey | fireclawTheFox: the snap fails to build here. Do you rely on having PPAs or something enabled? | 21:01 |
| fireclawTheFox | I don't rely on PPAs, just on a pipy package. Which version of snapcraft do you use? I've just pushed a version of my custom plugin to make it build on the version used on LP. | 21:02 |
| popey | snapcraft, version 2.39.2 | 21:03 |
| popey | on 16.04 (well, I'm doing snapcraft cleanbuild) | 21:03 |
| popey | I need to disappear soon to get my daughter from dancing, if we don't fix it here, I'd recommend a thread on the forum | 21:04 |
| fireclawTheFox | ok, then the x-panda3d.py script has to be changed for that version | 21:04 |
| popey | ahh | 21:04 |
| fireclawTheFox | I've once opened up a thread in the forums but it didn't got much attention. | 21:05 |
| fireclawTheFox | Anyways, in the x-panda3d.py script just two things have to be changed, first enable the code from line 38 and disable line 49 to 54 as well as switch line 78 and 79 | 21:07 |
| cachio | Pharaoh_Atem, no way | 21:08 |
| cachio | didn't work | 21:08 |
| Pharaoh_Atem | :'( | 21:08 |
| cachio | it is rejecting to set the type as unconfined_t aparently | 21:08 |
| popey | fireclawTheFox: ok, lemme rebuild and see | 21:09 |
| cachio | Pharaoh_Atem, even if I do it manually with chcon | 21:09 |
| Pharaoh_Atem | hmm | 21:10 |
| Pharaoh_Atem | it's probably not letting you transition domains from init_t to unconfined_t | 21:10 |
| cachio | any other idea to exec that file? | 21:11 |
| cachio | Pharaoh_Atem, create a new test domain to set as permissive? | 21:13 |
| popey | fireclawTheFox: ok, that built! :D | 21:13 |
| Pharaoh_Atem | either that or just set the VM to permissive while running the tests | 21:13 |
| fireclawTheFox | awesome | 21:13 |
| Pharaoh_Atem | and collecting the audit results | 21:13 |
| popey | fireclawTheFox: ah, your exec line is wrong | 21:14 |
| popey | fireclawTheFox: the exec line should not be launching the command name, but the app name | 21:15 |
| popey | exec=the-traveling-fox | 21:15 |
| fireclawTheFox | popey: ah, yeah now that you say it, makes sense. | 21:16 |
| popey | also, add this | 21:16 |
| popey | https://www.irccloud.com/pastebin/XsBC54Nc/ | 21:16 |
| popey | to the game part | 21:16 |
| popey | that will put the pulseaudio library in an accessible place | 21:16 |
| popey | oh, you mung the LD_LIBRARY_PATH... never mind | 21:16 |
| popey | also if you put libs in $SNAP/lib you won't need to "cd ${SNAP}" | 21:17 |
| popey | because $SNAP/lib is automagically in the path | 21:18 |
| zyga-ubuntu | mvo: I will check your pull request tomorrow. Spending time with homework and kids | 21:19 |
| mvo | zyga-ubuntu: sure, thats fine, I had some strange results, I suspect there is also the cache (apparmor cache) that is making things compilicated | 21:21 |
| mvo | zyga-ubuntu: I will let the tests run over night, fingers crossed | 21:21 |
| fireclawTheFox | popey: sorry, my laptop just crashed, did you wrote anything after (22:16:58) popey: oh, you mung the LD_LIBRARY_PATH... never mind | 21:21 |
| mvo | zyga-ubuntu: lets talk tomorrow :) | 21:22 |
| * mvo waves | 21:22 | |
| popey | fireclawTheFox: no | 21:27 |
| * cachio afk | 21:34 | |
| fireclawTheFox | popey: just got the snap built, the desktop file works fine now, thanks so much for your help. | 21:41 |
| popey | Yay | 21:41 |
| popey | Good. Looking forward to playing it | 21:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
