| mborzecki | morning | 06:03 |
|---|---|---|
| tyhicks | zyga: hey - I just saw that you were debugging a dbus apparmor query bug | 06:15 |
| tyhicks | zyga: did you get to the bottom of it? | 06:15 |
| tyhicks | (I see the dc25979eb commit) | 06:16 |
| mup | Bug #1743504 opened: Ubuntu 16.04 snapd service not working <Snappy:New> <https://launchpad.net/bugs/1743504> | 06:21 |
| mup | PR snapd#4489 opened: vendor: remove x/sys/unix to fix builds on arm64 and powerpc <Created by mvo5> <https://github.com/snapcore/snapd/pull/4489> | 07:41 |
| mborzecki | mvo: morning | 07:53 |
| zyga | good morning | 07:56 |
| zyga | I'll get some coffee and will be back shortly :) | 07:57 |
| mborzecki | zyga: hey | 07:57 |
| mborzecki | have you guys seen this? https://forum.snapcraft.io/t/ubuntu-16-04-snapd-fail-to-start/3529 | 07:58 |
| zyga | mborzecki: looking | 07:58 |
| mvo | hey mborzecki ! good morning | 07:58 |
| mvo | and good morning zyga | 07:58 |
| zyga | looks like #include maybe (vs include) | 07:59 |
| zyga | but not sure | 07:59 |
| zyga | mvo: hey! | 07:59 |
| zyga | -> coffee | 07:59 |
| mborzecki | zyga: apparmor thing? | 08:01 |
| zyga | yes, we delt with this in the past, that's the only thing that I can recall having an '#' issue | 08:02 |
| zyga | but | 08:02 |
| zyga | this is not a guarantee this is it | 08:02 |
| jdstrand | that error is talking about the '#' being a problem | 08:02 |
| jdstrand | the issue you were thinking of was a missing '#' | 08:03 |
| zyga | indeed | 08:03 |
| zyga | hey jdstrand :) | 08:03 |
| jdstrand | hey | 08:03 |
| zyga | I'm not used to you being in the same timezone | 08:03 |
| zyga | how was day one? :) | 08:03 |
| jdstrand | but regardless, snapd was not affected by the '#' or lack of '#', it was the apparmor python tools. I think this is unrelated to all that | 08:03 |
| jdstrand | day one went fine | 08:04 |
| zyga | ah, indeed, I think you are right | 08:04 |
| mvo | zyga, mborzecki doing a "grep -r" for the error message in vendor/ and /usr/share/go-1.8/src indicates its a json decode error, so probably corrupted state.json | 08:04 |
| mvo | mborzecki: (as you already guessed :) | 08:04 |
| jdstrand | no time to do any engineering really. lots of meetings, lots of interrupts when I thought I had time to do something | 08:04 |
| jdstrand | typical sprint :) | 08:04 |
| jdstrand | zyga: ftr, I have a slew of PRs scheduled for review. just need time to focus on them. they will be at the top of my list next week if I can't get to them this week (and I don't expect I can) | 08:06 |
| mborzecki | mvo: makes me wonder, unless hand edited, how would # end up in state.json? | 08:06 |
| zyga | jdstrand: ack | 08:06 |
| mvo | mborzecki: yeah, a good question, we would need the state.json to inspect, might be a bit flip, once you have enough users this will happen (we saw that with e.g. the dpkg/apt database frequently). or a corrupted hdd like zyga had earlier. hard to say (or of course our fault somewhere in our state saving code) | 08:07 |
| mborzecki | it's not part of the pacakge right? so there's no chance of state.json getting updated as part of package upgrade? | 08:08 |
| zyga | jdstrand: how's the weather like? | 08:09 |
| jdstrand | zyga: beautiful | 08:09 |
| zyga | mborzecki: or if you remember my crazy hdd yesterday, may be the xml profile in place of json :) | 08:09 |
| zyga | mborzecki: on my disk the dpkg database contains random files | 08:09 |
| jdstrand | zyga: sounds like a fun day :) | 08:09 |
| mborzecki | zyga: yeah, that's possible too :/ | 08:09 |
| kalikiana | sliff | 08:12 |
| pstolowski | good morning! | 08:12 |
| * kalikiana feeling a bit under the weather this not so good morning :-( | 08:12 | |
| mvo | mborzecki: correct | 08:12 |
| zyga | kalikiana: ouch | 08:12 |
| zyga | hey pstolowski | 08:13 |
| pstolowski | kalikiana, sad to hear that.. take it easy and get well! | 08:13 |
| zyga | mwhudson: snapd in debian is updating now | 08:19 |
| mvo | zyga, mborzecki, pstolowski quick question - what feels more natural to you: `snap run --strace-opts="-tt" hello` or `snap run --strace="-tt" hello` ? | 08:19 |
| zyga | mvo: the latter | 08:20 |
| pstolowski | mvo, the latter | 08:20 |
| mvo | (the former could also be written as `snap run --strace --strace-opts="-tt" ` | 08:20 |
| mvo | ok - cool, I look at it | 08:20 |
| mvo | thanks for your feedback | 08:20 |
| zyga | great, thanks for asking :) | 08:20 |
| zyga | snapd is now at 2.30-4 in sid :) | 08:21 |
| zyga | mwhudson: thank you for pushing that! | 08:21 |
| mborzecki | mvo: yup, the latter | 08:21 |
| mvo | mborzecki: ta! | 08:21 |
| mborzecki | mvo: btw. it'd also be a nice feature to be able to disable filtering out of pre snap-exec starce output | 08:22 |
| zyga | mvo: does the method to run strace scale to things like gdb? | 08:23 |
| mup | PR snapcraft#1869 closed: cli: exported login should only be readable by owner <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1869> | 08:23 |
| mvo | mborzecki: interessting idea | 08:23 |
| zyga | mvo: though gdb is also more complex because od symbols | 08:23 |
| pstolowski | and valgrind? ;) | 08:23 |
| zyga | hmm | 08:23 |
| zyga | I need to reboot my laptop | 08:24 |
| mvo | zyga: for gdb one would have to automatically set a breakpoint at "execve("the-snap-app")" and then run it | 08:24 |
| zyga | it goes crazy after suspend and all the textures blink | 08:24 |
| pstolowski | just kidding, valgrind is tricky for many reasons I suppose.. just gdb would be cool | 08:24 |
| zyga | brb | 08:24 |
| mup | PR snapd#4490 opened: tests/main/snap-service-after-before: add test for after/before service ordering <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4490> | 08:29 |
| zyga | hmmm | 08:30 |
| zyga | I think I need to power it off | 08:30 |
| zyga | it's still wonky | 08:30 |
| zyga | and wifi is wonky too | 08:30 |
| mborzecki | the year of linux desktop :P | 08:30 |
| * zyga looks for debian topics on the forum | 08:33 | |
| mup | PR snapd#4491 opened: snap: allow options for --strace, e.g. `snap run --strace="-tt"` <Created by mvo5> <https://github.com/snapcore/snapd/pull/4491> | 08:37 |
| mvo | kalikiana: hey, iirc you had some suggestion for `snap refresh --amend`, a better term. now is a good time to add them to 4356 as samuele also expressed that its not super clear to him | 08:38 |
| zyga | mvo: I didn't like amed too | 08:40 |
| zyga | mvo: I proposed one alternative on the forum but I forgot what it was | 08:40 |
| pedronis | mvo: I could think: --reestablish otherwise I thing we need more than one word with store in it somehow | 08:43 |
| pedronis | *I think | 08:43 |
| mvo | pedronis: I like --reestablish - feel free to add to the PR. I'm addressing your comments now fwiw | 08:44 |
| pedronis | mvo: and we have other plans for "replace" | 08:45 |
| pedronis | that might happen or not, but I don't think we want to use that | 08:45 |
| kalikiana | pedronis, mvo: I commented on the PR https://github.com/snapcore/snapd/pull/4356#discussion_r160633033 | 08:46 |
| mup | PR #4356: many: add new `snap refresh --amend <snap>` command <Created by mvo5> <https://github.com/snapcore/snapd/pull/4356> | 08:46 |
| * kalikiana getting more tea, with an extra slice of lemon | 08:49 | |
| pedronis | mvo: put a rambling there about this | 08:51 |
| mvo | ta | 08:51 |
| zyga | snapd 2.30 on debian sid works well, spotify, gimp and brave tested | 08:59 |
| mvo | yay | 09:00 |
| mborzecki | mvo: will the strace PR will work with classic snaps too? | 09:00 |
| zyga | mborzecki: classic snaps don't need anything for strace | 09:02 |
| zyga | though it'd be nice if they also worked with the same U | 09:02 |
| zyga | \UI | 09:02 |
| mborzecki | what i meant if you do `snap run --starce <some-classic-snap>` will it work too? | 09:03 |
| zyga | right | 09:03 |
| zyga | I don't know :) | 09:03 |
| mvo | mborzecki, zyga: do we run snap-confine on classic snaps at all? iirc we do and if so strace should work | 09:04 |
| mwhudson | zyga: np, does it work? :) | 09:09 |
| zyga | mwhudson: yes | 09:10 |
| mwhudson | oh good | 09:10 |
| zyga | mwhudson: with apparmor enabled | 09:10 |
| zyga | so good work :-) | 09:11 |
| mborzecki | mvo: tried `snap run --strace` with a classic snap just now, works fine :) | 09:11 |
| mwhudson | i should send some of the changes your way | 09:11 |
| mvo | mborzecki: \o/ | 09:11 |
| mwhudson | the "arch all only builds fail" thing would happen with ubuntu packaging too i'm fairly sure | 09:11 |
| mborzecki | mvo: https://paste.ubuntu.com/26396653/ the default value for --strace in --help is a bit confusing, i think you need to add `default-mask:""` or something similar | 09:12 |
| mvo | mborzecki: aha, good point. quirks with the go-flags | 09:19 |
| mvo | mborzecki: thanks, let me fix this | 09:19 |
| mvo | mborzecki: there is a failure in 4490 on 14.04 that looks vaguely ral | 09:21 |
| mvo | real | 09:21 |
| === __chip__ is now known as Chipaca | ||
| Chipaca | good morning peeps | 09:25 |
| mvo | Chipaca: hey, good morning! | 09:25 |
| Chipaca | just popping in to let you know (because I completely forgot yesterday) | 09:25 |
| mborzecki | mvo: thanks, looks like the formatting changed between systemd versions :/ | 09:26 |
| Chipaca | that i've got two long parent meetings at the school today, so i've taken half a day off | 09:26 |
| mborzecki | Chipaca: morning | 09:26 |
| mvo | mborzecki: :( | 09:26 |
| zyga | hey there john! | 09:26 |
| Chipaca | so, hello and goodbye :-) | 09:26 |
| zyga | mborzecki: oh, "fun" | 09:26 |
| mvo | Chipaca: sure - when you have a moment 4489 is an easy win | 09:26 |
| zyga | how can projects do that :/ | 09:26 |
| mvo | or someone else :) | 09:26 |
| Chipaca | mvo: ack | 09:26 |
| Chipaca | mvo: reach me on telegram if you need me though | 09:27 |
| mborzecki | zyga: systemctl --porcelain :) | 09:27 |
| zyga | mvo: did you see http://travis.debian.net/ ? :) | 09:28 |
| zyga | would be cool to have instructions like that for snapcraft | 09:29 |
| mvo | zyga: might cool | 09:30 |
| mvo | mborzecki: you mentioned you would be interested in havng "snap run --strace" not hide anything (so include the snap-confine traces). do you think a environment options is appropriate? or an extra option to `snap run --strace-it-all` or something? | 09:31 |
| mborzecki | mvo: enabling it via environment sounds good to me, SNAP_STRACE_EARLY=1 or something similar | 09:33 |
| mwhudson | zyga: what's the motivation for wanting to update snapd in stretch? | 09:37 |
| mwhudson | the version released with stretch re-execs i think... | 09:38 |
| zyga | mwhudson: yes, thought I don't know if that enables all the features | 09:38 |
| zyga | mwhudson: it would be a nice thing to update it | 09:38 |
| zyga | mwhudson: flapak gets the updates, for example | 09:38 |
| mwhudson | oh ok | 09:38 |
| mwhudson | zyga: looks like the newest flatpak is only in backports? | 09:43 |
| mwhudson | which would be an easier thing to do i guess | 09:43 |
| zyga | mwhudson: yes, that's a good thing IMO | 09:45 |
| mup | PR snapd#4492 opened: spread: try to enable Fedora once again <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4492> | 09:49 |
| zyga | mvo: can you please try to review https://github.com/snapcore/snapd/pull/4471 today? | 09:54 |
| mup | PR #4471: cmd/snap-update-ns: refactor and improve Change.Perform to handle EROFS <Created by zyga> <https://github.com/snapcore/snapd/pull/4471> | 09:54 |
| * zyga cannot stop laughing | 10:07 | |
| zyga | https://twitter.com/Lilobase/status/952504781515509761 | 10:07 |
| mup | PR snapd#4489 closed: vendor: remove x/sys/unix to fix builds on arm64 and powerpc <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4489> | 10:09 |
| mup | PR snapd#4482 closed: cmd/libsnap-confine-private: add debug build of libsnap-confine-private.a, link it into snap-confine-debug <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4482> | 10:11 |
| mvo | mborzecki: 4483 has feedback - seems super close to handling | 10:11 |
| mvo | zyga: sure, going over the open PRs now | 10:11 |
| mborzecki | mvo: thanks for the reviews | 10:12 |
| zyga | thank you! :) | 10:12 |
| mvo | mborzecki: the failure in bboozzoo/snap-mgmt-extend-tests is very strange, could you please merge master and see if it persists? does not make much sense to me (spread failure in go unit tests on 14.04) | 10:16 |
| mborzecki | mvo: i'll be pushing more commits in a while and i'll merge master as well | 10:19 |
| mvo | mborzecki: ta | 10:20 |
| mborzecki | mvo: i'll have to open a follow-up pr anyway, for now i only merged master and pushed to #4480 | 10:33 |
| mup | PR #4480: snap-mgmt: extend spread tests, stop, disable and cleanup snap services <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4480> | 10:33 |
| pedronis | mvo: so far we implemented Type=notify for snapd but no the watchdog stuff, right? | 11:02 |
| mborzecki | fedora currently fails with: 'No package golang(github.com/Thomasdezeeuw/ini) available.', any ideas? | 11:20 |
| zyga | that's a new dependency | 11:23 |
| zyga | we need to package it apparently | 11:23 |
| * kalikiana taking a break, not feeling awesome at all | 11:27 | |
| Alexander_ | Bumping into some problems with using iptables on ubuntu core. I have been trying to put in some dnat rules and they have not be working at all. Tcpdump is showing the packets going to the host machine. Any thoughts? | 11:27 |
| zyga | Alexander_: hmm, are the right modules loaded? | 11:28 |
| mborzecki | from a quick survey, github.com/go-ini/ini seems to be avialble in fedora/ubuntu/debian | 11:28 |
| mborzecki | and this one too github.com/vaughan0/go-ini | 11:29 |
| Alexander_ | zyga: I do not know, I have just been call iptables from command line in normal userspace and the "classic" space. How could I find out? | 11:30 |
| zyga | Alexander_: lsmod may tell you that | 11:30 |
| zyga | mborzecki: maybe it's just a missing dep then, low hanging fruit to add | 11:31 |
| mborzecki | zyga: you mean replace github.com/Thomasdezeeuw/ini with one of the 2 i listed above? | 11:31 |
| zyga | mborzecki: ah | 11:32 |
| zyga | sorry I misread | 11:32 |
| zyga | I think go-ini is the one that pedronis was unhappy about | 11:32 |
| zyga | but if that's not the case and we could use that then yes, that's a quick win | 11:33 |
| Alexander_ | $ lsmod | grep ip | 11:36 |
| Alexander_ | gives me | 11:36 |
| Alexander_ | iptable_filter ip_tables ip6table_filter ip6_tables x_tables | 11:36 |
| Alexander_ | I assume ip_tables is the support for iptables? | 11:37 |
| pedronis | zyga: mborzecki: mvo proposed to use our old goconfigparser, that should have been packaged already too | 11:38 |
| mborzecki | pedronis: is it in the tree now? | 11:39 |
| pedronis | mborzecki: no, it's on github though | 11:39 |
| pedronis | probably best to wait for mvo to decide what to do | 11:40 |
| mborzecki | ok | 11:40 |
| zyga | hmm | 11:44 |
| zyga | I'm learning more aboud dbus the hard wy | 11:44 |
| zyga | way* | 11:44 |
| mvo | pedronis, zyga either way is fine with me, if we decide on the old parser I'm happy to look into the porting | 11:45 |
| pedronis | mvo: I think I would prefer the old parser over go-ini | 11:45 |
| mvo | pedronis: works for me, I will look into the porting (unless you want to do it) | 11:46 |
| ikey | dbus is the debil | 11:46 |
| zyga | ikey: debil? | 11:46 |
| ikey | devil. | 11:46 |
| zyga | ah :D | 11:46 |
| zyga | in polish debil has another meaning and I was now wondering if that's an english word as well | 11:46 |
| ikey | ah ok | 11:46 |
| ikey | waterboy reference :P | 11:46 |
| zyga | https://translate.google.com/#pl/en/debil ;-) | 11:47 |
| ikey | hah nice | 11:47 |
| ikey | that works too | 11:47 |
| mvo | pedronis: heh, fun! goconfigparser is even part of the vendoring still as we use it in one of our tests | 11:49 |
| pedronis | mvo: yes, I see | 11:50 |
| mvo | pedronis: fwiw, I addressed the points in 4356 | 11:52 |
| mborzecki | don't remember the details of fedora policy on go packages, but if it's under vendor then there musn't there be a real package with that dep too? | 11:55 |
| zyga | mborzecki: it depends on where it is, it needs to be marked as an embedded package, in some places it's embedded (centos) and in some places it's not (fedora) | 11:56 |
| zyga | mborzecki: that's what I remember, I'm sure Pharaoh_Atem can correct me if I'm wrong | 11:56 |
| mborzecki | zyga: i think https://github.com/snapcore/snapd/blob/master/dirs/dirs.go#L234 is causing https://bugs.launchpad.net/snappy/+bug/1743301 korora is derived from fedora and apaprently it's picking the wrong libexedir | 12:04 |
| mup | Bug #1743301: cannot install apps using snap on Korora <Snappy:New> <https://launchpad.net/bugs/1743301> | 12:04 |
| mvo | pedronis: I pushed a PR and have lunch now. wonder if I should add more unit tests for the error cases? or do you think its sufficient? | 12:04 |
| mup | PR snapd#4493 opened: image: port ini handling to goconfigparser <Created by mvo5> <https://github.com/snapcore/snapd/pull/4493> | 12:04 |
| mborzecki | zyga: we should do release.DistroLike() probably | 12:05 |
| mborzecki | zyga: do you know what os-relase looks like on rhel and cetos? | 12:05 |
| pedronis | mvo: I think the error handling is easy enough to follow | 12:08 |
| pedronis | mvo: pushed couple of comments | 12:08 |
| zyga | mborzecki: looking | 12:08 |
| zyga | mborzecki: yep | 12:08 |
| zyga | mborzecki: sure | 12:09 |
| zyga | mborzecki: one sec... | 12:09 |
| zyga | https://github.com/zyga/os-release-zoo/blob/master/redhat/rhel7.txt | 12:09 |
| zyga | https://github.com/zyga/os-release-zoo/blob/master/centos/centos-7.txt | 12:09 |
| zyga | :-) | 12:09 |
| zyga | enjoy! and add anything you find missing please | 12:09 |
| mborzecki | zyga: hah, thanks | 12:09 |
| * zyga still fights dbus | 12:09 | |
| mborzecki | zyga: url open thing? | 12:10 |
| zyga | mborzecki: hmm? | 12:11 |
| zyga | mborzecki: ah, yes | 12:11 |
| zyga | but in reality dbus bug | 12:11 |
| mborzecki | interesting, does it warrant a blog post? :) | 12:11 |
| zyga | mborzecki: ha, I can write about that though it's pretty obscure and I haven't fixed it yet | 12:11 |
| * pstolowski lunch | 12:13 | |
| zyga | hey there neal! | 12:18 |
| mborzecki | zyga: https://github.com/zyga/os-release-zoo/pull/26 | 12:27 |
| mup | PR zyga/os-release-zoo#26: korora: add Korora 26 <Created by bboozzoo> <https://github.com/zyga/os-release-zoo/pull/26> | 12:27 |
| zyga | merged | 12:28 |
| zyga | thank you | 12:28 |
| zyga | man | 12:29 |
| zyga | building dbus sucks, it's hediously complex | 12:29 |
| zyga | I ended up rebuilding the package | 12:29 |
| zyga | I have no idea how things get configured apart from 'by magic' there | 12:30 |
| mup | PR snapd#4494 opened: dirs: check if distro 'is like' fedora when picking path to libexecdir <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4494> | 12:52 |
| * Chipaca is back but really exhausted from the meetings | 12:58 | |
| zyga | joining | 13:01 |
| niemeyer | Speaking of which, I won't join you today | 13:01 |
| zyga | niemeyer: thanks for the heads up! | 13:04 |
| ondra | ogra ping | 13:07 |
| ogra | ondra, yo | 13:07 |
| mup | PR snapd#4307 closed: tests: fix "job canceled" issue and improve cleanup for snaps <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4307> | 13:20 |
| zyga | pstolowski: sudo snap debug get-base-declaration | 13:27 |
| pstolowski | zyga, thanks! | 13:27 |
| * Chipaca hugs niemeyer | 13:29 | |
| === Joneleth1 is now known as JonelethIrenicus | ||
| pedronis | pstolowski: do you have a pointer to a place where we iterate of attrs (not constraints) | 13:31 |
| pstolowski | pedronis, 1 sec | 13:31 |
| JonelethIrenicus | what do I have multiple snappy cores? | 13:32 |
| Chipaca | JonelethIrenicus: pardon? | 13:33 |
| JonelethIrenicus | if I open up something like firelight I see mutliple snappy core "disks" | 13:34 |
| JonelethIrenicus | old versions | 13:35 |
| JonelethIrenicus | /snap/core/3604 | 13:35 |
| JonelethIrenicus | /snap/core/3748 | 13:35 |
| JonelethIrenicus | etc.. | 13:35 |
| ogra | for rollback | 13:36 |
| mup | PR snapcraft#1873 opened: elf: cleaner patchelf experience <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1873> | 13:36 |
| zyga | JonelethIrenicus: those are multiple revisions of one snap | 13:36 |
| zyga | JonelethIrenicus: snapd maintains up to three revisions per snap | 13:36 |
| zyga | JonelethIrenicus: they get recycled automatically | 13:36 |
| ogra | on classic you always need to have two ... on ubuntu-core you need three (two for rollback, one for factory reset) | 13:36 |
| JonelethIrenicus | i see | 13:37 |
| ogra | (i think snapd doesnt make any difference between core and classic on that level currently, so you will end up with three on classic too ... ) | 13:37 |
| mvo | pedronis: I updated the ini pr and addressed your feedback (thanks again for this) | 13:39 |
| Chipaca | JonelethIrenicus: you can remove them if you need to via "snap remove --revision=<rev#> <snapname>" | 13:40 |
| JonelethIrenicus | Chipaca: good tip thanks | 13:40 |
| Chipaca | JonelethIrenicus: if you try to remove the current one it'll tell you to behave :-) | 13:40 |
| JonelethIrenicus | haha well that is never going to happen | 13:41 |
| pedronis | mvo: looks good, you miss a bundled(...) in one of those packaging lines though | 13:41 |
| mvo | pedronis: uh, thanks. silly copy/paste | 13:42 |
| pstolowski | pedronis, hmm I think I was wrong and confused the loop over constraints with looping over attributes | 13:42 |
| mborzecki | does snapcraft need to know about after/before properties in apps now that the systemd after/before ordering is merged? | 13:43 |
| pedronis | pstolowski: I suppose better this way, but that's what I wondered, because I don't remember code like that (but it was a long time ago) | 13:44 |
| pstolowski | pedronis, yes, that solves half of the problems | 13:46 |
| zyga | lunch is soon, let's do one more test | 13:46 |
| mvo | mborzecki: one question about 4494> did you check that rhel and centos have a DISTRO_LIKE=fedora ? i.e. that we won't regress on those? | 13:49 |
| mup | PR snapd#4494 closed: dirs: check if distro 'is like' fedora when picking path to libexecdir <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4494> | 13:49 |
| mborzecki | mvo: i checked in zyga's os-release-zoo https://github.com/zyga/os-release-zoo/blob/master/redhat/rhel7.txt https://github.com/zyga/os-release-zoo/blob/master/centos/centos-7.txt | 13:50 |
| mvo | mborzecki: neat, thanks | 13:50 |
| Chipaca | mborzecki: that project takes patches (e.g. korororora?) | 13:50 |
| mborzecki | sounds kiwi'sh | 13:51 |
| Chipaca | my dad skills have spilled into the forum! first time i've used "you (plural)" like that that i know of :-D | 13:53 |
| Chipaca | anyhoo, work calls | 13:53 |
| mborzecki | since korora is basically fedora, I wonder if Son_Goku could cherry-pick the patch when updating the package to 2.30 | 13:54 |
| Son_Goku | mborzecki: which patch do I need to cherry pick? | 13:54 |
| mborzecki | Son_Goku: https://github.com/snapcore/snapd/pull/4494 | 13:54 |
| mup | PR #4494: dirs: check if distro 'is like' fedora when picking path to libexecdir <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4494> | 13:54 |
| Son_Goku | mvo: I thought I had gotten all of these things when I attempted to fix this for Korora last time? | 13:54 |
| Son_Goku | I swear I did... | 13:55 |
| Son_Goku | oh, geez | 13:56 |
| Son_Goku | there was another check for libexecdir | 13:56 |
| mvo | Son_Goku: :/ well, I guess we now have them all! | 13:56 |
| Son_Goku | are we really sure this time? | 13:56 |
| Son_Goku | now even I'm not sure... | 13:56 |
| Son_Goku | mborzecki: but yeah, I'll be cherry-picking this | 13:57 |
| mborzecki | Son_Goku: great, thanks | 13:58 |
| Son_Goku | mvo, could you just make sure the PR is cherry picked into the 2.30 branch? | 13:58 |
| Son_Goku | it makes it easier for me to keep track of these things | 13:58 |
| mvo | Son_Goku: sure | 13:59 |
| mvo | Son_Goku: its in release/2.30 now | 14:01 |
| Son_Goku | thanks | 14:01 |
| Son_Goku | I'm going to be preparing the backport later today | 14:01 |
| Son_Goku | err, upgrade | 14:01 |
| mborzecki | mvo: since you're cherry picking to 2.30, can you also pick https://github.com/snapcore/snapd/pull/4432 ? Son_Goku left a note there, but I don't see it in release/2.30 | 14:05 |
| mup | PR #4432: cmd/snap, tests/main/classic-confinement: fix snap-exec path when running under classic confinement <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4432> | 14:05 |
| mvo | mborzecki: sure, looking | 14:05 |
| mvo | mborzecki: done | 14:06 |
| mborzecki | mvo: thanks | 14:06 |
| Son_Goku | mvo: I just want to avoid being forced to have my own source maint tree | 14:06 |
| Son_Goku | because in my opinion, such things are counterproductive with ensuring fixes are upstream | 14:07 |
| Son_Goku | (it's one of the reasons I dislike the Debian/Ubuntu model of packaging with gbp trees) | 14:07 |
| Son_Goku | today, there's exactly ONE downstream patch that's not upstream | 14:08 |
| mvo | Son_Goku: +1 | 14:08 |
| mvo | Son_Goku: ping me anytime if you need something cherry-picked | 14:08 |
| Son_Goku | cool, thanks | 14:08 |
| mvo | zyga: 4483 needs a second review, iirc you looked at this before so should be trivial | 14:08 |
| Son_Goku | God knows, I could actually do my own source trees for packaging, but I hate that stuff | 14:09 |
| Son_Goku | it's far too easy to get lazy and complacent | 14:09 |
| mvo | Son_Goku: plus the collaborating with upstream is usually very healthy | 14:09 |
| Son_Goku | yeah | 14:09 |
| mvo | (and great for upstream because they understand the needs of the packages better etc etc) | 14:10 |
| Son_Goku | I think what really burned me was my experience with Debian as an upstream software developer | 14:10 |
| Son_Goku | one of my software packages was effectively forked and they never bothered to talk to me | 14:10 |
| Son_Goku | meanwhile I was listed as a contact point in the copyright, so I got weird questions from people using the Debian version | 14:10 |
| mvo | Son_Goku: uh, that sucks - may I ask what the package name was? | 14:11 |
| Son_Goku | lugaru / openlugaru | 14:11 |
| Son_Goku | they'd also converted the source tree from Mercurial (as it was at the time) to Git | 14:11 |
| Son_Goku | which meant it was painful to figure out where they actually were | 14:11 |
| mvo | Son_Goku: uh, I see, that sounds painful | 14:12 |
| Son_Goku | needless to say, it annoyed me | 14:12 |
| mvo | Son_Goku: *nod* | 14:12 |
| Son_Goku | when development of lugaru restarted, I switched to Git (as everyone else wanted it), and did significant work | 14:13 |
| mvo | Son_Goku: I hope it got better over time | 14:13 |
| Son_Goku | unfortunately, their little weird tree meant that they spent a year arguing about how to refork the source tree into Alioth for packaging | 14:13 |
| Son_Goku | Debian was *the last* distribution to get the new Lugaru, and they missed the first release | 14:14 |
| Son_Goku | I wish it wasn't common practice to fork source trees for packaging in Debian, because it seems to lead to people cheaply patching things without talking to upstream | 14:14 |
| Son_Goku | the upstream project (that is me and a couple of others) requested that they didn't fork the tree again, and we were told to butt out :( | 14:15 |
| Son_Goku | it's not like I don't understand how to handle the upstream/downstream relationship | 14:16 |
| Son_Goku | but that was cold :/ | 14:16 |
| mvo | Son_Goku: :( | 14:16 |
| mvo | Son_Goku: sorry to hear this bad experience | 14:16 |
| Son_Goku | yeah, well, I've made a point now to avoid what I call merged source trees for packaging | 14:16 |
| Son_Goku | I don't want to inflict that kind of mess onto someone else | 14:16 |
| Son_Goku | mvo: that said, it's not like I don't understand why debian is evolving towards that form of packaging | 14:17 |
| Son_Goku | debian source control is designed to be integrated with source trees, always has and always will | 14:18 |
| Son_Goku | it's even in the name ;) | 14:18 |
| Son_Goku | but it's one of the reasons I prefer the way RPMs are packaged, because it solidifies that split | 14:19 |
| mborzecki | off to pick up the kids | 14:19 |
| Son_Goku | most packaging formats impose that split (RPM Spec, Arch PKGBUILD, Solus ypkg, etc.) | 14:19 |
| Son_Goku | and personally, I think it's a very good thing | 14:19 |
| mvo | Son_Goku: right, well, there is a concept of orig.tar.gz in the deb sources as well. but yeah, its easy to fork | 14:27 |
| mvo | zyga: I looked at 4471 and it seems there is some good feedback already so I am happy to have another look once this feedback is addressed | 14:28 |
| Son_Goku | mvo, which reminds me, why aren't you just using the deb sources multi-tarball thing to deal with bundling squashfuse? | 14:29 |
| Son_Goku | the go hack is kind of garbage, tbh, and I don't think it's worth risking making it a permanent part of snapd | 14:30 |
| Son_Goku | it really only needs to exist for 16.04, as 18.04 could just have squashfuse declared as a proper dependency (since dist-upgrade is used for that process) | 14:30 |
| zyga | mvo: thanks! | 14:31 |
| zyga | mvo: looking at the earlier one as well | 14:32 |
| mvo | Son_Goku: I need to look into this, it will make the packaging slightly more complicated, but might be worth checking. I kind of like the facts that its inside vendor/ as this is the place where we put stuff we "vendor" :) the fact that its a bit hacky around that makes me slightly sad, I need to explore if the other options are better | 14:32 |
| Son_Goku | mvo: well my thought is that "snapfuse" is a workaround for an apt deficiency | 14:33 |
| Son_Goku | the proper thing to do is depend on squashfuse | 14:33 |
| mvo | it is | 14:33 |
| Son_Goku | again, I want to avoid the risk of "snapfuse" being a mandatory dep | 14:34 |
| Son_Goku | in Fedora, I just introduced squashfuse as a dependency and we were good to go | 14:34 |
| tedg | cjwatson: sergiusens: Good morning, I have Inkscape master building in a "snapcraft cleanbuild" well, but it fails on the builders in a weird way. https://code.launchpad.net/~ted/+snap/inkscape-master | 14:45 |
| tedg | I'm not sure what could be different between the two (at all), but much less that could cause something like this. | 14:45 |
| tedg | Or frankly, what the error really is there. | 14:45 |
| mup | PR snapd#4495 opened: data/dbus: add AssumedAppArmorLabel=unconfined t <Created by mvo5> <https://github.com/snapcore/snapd/pull/4495> | 14:48 |
| cjwatson | tedg: maybe cleanbuild uses a slightly different sources.list by default? | 14:57 |
| tedg | cjwatson: Yeah, I did have to add software-proprties-common as add-apt-repository wasn't on the builders but was in cleanbuild. So there are certainly some slight differences. | 14:59 |
| cjwatson | right, that's a difference in the default installed package set which is slightly different although conceivably also relevant | 15:03 |
| cjwatson | tedg: my first guess would definitely be that it's something broken in ppa:ubuntu-desktop/ubuntu/gnome-3-26, although I don't know why you wouldn't see that in cleanbuild | 15:06 |
| tedg | Hmm, and kenvandine is suspiciously not here :-) | 15:08 |
| mvo | pedronis: did you notice that master is currently failing? it looks like it cannot install test-snapd-private | 15:08 |
| tedg | seb128: Do you know about the gnome-3-26 backport PPA? | 15:08 |
| seb128 | tedg, what about it? | 15:08 |
| tedg | seb128: My snap is failing to build with it, cjwatson thinks that it may be an issue with a package there. (I'm not sure what's up personally) | 15:09 |
| seb128 | tedg, Ken did recent uploads there, I guess it's not impossible that he screwed | 15:11 |
| seb128 | if your issue is in the gtkmm stack | 15:11 |
| seb128 | we didn't do recent builds afaik so I'm unsure if the ppa got tested since those uploads | 15:12 |
| cjwatson | aha, reproduced, ish | 15:12 |
| tedg | Yeah, and he added that at my request as it was needed to get Inkscape building. | 15:12 |
| seb128 | so you blame him but it's your fault :p | 15:13 |
| tedg | (well, building with the new GTK) | 15:13 |
| cjwatson | tedg: https://paste.ubuntu.com/26398323/ | 15:13 |
| tedg | Haha | 15:13 |
| * cjwatson adds a few more packages to drill down | 15:14 | |
| pedronis | mvo: no | 15:14 |
| mvo | pedronis: aha, nevermind | 15:14 |
| cjwatson | https://paste.ubuntu.com/26398330/ | 15:14 |
| mvo | pedronis: I think its just a change error message, I will fix it | 15:14 |
| mvo | pedronis: strange that we did not see it in PRs | 15:15 |
| cjwatson | so the basic problem is a conflict somewhere in that set | 15:15 |
| pedronis | mvo: ah | 15:15 |
| cjwatson | libgdk-pixbuf2.0-dev Depends: libpng-dev | 15:16 |
| mvo | pedronis: aha, of course, we only run this test against main, right? I think you told me a while ago | 15:16 |
| tedg | Hmm, so perhaps I need to explicitly remove the older libpng? | 15:16 |
| seb128 | cjwatson, tedg, Ken is back tomorrow if he needs to fix something | 15:16 |
| pedronis | mvo: yes, that's because of travis security rules, secrets are set only for main repo branches | 15:17 |
| pedronis | not PRs | 15:17 |
| cjwatson | tedg: dropping libpng12-dev and adding gtk-update-icon-cache (I'm not sure why ...) seems to work at least in my reduced test case | 15:18 |
| mup | PR snapd#4496 opened: tests: update auto-refresh-private to match messages from current master <Created by mvo5> <https://github.com/snapcore/snapd/pull/4496> | 15:19 |
| mvo | pedronis: indeed, PR on the way | 15:19 |
| tedg | cjwatson: Thanks, I'll give those a try! (it'll take a while to get test builds done) | 15:19 |
| elopio | hey kyrofa, should I make a PR to try one of the desktop solutions so we can discuss there? | 15:33 |
| mup | PR snapcraft#1874 opened: kbuild: pick up CROSS_COMPILE only if it's not empty <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1874> | 15:33 |
| pstolowski | hey tedg, howdy! | 15:35 |
| tedg | Howdy pstolowski ! | 15:35 |
| diddledan | what's the mechanism for including my own plugin to build my project? I have written the pyhton script but can't get snapcraft to recognise it | 15:36 |
| diddledan | (I modified the PythonPlugin and saved it to ./snap/plugins/foo.py) | 15:36 |
| kyrofa | diddledan, try naming it x-foo.py | 15:39 |
| kyrofa | Or maybe x_foo.py... now I can't remember :P | 15:39 |
| kyrofa | Probably the latter | 15:40 |
| diddledan | doesn't make a difference | 15:40 |
| kyrofa | diddledan, what name are you using in the YAML? | 15:40 |
| diddledan | oh, wait, that made it work, but doesn't list it in `snapcraft plugins` | 15:41 |
| kyrofa | diddledan, no, those are just the built-in plugins | 15:43 |
| kyrofa | elopio, we can chat a little in the meeting if you like | 15:50 |
| elopio | sure | 15:50 |
| Pharaoh_Atem | mborzecki: new deps need to be packaged for fedora | 16:01 |
| Pharaoh_Atem | but for epel7, bundling is allowed | 16:02 |
| Pharaoh_Atem | that's the only reason there's a bundled mode | 16:02 |
| Pharaoh_Atem | (in re fedora packaging) | 16:02 |
| mvo | Pharaoh_Atem: for 2.31 we have a new boltdb dep, but this might be packaged already for fedora, its quite popular aiui | 16:07 |
| pedronis | mvo: do you know what core-snap-refresh (but it checks boot envs) vs core-snap-refresh-on-core are about? I expected the first to have bits only about classic | 16:17 |
| pedronis | they are manual | 16:17 |
| mvo | pedronis: let me look, they are confusing | 16:21 |
| mvo | pedronis: core-snap-refresh-on-core is about refresh and revert working, it is also the newer one of the two and should be used in spread-cron (I need to double check this though) | 16:23 |
| mvo | pedronis: the other one looks like we should simplify it, i.e. just test that a new core snap survies refreshes and we can ignore core devices for this test because we already test that in the other test | 16:25 |
| pedronis | mvo: so make it classic only , and remove the bits about boot envs ? | 16:25 |
| mvo | pedronis: that would be my suggestion | 16:26 |
| pedronis | ok | 16:26 |
| mvo | pedronis: yeah, I think that is sufficient. we may need to add a loop to wait until snapd is active in `snap changes` though, I think as it is currently written it is racy | 16:27 |
| mvo | pedronis: i.e. after the reboot we may call `snap changes` before snapd has started (but then we have some wait-time for snap to wait for the socket so maybe not an issue) | 16:27 |
| pedronis | we do that in other places | 16:28 |
| pedronis | I haven't seen (yet) issues with that | 16:28 |
| mvo | pedronis: even better, then lets ignore it | 16:28 |
| mup | PR snapd#4497 opened: many: make rebooting of core on refresh immediate, refactor logic around it <Created by pedronis> <https://github.com/snapcore/snapd/pull/4497> | 16:30 |
| pedronis | mvo: I proposed this ^ though spread tests need a bit more work (for example those two), also there may be different approaches/policies | 16:33 |
| mvo | pedronis: cool, I have a look in a bit (fighting with seccomp just now) | 16:43 |
| mup | PR snapd#4496 closed: tests: update auto-refresh-private to match messages from current master <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4496> | 16:44 |
| pedronis | mvo: thx, is not super urgent but wanted to push it before leaving, it's been a todo since long, can wait after I'm back for sure to land | 16:55 |
| mvo | pedronis: ok, thank you | 16:56 |
| mvo | zyga-ubuntu: hey, welcome back - does https://travis-ci.org/snapcore/snapd/builds/329513349#L1950 make any sense to you? | 16:57 |
| zyga-ubuntu | mvo: hey | 16:58 |
| zyga-ubuntu | mvo: sorry, some stuff at home | 16:58 |
| mvo | zyga-ubuntu: in my strace PR there is a failure in the snap-update-ns test | 16:58 |
| zyga-ubuntu | mvo: I'm not back for real yet | 16:58 |
| zyga-ubuntu | mvo: great insight on your PR | 16:58 |
| zyga-ubuntu | (on the older one with dbus) | 16:58 |
| mvo | zyga-ubuntu: that looks like it is happening consistently but it does not make sense to me | 16:58 |
| mvo | zyga-ubuntu: aha, no worries | 16:58 |
| mvo | zyga-ubuntu: well, that PR is yours really, you figured it all out :) | 16:58 |
| * mvo hugs zyga-ubuntu | 16:58 | |
| zyga-ubuntu | looking | 16:58 |
| zyga-ubuntu | mvo: that strace branch is interesting | 17:00 |
| mvo | zyga-ubuntu: the fun part is that #4473 (which contain most of it) is green | 17:01 |
| mup | PR #4473: snap: add `snap run --strace` to be able to strace snap apps <Created by mvo5> <https://github.com/snapcore/snapd/pull/4473> | 17:01 |
| zyga-ubuntu | that's .... unexpected | 17:01 |
| zyga-ubuntu | mvo: as for the dbus problem I think there is a real bug in dbus now but I your patch works around it (and is not incorrect) | 17:06 |
| zyga-ubuntu | mvo: and will save me exploring that (which is painful becauese iteration is annoyingly slow) | 17:07 |
| zyga-ubuntu | mvo: I'm still trying to grok the strace bug, does it happen in interactive debug as well? | 17:08 |
| mvo | zyga-ubuntu: I have not tried that yet | 17:09 |
| mvo | zyga-ubuntu: we can talk about it tomorrow, its just puzzling and maybe things get clearer if my initial strace PR is merged | 17:09 |
| mvo | (as the diff will get smallre) | 17:10 |
| mvo | smaller | 17:10 |
| zyga-ubuntu | mvo: ok, that sounds good to me | 17:10 |
| zyga-ubuntu | mvo: I will be back in 15 minutes, just some constant interrupts at home now | 17:11 |
| zyga-ubuntu | mvo: nothing in that PR screams at me 'here' | 17:19 |
| zyga-ubuntu | mvo: unless there's a typo that makes strace go where it shouldnt | 17:19 |
| zyga-ubu1tu | re for good | 17:49 |
| === zyga-ubu1tu is now known as zyga-bionic | ||
| pedronis | did travis change their timeout? | 18:12 |
| pedronis | there's a run that is finished after 1h+ | 18:13 |
| pedronis | *is not finished | 18:13 |
| === SergioMeneses is now known as SergioMeneses1 | ||
| === SergioMeneses1 is now known as SergioMeneses | ||
| boopy | how do you update snap and how do you recover from this? | 18:27 |
| boopy | > snap "ubuntu-core" has changes in progress | 18:27 |
| cachio | niemeyer, when you have a free slot, could you please take a look to the PR #49 for spread | 18:28 |
| mup | PR #49: allow (optional) snappy update $pkgname <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/49> | 18:28 |
| mup | PR snapd#4418 closed: tests: enabling opensuse for tests <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4418> | 18:40 |
| mup | PR snapd#4490 closed: tests/main/snap-service-after-before: add test for after/before service ordering <Created by bboozzoo> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4490> | 18:45 |
| Pharaoh_Atem | mvo: it looks like we're not testing against Fedora in snapd CI | 18:57 |
| Pharaoh_Atem | what happened here? | 18:57 |
| mvo | Pharaoh_Atem: there were a bunch of issues with the fedora repos, there is a PR to enable fedora again iirc | 19:13 |
| mup | PR snapcraft#1875 opened: Remove deprecated 'snap' recommendation <Created by ted-gould> <https://github.com/snapcore/snapcraft/pull/1875> | 19:13 |
| Pharaoh_Atem | mvo: that means I probably have idea if the deps for master are satisfiable | 19:13 |
| Pharaoh_Atem | have no idea, I mean | 19:13 |
| mvo | Pharaoh_Atem: yeah, we are unhappy about this too: https://github.com/snapcore/snapd/pull/4492 | 19:14 |
| mup | PR #4492: spread: try to enable Fedora once more <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4492> | 19:14 |
| mvo | Pharaoh_Atem: actually, this one fails because of a new dep, there is a fix already for this | 19:15 |
| mvo | (in 4493) | 19:15 |
| niemeyer | cachio: Will do | 19:16 |
| cachio | niemeyer, tx | 19:21 |
| robert_ancell | Snap packages are installed in a queue right? Does anyone know if there's a plan to be able to install in parallel? | 20:30 |
| nacc | robert_ancell: LP: #1585403 ? | 20:32 |
| mup | Bug #1585403: please support parallel operation <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1585403> | 20:32 |
| robert_ancell | nacc, thanks! | 20:36 |
| pedronis | robert_ancell: there is no queue, some single things are serialized | 20:36 |
| nacc | robert_ancell: np | 20:36 |
| robert_ancell | pedronis, so can a second install start before the first one is complete currently? | 20:37 |
| pedronis | yes, at least if core is already there | 20:37 |
| robert_ancell | pedronis, ok, thanks! | 20:37 |
| pedronis | if they need core they will wait on that | 20:37 |
| robert_ancell | I'm asking because there's a discussion in GNOME Software about parallel vs. queued installation and I'm giving the snap datapoint. | 20:37 |
| pedronis | as I said, there's no queue in snapd, there are conflict checks between ops (usually at the level of each single snap), and some internal ops (like changes to security) are serialized, but overall install can be started in parallel | 20:40 |
| pedronis | and most of it will proceed in parallel | 20:40 |
| robert_ancell | e.g. downloading? | 20:41 |
| pedronis | right | 20:41 |
| nacc | pedronis: does that imply the above bug should be closed? | 20:41 |
| pedronis | yes, except I have no idea why my colleagues didn't close it, what they were thinking | 20:42 |
| pedronis | with their answers | 20:42 |
| niemeyer | I think it can be closed | 20:43 |
| niemeyer | snapd indeed operates closer to make -j than it does to apt or deb in that regard | 20:44 |
| niemeyer | Those really serialize all steps of the installation, while snapd goes wild and only rejects known conflicts as you pointed out pedronis | 20:44 |
| niemeyer | make -j also doesn't parallelize _everything_ either.. just the things it knows are independent.. so vaguely resembling snapd's behavior indeed | 20:46 |
| nacc | pedronis: niemeyer: sounds good, thanks | 20:47 |
| niemeyer | It's quite awkward to say "Fix Released" for something that was always like that.. and curious that there's no better option. | 20:48 |
| niemeyer | nacc: np | 20:48 |
| nacc | niemeyer: yeah, you can change the state of the bug to Invalid, if that's actually the case | 20:48 |
| nacc | (IMO) | 20:48 |
| nacc | roughly like NOTABUG in bugzillas | 20:48 |
| robert_ancell | niemeyer, yeah, it always feels weird doing a Fix Released like that. | 20:49 |
| nacc | niemeyer: but yeah, the states aren't quite what i expect, ever :) | 20:49 |
| niemeyer | nacc: Invalid also feels wrong.. it's not invalid.. it's a valid feature request, and it's implemented, and always was. :) | 20:49 |
| robert_ancell | The other option is invalid, but that seems a bit harsh if it was a valid request at the time. | 20:49 |
| nacc | niemeyer: yeah, but it soudns like it was't a valid feature request then either? | 20:50 |
| niemeyer | Yeah, it's more like "Yay!" | 20:50 |
| niemeyer | :) | 20:50 |
| nacc | dunno, it's a lose-lose :) | 20:50 |
| nacc | a good comment and whatever terminal state you want :) | 20:50 |
| niemeyer | nacc: yeah details.. from a human perspective, a person asked for a behavior, and it's already in place.. it's not "Okay I did it", and it's not "That's wrong" either | 20:50 |
| nacc | niemeyer: yep, agreed | 20:51 |
| niemeyer | GitHub gets that right.. it's just Closed | 20:51 |
| nacc | right | 20:51 |
| nacc | the graph for LP doesn't match my brain often | 20:51 |
| niemeyer | I'd suspect it inherited from Bugzilla, but it's been such a long time that I can't even remember.. | 20:52 |
| niemeyer | Anyway.. it's closed. :) | 20:52 |
| robert_ancell | Is there any online documentation on the policy for snapd updating snaps? They're always automatically updated on a schedule, right? | 20:55 |
| robert_ancell | And you can manually update them at any time. | 20:56 |
| robert_ancell | This seems to be the closest I can find: https://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap-from-store/707/4 | 20:57 |
| mup | Issue snapcraft#1876 opened: Cleanbuild doesn't work with SSH based Git repos <Created by ted-gould> <https://github.com/snapcore/snapcraft/issue/1876> | 21:10 |
| niemeyer | robert_ancell: Right, that's it | 21:11 |
| niemeyer | robert_ancell: The default schedule right now is 4 times within the day | 21:11 |
| niemeyer | robert_ancell: At random times | 21:12 |
| niemeyer | That is, once every 6h window | 21:12 |
| niemeyer | robert_ancell: We have improvements landing right now (just reviewed a PR on that, actually) that introduce monthly support in the scheduling | 21:13 |
| robert_ancell | niemeyer, nice | 21:13 |
| niemeyer | So people will be able to pick a specific day within the month | 21:13 |
| niemeyer | The syntax is documented in ... | 21:13 |
| niemeyer | https://forum.snapcraft.io/t/refresh-scheduling-on-specific-days-of-the-month/1239 | 21:14 |
| niemeyer | and the options for core in general are documented in ... | 21:14 |
| niemeyer | https://forum.snapcraft.io/t/configuration-options-for-core-snap/87 | 21:14 |
| niemeyer | The latter was not yet updated with the former because it's not yet publicly available | 21:14 |
| robert_ancell | I feel like we need a snapd section (perhaps a different name) in https://docs.snapcraft.io/ as that seems to cover the snap format and snapcraft | 21:14 |
| niemeyer | robert_ancell: I would prefer to just drop these pages there and make them point to our forum, which is easier to keep up to date and more visible | 21:15 |
| niemeyer | For example, the format is documented at | 21:15 |
| robert_ancell | niemeyer, that would work for me | 21:15 |
| niemeyer | https://forum.snapcraft.io/t/the-snap-format/698 | 21:15 |
| niemeyer | And we have similar pages for each of the fundamnetal snaps (gadget, kernel, etc) | 21:16 |
| niemeyer | Alright, I'm going to call it a day and see if I can get some proper sleep for a change.. | 21:20 |
| niemeyer | Have a good night all | 21:21 |
| Pharaoh_Atem | niemeyer, zyga-ubuntu: it seems that we might want to reprovision the Fedora 27 Linode VM from scratch: https://pagure.io/Fedora-Council/tickets/issue/99 | 21:59 |
| Pharaoh_Atem | that will let us add tests for SELinux stuff | 21:59 |
| Pharaoh_Atem | c.f.: https://pagure.io/Fedora-Council/tickets/issue/99#comment-480742 | 21:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!