/srv/irclogs.ubuntu.com/2018/04/03/#snappy.txt

zygaCaelum: Yeah, Good idea. I will mąkę that change unless already did00:16
zygaI’m back tomorrow00:16
Caelumawesome, thank you!00:16
mwhudsonso is there any way to tell patchelf to leave certain files alone? https://launchpadlibrarian.net/363045593/buildlog_snap_ubuntu_xenial_ppc64el_go110_BUILDING.txt.gz03:59
mwhudsonthe hints in the log seem to be about how to exclude the file, which i don't really want to do03:59
mborzeckimorning05:01
mborzeckimvo: morning06:05
mvohey mborzecki ! good morning06:15
mvomborzecki: how are things? any fires?06:15
mborzeckimvo: not that i'm aware of06:15
mvomborzecki: excellent06:15
mvomborzecki: I see the list of open PRs is also relatively tame06:16
mborzeckimvo: yes, zyga was doing the 'trimming'06:16
mvomborzecki: nice!06:16
mvo4967 needs a "review" :)06:18
mvo(just changelog updates so not really much of a review906:18
mvo)06:18
zygaHey06:24
zygaI’m trying to wake up06:24
zygaSorry for being late06:25
mvozyga: good morning!06:25
zygaGood morning06:25
mvozyga: how are you? any issues that need attention?06:27
zyga Sleepy :-)06:28
zygaI think one issue needs attention.  The release, I didn’t publish the build to beta that day.06:28
mvozyga: ok, on it06:29
mvozyga: done06:30
zygaThank you06:30
zygaI noticed a new recurring test failure06:32
zyga    - google:debian-9-64:tests/main/interfaces-network fails very often, though not all the time06:32
zygaand the failure looks real06:33
zygatypical failure of the network test on debian https://www.irccloud.com/pastebin/KujuZdgP/06:33
FeelAporlLicense error in discord app showing Up! https://paste.ubuntu.com/p/yHcHWGH2z2/06:46
kalikianagood morning06:59
zygahey kalikiana06:59
zygamvo: I found an interesting bug06:59
zygasnaps cannot be refreshed concurrently with core when reexec is supported https://www.irccloud.com/pastebin/46PfLThC/07:00
zygaas snapd restarts and snapctl doesn't run07:00
mvozyga: uh, indeed07:01
zygawe could sort the refresh list so that snapd-carrier is always first07:02
zygaand make it so that core refresh blocks all the other guys07:02
zygabut not sure how since they are in lanes07:03
zygawe could perhaps make concurrentl downloads but apply them one by one07:03
zyga(so lane some part but not all of it007:03
zygabut it would be a bigger redesign07:03
mvozyga: yeah, or we ensure core is done last07:04
mvozyga: fwiw, the nvidia fix works for me (tm) on bionic - thanks mborzecki for this!07:04
mborzeckimvo: yay!07:04
zygaI chose core first because of assumes: snapdXY07:04
zygamvo: can we have a "bug" tag on the forum?07:04
mvozyga: sure, I think you can add tags yourself07:05
zygaoh, thanks, I didn't see that07:05
mvozyga: just write them and I think they appear. I'm not fully sure though, I did not use them much in the past (only for releases)07:05
zygamvo: I don't think I can do that actually07:08
zygamvo: anywy, I tried to capture this so that we don't forget: https://forum.snapcraft.io/t/musnt-refresh-core-concurrently-with-other-snaps-when-reexec-is-supported/484107:08
=== pstolowski|afk is now known as pstolowski
pstolowskimorning07:16
pstolowskido we have a fire with a configure hook?07:17
mvopstolowski: good morning! not really a fire more a bit of a wart: https://forum.snapcraft.io/t/musnt-refresh-core-concurrently-with-other-snaps-when-reexec-is-supported/4841 but we should fix it as it leaves ugly errors in the `snap changes`07:28
zygahey hey pawel07:34
mborzeckipstolowski: hey07:38
pstolowskio/07:38
zygapstolowski: I added some feedback to https://github.com/snapcore/snapd/pull/491707:39
mupPR #4917: repo: added repo ConnectionsInfo method (for the new snap connections API) <Created by stolowski> <https://github.com/snapcore/snapd/pull/4917>07:39
zygabut I think it's close to landing otherwise07:39
zygathough I think it warrants a gustavo/pedronis review07:39
pstolowskizyga: thank you, i need to revisit this07:41
zygasure07:42
zygamvo: how do you feel about https://github.com/snapcore/snapd/pull/491107:42
mupPR #4911: daemon,client: add build-id to /v2/system-info <Created by mvo5> <https://github.com/snapcore/snapd/pull/4911>07:42
zygawe can rebase it to make tests pass07:43
zygabut we could also close it07:43
zygamborzecki: I have a question about https://github.com/snapcore/snapd/pull/488007:43
mupPR #4880: [RFC] cmd, data: plain make  <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4880>07:43
zygamborzecki: can we please close it, add a makefile and switch to it gradually07:43
zygamborzecki: it'd be easier to review and I have some strong opinions about how to use plain make to its full extent07:44
mborzeckizyga: can you leave some comments on what you have in mind there?07:45
zygamborzecki: well, it's a lot of little thing07:45
zyga*things07:46
zygaI'm mainly saying it's easier to discuss this in PRs when the scope is smaller07:46
zygamborzecki: let me propose some skeletons to show what I mean07:49
zygabut I need to finish trespassing branch first07:49
zygaso in the afternoon07:49
mborzeckizyga: ok, i'll close it for now07:50
mupPR snapd#4880 closed: [RFC] cmd, data: plain make  <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/4880>07:51
* zyga is once again reaffirmed that terminus is the best font for low-dpi displays07:57
mborzeckimorphis: can you take a look at https://github.com/morphis/meta-snappy/pull/17 ?07:59
mupPR morphis/meta-snappy#17: updates: snapd 2.32.2, libseccomp 2.3.3 <Created by bboozzoo> <https://github.com/morphis/meta-snappy/pull/17>07:59
morphismborzecki: sure07:59
mborzeckimorphis: thanks08:00
zygabrb08:17
seb128mvo, hey, how are you? had a good easter w.e?08:25
mvoseb128: hey, good morning! I had a really nice weekend, thank you. how are you?08:35
seb128mvo, I'm good, thanks! I had a long relaxing w.e :) but now back to bionic crazyness :/08:36
seb128mvo, did you see https://forum.snapcraft.io/t/translation-management/4798 ? is that something you could help with ? ;)08:37
seb128mvo, basically how is snapd setup for translations? do you import the translation work from launchpad to github?08:37
mvoseb128: I have seen it but not thought about it yet. we do not currently merge the translations back but we could easily do this of course08:38
mvoseb128: and I think we have to for the benefit of the other distros08:38
seb128mvo, do you have translators on github?08:38
mvoseb128: I mean, for ubuntu langpacks are probably ok08:38
seb128right08:38
mvoseb128: not really, LP seems to be the better choice here08:38
seb128but even on ubuntu, the template was outdated on launchpad08:38
seb128Gunnar updated it manuallys08:38
seb128-s08:39
seb128so at least translators can do their job now, but it made us wonder what was the expected workflow around snapd translations08:39
mvoseb128: uh, I though we had setup auto-sync :/ I need to look into this, we certainly want the auto-imported snapd LP tree for the translations08:39
seb128k08:39
mvoseb128: tbh we just had not put enough effort into the translations and to support them, but now is a good time to fix that I think08:40
Chipacamoin moin08:40
seb128mvo, k, well let me know if I can do anything to help. I think that with the template update from Gunnar translators can do their work, you might just want to do an export/import of those in github a bit later for other distros as you said08:42
seb128mvo, and I'm going to keep an eye on what's going on with the template import, the package build generated a correct one but somehow launchpad ended up not having all the strings until Gunnar workarounded it08:42
Chipacais there an automated way to export it, so we can add it to the other distros build scrips?08:42
mvoseb128: I look into it once I finished my current task08:47
seb128mvo, thx08:47
seb128Chipaca, launchpad can auto export to a branch/vcs I think08:48
zygaChipaca: hello08:53
Chipacazyga: hiya08:53
zygamvo: hey, do you think we could seed langpacks-all into the core as an experiment?08:53
Chipacazyga: did you see #1760416?08:53
zygaChipaca: how have you been? :)08:53
mupBug #1760416: dropping privs did not work: Invalid argument <amd64> <apport-bug> <artful> <wayland-session> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1760416>08:53
zygaoh, nope08:53
Chipacazyga: very lazy :D08:53
zygabummer, that's something nasty08:54
Chipacawas tempted into looking at snapd things only twice in the last week \o/08:54
mborzeckizyga: can you do antoher pass of #494208:57
mupPR #4942: cmd/snap: user session application autostart v3 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4942>08:57
zygamborzecki: queued, now looking into the bug chipaca referenced08:57
mborzeckizyga: thanks08:58
zygaI cannot reproduce that bug on bionic09:01
zygatrying artful09:01
zygasame09:15
zygais anyone on artful that can reproduce that bug?09:16
zygajust running any snap should fail09:16
zygathat code is on an unconditional code path09:16
mborzeckizyga: any idea what's happening with fedora?09:19
zygain which sense?09:19
mborzeckizyga: i mean the go build thing09:19
zygaah09:19
zygathe one that was failing last week09:19
zygayes09:19
zygadownstream package for gopkg.in/yaml.v2 was broken09:20
zygaI added some information about this here: https://github.com/snapcore/snapd/pull/4832#issuecomment-37753945709:20
mupPR #4832: tests: move fedora 27 to google backend <Blocked> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4832>09:20
mborzeckizyga: https://src.fedoraproject.org/rpms/golang-gopkg-yaml/pull-request/1 ??09:20
zygamaybe Pharaoh_Atem can help us speed up landing and releasing this09:21
zygaas it's a terribly broken package now09:21
zyga(out in stable)09:21
kjackalHey snappy people! Is there a way to disable elf stripping?09:29
zygakjackal: hey09:29
kjackal2.40 is breaking at least one of our banaries and trying to see why09:30
kjackalbinary is kubernetes-test09:30
kjackalhi zyga (!?)09:31
zygakalikiana: ^ I think you know the answer09:31
kjackalJust to offer some context. Here is the build with snapcraft 2.40 with -d: https://pastebin.ubuntu.com/p/jTm7TBJH4B/09:34
kjackaland here is the segfault we are getting with builds from 2.39 vs 2.40 : https://pastebin.ubuntu.com/p/f4552kVxVK/09:35
mvozyga: 4967 needs a "review" :)09:39
zygaOH09:47
zygaah :)09:47
* zyga mvo: #4938 needs a review as well09:48
mupPR #4938: release-tools: add repack-debian-tarball.sh <Created by zyga> <https://github.com/snapcore/snapd/pull/4938>09:48
mupPR snapd#4967 closed: release: 2.32.2 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4967>09:48
kalikianakjackal: yes, you can disable it. By adding build-attributes: [no-patchelf] to the part09:51
zygamborzecki: there are some unanswered comments on your PR09:52
zygawell, one so far :)09:52
kjackaltrying that kalikiana, thanks09:52
zygathef first one down the line , aobut the error message09:52
zygathank you kalikiana :)09:52
kalikianasure09:53
* zyga does the review and enjoys the sunny day today :)09:55
zygafinally less clouds and more sun09:55
mvozyga: oh, ah :) will do in a little bit09:57
mvozyga: thanks for the merge09:57
kjackalkalikiana: zyga: seems to be working now. But I was wondering, why would snapcraft touch the banaries packaged? Seems like a bug to me. I guess I would better open a forum thread10:01
kalikianakjackal: Yeah, a forum post sounds sensible. If you think it's doing the wrong thing we can discuss it there.10:07
kjackalthanks10:08
=== matteo| is now known as matteo
kjackalYou definetely have your reasons I just do not know them10:09
Chipacaany other reviews i should do before going to add stuff to the error report?10:09
zygahmm hmm10:15
ogra_hmm?10:16
zygawondering why tests on my branch failed10:17
zygait was supposed to work, just a re-factor10:17
zygabut let me finish one review before jumping back into my branches10:17
zygahey ogra_, how have you been btw?10:17
ogra_busy implementing workarounds for customers ;)10:18
Chipacaogra_: hehe10:18
Chipacaogra_: phrasing there makes it sound like you're working around customers =)10:18
ogra_heh, well ...10:19
Chipacala la la la can't hear you10:20
Chipacazyga: wasn't snap-confine always in core?10:21
ogra_not in the early days (IIRC it was also called differetly in the begining)10:23
ogra_*differently10:23
zygaChipaca: yes, that's a good point10:26
zygaChipaca: but the one in core is correct and I have no idea how this could happen there10:26
Chipacazyga: MAGIC10:28
pedronisChipaca: hi, #4900 needs reviews10:30
mupPR #4900: many: use the new install/refresh API by switching snapstate to use store.SnapAction <Critical> <Squash-merge> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4900>10:30
Chipacapedronis: hi10:30
Chipacapedronis: ack, on it in a bit10:30
pedronisit's big, the big parts are the test changes10:30
zygahey pedronis, power is back?10:31
pedronisyes10:31
pedronisI noticed the problems with interfaces-network on debian10:32
zygaI haven't debugged that yet10:32
zygait's certainly random but also worrysome (related to security) and pretty frequent now10:33
zygaI suspect it is related to system key somehow10:33
mvozyga: oh? how?10:37
zygamvo: nothing changed in that area for a while and we introduced system key recently, I don't know what else could cause this10:37
zygamvo: but it's just a guess, it needs to be debugged10:38
mupPR snapd#4968 opened: RFC: ifacemgr: remove stale connections on startup <Created by stolowski> <https://github.com/snapcore/snapd/pull/4968>10:40
pstolowskizyga: hey, thoughts on https://github.com/snapcore/snapd/pull/4968 ? some tests will need updating but before that I'd like to get +1/-1 on the approach10:40
mupPR #4968: RFC: ifacemgr: remove stale connections on startup <Created by stolowski> <https://github.com/snapcore/snapd/pull/4968>10:40
zygalooking10:40
mvozyga: isn't debian itself changing?10:42
zygamvo: debian 9 is not changing much10:42
zygathis was on stretch, not sid10:43
mvozyga: hm, hm, ok10:43
pstolowskizyga: thanks for the quick review; apart from that minor detail re logging, do you see any big no-no?11:01
cjwatson~/wg 4011:04
cjwatsonsorry11:04
zygapstolowski: no, it's fine I think11:19
zygapstolowski: sorry, I will be back with reviews in a moment11:19
zygasome interruptions IRL11:19
pstolowskinp, ty!11:20
diddledansnapcraft isn't working :-( (paste follows)11:39
diddledanhttps://www.irccloud.com/pastebin/dOwZkaZC/11:39
diddledanwas fine when I went to bed last night11:39
zyga4327 is the core snap in candidate now11:39
diddledanmaybe related:11:40
diddledanhttps://www.irccloud.com/pastebin/Us8ymABs/11:40
zygahmm, no idea though11:40
zygakalikiana: more fire ^11:40
zygaah, I found a typo in my PR11:44
zygafixed locally, should make it green now11:44
zygabut I need to make that more robust, one sec...11:44
* Chipaca -> lunch11:47
zygasigh11:48
zygais there any gnome extension that makes alt-tab less moronic11:48
zygaI have two virtual screens,11:48
zygatwo terminals open, one on each11:48
zygaeach screen also has one other unrelated window (browser and editor)11:49
zyga(again, each)11:49
zygaalt-tab from unrelated window should not jump to the terminal on another virtual screen11:49
zygaman, I hate how gnome gets most things right and consistently breaks something very very commonly used11:49
zygaand https://extensions.gnome.org/ says there is no "native connector", whatever that means11:51
tomwardillzyga: I use https://extensions.gnome.org/extension/15/alternatetab/ and you’ll need to install the extension for your browser to install gnome-extensions from that site11:53
zygaI have that installed (apparently)11:53
zygathe extension for firefox that is11:54
mborzeckiany idea for which snap we dump a dbus policy file in /etc/dbus-1/system.d?11:54
zygamborzecki: mmm11:54
zygalet me look11:54
mborzeckii've tried some of the test-snapd-* ones but no luck so far11:54
zygamborzecki: anything that uses dbus backend would11:55
mborzeckizyga: hmm test-snapd-dbus-{consumer,provider} did not (at least on arch)11:55
zygamborzecki: oh, that's very weird11:55
zygalet me try quickly11:55
zygahmm11:58
zyga`func (iface *dbusInterface) getAttribs(attribs interfaces.Attrer) (string, string, error) {`11:58
zyganeed to name the return values11:58
mborzeckiheh :)11:58
mborzeckiprobably, (ok, ok, not-so-ok)11:58
zygamborzecki: so dbus services need a policy only if they are on the system bus11:59
zygaand the snaps you mentioned use the session bus12:00
zygaso you'd have to find one that uses bus: system12:00
* zyga found one more bug the refactoring has introduced12:04
mupBug #1760841 opened: snapd does not parse /etc/fstab properly when using mhddfs <Snappy:New> <https://launchpad.net/bugs/1760841>12:04
zygamore interesting than just a bug12:04
zygaoh12:04
zygainteresting bugs galore12:04
=== pstolowski is now known as pstolowski|lunch
Chipacamhdwtfs?12:10
ogra_a new filesystem !12:11
zygawtffs12:12
zygaoh12:12
zygathat's frelling interesting12:12
zygahttps://romanrm.net/mhddfs12:12
zygalooks like another overlayfs?12:12
diddledanyaffs = yet another ferking file system?12:12
diddledanwas yaffs invented by SuSE? :-p12:13
zygamtfs: me too file system ;)12:13
diddledanlol12:13
zygaanyway, I need to fix this bug12:13
ogra_not overlay ... but union12:13
diddledanhtfs - hashtag filesystem12:13
zygayeah, overlay can do unions today12:13
ogra_indeed12:13
zygaeverything-in-a-box filesystem12:13
ogra_but that just looks like another unionfs-fuse stepchild12:14
diddledanwe missed April the 1st to launch our new bhfs - black hole file system. it's effectively >/dev/null12:14
zygadiddledan: lol, indeed12:14
zygaogra_: wait for our own snapdfs12:14
zygait's really coming12:14
ogra_oh my12:14
zyga(not april 1st)12:15
ogra_as if we had not more pressing issues to fix :P12:15
zygait will help a lot12:16
ogra_well, not with the issues we're facig at customers :) but yeah12:17
zygaogra_: hey, we released the fix for /dev/ttymcsN12:17
ogra_yeah, saw that12:18
ogra_is that already ib stable ?12:18
ogra_*in12:18
zygaogra_: no, needs to go through testing12:18
ogra_yeah, thats what i thought12:19
zygashould be out soonish though12:19
ogra_yep12:19
zygamvo: we need to fix https://bugs.launchpad.net/snappy/+bug/1760841 for .312:20
mupBug #1760841: snapd does not parse /etc/fstab properly when using mhddfs <Snappy:In Progress by zyga> <https://launchpad.net/bugs/1760841>12:20
zygamvo: this prevents snapd from starting :/12:21
zygamvo: the bug here is that when we cannot parse fstab we cannot start up12:21
zygaI didn't expect that12:21
zygaogra_: I'm sure some of the issues faced by our customers will be addressed with layouts and the snapdfs idea will make that easier to work with, we could essentially allow merging content in arbitrary ways (finally)12:24
zygathis would eliminate almost all reasons to patch or alter software with configuration12:24
pedronisChipaca: thx for the review12:25
ogra_zyga, well, main issues atm are autoconnecting interfaces on first boot, and disabling of console-conf (which michael seems to be tackling atm)12:25
ogra_also an option to disable the assertion auto-importer ... gadget updates ...12:26
zygaogra_: one of those, the auto-importer, why is that an issue12:26
ogra_zyga, some customers want a 100% locked down device12:26
zygaaha, I see12:27
zygaso not performance related12:27
ogra_with no way to insert anything, not even a valid assertion12:27
zygawell, only they can issue assertions :)12:27
ogra_well, also performance12:27
mvozyga: looking at the bug now12:27
zygathank you mvo12:27
zygaogra_: how is that performance critical?12:28
ogra_zyga, thats not the highest prio though ... autoconnecting is most important (saves one of the build.sh script hacks) atm12:28
zygaogra_: I think that was the missing bit that we didn't understand when that PR was closed12:28
zygayeah, the auto-connect is something I totally agree iwth12:29
zyga*wtih12:29
zyga*with :)12:29
mvozyga: do you think I could push my suggestion for 4930?12:29
zygalooking12:29
mvoogra_: iirc auto-connect from the gadget is something that pedronis will work on next12:29
zygayeah, go for it, great idea12:29
mvozyga: cool, thank you. but 176... first, looks more important12:30
ogra_zyga, it mounts all attached devices on every boot (and also falsely mounts XrpmbX and XbootX partitions (and fails since they are not mountabe ... but that causes a systemd timeout counter)12:30
ogra_)12:30
ogra_zyga, but it isnt the super imortant thing anyway12:30
zygaogra_: is this attached to the bug report? this is relevant12:30
ogra_as i said ... console-conf and auto-connect are high prio ... but seems they are properly on the TODO12:31
zygamvo: it basically is this:12:31
zyga Apr 03 13:43:33 asd snapd[4016802]: 2018/04/03 13:43:33.378103 helpers.go:115: error trying to compare the snap system key: cannot parse /etc/fstab: expected between 3 and 6 fields, found 112:31
zygawhen this happens we mustn't die12:31
ogra_zyga, i think i added it to the original description12:31
zygathanks!12:31
pedronismvo: yes,  need G-ustavo back to discuss syntax, but yes is next on my list after being done with 2.32.x stuff12:31
ogra_zyga, it is the "#" (your fstab issue)12:31
zygaoh?12:32
zygahmmm but don't we ignore those?12:32
* zyga looks12:32
ogra_how silly can you be to require a # sign in your fs line12:32
zygaah12:32
zygayes12:32
zygaman, is that how this operates12:32
zygafoo# /some/other/shit?\12:32
ogra_i think no space12:32
zygathank you ogra, I totally missed that12:32
ogra_foo#/some/other/shit12:32
mvozyga: hm, I think I know what is going on12:33
mvozyga: with the statup issue12:33
zygaI see12:33
zygamvo: thank you12:33
zygamvo: if you focus on this I will fix the parser12:33
zygaogra_: this is interesting (from man fstab):               mount(8) and umount(8) support filesystem subtypes.  The subtype12:33
zyga              is defined by '.subtype' suffix.  For example 'fuse.sshfs'. It's12:33
zyga              recommended  to  use subtype notation rather than add any prefix12:33
zyga              to the first fstab field  (for  example  'sshfs#example.com'  is12:33
zyga              deprecated).12:33
ogra_aha12:34
ogra_well, there you go .. deprecated12:34
ogra_(though i'm surprised this was ever valid)12:34
zygaespecially since the suffix is ... empty12:34
zygathis is going to be fun for parsing12:34
ogra_ŷeah12:34
zygaogra_: that field is out of spec but I guess reality trumps specs12:35
zygaand trump trumps reality12:36
zygaand reality will trump trump eventually12:36
zyga:-)12:36
zygabrb, tea time12:36
ogra_hopefully ...12:36
mupPR snapd#4969 opened: interfaces: make system-key more robust against invalid fstab entries <Created by mvo5> <https://github.com/snapcore/snapd/pull/4969>12:42
=== pstolowski|lunch is now known as pstolowski
vidal72[m]it would be nice to have snapd in debian stable backports https://backports.debian.org/ , I'm little afraid of using it from normal repos12:46
vidal72[m]flatpak is there already12:46
zygavidal72[m]: on debian we benefit from reexec12:51
ogra_vidal72[m], snapd should re-exec itself to the binary from the core snap if this is newer so you should automatically always get the latest12:51
zygavidal72[m]: but yeah, no disagreement12:51
ogra_vidal72[m], "snap version" will tell you12:51
zygaand some things cannot be fixed with reexec12:51
ogra_zyga, huh ? you mean it wont bring us world peas ?12:52
cwayneThat's a lot of peas12:53
ogra_not *that* many https://imgur.com/gallery/MQWyj12:53
vidal72[m]zyga ,ogra_ : thx, I may try it12:53
cwayneogra_: nice12:56
ogra_:)12:56
kalikianadiddledan: zyga: I just saw this before reading this. The `lxc push` seems to be failing consistently as if cleanbuild's source tarball didn't exist... I'm investigating what's going on there.13:02
zygakalikiana: thank you13:03
diddledan\o/13:03
mvocachio: (for later) is it possible to run the sru validation against https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+sourcepub/8895866/+listing-archive-extra ? (2.32.2 from the ppa:snappy-dev/image) ? it would be great to know if the issues we saw with the sru validateion for 2.31 is now fixed13:18
zygamvo: the converstaion is spread among two PRs: https://github.com/snapcore/snapd/pull/4868 and https://github.com/snapcore/snapd/pull/495713:23
mupPR #4868: cmd/snap-update-ns: add secure bind mount implementation for use with user mounts <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4868>13:23
mupPR #4957: cmd/snap-update-ns: remove the need for stash directory in secure bind mount implementation <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4957>13:23
zygamvo: the tofu-meat is in this comment: https://github.com/snapcore/snapd/pull/4957#pullrequestreview-10813106313:35
mupPR #4957: cmd/snap-update-ns: remove the need for stash directory in secure bind mount implementation <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4957>13:35
kalikianadiddledan: zyga FYI reported it here after narrowing it down a bit https://github.com/lxc/lxd/issues/439413:53
mvozyga: thank you13:54
mvocachio: let me know if it is possible to run the sru vadlidation (or even just the subset that failed in 2.31) against the 2.32.2 ppa deb, if that is possible and the results are green I will do the sru based on 2.32.2 today13:54
* kalikiana now lunch13:55
* zyga -> walk13:57
zygakalikiana: thank you, will read soon13:57
pedronismvo: #4900 is the new API switch PR14:02
mupPR #4900: many: use the new install/refresh API by switching snapstate to use store.SnapAction <Critical> <Squash-merge> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4900>14:02
oSoMoNjdstrand, hey, would you mind commenting on https://bugzilla.mozilla.org/show_bug.cgi?id=1449594#c9 ?14:26
mvozyga: hey, whats the latest on user-mounts? I am asked in a HO about this right now14:33
mupPR snapd#4970 opened: Add SocketUser and SocketGroup options <Created by guilhem> <https://github.com/snapcore/snapd/pull/4970>14:36
jdstrandoSoMoN: there are no current plans to mount /tmp/.X11-unix into the snap's mount namespace since X is typically accessed via an abstract socket. I guess the request is "since we are special and use 'allow-sandbox: true' and can unshare() the network namespace, we break because now we don't have access to the abstract socket and .X11-unix isn't in /tmp either"14:42
cachiomvo, sure, I'll run that14:43
jdstrandoSoMoN: the simple answer is "don't do that and you get the abstract socket". I'm not sure what the network namesapce is giving them over apparmor mediation, but maybe they are concerned about devmode classic distro14:44
jdstrandoSoMoN: this requires a forum topic. it isn't a trivial request14:44
mvocachio: great, please keep me updated!14:46
oSoMoNjdstrand, ack, that makes sense. it looks like they have a solution (not unsharing) even when /tmp/.X11-unix is not mounted in the snap's namespace, so that's alright. Can you just comment on the bug to state that there are no current plans to mount /tmp/.X11-unix, or shall I do it?14:51
alexlarssonRelying on abstract sockets is kinda ass14:52
jdstrandoSoMoN: well, just cause there aren't current plans doesn't mean there couldn't be14:52
alexlarssonI'm recommending everyone to stop listening to them, because they are not properly sandboxed14:52
jdstrandapparmor has mediation for abstract sockets with an out of tree patch (eg, Ubuntu, its derivatives and Solus have it). we are in the process of upstreaming that14:53
alexlarssonSure, but not everyone uses apparmor14:53
jdstrandsure, hence the 'devmode classic distro'14:54
alexlarssonabstract namespaces predate /run and are really made deprecated by it14:54
alexlarssonsince that is also auto-cleaned up, and additionally allows per socket access rights14:54
alexlarssonAnd is properly namespaceable14:55
* zyga is back14:58
zygahey alexlarsson, I'm very happy to see you here14:59
* zyga is happy to see green tests on #4889 15:23
mupPR #4889: cmd/snap-update-ns: don't trespass on host filesystem <Created by zyga> <https://github.com/snapcore/snapd/pull/4889>15:23
zygabut it needs some more love before I'm happy with it15:24
zygamvo: about https://github.com/snapcore/snapd/pull/4969/files15:24
mupPR #4969: interfaces: make system-key more robust against invalid fstab entries <Created by mvo5> <https://github.com/snapcore/snapd/pull/4969>15:24
zygaI think we should return the error but log it at the caller15:25
zygaas otherwise we neuter the whole error value15:25
zygaah, wait, actuall15:25
zygaactually, hmmm15:25
* zyga thinks15:25
diddledanis there any way to use snapcraft until lxd 3.1 comes along without uninstalling the lxd snap to clear it's configuration??15:28
diddledanI can't rollback because: error: The database schema is more recent than LXD's schema.15:28
zygadiddledan: doesn't lxd use $SNAP_DATA for the database location?15:29
diddledanyes15:29
diddledanit looks like the 2.0/* channels don't have the 2.21 release which is what I was running previous to the refresh15:31
diddledanactually using `snap revert` to get to 2.21 now tells me: error: Error creating database: schema version '37' is more recent than expected '36'15:32
diddledanI think whoever is in charge of lxd has made a mess15:32
nacc_stgraber: --^ :)15:32
diddledan:-p15:33
=== nacc_ is now known as nacc
diddledanshouldn't the database be backed-up by snapd so that reverts actually revert the database, too??15:35
cachiomvo, the errors we used to see on sru are not happening with15:35
cachio2.32.215:35
diddledanit looks to be being stored in $SNAP_COMMON15:35
cachiomvo, there are some problems to run on 17.10 which I have to fix15:36
stgraberdiddledan: snapcraft will be fixed in the next hour or so15:40
stgraberdiddledan: LXD can't be downgraded, we used to revert the database but then the rest of the data couldn't be read, so now we just don't allow it ever15:41
diddledanhmm15:41
diddledanok15:41
* diddledan twiddly diddly15:41
mvocachio: yay, thats encouraging that most of the errors are fixed. can you pastebin the 17.10 errors?15:43
cachiomvo, cannot find the linux-image-extra-4.10.0-20-generic15:43
mvocachio: i.e. I assume we need a 2.32.3 with the sru fixes?15:43
mvocachio: oh, heh :)15:43
mvocachio: thanks for finding this, do we hardcode this path?15:44
mvocachio: eh, package name15:44
cachioyes15:44
cachioI'll push a fix15:44
cachiomvo,  but it is a test problem15:45
cachioso I can patch that locally and run the tests15:45
mvocachio: thank you! once the fix is up I will prepare/sru 2.32.315:45
cachiook15:46
zygamvo: what's the timeline for 2.32.315:49
zygaI can prepare the 2nd part of the fix soon, just driving home now15:49
vidal72[m]jdstrand: I would prefer snap doesn't use abstract x socket https://forum.snapcraft.io/t/xorg-abstract-socket-is-mandatory-for-running-snaps/458015:52
jdstrandoSoMoN (cc vidal72[m]): I didn't answer your question because it is a matter of priority as opposed to me saying 'yes' or 'no' (tbh, I wouldn't probably be the one to implement it, but I would review it). this is why I suggested a forum topic. perhaps add to vidal72[m]'s16:04
oSoMoNack16:05
mupPR snapd#4971 opened: errtracker: add more fields to aid debugging <Created by chipaca> <https://github.com/snapcore/snapd/pull/4971>16:08
jdstrandoSoMoN: we aren't avoiding the named socket for security reasons. we just haven't needed it since the abstract is there16:08
Chipacajibel: ^^ fwiw (but i assume you're getting pinged via github and the forum on this already =)16:08
mvopstolowski: you have some feedback in 4940, looks reaonable to me, I wonder if we need gustavo for this or if we can just go ahead16:08
pstolowskimvo: thanks for you review! i'd like Gustavo's opinion on the overall approach, afaict he hasn't really evaluated the approach I described in the forum post16:12
mvopstolowski: ok16:12
mupPR snapd#4911 closed: daemon,client: add build-id to /v2/system-info <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4911>16:15
mvopedronis: I'm halfway through 4900, looks good so far and the non-test code is less than I expected it to be16:15
=== pstolowski is now known as pstolowski|afk
zygamvo: you now have a review on https://github.com/snapcore/snapd/pull/496916:20
mupPR #4969: interfaces: make system-key more robust against invalid fstab entries <Created by mvo5> <https://github.com/snapcore/snapd/pull/4969>16:20
zygajdstrand: hey,  have you seen https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/176041616:22
mupBug #1760416: dropping privs did not work: Invalid argument <amd64> <apport-bug> <artful> <wayland-session> <snapd (Ubuntu):New for zyga> <https://launchpad.net/bugs/1760416>16:22
zygaI'm very puzzled why that could ever fail16:22
cachiomvo, are you pushing 2.32.3 to beta too?16:27
zygamvo: is 2.32.3 already done?16:29
mupPR snapcraft#2046 opened: lxd: specify arch in lxc image list command <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/2046>16:29
zygaI haven't fixed the fstab parser error (though your fix is sufficient, though not merged either)16:29
* kalikiana wrapping up for today16:31
kenvandinealexlarsson, it was great to see the snap support PR for xdg-desktop-portals merged today16:33
jdstrandzyga: give me a minute, it seems I got the lxd 3.0 snap and things are broken16:33
jdstrandthat's weird. 'snap interfaces lxd' shows nothing16:35
zygaOh16:35
zygaSnap was not mounted or onterface was inwalidów?16:36
zygaInvalid16:36
zygaBut sure, no rush16:36
jdstrandthe snap doesn't show as broken this time16:36
jdstrandI have 16-2.32.216:37
jdstrandI stopped and started snapd and it seems to be back16:38
jdstrandthen I needed to disconnect/connect16:39
jdstrandweird16:39
zygajdstrand: weird16:51
zygajdstrand: are you on bionic?16:51
jdstrandzyga: the seteuid or setegid calls could fail for a number of reasons (see man seteuid)16:54
jdstrandzyga: I am16:54
jdstrandzyga: I responded to the bug16:55
* zyga breaks because kids are getting crazy16:58
mvozyga, cachio no 2.32.3 yet, we need the fstab fix and the sru fix in there at least17:15
zygawhat's the sru fix, the golang 1.6 thing?17:15
zygaI'm almost home, I will resume work on the fstab fix shortly, i have most of it done but I need to add some tests and see if I broke anything by changing things17:15
mvozyga: the sru validation fails on 17.10 because of a hardcoded linux-image package name (with an abi) apparently17:15
zygaah17:16
zygauch17:16
cachiook, is the sru for 2.32.2 ready?17:21
cachiotests for sru worked17:21
cachiojust some known issues17:21
mvocachio: almost ready, I think we need 4969 and then its a go (fixes a regression in 2.32.2)17:23
stgraberdiddledan: should be good now17:23
diddledanyey17:24
diddledandanke17:24
* diddledan pushes the button17:25
cwaynemvo: so should we be expecting another beta?17:25
diddledanyup everything good17:25
mvocwayne: yeah, we have one (corner case) regression we need to fix17:26
cwaynemvo: ack, will keep an eye out17:26
mvocwayne: thank you17:27
cwayneno problemo17:28
mupPR snapcraft#1997 closed: lxd: merge existing image info contents <Created by kalikiana> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1997>17:36
mupPR snapcraft#2038 closed: Add an option for setting npm flags option <Created by guilhem> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2038>17:36
=== jkridner_ is now known as jkridner
mvozyga: I updated 4969 based on your suggestion18:15
=== souther_ is now known as souther
* zyga looks18:49
zyga#4969 needs a 2nd review18:52
mupPR #4969: interfaces: make system-key more robust against invalid fstab entries <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4969>18:52
* cachio afk19:04
popeyWhen is 2.32 going to be in stable?21:29
mupPR snapcraft#2047 opened: pluginhandler: organize in build instead of stage <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2047>21:31
=== nacc_ is now known as nacc
=== devil is now known as Guest20669
mupPR snapcraft#2043 closed: cli: support exporting login to stdout <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2043>23:59

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