[00:41] <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:42] <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:43] <Son_Goku> snapd in Ubuntu 16.04 has had a tumultuous time getting updated
[00:44] <Son_Goku> so they've been lagging behind Fedora on updates
[01:05] <TingPing> funny
[01:06] <Son_Goku> well, I try to keep things fresh ;)
[01:07] <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:08] <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:09] <Son_Goku> you mean like the things Apple/Google do?
[01:09] <TingPing> yea
[01:10] <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:11] <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:12] <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:13] <TingPing> link to their logo?
[01:14] <Son_Goku> TingPing, yep, trying to find it
[01:14] <Son_Goku> one sec
[01:15] <Son_Goku> TingPing: https://assets.ubuntu.com/v1/d24ea71e-10.+SNAPCRAFT_LOGO_AW.zip
[01:16] <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:18] <TingPing> bit annoyingly sized
[05:46] <mborzecki> morning
[06:31]  * mborzecki is afk for ~1h
[07:18] <zyga-ubuntu> good morning
[07:38] <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:41] <mvo> hey zyga-ubuntu and mborzecki !
[07:41] <zyga-ubuntu> hey mvo! :)
[07:41] <mborzecki> mvo: hey
[07:43]  * zyga-ubuntu updates his fedora system
[07:44] <mborzecki> zyga-ubuntu: some intersting fedora work coming up?
[07:47] <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:56] <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:58] <mborzecki> zyga-ubuntu: maybe that's the media-sharing interace thing?
[07:59] <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
[08:00] <mborzecki> zyga-ubuntu: ok, ping me if you need help
[08:01] <mborzecki> hah, had to do blood tests in the morning, now i can make up for the lost blood with some chocolate :P
[08:07] <zyga-ubuntu> yum yum
[08:11] <pstolowski> morning!
[08:13] <mvo> hey pstolowski ! good morning
[08:20] <mborzecki> pstolowski: hey
[08:27] <zyga-ubuntu> mvo: hey, did you try the tea by any chance? :-)
[08:28] <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:29] <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:30] <zyga-ubuntu> I'd rather have a chroot with rawhide than a VM with one
[08:31] <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:32] <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:33] <zyga-ubuntu> mvo: not sure how many leaves did you use, I usually use a few for a sizable mug (~1L)
[08:40] <kalikiana> o/
[08:47] <pstolowski> how was your travel back home guys?
[08:47] <mborzecki> pstolowski: short :P
[08:49] <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:52] <mvo> zyga-ubuntu: ok, I try a smaller one then :)
[08:54] <pstolowski> mborzecki: nice!
[08:56] <morphis> mvo: zyga-ubuntu: any idea about https://forum.snapcraft.io/t/nvidia-gl-libs-access-broken-on-ubuntu-18-04/4440 ?
[09:05] <zyga-ubuntu> morphis: ah, interesting
[09:05] <zyga-ubuntu> I will respond on the forum
[09:08] <zyga-ubuntu> morphis: done
[09:09] <morphis> zyga-ubuntu: thanks!
[09:21] <Chipaca> moin moin
[09:22] <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:23] <mborzecki> Chipaca: ok, will try in a couple of minutes
[09:23] <Chipaca> mborzecki: thanks!
[09:30] <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:32] <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:34] <pstolowski> mvo: is https://github.com/pilebones/go-udev the udev implementation you found last week?
[09:35] <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:42] <pstolowski> mborzecki: commented
[09:44] <pstolowski> hey Chipaca!
[09:45] <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:46] <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:50] <mborzecki> pstolowski: cmd/snap-confine/spread-tests is not referenced in the top level spread test file
[09:53] <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:54] <pstolowski> +1
[09:54] <mborzecki> haha,  are those kept for reference or shall we make them go away then? :)
[09:55] <zyga-ubuntu> one by one either enable and port or drop
[09:58] <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:59] <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
[10:00] <zyga-ubuntu> perfect, 14.04, no logs
[10:01] <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:02] <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:03] <zyga-ubuntu> I ran tests/main
[10:04] <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:05] <mvo> zyga-ubuntu: ok
[10:05] <Chipaca> zyga-ubuntu: should I just restart this particular test?
[10:06] <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:18] <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:19] <Chipaca> mborzecki: ok
[10:22] <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:23] <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:26] <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:27] <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:28] <mvo> zyga-ubuntu: 1520606008 is what travis was using
[10:28] <zyga-ubuntu> thanks, I will try that with another backend
[10:29] <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:31] <Chipaca> mborzecki: ah! hm! oh!
[10:32] <Chipaca> mborzecki: thanks
[10:32] <mborzecki> Chipaca: that's the tool(ing) https://github.com/dvyukov/go-fuzz
[10:34] <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:36] <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:37] <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:38] <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:39] <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:40] <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:41] <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:51]  * Chipaca -> physio gym thing
[10:52] <mborzecki> mvo: i'll into tests/main/snap-service-refresh-mode as it's still failing randomly
[10:52] <mborzecki> look into
[10:57]  * Chipaca -> really leaves
[10:59] <mvo> mborzecki: \o/ thank you
[10:59] <mvo> mborzecki: maybe its a real issue :(
[11:00] <mvo> (even though its hard for me to see from the code how this could be)
[11:02] <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:03] <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:08] <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:09] <cachio> mvo, hey
[11:09] <mvo> cachio: hey
[11:09] <mvo> cachio: hope you are well!
[11:33] <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:34] <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:36] <mvo> zyga-ubuntu: indeed, very peculiar
[11:37] <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:40] <zyga-ubuntu> how come there's no shellcheck snap yet
[11:58] <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:59] <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>
[12:00] <zyga-ubuntu> same with the regression suite
[12:00] <zyga-ubuntu> mvo: I just got a failure on the 2.32 branch
[12:01] <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:02] <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:03] <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:04] <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:05] <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:06] <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:07] <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:08] <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:10] <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:11] <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:13] <zyga-ubuntu> mborzecki: I can send you my spread binary if that is a factor
[12:18] <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:19] <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:20] <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:21] <zyga-ubuntu> but when I inspected the system it wasn't apparent it ran
[12:22] <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:23] <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:26] <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:27] <zyga-ubuntu> I added some debug and I will try to reproduce that with the same seed ( -seed=1520852878)
[12:29] <zyga-ubuntu> mvo: one thing that _may_ be related is that /var/cache/apparmor is full of things
[12:31] <zyga-ubuntu> as is /etc/apparmor.d/cache
[12:31] <zyga-ubuntu> the biggest question is if the seed will reproduce the issue
[12:32] <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:33] <cachio> that shoul fix the issue that savic was reporting about out of space
[12:33] <cachio> tx
[12:46] <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:48] <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:49] <zyga-ubuntu> that is, run the failing test after running half of the preceding tests, etc
[12:54] <cachio> mvo, niemeyer I am waiting for a doctor at home, perhaps I'll be starting later the standup
[13:19] <zyga-ubuntu> excellent, I can reproduce the issue reliably now mvo
[13:25] <mborzecki> zyga-ubuntu: my test run is still in progress, should i abort?
[13:25] <zyga-ubuntu> no sure, why?
[13:26] <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:28] <zyga-ubuntu> mborzecki: when did you start it?
[13:29] <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:30] <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:31] <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:32] <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:33] <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:39] <mup> PR snapcraft#1985 closed: tests: document arm testing setup <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1985>
[13:42] <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:43] <zyga-ubuntu> thank you, I wonder what this says then
[13:43] <mborzecki> yes, tip of release/2.32 branch
[13:51] <pstolowski> niemeyer: so, the interface is named "dummy" atm, with a description saying "snapd dummy test interface"
[13:52] <niemeyer> pstolowski: What's the PR?
[13:54] <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:55] <zyga-ubuntu> niemeyer: no-op interface?
[13:59] <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>
[14:00]  * Chipaca looks
[14:00] <Chipaca> wtf
[14:01] <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:02] <Chipaca> :-)
[14:02] <Chipaca> mborzecki: probably fat fingers of some sort
[14:03] <mborzecki> Chipaca: hopefully nothing that cannot be fixed with the reflog :P
[14:04] <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:06] <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:07] <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:17] <zyga-ubuntu> sunshine
[14:24] <pstolowski> niemeyer: it's dummy in a sense that it doesn't provide any functionality; it's only useful to test against
[14:28]  * Chipaca brb
[14:30] <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:34] <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:35] <pstolowski> niemeyer: thanks
[14:37] <kalikiana> re
[14:41] <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:42] <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:43] <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:45] <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:46] <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:47] <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:48] <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:49] <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:51] <zyga-ubuntu> I'll try your patch on my system, thank you for pushing the fix and finding the problem
[14:53] <mup> PR snapd#4816 opened: Tests move xenial i386 to google <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4816>
[15:04] <mvo> zyga-ubuntu: thank you!
[15:20] <zyga-ubuntu> I will try -resend next
[15:20] <zyga-ubuntu> now that I can essentially iterate on one test
[15:23] <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:24] <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:28] <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:29] <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:32] <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:33] <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:34] <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:35] <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:36] <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:37] <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:38] <mvo> zyga-ubuntu: it looks like spread is disagreeing with my fix :(
[15:39] <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:40] <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:43] <zyga-ubuntu> added more debug, with your patch and restarted
[15:51] <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:52] <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:53] <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:54] <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:55] <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:56] <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:57] <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:58] <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:59] <Muravey> After install package i cant run game and it's crashed with file not found
[16:00] <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:02] <zyga-ubuntu> mvo: it didn't fail with your patch now ://
[16:02] <Muravey> zyga-ubuntu: sorry for my english
[16:03] <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:04] <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:07] <Muravey> zyga-ubuntu: will you here in an hour? I'm driving.
[16:08] <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:15] <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:16] <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:17] <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:18] <Chipaca> cachio: is tht 14.04?
[16:18] <cachio> core-16-arm-64
[16:19] <niemeyer> mvo, Chipaca: Anything I can help with or is it sorted?
[16:20] <Chipaca> cachio: do we ship policykit in core?
[16:20] <cachio> Chipaca, with sudo is working
[16:21] <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:22] <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:23] <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:24] <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:25] <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:26] <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:27] <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:29] <cachio> Chipaca, then the suite fails because the initial state was not created
[16:31] <mvo> cachio: could you please pastebin "git status" and "git rev-parse HEAD"?
[16:32] <mvo> cachio: I really though we fixed this timer issue :/
[16:33] <cachio> mvo, you are right
[16:33] <cachio> was my fault
[16:34] <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:36] <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:37] <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:40] <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:41] <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:45] <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:47]  * Chipaca hugs cachio 
[16:47] <Chipaca> cachio: take care dude
[16:49] <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:50] <cachio> mvo, we need the user assertion
[16:50] <cachio> to run again in nightly the core revert test
[16:52] <Muravey> zyga-ubuntu: i thought that app in snap package after installing get it's own mount name space.
[16:59] <pedronis> Chipaca: no, was waiting for ther revert
[16:59] <Chipaca> pedronis: already there
[17:00] <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:05] <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:06] <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:07] <niemeyer> Chipaca: Not sure I understand what's the advantage vs. trying to actually mount the thing you indeed want to mount
[17:08] <Chipaca> niemeyer: 'snap install foo -> download core -> cryptic message because mount failed' vs 'snap install foo' -> 'no squashfs support lolz'
[17:09] <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:10] <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:11] <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:12] <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:13] <Chipaca> it's looking at 'systemd show', probably
[17:13] <Chipaca> ('systemctl show' i meant -- 'systemctl status's machine-friendly cousin)
[17:15] <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:16] <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:17] <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:18] <Chipaca> niemeyer: 'exit status 1' is a lot less information than checking errno == ENODEV
[17:20] <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:21] <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:22] <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:23] <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:24] <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:25] <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:26] <niemeyer> If that's the goal, that's a handful of lines in a function
[17:27] <zyga-ubuntu> re (briefly)
[17:28] <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:29] <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:30] <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:31] <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:32] <niemeyer> Ah
[17:32] <pedronis> mount the syscall?
[17:32] <Chipaca> yes
[17:33] <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:34] <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:35] <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:36] <niemeyer> modprobe actually, not insmod, sorry
[17:37] <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:38] <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:39] <zyga-ubuntu> muravey_omsk: can that game be modified to load things from a config file, variable of some kind?
[17:41] <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:42] <zyga-ubuntu> muravey_omsk: today edge is "busy" with release process but you can use it in edge soon
[17:43] <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:49] <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:50] <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:51] <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:52] <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:53] <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:54] <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:55] <Pharaoh_Atem> wut?
[17:55] <zyga-ubuntu> Pharaoh_Atem: selinux denial from fakestore (go implementation of trivial store for tests)
[17:56] <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:58] <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:59] <cachio> Pharaoh_Atem, hey
[18:01] <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:02] <cachio> it happens running in a google mashine
[18:02] <cachio> which I recently created downloading from here https://alt.fedoraproject.org/cloud/
[18:03] <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:04] <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:05] <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:09] <cachio> zyga-ubuntu, selinux configuration in kernel config is the same
[18:09] <cachio> :(
[18:11] <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:12] <cachio> zyga-ubuntu, is it on porpouse?
[18:15] <zyga-ubuntu> mvo: this issue is driving me crazy
[18:16] <Pharaoh_Atem> cachio: it's because of this: https://pagure.io/Fedora-Council/tickets/issue/99
[18:17] <Pharaoh_Atem> our images are based on the version of the image with no SELinux support
[18:20] <cachio> Pharaoh_Atem, ok
[18:21] <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:22] <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:23] <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:25] <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:26] <Pharaoh_Atem> SELinuxContext=unconfined_t
[18:27] <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:29] <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:30] <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:31] <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:32] <muravey_omsk> hey, how to debug or find a problem with fonts at my snap app?
[18:36]  * 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:37] <om26er> popey: the suggestion from zyga-ubuntu (and others) was to use a single name  and make use of 'tracks'
[18:38] <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:39] <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:40] <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:41] <popey> if we use build.snapcraft.io we can only push to edge, and then release to tracks/channels
[18:42] <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:44] <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
[19:15] <zyga-ubuntu> re
[19:15] <zyga-ubuntu> my kernel crashed again :/
[19:15] <zyga-ubuntu> bionic is not happy
[19:30] <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:52] <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:55] <Chipaca> slangasek: question about today's live cd
[19:55] <Chipaca> zyga-ubuntu: you still around?
[20:05] <zyga-ubuntu> Yes
[20:06] <zyga-ubuntu> Chipaca: how can I help
[20:07] <Chipaca> zyga-ubuntu: ah drat, i just closed it, give me a bit to start it up again
[20:08] <Chipaca> zyga-ubuntu: snap-confine error on today's live cd, about it not running to prevent escalation attacks or sth
[20:09] <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:10] <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:11]  * 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:12]  * Chipaca hugs mvo
[20:15] <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:17] <muravey_omsk> What am I doing wrong?
[20:18] <muravey_omsk> my program do not see my locale and don't show messages on my language
[20:48] <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:51] <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:52] <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:53] <fireclawTheFox> popey: I thought it already fits the name as the snap also is also named the-traveling-fox
[20:54] <popey> oh, you're right. huh.
[20:56] <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:57] <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
[21:01] <popey> fireclawTheFox: the snap fails to build here. Do you rely on having PPAs or something enabled?
[21:02] <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:03] <popey> snapcraft, version 2.39.2
[21:03] <popey> on 16.04 (well, I'm doing snapcraft cleanbuild)
[21:04] <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:05] <fireclawTheFox> I've once opened up a thread in the forums but it didn't got much attention.
[21:07] <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:08] <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:09] <popey> fireclawTheFox: ok, lemme rebuild and see
[21:09] <cachio> Pharaoh_Atem, even if I do it manually with chcon
[21:10] <Pharaoh_Atem> hmm
[21:10] <Pharaoh_Atem> it's probably not letting you transition domains from init_t to unconfined_t
[21:11] <cachio> any other idea to exec that file?
[21:13] <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:14] <popey> fireclawTheFox: ah, your exec line is wrong
[21:15] <popey> fireclawTheFox: the exec line should not be launching the command name, but the app name
[21:15] <popey> exec=the-traveling-fox
[21:16] <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:17] <popey> also if you put libs in $SNAP/lib you won't need to "cd ${SNAP}"
[21:18] <popey> because $SNAP/lib is automagically in the path
[21:19] <zyga-ubuntu> mvo: I will check your pull request tomorrow. Spending time with homework and kids
[21:21] <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:22] <mvo> zyga-ubuntu: lets talk tomorrow :)
[21:22]  * mvo waves
[21:27] <popey> fireclawTheFox: no
[21:34]  * cachio afk
[21:41] <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