tyhickszyga: hey - I just saw that you were debugging a dbus apparmor query bug06:15
tyhickszyga: did you get to the bottom of it?06:15
tyhicks(I see the dc25979eb commit)06:16
mupBug #1743504 opened: Ubuntu 16.04 snapd service not working <Snappy:New> <https://launchpad.net/bugs/1743504>06:21
mupPR 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
mborzeckimvo: morning07:53
zygagood morning07:56
zygaI'll get some coffee and will be back shortly :)07:57
mborzeckizyga: hey07:57
mborzeckihave you guys seen this? https://forum.snapcraft.io/t/ubuntu-16-04-snapd-fail-to-start/352907:58
zygamborzecki: looking07:58
mvohey mborzecki ! good morning07:58
mvoand good morning zyga07:58
zygalooks like #include maybe (vs include)07:59
zygabut not sure07:59
zygamvo: hey!07:59
zyga-> coffee07:59
mborzeckizyga: apparmor thing?08:01
zygayes, we delt with this in the past, that's the only thing that I can recall having an '#' issue08:02
zygathis is not a guarantee this is it08:02
jdstrandthat error is talking about the '#' being a problem08:02
jdstrandthe issue you were thinking of was a missing '#'08:03
zygahey jdstrand :)08:03
zygaI'm not used to you being in the same timezone08:03
zygahow was day one? :)08:03
jdstrandbut regardless, snapd was not affected by the '#' or lack of '#', it was the apparmor python tools. I think this is unrelated to all that08:03
jdstrandday one went fine08:04
zygaah, indeed, I think you are right08:04
mvozyga, 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.json08:04
mvomborzecki: (as you already guessed :)08:04
jdstrandno time to do any engineering really. lots of meetings, lots of interrupts when I thought I had time to do something08:04
jdstrandtypical sprint :)08:04
jdstrandzyga: 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
mborzeckimvo: makes me wonder, unless hand edited, how would # end up in state.json?08:06
zygajdstrand: ack08:06
mvomborzecki: 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
mborzeckiit's not part of the pacakge right? so there's no chance of state.json getting updated as part of package upgrade?08:08
zygajdstrand: how's the weather like?08:09
jdstrandzyga: beautiful08:09
zygamborzecki: or if you remember my crazy hdd yesterday, may be the xml profile in place of json :)08:09
zygamborzecki: on my disk the dpkg database contains random files08:09
jdstrandzyga: sounds like a fun day :)08:09
mborzeckizyga: yeah, that's possible too :/08:09
pstolowskigood morning!08:12
* kalikiana feeling a bit under the weather this not so good morning :-(08:12
mvomborzecki: correct08:12
zygakalikiana: ouch08:12
zygahey pstolowski08:13
pstolowskikalikiana, sad to hear that.. take it easy and get well!08:13
zygamwhudson: snapd in debian is updating now08:19
mvozyga, mborzecki, pstolowski quick question - what feels more natural to you: `snap run --strace-opts="-tt" hello` or `snap run --strace="-tt" hello` ?08:19
zygamvo: the latter08:20
pstolowskimvo, the latter08:20
mvo(the former could also be written as `snap run --strace --strace-opts="-tt"  `08:20
mvook - cool, I look at it08:20
mvothanks for your feedback08:20
zygagreat, thanks for asking :)08:20
zygasnapd is now at 2.30-4 in sid :)08:21
zygamwhudson: thank you for pushing that!08:21
mborzeckimvo: yup, the latter08:21
mvomborzecki: ta!08:21
mborzeckimvo: btw. it'd also be a nice feature to be able to disable filtering out of pre snap-exec starce output08:22
zygamvo: does the method to run strace scale to things like gdb?08:23
mupPR 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
mvomborzecki: interessting idea08:23
zygamvo: though gdb is also more complex because od symbols08:23
pstolowskiand valgrind? ;)08:23
zygaI need to reboot my laptop08:24
mvozyga: for gdb one would have to automatically set a breakpoint at "execve("the-snap-app")" and then run it08:24
zygait goes crazy after suspend and all the textures blink08:24
pstolowskijust kidding, valgrind is tricky for many reasons I suppose.. just gdb would be cool08:24
mupPR 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
zygaI think I need to power it off08:30
zygait's still wonky08:30
zygaand wifi is wonky  too08:30
mborzeckithe year of linux desktop :P08:30
* zyga looks for debian topics on the forum08:33
mupPR 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
mvokalikiana: 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 him08:38
zygamvo: I didn't like amed too08:40
zygamvo: I proposed one alternative on the forum but I forgot what it was08:40
pedronismvo: I could think:  --reestablish  otherwise I thing we need more than one word with store in it somehow08:43
pedronis*I think08:43
mvopedronis: I like --reestablish - feel free to add to the PR. I'm addressing your comments now fwiw08:44
pedronismvo: and we have other plans for "replace"08:45
pedronisthat might happen or not, but I don't think we want to use that08:45
kalikianapedronis, mvo: I commented on the PR https://github.com/snapcore/snapd/pull/4356#discussion_r16063303308:46
mupPR #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 lemon08:49
pedronismvo: put a rambling there about this08:51
zygasnapd 2.30 on debian sid works well, spotify, gimp and brave tested08:59
mborzeckimvo: will the strace PR will work with classic snaps too?09:00
zygamborzecki: classic snaps don't need anything for strace09:02
zygathough it'd be nice if they also worked with the same U09:02
mborzeckiwhat i meant if you do `snap run --starce <some-classic-snap>` will it work too?09:03
zygaI don't know :)09:03
mvomborzecki, zyga: do we run snap-confine on classic snaps at all? iirc we do and if so strace should work09:04
mwhudsonzyga: np, does it work? :)09:09
zygamwhudson: yes09:10
mwhudsonoh good09:10
zygamwhudson: with apparmor enabled09:10
zygaso good work :-)09:11
mborzeckimvo: tried `snap run --strace` with a classic snap just now, works fine :)09:11
mwhudsoni should send some of the changes your way09:11
mvomborzecki: \o/09:11
mwhudsonthe "arch all only builds fail" thing would happen with ubuntu packaging too i'm fairly sure09:11
mborzeckimvo: 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 similar09:12
mvomborzecki: aha, good point. quirks with the go-flags09:19
mvomborzecki: thanks, let me fix this09:19
mvomborzecki: there is a failure in 4490 on 14.04 that looks vaguely ral09:21
=== __chip__ is now known as Chipaca
Chipacagood morning peeps09:25
mvoChipaca: hey, good morning!09:25
Chipacajust popping in to let you know (because I completely forgot yesterday)09:25
mborzeckimvo: thanks, looks like the formatting changed between systemd versions :/09:26
Chipacathat i've got two long parent meetings at the school today, so i've taken half a day off09:26
mborzeckiChipaca: morning09:26
mvomborzecki: :(09:26
zygahey there john!09:26
Chipacaso, hello and goodbye :-)09:26
zygamborzecki: oh, "fun"09:26
mvoChipaca: sure - when you have a moment 4489 is an easy win09:26
zygahow can projects do that :/09:26
mvoor someone else :)09:26
Chipacamvo: ack09:26
Chipacamvo: reach me on telegram if you need me though09:27
mborzeckizyga: systemctl --porcelain :)09:27
zygamvo: did you see http://travis.debian.net/ ? :)09:28
zygawould be cool to have instructions like that for snapcraft09:29
mvozyga: might cool09:30
mvomborzecki: 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
mborzeckimvo: enabling it via environment sounds good to me, SNAP_STRACE_EARLY=1 or something similar09:33
mwhudsonzyga: what's the motivation for wanting to update snapd in stretch?09:37
mwhudsonthe version released with stretch re-execs i think...09:38
zygamwhudson: yes, thought I don't know if that enables all the features09:38
zygamwhudson: it would be a nice thing to update it09:38
zygamwhudson: flapak gets the updates, for example09:38
mwhudsonoh ok09:38
mwhudsonzyga: looks like the newest flatpak is only in backports?09:43
mwhudsonwhich would be an easier thing to do i guess09:43
zygamwhudson: yes, that's a good thing IMO09:45
mupPR snapd#4492 opened: spread: try to enable Fedora once again <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4492>09:49
zygamvo: can you please try to review https://github.com/snapcore/snapd/pull/4471  today?09:54
mupPR #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
mupPR 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
mupPR 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
mvomborzecki: 4483 has feedback - seems super close to handling10:11
mvozyga: sure, going over the open PRs now10:11
mborzeckimvo: thanks for the reviews10:12
zygathank you! :)10:12
mvomborzecki: 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
mborzeckimvo: i'll be pushing more commits in a while and i'll merge master as well10:19
mvomborzecki: ta10:20
mborzeckimvo: i'll have to open a follow-up pr anyway, for now i only merged master and pushed to #448010:33
mupPR #4480: snap-mgmt: extend spread tests, stop, disable and cleanup snap services <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4480>10:33
pedronismvo: so far we implemented   Type=notify for snapd but no the watchdog stuff, right?11:02
mborzeckifedora currently fails with: 'No package golang(github.com/Thomasdezeeuw/ini) available.', any ideas?11:20
zygathat's a new dependency11:23
zygawe need to package it apparently11:23
* kalikiana taking a break, not feeling awesome at all11: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
zygaAlexander_: hmm, are the right modules loaded?11:28
mborzeckifrom a quick survey, github.com/go-ini/ini seems to be avialble in fedora/ubuntu/debian11:28
mborzeckiand this one too github.com/vaughan0/go-ini11: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
zygaAlexander_: lsmod may tell you that11:30
zygamborzecki: maybe it's just a missing dep then, low hanging fruit to add11:31
mborzeckizyga: you mean replace github.com/Thomasdezeeuw/ini with one of the 2 i listed above?11:31
zygamborzecki: ah11:32
zygasorry I misread11:32
zygaI think go-ini is the one that pedronis was unhappy about11:32
zygabut if that's not the case and we could use that then yes, that's a quick win11:33
Alexander_$ lsmod | grep ip11:36
Alexander_ gives me11:36
Alexander_iptable_filter  ip_tables ip6table_filter ip6_tables x_tables11:36
Alexander_I assume ip_tables is the support for iptables?11:37
pedroniszyga: mborzecki: mvo proposed to use our old goconfigparser, that should have been packaged already too11:38
mborzeckipedronis: is it in the tree now?11:39
pedronismborzecki: no, it's on github though11:39
pedronisprobably best to wait for mvo to decide what to do11:40
zygaI'm learning more aboud dbus the hard wy11:44
mvopedronis, zyga either way is fine with me, if we decide on the old parser I'm happy to look into the porting11:45
pedronismvo: I think I would prefer the old parser  over go-ini11:45
mvopedronis: works for me, I will look into the porting (unless you want to do it)11:46
ikeydbus is the debil11:46
zygaikey: debil?11:46
zygaah :D11:46
zygain polish debil has another meaning and I was now wondering if that's an english word as well11:46
ikeyah ok11:46
ikeywaterboy reference :P11:46
zygahttps://translate.google.com/#pl/en/debil ;-)11:47
ikeyhah nice11:47
ikeythat works too11:47
mvopedronis: heh, fun! goconfigparser is even part of the vendoring still as we use it in one of our tests11:49
pedronismvo: yes, I see11:50
mvopedronis: fwiw, I addressed the points in 435611:52
mborzeckidon'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
zygamborzecki: 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
zygamborzecki: that's what I remember, I'm sure Pharaoh_Atem can correct me if I'm wrong11:56
mborzeckizyga: 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 libexedir12:04
mupBug #1743301: cannot install apps using snap on Korora <Snappy:New> <https://launchpad.net/bugs/1743301>12:04
mvopedronis: 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
mupPR snapd#4493 opened: image: port ini handling to goconfigparser <Created by mvo5> <https://github.com/snapcore/snapd/pull/4493>12:04
mborzeckizyga: we should do release.DistroLike() probably12:05
mborzeckizyga: do you know what os-relase looks like on rhel and cetos?12:05
pedronismvo: I think the error handling is easy enough to follow12:08
pedronismvo: pushed couple of comments12:08
zygamborzecki: looking12:08
zygamborzecki: yep12:08
zygamborzecki: sure12:09
zygamborzecki: one sec...12:09
zygaenjoy! and add anything you find missing please12:09
mborzeckizyga: hah, thanks12:09
* zyga still fights dbus12:09
mborzeckizyga: url open thing?12:10
zygamborzecki: hmm?12:11
zygamborzecki: ah, yes12:11
zygabut in reality dbus bug12:11
mborzeckiinteresting, does it warrant a blog post? :)12:11
zygamborzecki: ha, I can write about that though it's pretty obscure and I haven't fixed it yet12:11
* pstolowski lunch12:13
zygahey there neal!12:18
mborzeckizyga: https://github.com/zyga/os-release-zoo/pull/2612:27
mupPR zyga/os-release-zoo#26: korora: add Korora 26 <Created by bboozzoo> <https://github.com/zyga/os-release-zoo/pull/26>12:27
zygathank you12:28
zygabuilding dbus sucks, it's hediously complex12:29
zygaI ended up rebuilding the package12:29
zygaI have no idea how things get configured apart from 'by magic' there12:30
mupPR 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 meetings12:58
niemeyerSpeaking of which, I won't join you today13:01
zyganiemeyer: thanks for the heads up!13:04
ondraogra ping13:07
ograondra, yo13:07
mupPR 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
zygapstolowski: sudo snap debug get-base-declaration13:27
pstolowskizyga, thanks!13:27
* Chipaca hugs niemeyer 13:29
=== Joneleth1 is now known as JonelethIrenicus
pedronispstolowski: do you have a pointer to a place where we iterate of attrs (not constraints)13:31
pstolowskipedronis, 1 sec13:31
JonelethIrenicuswhat do I have multiple snappy cores?13:32
ChipacaJonelethIrenicus: pardon?13:33
JonelethIrenicusif I open up something like firelight I see mutliple snappy core "disks"13:34
JonelethIrenicusold versions13:35
ografor rollback13:36
mupPR snapcraft#1873 opened: elf: cleaner patchelf experience <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1873>13:36
zygaJonelethIrenicus: those are multiple revisions of one snap13:36
zygaJonelethIrenicus: snapd maintains up to three revisions per snap13:36
zygaJonelethIrenicus: they get recycled automatically13:36
ograon classic you always need to have two ... on ubuntu-core you need three (two for rollback, one for factory reset)13:36
JonelethIrenicusi see13: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
mvopedronis: I updated the ini pr and addressed your feedback (thanks again for this)13:39
ChipacaJonelethIrenicus: you can remove them if you need to via "snap remove --revision=<rev#> <snapname>"13:40
JonelethIrenicusChipaca: good tip thanks13:40
ChipacaJonelethIrenicus: if you try to remove the current one it'll tell you to behave :-)13:40
JonelethIrenicushaha well that is never going to happen13:41
pedronismvo: looks good, you miss a bundled(...) in one of those packaging lines though13:41
mvopedronis: uh, thanks. silly copy/paste13:42
pstolowskipedronis, hmm I think I was wrong and confused the loop over constraints with looping over attributes13:42
mborzeckidoes snapcraft need to know about after/before properties in apps now that the systemd after/before ordering is merged?13:43
pedronispstolowski: 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
pstolowskipedronis, yes, that solves half of the problems13:46
zygalunch is soon, let's do one more test13:46
mvomborzecki: 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
mupPR 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
mborzeckimvo: 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.txt13:50
mvomborzecki: neat, thanks13:50
Chipacamborzecki: that project takes patches (e.g. korororora?)13:50
mborzeckisounds kiwi'sh13:51
Chipacamy dad skills have spilled into the forum! first time i've used "you (plural)" like that that i know of :-D13:53
Chipacaanyhoo, work calls13:53
mborzeckisince korora is basically fedora, I wonder if Son_Goku could cherry-pick the patch when updating the package to 2.3013:54
Son_Gokumborzecki: which patch do I need to cherry pick?13:54
mborzeckiSon_Goku: https://github.com/snapcore/snapd/pull/449413:54
mupPR #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_Gokumvo: I thought I had gotten all of these things when I attempted to fix this for Korora last time?13:54
Son_GokuI swear I did...13:55
Son_Gokuoh, geez13:56
Son_Gokuthere was another check for libexecdir13:56
mvoSon_Goku: :/ well, I guess we now have them all!13:56
Son_Gokuare we really sure this time?13:56
Son_Gokunow even I'm not sure...13:56
Son_Gokumborzecki: but yeah, I'll be cherry-picking this13:57
mborzeckiSon_Goku: great, thanks13:58
Son_Gokumvo, could you just make sure the PR is cherry picked into the 2.30 branch?13:58
Son_Gokuit makes it easier for me to keep track of these things13:58
mvoSon_Goku: sure13:59
mvoSon_Goku: its in release/2.30 now14:01
Son_GokuI'm going to be preparing the backport later today14:01
Son_Gokuerr, upgrade14:01
mborzeckimvo: 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.3014:05
mupPR #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
mvomborzecki: sure, looking14:05
mvomborzecki: done14:06
mborzeckimvo: thanks14:06
Son_Gokumvo: I just want to avoid being forced to have my own source maint tree14:06
Son_Gokubecause in my opinion, such things are counterproductive with ensuring fixes are upstream14:07
Son_Goku(it's one of the reasons I dislike the Debian/Ubuntu model of packaging with gbp trees)14:07
Son_Gokutoday, there's exactly ONE downstream patch that's not upstream14:08
mvoSon_Goku: +114:08
mvoSon_Goku: ping me anytime if you need something cherry-picked14:08
Son_Gokucool, thanks14:08
mvozyga: 4483 needs a second review, iirc you looked at this before so should be trivial14:08
Son_GokuGod knows, I could actually do my own source trees for packaging, but I hate that stuff14:09
Son_Gokuit's far too easy to get lazy and complacent14:09
mvoSon_Goku: plus the collaborating with upstream is usually very healthy14:09
mvo(and great for upstream because they understand the needs of the packages better etc etc)14:10
Son_GokuI think what really burned me was my experience with Debian as an upstream software developer14:10
Son_Gokuone of my software packages was effectively forked and they never bothered to talk to me14:10
Son_Gokumeanwhile I was listed as a contact point in the copyright, so I got weird questions from people using the Debian version14:10
mvoSon_Goku: uh, that sucks - may I ask what the package name was?14:11
Son_Gokulugaru / openlugaru14:11
Son_Gokuthey'd also converted the source tree from Mercurial (as it was at the time) to Git14:11
Son_Gokuwhich meant it was painful to figure out where they actually were14:11
mvoSon_Goku: uh, I see, that sounds painful14:12
Son_Gokuneedless to say, it annoyed me14:12
mvoSon_Goku: *nod*14:12
Son_Gokuwhen development of lugaru restarted, I switched to Git (as everyone else wanted it), and did significant work14:13
mvoSon_Goku: I hope it got better over time14:13
Son_Gokuunfortunately, their little weird tree meant that they spent a year arguing about how to refork the source tree into Alioth for packaging14:13
Son_GokuDebian was *the last* distribution to get the new Lugaru, and they missed the first release14:14
Son_GokuI 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 upstream14:14
Son_Gokuthe 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_Gokuit's not like I don't understand how to handle the upstream/downstream relationship14:16
Son_Gokubut that was cold :/14:16
mvoSon_Goku: :(14:16
mvoSon_Goku: sorry to hear this bad experience14:16
Son_Gokuyeah, well, I've made a point now to avoid what I call merged source trees for packaging14:16
Son_GokuI don't want to inflict that kind of mess onto someone else14:16
Son_Gokumvo: that said, it's not like I don't understand why debian is evolving towards that form of packaging14:17
Son_Gokudebian source control is designed to be integrated with source trees, always has and always will14:18
Son_Gokuit's even in the name ;)14:18
Son_Gokubut it's one of the reasons I prefer the way RPMs are packaged, because it solidifies that split14:19
mborzeckioff to pick up the kids14:19
Son_Gokumost packaging formats impose that split (RPM Spec, Arch PKGBUILD, Solus ypkg, etc.)14:19
Son_Gokuand personally, I think it's a very good thing14:19
mvoSon_Goku: right, well, there is a concept of orig.tar.gz in the deb sources as well. but yeah, its easy to fork14:27
mvozyga: 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 addressed14:28
Son_Gokumvo, which reminds me, why aren't you just using the deb sources multi-tarball thing to deal with bundling squashfuse?14:29
Son_Gokuthe go hack is kind of garbage, tbh, and I don't think it's worth risking making it a permanent part of snapd14:30
Son_Gokuit 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
zygamvo: thanks!14:31
zygamvo: looking at the earlier one as well14:32
mvoSon_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 better14:32
Son_Gokumvo: well my thought is that "snapfuse" is a workaround for an apt deficiency14:33
Son_Gokuthe proper thing to do is depend on squashfuse14:33
mvoit is14:33
Son_Gokuagain, I want to avoid the risk of "snapfuse" being a mandatory dep14:34
Son_Gokuin Fedora, I just introduced squashfuse as a dependency and we were good to go14:34
tedgcjwatson: 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-master14:45
tedgI'm not sure what could be different between the two (at all), but much less that could cause something like this.14:45
tedgOr frankly, what the error really is there.14:45
mupPR snapd#4495 opened: data/dbus: add AssumedAppArmorLabel=unconfined t <Created by mvo5> <https://github.com/snapcore/snapd/pull/4495>14:48
cjwatsontedg: maybe cleanbuild uses a slightly different sources.list by default?14:57
tedgcjwatson: 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
cjwatsonright, that's a difference in the default installed package set which is slightly different although conceivably also relevant15:03
cjwatsontedg: 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 cleanbuild15:06
tedgHmm, and kenvandine is suspiciously not here :-)15:08
mvopedronis: did you notice that master is currently failing? it looks like it cannot install test-snapd-private15:08
tedgseb128: Do you know about the gnome-3-26 backport PPA?15:08
seb128tedg, what about it?15:08
tedgseb128: 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
seb128tedg, Ken did recent uploads there, I guess it's not impossible that he screwed15:11
seb128if your issue is in the gtkmm stack15:11
seb128we didn't do recent builds afaik so I'm unsure if the ppa got tested since those uploads15:12
cjwatsonaha, reproduced, ish15:12
tedgYeah, and he added that at my request as it was needed to get Inkscape building.15:12
seb128so you blame him but it's your fault :p15:13
tedg(well, building with the new GTK)15:13
cjwatsontedg: https://paste.ubuntu.com/26398323/15:13
* cjwatson adds a few more packages to drill down15:14
pedronismvo: no15:14
mvopedronis: aha, nevermind15:14
mvopedronis: I think its just a change error message, I will fix it15:14
mvopedronis: strange that we did not see it in PRs15:15
cjwatsonso the basic problem is a conflict somewhere in that set15:15
pedronismvo: ah15:15
cjwatsonlibgdk-pixbuf2.0-dev Depends: libpng-dev15:16
mvopedronis: aha, of course, we only run this test against main, right? I think you told me a while ago15:16
tedgHmm, so perhaps I need to explicitly remove the older libpng?15:16
seb128cjwatson, tedg, Ken is back tomorrow if he needs to fix something15:16
pedronismvo: yes,  that's because of travis security rules, secrets are set only for main repo branches15:17
pedronisnot PRs15:17
cjwatsontedg: dropping libpng12-dev and adding gtk-update-icon-cache (I'm not sure why ...) seems to work at least in my reduced test case15:18
mupPR 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
mvopedronis: indeed, PR on the way15:19
tedgcjwatson: Thanks, I'll give those a try! (it'll take a while to get test builds done)15:19
elopiohey kyrofa, should I make a PR to try one of the desktop solutions so we can discuss there?15:33
mupPR 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
pstolowskihey tedg, howdy!15:35
tedgHowdy pstolowski !15:35
diddledanwhat'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 it15:36
diddledan(I modified the PythonPlugin and saved it to ./snap/plugins/foo.py)15:36
kyrofadiddledan, try naming it x-foo.py15:39
kyrofaOr maybe x_foo.py... now I can't remember :P15:39
kyrofaProbably the latter15:40
diddledandoesn't make a difference15:40
kyrofadiddledan, what name are you using in the YAML?15:40
diddledanoh, wait, that made it work, but doesn't list it in `snapcraft plugins`15:41
kyrofadiddledan, no, those are just the built-in plugins15:43
kyrofaelopio, we can chat a little in the meeting if you like15:50
Pharaoh_Atemmborzecki: new deps need to be packaged for fedora16:01
Pharaoh_Atembut for epel7, bundling is allowed16:02
Pharaoh_Atemthat's the only reason there's a bundled mode16:02
Pharaoh_Atem(in re fedora packaging)16:02
mvoPharaoh_Atem: for 2.31 we have a new boltdb dep, but this might be packaged already for fedora, its quite popular aiui16:07
pedronismvo: 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 classic16:17
pedronisthey are manual16:17
mvopedronis: let me look, they are confusing16:21
mvopedronis: 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
mvopedronis: 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 test16:25
pedronismvo: so make it classic only , and remove the bits about boot envs ?16:25
mvopedronis: that would be my suggestion16:26
mvopedronis: 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 racy16:27
mvopedronis: 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
pedroniswe do that in other places16:28
pedronisI haven't seen (yet) issues with that16:28
mvopedronis: even better, then lets ignore it16:28
mupPR 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
pedronismvo: I proposed this  ^    though spread tests need a bit more work (for example those two), also there may be different approaches/policies16:33
mvopedronis: cool, I have a look in a bit (fighting with seccomp just now)16:43
mupPR 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
pedronismvo: 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 land16:55
mvopedronis: ok, thank you16:56
mvozyga-ubuntu: hey, welcome back - does https://travis-ci.org/snapcore/snapd/builds/329513349#L1950 make any sense to you?16:57
zyga-ubuntumvo: hey16:58
zyga-ubuntumvo: sorry, some stuff at home16:58
mvozyga-ubuntu: in my strace PR there is a failure in the snap-update-ns test16:58
zyga-ubuntumvo: I'm not back for real yet16:58
zyga-ubuntumvo: great insight on your PR16:58
zyga-ubuntu(on the older one with dbus)16:58
mvozyga-ubuntu: that looks like it is happening consistently but it does not make sense to me16:58
mvozyga-ubuntu: aha, no worries16:58
mvozyga-ubuntu: well, that PR is yours really, you figured it all out :)16:58
* mvo hugs zyga-ubuntu 16:58
zyga-ubuntumvo: that strace branch is interesting17:00
mvozyga-ubuntu: the fun part is that #4473 (which contain most of it) is green17:01
mupPR #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-ubuntuthat's .... unexpected17:01
zyga-ubuntumvo: 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-ubuntumvo: and will save me exploring that (which is painful becauese iteration is annoyingly slow)17:07
zyga-ubuntumvo: I'm still trying to grok the strace bug, does it happen in interactive debug as well?17:08
mvozyga-ubuntu: I have not tried that yet17:09
mvozyga-ubuntu: we can talk about it tomorrow, its just puzzling and maybe things get clearer if my initial strace PR is merged17:09
mvo(as the diff will get smallre)17:10
zyga-ubuntumvo: ok, that sounds good to me17:10
zyga-ubuntumvo: I will be back in 15 minutes, just some constant interrupts at home now17:11
zyga-ubuntumvo: nothing in that PR screams at me 'here'17:19
zyga-ubuntumvo: unless there's a typo that makes strace go where it shouldnt17:19
zyga-ubu1ture for good17:49
=== zyga-ubu1tu is now known as zyga-bionic
pedronisdid travis change their timeout?18:12
pedronisthere's a run that is finished after 1h+18:13
pedronis*is not finished18:13
=== SergioMeneses is now known as SergioMeneses1
=== SergioMeneses1 is now known as SergioMeneses
boopyhow do you update snap and how do you recover from this?18:27
boopy> snap "ubuntu-core" has changes in progress18:27
cachioniemeyer, when you have a free slot, could you please take a look to the PR #49 for spread18:28
mupPR #49: allow (optional) snappy update $pkgname <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/49>18:28
mupPR snapd#4418 closed: tests: enabling opensuse for tests <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4418>18:40
mupPR 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_Atemmvo: it looks like we're not testing against Fedora in snapd CI18:57
Pharaoh_Atemwhat happened here?18:57
mvoPharaoh_Atem: there were a bunch of issues with the fedora repos, there is a PR to enable fedora again iirc19:13
mupPR snapcraft#1875 opened: Remove deprecated 'snap' recommendation <Created by ted-gould> <https://github.com/snapcore/snapcraft/pull/1875>19:13
Pharaoh_Atemmvo: that means I probably have idea if the deps for master are satisfiable19:13
Pharaoh_Atemhave no idea, I mean19:13
mvoPharaoh_Atem: yeah, we are unhappy about this too: https://github.com/snapcore/snapd/pull/449219:14
mupPR #4492: spread: try to enable Fedora once more <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4492>19:14
mvoPharaoh_Atem: actually, this one fails because of a new dep, there is a fix already for this19:15
mvo(in 4493)19:15
niemeyercachio: Will do19:16
cachioniemeyer, tx19:21
robert_ancellSnap packages are installed in a queue right? Does anyone know if there's a plan to be able to install in parallel?20:30
naccrobert_ancell: LP: #1585403 ?20:32
mupBug #1585403: please support parallel operation <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1585403>20:32
robert_ancellnacc, thanks!20:36
pedronisrobert_ancell:  there is no queue,  some single things are serialized20:36
naccrobert_ancell: np20:36
robert_ancellpedronis, so can a second install start before the first one is complete currently?20:37
pedronisyes,   at least  if core is already there20:37
robert_ancellpedronis, ok, thanks!20:37
pedronisif they need core they will wait on that20:37
robert_ancellI'm asking because there's a discussion in GNOME Software about parallel vs. queued installation and I'm giving the snap datapoint.20:37
pedronisas 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 parallel20:40
pedronisand most of it will proceed in parallel20:40
robert_ancelle.g. downloading?20:41
naccpedronis: does that imply the above bug should be closed?20:41
pedronisyes, except I have no idea why my colleagues didn't close it, what they were thinking20:42
pedroniswith their answers20:42
niemeyerI think it can be closed20:43
niemeyersnapd indeed operates closer to make -j than it does to apt or deb in that regard20:44
niemeyerThose really serialize all steps of the installation, while snapd goes wild and only rejects known conflicts as you pointed out pedronis20:44
niemeyermake -j also doesn't parallelize _everything_ either.. just the things it knows are independent.. so vaguely resembling snapd's behavior indeed20:46
naccpedronis: niemeyer: sounds good, thanks20:47
niemeyerIt's quite awkward to say "Fix Released" for something that was always like that.. and curious that there's no better option.20:48
niemeyernacc: np20:48
naccniemeyer: yeah, you can change the state of the bug to Invalid, if that's actually the case20:48
naccroughly like NOTABUG in bugzillas20:48
robert_ancellniemeyer, yeah, it always feels weird doing a Fix Released like that.20:49
naccniemeyer: but yeah, the states aren't quite what i expect, ever :)20:49
niemeyernacc: Invalid also feels wrong.. it's not invalid.. it's a valid feature request, and it's implemented, and always was. :)20:49
robert_ancellThe other option is invalid, but that seems a bit harsh if it was a valid request at the time.20:49
naccniemeyer: yeah, but it soudns like it was't a valid feature request then either?20:50
niemeyerYeah, it's more like "Yay!"20:50
naccdunno, it's a lose-lose :)20:50
nacca good comment and whatever terminal state you want :)20:50
niemeyernacc: 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" either20:50
naccniemeyer: yep, agreed20:51
niemeyerGitHub gets that right.. it's just Closed20:51
naccthe graph for LP doesn't match my brain often20:51
niemeyerI'd suspect it inherited from Bugzilla, but it's been such a long time that I can't even remember..20:52
niemeyerAnyway.. it's closed. :)20:52
robert_ancellIs there any online documentation on the policy for snapd updating snaps? They're always automatically updated on a schedule, right?20:55
robert_ancellAnd you can manually update them at any time.20:56
robert_ancellThis seems to be the closest I can find: https://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap-from-store/707/420:57
mupIssue 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
niemeyerrobert_ancell: Right, that's it21:11
niemeyerrobert_ancell: The default schedule right now is 4 times within the day21:11
niemeyerrobert_ancell: At random times21:12
niemeyerThat is, once every 6h window21:12
niemeyerrobert_ancell: We have improvements landing right now (just reviewed a PR on that, actually) that introduce monthly support in the scheduling21:13
robert_ancellniemeyer, nice21:13
niemeyerSo people will be able to pick a specific day within the month21:13
niemeyerThe syntax is documented in ...21:13
niemeyerand the options for core in general are documented in ...21:14
niemeyerThe latter was not yet updated with the former because it's not yet publicly available21:14
robert_ancellI 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 snapcraft21:14
niemeyerrobert_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 visible21:15
niemeyerFor example, the format is documented at21:15
robert_ancellniemeyer, that would work for me21:15
niemeyerAnd we have similar pages for each of the fundamnetal snaps (gadget, kernel, etc)21:16
niemeyerAlright, I'm going to call it a day and see if I can get some proper sleep for a change..21:20
niemeyerHave a good night all21:21
Pharaoh_Atemniemeyer, zyga-ubuntu: it seems that we might want to reprovision the Fedora 27 Linode VM from scratch: https://pagure.io/Fedora-Council/tickets/issue/9921:59
Pharaoh_Atemthat will let us add tests for SELinux stuff21:59
Pharaoh_Atemc.f.: https://pagure.io/Fedora-Council/tickets/issue/99#comment-48074221:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!