tedgcjwatson: sergiusens: Okay, so it seems the root difference is in ordering of the parts. For whatever reason on the builders the remote parts run first, while in my cleanbuild they run last. I copied the remote part and hardcoded its order, and things seem good now.00:53
tedgFWIW, only having single direction ordering made me have to copy. Where if I could have put a "before" in I could have achieved the result without the copy.00:54
tedgProbably not worth the work to add to snapcraft.00:54
cjwatsontedg: Glad you got it sorted out01:37
tedgcjwatson: thanks for the help, I was sure stuck!01:39
mupPR snapcraft#1877 opened: tests: move test files out of the snapcraft dir <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1877>04:32
sergiusenstedg so strange as we load everything into an OrderedDict (I haven't read through the full thread)04:57
mupBug #1638537 changed: snapd eats 100% CPU for about 5 minutes on first boot causing a load of >2.0 <snapd:Triaged> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1638537>07:21
mupBug #1611638 changed: snap upgrade hook <snapd:Fix Committed> <snapd (Ubuntu):Fix Committed> <https://launchpad.net/bugs/1611638>07:24
mupBug #1637325 changed: snapd provides no way to register a new account <snapd:Triaged> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1637325>07:30
zyga-ubuntumborzecki: some snow :)07:33
mborzeckizyga-ubuntu: mvo: morning07:33
mborzeckizyga-ubuntu: yeah, though it'll probably be gone in a matter of days07:34
mborzeckidamn i hope it will be gone07:34
mborzeckiotoh, at least driving a car if fun again :)07:35
mvomborzecki: good morning! and good morning to zyga-ubuntu07:36
mupPR snapd#4498 opened: debian/tests: add missing autopkgtest test dependencies for debian <Created by mvo5> <https://github.com/snapcore/snapd/pull/4498>07:38
zyga-ubuntugood morning mvo :)07:40
=== cpaelzer_ is now known as cpaelzer
mupBug #1673539 changed: snapd doesn't clean up imported (snap) assertions <snapd:Triaged> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1673539>07:42
mupPR snapd#4499 opened: packaging/14.04: move linux-generic-lts-xenial to recommends <Created by mvo5> <https://github.com/snapcore/snapd/pull/4499>07:45
zyga-ubuntumborzecki: can you please do a 2nd review on 449507:59
zyga-ubuntuI provided some context that should make it easier07:59
zyga-ubuntujdstrand: good morning08:05
zyga-ubuntujdstrand: can you please have a loot at 4495 as well, it's based on your suggestion08:05
mborzeckipstolowski: hey08:08
mupPR snapd#4493 closed: image: port ini handling to goconfigparser <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4493>08:09
zyga-ubuntumborzecki: 4492 can be rebased now, it should land ok08:10
mborzeckidoing that right now08:11
mborzeckiand pushed08:11
zyga-ubuntuthanks, I'm mid rebase myself so didn't want to do that08:13
mvoquick brainstorm: what would be a better sentence for "No snaps to auto-refresh found" apparently someone reads this as "my snaps cannot be auto-refreshed". but we want something like convey: "No new snap revisions to auto-refresh to found" - any ideas about a good sentence for this?08:16
zyga-ubuntumvo: "all snaps are up-to-date"08:16
zyga-ubuntumvo: "snap foo is already up-to-date"08:16
zyga-ubuntumvo: "snaps foo, bar and froz are already up-to-date"08:16
mvozyga-ubuntu: "auto-refresh: all snaps are up-to-date" ?08:17
zyga-ubuntumvo: sounds good08:17
mborzeckimvo: +108:17
zyga-ubuntuif you need the prefix for some reason, I think it's hard to misunderstand that "all up to date" message08:17
mvomborzecki: if you run "snap version" on arch, do you get correct output?08:17
mvozyga-ubuntu: its in the logs, this is why I think the prefix is since, to give context to the log message08:18
mborzeckisnap    2.30.r545.g0d212818e-108:18
mborzeckisnapd   2.30.r545.g0d212818e-108:18
mborzeckiseries  1608:18
mvomborzecki: ta08:18
mborzeckikernel  4.14.13-1-ARCH08:18
mborzeckisnap    2.30.r545.g0d212818e-108:18
mborzeckisnapd   2.30.r545.g0d212818e-108:18
mborzeckiseries  1608:18
zyga-ubuntumvo: ah, I ee08:18
mborzeckikernel  4.14.13-1-ARCH08:18
mborzeckisnap    2.30.r545.g0d212818e-108:18
mborzeckisnapd   2.30.r545.g0d212818e-108:18
mborzeckiseries  1608:18
mborzeckikernel  4.14.13-1-ARCH08:18
mborzeckisnap    2.30.r545.g0d212818e-108:18
mborzeckisnapd   2.30.r545.g0d212818e-108:18
mborzeckiseries  1608:18
mborzeckikernel  4.14.13-1-ARCH08:18
mborzeckiglowing bear :/08:18
zyga-ubuntuuff :)08:18
zyga-ubuntu"once more with feeling"08:19
mupPR snapd#4500 opened: snapstate: make no autorefresh message clearer <Created by mvo5> <https://github.com/snapcore/snapd/pull/4500>08:20
kalikianagood(?) morning08:21
zyga-ubuntukalikiana: hey, are you saying that good may be NULL?08:22
zyga-ubuntukalikiana: it's snowing heavily here :)08:22
* kalikiana still deciding if fit for work08:22
kalikianaHeh, yeah, good might be undefined08:23
zyga-ubuntuoh, digitalocean has updated their prices, there are much better droplet configurations for the same price available!08:24
* zyga-ubuntu looks at wind blowing heavy snowfall08:26
zyga-ubuntuhey spineau08:30
zyga-ubuntuhow are you doing? long time no see :)08:30
spineauhi zyga-ubuntu08:31
spineauvery well, thx08:31
spineauzyga-ubuntu: and you, are you missing Spain those days ;) ?08:32
mborzeckizyga-ubuntu: DO adjusting their prices after meltdown/spectre?08:34
zyga-ubuntuspineau: some of us here are :-)08:39
zyga-ubuntuspineau: my daugther prefers Poland, my son prefers Spain08:39
zyga-ubuntuspineau: I miss the constant sunshine and good mood08:40
zyga-ubuntumborzecki: they give x2 more for the same price08:40
zyga-ubuntumborzecki: and some new features too, like spaces (kind of like volumes but not really), super cheap08:40
spineauzyga-ubuntu: sun helps, I miss it too since my recent move to French east border. I'm now very close to Switzerland08:41
spineauit's a drastic weather change, especially in January08:42
zyga-ubuntuspineau: oh, that's harsh, why did you move?08:42
spineauzyga-ubuntu: my wife's new job08:42
zyga-ubuntuspineau: I see, well08:42
zyga-ubuntudo you see any mountains or hills? :)08:42
spineaulittle hills :)08:42
zyga-ubuntuthat's one of the things I miss as well, Poland is too flat for my taste08:42
zyga-ubuntuin Spain we could drive for 30 minutes and be at the base of serious mountains :)08:43
spineauSpain rocks, definitely08:43
zyga-ubuntuor go north for a little longer and have all the mountains and snow we'd ever need08:43
zyga-ubuntumaybe for holidays :)08:43
spineauhehe, it was good to hear some news from you.08:44
zyga-ubuntusame :)08:44
mupPR snapd#4501 opened: configcore: ensure config.txt has a final newline <Created by mvo5> <https://github.com/snapcore/snapd/pull/4501>09:06
mvozyga-ubuntu: do we need a jamie review for 4329?09:09
zyga-ubuntumvo: I think so09:09
zyga-ubuntuwe need a formal one09:09
zyga-ubuntuhe looked at it before09:09
zyga-ubuntubut I'd rather wait09:09
mvozyga-ubuntu: ok09:10
mborzeckimvo: trying out the strace build and have some trouble  with it, --strace no longer works09:13
mborzeckimvo: looks like the actual strace output was filtered out too09:15
sergiusenskalikiana hey, feeling better today?09:16
mvomborzecki: uh, the first of the strace PRs?09:16
kalikianahey sergiusens09:17
mborzeckimvo: #449109:17
mupPR #4491: snap: allow options for --strace, e.g. `snap run --strace="-tt"` <Created by mvo5> <https://github.com/snapcore/snapd/pull/4491>09:17
mborzeckimvo: looks like the 2nd strace loop filters everything out09:17
kalikianasergiusens: Yeah, better so far09:18
mvomborzecki: can you please apply https://paste.ubuntu.com/26403283/09:18
mvomborzecki: and pastebin the output?09:18
mvomborzecki: did you add any specific option?09:18
mborzeckimvo: i have this diff http://paste.ubuntu.com/26403285/ and the log http://paste.ubuntu.com/26403287/09:18
* mvo looks09:19
mvomborzecki: do you use /snap on your distro as prefix?09:20
mvomborzecki: still filtering 2: "[pid  6906] execve(\"/snap/hello-world/27/bin/echo\", [\"/snap/hello-world/27/bin/echo\"], 0xc8200b4a00 /* 73 vars */ <unfinished ...>\n" is the line I see - but *maybe* thats the issue09:20
mvomborzecki: i.e. that inside the snap env it is always /snap not dirs.SnapMountDir09:21
zyga-ubuntumvo: inside the env it's always /snap09:21
zyga-ubuntumvo: *except for classic09:21
zyga-ubuntuon any distro09:21
mvomborzecki: you found a bug09:21
mborzeckiyeah, looks like it ;)09:21
mvomborzecki: haha, the opposite, you should be proud!09:22
mvomborzecki: fixing, thank you!09:22
mborzeckimvo: yw09:22
zyga-ubuntuthereare 4 CVEs on irssi09:35
mvomborzecki: could you please "git pull; git checkout naive-strace" and see if the last commit fixes the issue?09:36
mvomborzecki: ups, sorry, of course git fetch mvo5 etc09:38
mborzeckimvo: works now09:44
mborzeckimvo: and classic works too09:47
mupIssue snapcraft#1876 closed: Cleanbuild doesn't work with SSH based Git repos <Created by ted-gould> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/issue/1876>09:51
jdstrandzyga-ubuntu: re 4495> added09:59
zyga-ubuntujdstrand: thank you!10:00
jdstrandzyga-ubuntu: btw, I was looking at an unsupported distro for something unrelated and snapd is running. I installed a snap and was able to run hello-world on first invocation10:00
zyga-ubuntujdstrand: nice :-)10:00
jdstrandzyga-ubuntu: but on second invocation, the mnt file in /run/snapd/ns is empty10:01
zyga-ubuntuit got unmounted?10:01
jdstrandzyga-ubuntu: so the machinery tries to move into that namespace but fails10:01
jdstrandI don't know yet10:01
jdstrandmy question is if this rings any bells on where to look. it is a 4.9 kernel if that helps10:02
jdstrandzyga-ubuntu: snap-discard-ns resolves the issue (of course)10:02
zyga-ubuntujdstrand: what was the exact error message?10:02
mvomborzecki: yay, thanks for double checking10:02
zyga-ubuntujdstrand: there are several places where we want to jump into a namespace10:02
zyga-ubuntujdstrand: and they should all handle this well10:03
zyga-ubuntujdstrand: it doesn't ring any bells on first thought yet10:03
jdstrandzyga-ubuntu: unfortunately, I didn't write it down and it isn't at hand. I'll see if I can get more detail10:03
zyga-ubuntujdstrand: if you give me the distro I can look10:04
jdstrandzyga-ubuntu: I don't really want to distract you, but it sorta sounded familiar to some old issues, but they've been long resolved so nothing came to mind otoh either10:04
zyga-ubuntujdstrand: so, on 1st try it just constructs10:06
zyga-ubuntujdstrand: on 2nd try it will inspect it (even if the outcome is unused today)10:06
jdstrandthere was enough info that 'file' showed it was empty, which I thought was odd. but now looking at my 17.10 system, file shows them as empty, so file probably isn't dtrt10:08
jdstrandok, I need to play more. thanks10:08
zyga-ubuntujdstrand: yes, they are always empty10:23
zyga-ubuntujdstrand: you want to "stat -f" them10:23
mupPR snapd#4068 closed: interfaces/builtin: add support for content "source" section <Blocked> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/4068>10:32
pedronisnot really here but  https://travis-ci.org/snapcore/snapd/builds/329545603?utm_source=github_status&utm_medium=notification is very strange, there seems to be two runs in the log there10:32
jdstrandzyga-ubuntu: ah right. I forgot I needed to use stat on those10:41
mvomborzecki: thanks for your feedback, I addressed your points for naive-strace-opts (which is not that naive anymore actually ;)10:42
zyga-ubuntumborzecki, pstolowski: can you please look at 450210:50
mupPR snapd#4502 opened: interfaces/builtin: add support for content "source" section (v2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4502>10:50
zyga-ubuntupstolowski: for attribute / slot / plug usage (I think ok but just in case)10:50
zyga-ubuntumborzecki: as a iteration of closed 406810:50
* zyga-ubuntu -> small break10:58
zyga-ubuntuactually, maybe in 15 minutes11:01
Saviqcan I somehow refresh from a "local" snap to a store one without purging data for the snap? I often have to move between a store snap and a local one for development and purging hundreds of megs of data every time is :(11:04
zyga-ubuntuSaviq: that's mvo's snap refresh --amend branch11:05
zyga-ubuntuwith new name coming for amend11:05
Saviqaha, glad it's coming11:06
mborzeckizyga-ubuntu: reviewed 4502, not sure about MountEntries()11:07
zyga-ubuntumborzecki: good catch, it should be used in mount/backend.go but itsn't11:09
zyga-ubuntumborzecki: i will fix that11:09
mborzeckigreat :)11:09
zyga-ubuntumborzecki: I don't think the code should be in add mount entries, it may be needed to push it back even more to the backend11:09
zyga-ubuntuwe'll see11:09
zyga-ubuntuthis code didn't run with spread yet (it depends on other parts) so it's likely something is lurking11:10
mborzeckizyga-ubuntu: while at it, consider putting it into a helper func11:10
zyga-ubuntumborzecki: declash?11:10
ppisatithis, in a clean xenial amd64 chroot this morning: https://pastebin.ubuntu.com/26403870/11:10
ppisatisergiusens: ^11:10
mborzeckizyga-ubuntu: yeah11:10
ppisatikalikiana: ^11:10
ppisatikyrofa: ^11:11
zyga-ubuntuok, I'll think11:11
mborzeckizyga-ubuntu: if you happen to move the declash into a place where snap names are known, it'd be great to log them11:11
kalikianappisati: you should be running from a python virtual env11:14
kalikianais that the case?11:14
ppisatikalikiana: let me try11:14
baimafeimahi does anyone know whether it would be possible to create a snap for this game? http://zod.sourceforge.net/11:14
kalikianappisati: https://github.com/snapcore/snapcraft/blob/master/HACKING.md11:14
mvoChipaca: does "src/github.com/snapcore/snapd/osutil/sys/sysnum_32.go:26:25: error: reference to undefined identifier ‘syscall.SYS_GETUID32’" ring any bells? build failure on powerpc on xenial11:15
mcphailhi sergiusens. when the build servers are fully up and running again would it be ok if i ask you to keep https://bugs.launchpad.net/snapcraft/+bug/1718245 in mind? it would be great to get svn repos working11:17
mupBug #1718245: svn source-type not honoring proxies <Snapcraft:Triaged> <https://launchpad.net/bugs/1718245>11:17
mborzeckimvo: iirc it was added for 32bit systems where they use SYS_GETUID32 instead of SYS_GETEUID on 64bit11:18
mvomborzecki: ok, I think we need to do something about this if it is not defined11:19
* kalikiana tea break, brb11:26
cory_fusergiusens: Can I find you and get a few minutes of your time when you have a minute?11:43
sergiusenscory_fu where are you?11:52
* zyga-ubuntu goes out11:54
cory_fusergiusens: I'm in Hudson right now.  I can meet in the plenary11:56
sergiusenscory_fu that's where I am, come over :-)11:58
sergiusensHudson is freezing iirc :-)11:58
* pstolowski lunch12:11
mvoChipaca: fwiw, I poked a bit at the powerpc issue and my feeling is that for gccgo (powerpc) we need a different approach for osutil/sys/syscall.go. slightly sad but there seems to be no syscall.SYS_GETPID32 - I poke a bit more after lunch12:24
mvoChipaca: but there is syscall.SYS_GETPID so maybe we need to make do with that. anyway, after lunch12:27
tedgsergiusens: In the original case there was no specified ordering between the parts, so I imagine they ended up in the map effectively randomly?12:29
greybackjdstrand: question for you: I'm snapping chromium-on-XWayland, to run with the mir-kiosk snap. I'm hitting issue with confinement where XWayland wants ability to bind sockets. Would adding that to the wayland interface be a bit much?12:35
greybackelse I'll change tack and have mir-kiosk implement the x11 interface, and have XWayland in there instead. I'm less enthusiastic about this option due to X being harder to secure12:37
Chipacamvo: remind me, is powerpc 32 bits?12:43
jdstrandgreyback: does simply plugging the x11 interface not work?12:44
jdstrandgreyback: if not, can you show me the denials?12:45
jdstrandgreyback: note, I'm at a sprint and may be laggy. don't hesitate to ping me if I don't respond12:45
greybackjdstrand: ack. I'll try and let you know12:45
jdstrandgreyback: we can look at the denials, but I consider Xwayland a special X server12:46
jdstrandso x11 seems like the first thing to at least think about if things are broken12:47
* kalikiana going for lunch in a few and taking a break from fighting tar12:53
zyga-ubuntuChipaca: yes12:56
greybackjdstrand: adding x11 plug doesn't help, as core has no x11 slot I can connect it to. x11 is classic only. It seems like a pity to expose that x11 is being used at all, ideally it is an internal implementation detail of the chromium snap12:57
Chipacazyga-ubuntu: thanks12:57
zyga-ubuntuUnable to process SAML login request12:57
zyga-ubuntuthis is me trying to open the calendar12:57
greybackjdstrand: denials & interfaces: https://pastebin.ubuntu.com/26404327/12:58
zyga-ubuntuhmm, worked now12:58
jdstrandgreyback: ah right. so if your snap provides xwayland, then (conceptually) it should 'slots: [ x11 ]', which would mean doing for the x11 interface what you did for the wayland. that said, let me look at your paste12:59
greybackjdstrand: the snap provides wayland, yes, but not in a way that other snaps should be able to conenct to. It shoud be exclusively for chromium (also in the snap)12:59
jdstrandyeah, so that unix socket is exactly what is in the plugs of the x1113:00
mupPR snapd#4448 closed: Add rules for Media API to the BlueZ D-Bus policy <Created by lhartung> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4448>13:00
jdstrandthe shm denial is different13:00
jdstrand(though we need to handle it)13:00
greybackI've tried redirecting /dev/shm to /dev/shm/$SNAP.** with LD_PRELOAD, not had success yet13:00
jdstrandgreyback: can you expand on 'exclusively for chromium'?13:01
mvoChipaca: it is13:01
jdstrandgreyback: I don't think that will work. that is the special mir socket from mirPermanentSlotAppArmor13:02
jdstrand(I think)13:02
jdstrandwhich, iirc, is a special kernel file that you can't adjust the path on13:03
jdstrandit just happens to show up as a regular file rule. Ideally we would have shm mediation that would handle that better. anyway...13:03
greybackjdstrand: sure. Desire is for single chromium snap to run on mir-kiosk. Chromium's wayland support is broken, so XWayland is needed. So I thought it sensible to have XWayland inside the Chromium snap, which exclusively Chromium can connect to with the X protocol. Xwayland then talks to mir's wayland interface. So from the outside you woudn't know/care xwaylad was involved at all13:04
jdstrandoh I see13:04
jdstrandgreyback: I have to attend a meeting. let me ponder this. I may be laggy13:05
greybackblocker is that xwayland needs a socket for chromium to connect to, which seccomp isn't allowing13:05
greybacksince most gui apps don't want that13:05
greybackjdstrand: no worries, please chew it over13:05
greybackin the mean time I'll see how terrible it is to have mir-kiosk implement the x11 slot itself13:06
zyga-ubuntuok, actualy working this way is not too bad13:21
zyga-ubuntuI'm mounted via sshfs to my desktop and I can keep working on the same files :)13:22
cachio_zyga-ubuntu, trying to join but no power at home13:24
zyga-ubuntucachio_: we've finished now, no worries13:24
zyga-ubuntucachio_: is everything ok?13:24
cachio_zyga-ubuntu, yes, but electricity has gone during the night in all the neighborhood13:25
Chipacamvo: it seems powerpc wasn't a thing before the uid_t became 32 bits, so getuid is the syscall we want13:26
mvoChipaca: \o/13:26
Chipacamvo: want me to propose a pr?13:26
mvoChipaca: yeah, unless you are busy please go ahead13:26
Chipacazyga-ubuntu: all hail your lab :-D13:26
cachio_zyga-ubuntu, now I am using phone connection13:26
Chipacamvo: raise your hand if you aren't busy13:26
Chipacazyga-ubuntu: do you have a i386 hanging off of this?13:27
Chipacazyga-ubuntu: otherwise I can take you an eeepc :-)13:27
zyga-ubuntuChipaca: no but I have one and I can add it tomorrow13:27
zyga-ubuntu(real i386)13:27
zyga-ubuntuChipaca: I also have a mips but it's not reliable (bad ddr)13:27
Chipacazyga-ubuntu: well, i586 at least plz :-D13:27
zyga-ubuntuChipaca: it's an atom13:27
zyga-ubuntuChipaca: actually13:27
zyga-ubuntu32bit only13:27
zyga-ubuntuso, ... tomorrow :)13:27
zyga-ubuntuor later today13:27
Chipacazyga-ubuntu: no hurries, it's mostly curiosity13:28
zyga-ubuntuI'll put classic on it as it has an PATA ssd that didn't work in core (no IDE support)13:28
zyga-ubuntuChipaca: anything else? :D13:28
Chipacazyga-ubuntu: uh.... no, it'd be greedy of me13:28
Chipacaalso we don't support pep813:29
zyga-ubuntuhahaha :D13:29
zyga-ubuntuI was thinking about adding a server (UEFI) armv8 later13:29
zyga-ubuntusoon people will start to sell those first gen boxes13:29
mvoChipaca: haha - point taken13:30
* Chipaca squints at git13:31
Chipacawhat's the point of doing 'gt mv' if it then just does whatever13:31
Chipacaah no maybe it's just 'get status' that gets confused13:32
* Chipaca gets on with it13:32
zyga-ubuntuI'm so dumb13:34
zyga-ubuntuI was staring at a compile error, trying to understand it13:34
zyga-ubuntuwhen I typed "function() errror" instead of "func() error"13:34
zyga-ubuntumvo: btw, any luck with that strace test failure?13:36
mvozyga-ubuntu: not yet, let me run with -debug now13:37
mvozyga-ubuntu: hm, no, some 2.31 prep first13:38
Chipacamvo: 4503 is what it is13:38
mupPR snapd#4503 opened: osutil/sys: ppc has 32-bit getuid already <Created by chipaca> <https://github.com/snapcore/snapd/pull/4503>13:38
jdstrandgreyback: I think the x11 slot implementation would actually be quite easy compared to wayland, but, I have a couple of questions13:38
jdstrandgreyback: is a snap shipping Xwayland a common pattern, or something unusual?13:39
zyga-ubuntuChipaca: typo13:41
Chipacazyga-ubuntu: I don't know what you're takling about13:42
greybackjdstrand: the use-cases I have for it are things like chromium (for web kiosks) and electron (more kiosky bits)13:42
greybackjdstrand: wherever xwayland lives, is really just an implementation detail.13:43
zyga-ubuntuChipaca: you made a typo in your PR13:44
zyga-ubuntuChipaca: 453013:44
greybackjdstrand: I leaned toward xwayland in the app snap, just for security reasons13:44
Chipacazyga-ubuntu: i never make any typos, you're liying13:44
greybackbut I'm not forcing that as the only option13:44
zyga-ubuntuChipaca: drat, cosmic rays hit your keyboard then!13:45
Chipacazyga-ubuntu: obviosuly13:45
zyga-ubuntuChipaca: put tinfoil around your room ;-)13:45
Chipacai've got a better idea13:45
Chipacaand it involves lunch13:45
cachio_mvo, hey13:57
zyga-ubuntupstolowski, mborzecki: https://github.com/snapcore/snapd/pull/447113:57
mupPR #4471: cmd/snap-update-ns: refactor and improve Change.Perform to handle EROFS <Created by zyga> <https://github.com/snapcore/snapd/pull/4471>13:57
zyga-ubuntuupdated, should be good now13:57
cachio_mvo, sorry to skip the daily today13:57
zyga-ubuntuChipaca: ^^13:58
zyga-ubuntuI'll rebase stuff stacked on top of that to see if all the extensive unit tests (>>1K diff) passes13:58
cachio_mvo, any idea why travis jobs are not starting?13:58
mvocachio_: no worries about the standup, hope your elecricity is back. no idea about travis, let me check if I find anything out14:00
pstolowskizyga-ubuntu, thank you, will re-review soon14:01
mborzeckicachio_: mvo: https://www.traviscistatus.com/ show some major outage today14:01
mvoyeah, backlog of ~650 container jobs14:02
mvoups. no, sorry14:02
mvoactive builds, woah14:03
Chipacazyga-ubuntu: I didn't mean for you to use my names for the helpers /o\14:04
mborzeckicachio_: i'll close #4492 if #4336 is to be merged soon14:05
mupPR #4492: spread: try to enable Fedora once more <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4492>14:05
mupPR #4336: spread.yaml: add fedora 27 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4336>14:05
cachio_mborzecki, ok14:06
zyga-ubuntuChipaca: better names welcome :)14:06
cachio_mborzecki, thanks for the info14:06
Chipacazyga-ubuntu: if I were good at names, I'd be good at names14:06
elopiogood morning! I will start a few minutes late today to take my girlfriend to her office.14:10
zyga-ubuntumborzecki: there's no advantage from moving this into the backend14:11
kalikianaelopio: you're such a gentleman :-D14:11
mborzeckizyga-ubuntu: ok14:11
zyga-ubuntumborzecki: it's a public thing so we need to declash in specification anyway14:11
zyga-ubuntumborzecki: I'm trying to see how to make the logging friendlier14:12
zyga-ubuntumborzecki: I think we can use the same trick that other backends use14:12
zyga-ubuntumborzecki: store the snap as a hint14:12
mborzeckizyga-ubuntu: yeah, that would work14:12
zyga-ubuntuthough need to think about the result first14:13
zyga-ubuntuwhat we want14:13
zyga-ubuntu(what the error message should look like14:13
mborzeckizyga-ubuntu: how about this: "detected a path conflict at '/some/path' coming from snaps 'foo' and 'bar', '/some/path' from snap 'bar' will be mounted at '/some/path-2'" ?14:18
zyga-ubuntumborzecki: all of those are from one snap, the backend doesn't know enough to have that information14:19
zyga-ubuntumborzecki: the spec is for a snap (always)14:19
zyga-ubuntumborzecki: then each interface will influcnce it14:20
zyga-ubuntumborzecki: we could look at connected plug/slot to get the 2nd snap info14:20
zyga-ubuntumborzecki: but those are not conveyed by mount.Entry14:20
zyga-ubuntumborzecki: we could patch it to do that (store some snap name hint in the mount entry)14:20
zyga-ubuntumborzecki: but feels icky at that level14:20
zyga-ubuntumborzecki: I could patch mount.Specification to instead remmeber this in a side table14:21
zyga-ubuntumborzecki: not sure14:21
mborzeckizyga-ubuntu: and if you declash in AddMountEntry() ?14:22
zyga-ubuntumborzecki: that's the same, those don't know anything about plug/slot14:23
zyga-ubuntumborzecki: I could declash there, not sure what's best14:24
zyga-ubuntumborzecki: but it doesn't help logging14:24
mborzeckizyga-ubuntu: AddMountEntry() could return a custom error, eg ErrMountPointConflict that has an extra method returning the path the conflict was resolved to, then you could log at least one snap14:25
zyga-ubuntumborzecki: but then each caller would have to do that14:26
zyga-ubuntumborzecki: I think the trick is to figure out how to give it context without making it annoying to use14:26
cachio_mborzecki, I need to work on PR 433614:26
mupPR #4336: spread.yaml: add fedora 27 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4336>14:26
cachio_mborzecki, for some reason fedora 27 machines are not working at all14:26
cachio_mborzecki, I'll merge with latest changes and research a bit about what's happeninig14:27
mborzeckicachio_: sounds like a plan :)14:27
Chipacamborzecki: the changes i asked you to block #4464 are there now14:35
mupPR #4464: overlord/snapstate: do a minimal sanity check on containers <Created by chipaca> <https://github.com/snapcore/snapd/pull/4464>14:35
Chipacamborzecki: sprinkle a 'for' into that sentence somewhere for it to make sense14:35
zyga-ubuntuor a comma14:36
zyga-ubuntuhmm, there's a glibc update with lots of security fixes, feels like new core snap is needed14:37
mvozyga-ubuntu: indeed14:38
* zyga-ubuntu gardens email14:40
zyga-ubuntu(using a scythe)14:41
kalikianappisati: did you get the env to work?14:43
mupPR snapd#4498 closed: debian/tests: add missing autopkgtest test dependencies for debian <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4498>14:46
diddledanhello. is this hole in a random app something that highlights a way an application could bypass our sandbox? https://nvd.nist.gov/vuln/detail/CVE-2017-1290414:48
zyga-ubuntudiddledan: looking14:49
diddledanit's an interesting quesiton becuase theoretically the application developer opts-into the sandbox by distributing a snap but that vector could allow him to escape his self-imposed prison..14:50
zyga-ubuntudiddledan: hmmm14:51
zyga-ubuntudiddledan: this is a bug in a particular app14:51
diddledanyes. but it highlights that code can be executed via terminal escape sequences14:51
zyga-ubuntudiddledan: the app can be simply a "rm -rf /home/*"14:51
zyga-ubuntudiddledan: ah14:51
diddledanit was just that it triggered me to thinking about vectors14:52
zyga-ubuntuit doesn't look like it14:52
zyga-ubuntuthis talks about subshell invocation14:52
zyga-ubuntuso it's not a bug in the way terminal emulators implement parsing of ansi escape codes and other magic14:53
diddledanwell yes, that one application fixes it14:53
zyga-ubuntujust in what this app wants to do14:53
zyga-ubuntudiddledan: disclaimer, I'm not a security engineer so please ask someone from the security team for official confirmation14:53
zyga-ubuntudiddledan: but obviously the attack vector of printing stuff that chokes the terminal somehow is real14:54
zyga-ubuntudiddledan: and it would be some kid of sandbox escape, yes14:54
diddledanI guess I misread the Gentoo securty advisory: "A remote attacker, by enticing a user to open a feed with specially crafted URLs, could possibly execute arbitrary shell commands with the privileges of the user running the application."14:54
diddledanI read that as "escape sequences used for display"14:55
diddledan"Newsbeuter does not properly escape shell meta-characters in the title and description of RSS feeds when bookmarking."14:55
diddledanit's an age-old unsanitized variable used in command line then14:56
diddledanthat in itself wouldn't escape the sandbox14:56
diddledanphew. crisis averted.14:56
Chipacadiddledan: meta-character != escape sequence though14:56
diddledanthis was a drill14:56
diddledanthere is NOT an ICBM heading to hawaii14:57
diddledanthat we know of. I mean there _might_ be an ICBM but we didn't alert you about that. We only alerted you about a fake ICBM that doesn't exist. If there is in fact an ICBM then as we didn't warn you: "our bad"14:58
* zyga-ubuntu heads ohme15:00
* kalikiana thinks "ohme" should be the plural for units of resistance15:08
mborzeckiChipaca: posted random ideas about symlinks, feel free to ignore :)15:12
Chipacamborzecki: I am going to ignore.15:12
Chipacamborzecki: mostly because it's work that can be done iteratively15:12
Chipacamborzecki: but partly because it'd need some more work to get some form of Readlink to work somehow15:13
Chipacamborzecki: in any case, it's for a follow-up15:13
mborzeckiChipaca: yup, i'm not going to be adamant about it either :)15:15
Chipacamborzecki: yeah, something like what you pasted would work15:15
Chipacathat and the extra check on things that go 'outside' are worth adding at some point15:16
diddledanisn't an ohme a "brother from another mother" in London?15:16
diddledanI is wiv me ohme's innit blood!15:16
mvocachio_: I updated core for a new stable release and pushed the result to beta, could you please validate it?15:42
mvocachio_: not sure we need the full validation as its just a respin with updated packages15:43
ogramvo, seems the multi-volume fix doesnt work ... :/15:43
cachio_mvo, sure15:43
mvoogra: oh? what is the error?15:43
ogramvo, https://pastebin.canonical.com/207779/15:44
ograseveral OOPSIDs you can look up on errors.u.c15:44
ogramvo, looks the same as before "ERROR cannot read gadget snap details: bootloader already declared"15:45
mvoogra: it looks like snapd 2.30 runs on the image15:46
ogra(i used the core from edge from 15min ago)15:46
mvoogra: but the fix is only in 2.30+git15:46
mvoogra: before image building did not work, right?15:46
ograoh, i thought that was in edge already15:46
ograimage building did always work15:46
ograonly device init after boot didnt15:46
mvoogra: it should be in edge, I had 2.30 in edge for ~20min or so to build a new stable15:47
ograsame error as above15:47
mvoogra: could you please double check, edge is edge again15:47
ograogra@localhost:~$ snap version15:47
ograsnap    2.3015:47
ograsnapd   2.3015:47
ograok ...15:47
ograseems we picked up the stable 2.30 in edge15:48
mvoogra: sorry15:48
ograi'll goback to my manual hack (i just had validated the image to give to the customer when LP started building core again ... had just hoped we could give them the fix)15:49
* elopio is back and ready.15:50
mvoogra: edge should be ok again, you can give it one more try15:52
ograoh, did you re-build ?15:53
mvoogra: re-published15:53
mvoogra: the earlier core, not sure when exactly this one was build, I asked in between for a build, but not sure if it contains the fix or not15:53
ogramvo, according to the manifest both have 2.3015:54
ograi think there is a 2.30 in the image PPA still15:54
mvoogra: edge should be at 2.30+git497 - and yes, no new update in the ppa, I'm fixing this right now .)15:55
ograyeah, dashboard only shows git477 for armhf ... 479 was only in x86 arches15:57
zyga-ubuntuChipaca: could you please spare another look at 447115:59
zyga-ubuntuI really am blocked by that one landing so I'll be bugging you all until I get it resolved :)15:59
zyga-ubuntumvo: if you want to use your voice in the naming / refactoring discussion there15:59
zyga-ubuntuonce I get +2s from you I will ask gustavo to re-review16:00
zyga-ubuntupstolowski: 4472 needs a 2nd review, should be good now16:00
zyga-ubuntuthank you16:01
* zyga-ubuntu is still downtown16:02
zyga-ubuntuthe traffic is bad and it will be an hour before I get home16:02
zyga-ubuntuthank you!16:05
zyga-ubuntuI will re-run integration tests in my main integration branch to see if anything broke16:05
Chipacagit doesn't respect file permissions, that's why my spread tests that check for them fail16:07
zyga-ubuntuChipaca: it respects +x16:11
zyga-ubuntuChipaca: what do you need16:11
Chipacazyga-ubuntu: everything16:11
Chipacazyga-ubuntu: also it respects +x in the sense that if it has any +x, it sets all +x and viceversa16:11
Chipacaalso if i hadn't checked this out on another machine there was no way i'd've figured it out16:11
Chipacabecause on my other machine everything works, with git saying 'yep no changes'16:11
zyga-ubuntuChipaca: well, depending on system those are not representable much16:11
zyga-ubuntuI think it's better to chmod yourself16:12
zyga-ubuntuchmod chmod chmod16:12
zyga-ubuntuI'll go to the tube now, let's hope it's not super crowded (it will be)16:12
mupPR core#74 opened: 10-remove-documentation: preserve changelogs <Created by mvo5> <https://github.com/snapcore/core/pull/74>16:25
mvoa quick review -^ would be appreciated, should be trivial (cc ogra) - this will give us changelogs again16:26
mvocachio_: I will need to build another beta core, this one killed all changelogs which is a bit harsh, i.e. our http://people.canonical.com/~mvo/core-changes/html/stable/ will break for the "Package changelogs" section16:27
mvocachio_: sorry for this16:27
cachio_mvo, np16:27
cachio_mvo, I'll download the new ones once they are ready16:28
ogramvo, ack'ed16:31
mupPR snapcraft#1878 opened: repo: use debian.arfile instead of dpkg-deb <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1878>16:31
kalikiana^^ sergiusens16:32
mupPR core#75 opened: ensure that all live-build/hooks run with `set -e` <Created by mvo5> <https://github.com/snapcore/core/pull/75>16:32
cachio_zyga-ubuntu, any idea if we could replace the dependency golang(github.com/Thomasdezeeuw/ini) with another on fedora?16:36
cachio_zyga-ubuntu, we are having this error No match for argument: golang(github.com/Thomasdezeeuw/ini)16:37
cachio_ 16:37
cachio_after do dnf -y --refresh -v install 'golang(github.com/Thomasdezeeuw/ini)'16:37
mupPR core#74 closed: 10-remove-documentation: preserve changelogs <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/74>16:41
mborzeckicachio_: this has been resolved in master16:43
mborzeckicachio_: #449316:45
mupPR #4493: image: port ini handling to goconfigparser <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4493>16:45
cachio_mborzecki, nice16:45
cachio_mborzecki, ok, I'll make the change proposed by pedronis and pushe it to #433616:48
mupPR #4336: spread.yaml: add fedora 27 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4336>16:48
mupPR snapd#4483 closed: cmd/libsnap-confine-private: print failed mount/umount regardless of SNAP_CONFINE_DEBUG <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4483>16:49
cachio_mborzecki, testing now, it goes slow because I am using my phone connection16:51
cachio_mborzecki, and I also have 2 hours of laptop battery16:52
cachio_mborzecki, I hope electricity comes back soon16:52
* kalikiana wrapping up for the day17:00
leftyfbHow does snappy deal with custom configuration files? As a very simplified example, lets say I wanted to configure openssh to listen on a port other than 22.17:01
naccleftyfb: so you mean a snapped ssh-server?17:03
naccleftyfb: classic or confined?17:03
leftyfbprobably classic to start with. But yeah. ssh server is just an example17:04
naccleftyfb: if it's classic, the snap can read the host OS17:04
leftyfbwpasupplicant would be a better example in our case actually17:04
naccleftyfb: so, in theory, given the same sort of options are passed to the build (i.e, read /etc/ssh/...), a classic snapped ssh server would be no different than a non-snap17:05
naccas far as config goes, i mean17:05
Chipacaleftyfb: there's a wpa-supplicant snap, but I'm not sure it'll answer your question17:05
leftyfbwe're looking to replace pxe/kickstart/ansible/catkin with a full snappy core + snaps. How would we deal with all the custom configs17:05
Chipacaleftyfb: if your question is how does "snap get" and "snap set" interact with a pre-existing software's configuration, that's up to the snap17:06
naccif you were to confine it, i think you need to provide app(s) that expose the config you want to expose17:06
naccChipaca: ah yes, i forgot that `snap {set,get}` exist :)17:06
naccleftyfb: so, e.g., a ssh server snap could expose a port config option17:06
Chipacaleftyfb: if your question is "how can i read/write etc", you typically don't; things can usually told to read their config from elsewhere17:06
Chipacai meant "how can i read/write /etc/" in case that was unclear17:07
leftyfbI'm not sure I'm following. Basically I want to create a snappy core image to be dd'd onto a drive and have all the configs ready to go. wpasuppplicant being an example, how would I go about configuring the ssid/password during the creation of the snappy core image?17:07
naccleftyfb: if it's your own wpasupplicant snap, just put it in your snap?17:07
leftyfbok, so we can put custom configs in the snaps?17:08
Chipacaleftyfb: there's typically a factory setup step where you drop things like that in place, if I'm following you17:08
leftyfbwhat about if it's a config that is part of the core OS and we don't want to recreate a new snap just so we get a custom config?17:08
Chipacaleftyfb: ondra might have more experience with this than myself (I don't know what nacc works on :) )17:08
naccChipaca: a little bit of everything :)17:09
nacc(it feels like)17:09
Chipacaleftyfb: what's the config? (it'll depend)17:09
Chipacanacc: :-)17:09
leftyfbChipaca: there's lots. We build robots :)17:09
Chipacaleftyfb: right, but not a lot in the core os is about robots17:10
Chipacaleftyfb: not a lot in the core _snap_ is about robots17:10
Chipacathere, better17:10
leftyfbfor example, with wpasupplicant we have a custom wpasupplicant.conf and a custom systemd unit file for it17:10
naccleftyfb: right, so it's important to distinguish the bits here17:10
nacccore snap + app snaps17:10
leftyfbugh, I have to step away for a bit.17:11
leftyfbI'll come back and try to come up with other examples17:11
Chipacaleftyfb: there is no wpa supplicant in the core os as far as i know17:11
Chipacaleftyfb: so that's from a snap :-)17:11
Chipaca(i could be wrong!)17:11
naccand how or what you do with a config is totally up to that snap17:11
Chipacagranted if it's a service in the core os config can be tricky, but we've tried to keep that to a minimum17:12
Chipacabecause of this trickiness :-)17:12
Chipacaogra: do we ship wpa-supplicant in core?17:12
ograChindeed we do17:13
=== Chipaca is now known as Chindeed
ograget a bettar nick !17:13
Chindeedogra: ok17:13
=== Chindeed is now known as Chipaca
Chipacaogra: then I'm confused by the wpa-supplicant snap :)17:14
ograChipaca, but netplan only supports normal modes, no enterprise WPA or some such fancy stuff17:14
ograNM and the wpa-suppl. snap solve that17:14
Chipacaogra: netplan doesn't, or consoleconf doesn't?17:14
ogranetplan doesnt17:14
ogratheer was a recent discussion on the forum and with cyphermox about this17:14
Chipacaogra: link?17:15
* Chipaca so lazy17:15
ograChipaca, https://forum.snapcraft.io/t/standard-for-bootstrapping-network-on-raspberry-pi-and-similar-devices/313717:25
Chipacaleftyfb: ^17:26
mupPR snapd#4501 closed: configcore: ensure config.txt has a final newline <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4501>17:30
mupPR snapd#4419 closed: tests: fix snapctl configure core tests for rpi2 and 3 <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4419>17:41
cachio_mvo, are you uploading the new cores?18:29
cachio_I just see the one for amd6418:29
mvocachio_: I can't :( the build farm is disabled because of spectre for most architectures. so I can only do amd64/i386 without help from the launchpad team. I was not able to reach someone this evening so I will try again tomorrow.18:32
mvocachio_: you can poke a bit at the amd64 version but it should be fine18:32
mvocachio_: here are the changes http://people.canonical.com/~mvo/core-changes/html/beta/2.30_2.30.html18:32
cachio_mvo, ok, I'll try the amd6418:33
cachio_mvo, it should be quick18:33
mvocachio_: thank you!18:46
ogramvo, oh ... i thought we were already back in business for all arches ...18:50
* ogra turns the daily core snap builds back off to not get bombed with build failure mails ...18:51
cachio_mvo, my internet connection sucks today, still downloading the image19:15
cachio_downlaoding at 19.7kB/s19:15
kyrofaarrrgh ROS changed how their CLI tools work between when I wrote the script and when I recorded the videos...20:17
leftyfbwelcome to open source/api's :)20:22
leftyfbI was just getting a handle on init scripts when systemd became the thing ... I thought I mastered ifupdown and now netplan is the thing :/20:24
kyrofaleftyfb, but those are different technologies! catkin_create_pkg suddenly works differently, in the same ROS release :P20:31

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