/srv/irclogs.ubuntu.com/2017/10/27/#snappy.txt

=== JoshStrobl is now known as JoshStrobl|AFK
mupPR snapcraft#1642 opened: tests: move the plainbox test to the integration suite <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1642>03:54
mupPR snapcraft#1643 opened: [WIP] tests: run daily autopkgtest in travis <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1643>03:57
zyga-ubuntugood morning05:26
mvozyga-ubuntu: good morning !05:33
mvozyga-ubuntu: master is broken currently :/ https://travis-ci.org/snapcore/snapd/builds/293175118#L5810 - looks like something for pawel05:33
mupPR snapcraft#1644 opened: lxd: fix the push in container builds <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1644>05:43
mupPR snapd#4079 closed: daemon: allow Polkit authorization to cancel changes <Created by robert-ancell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4079>05:55
=== kira is now known as Guest63697
mupPR snapd#4082 opened: cmd/snap: tell translators about arg names and descs req's (2.29) <Created by mvo5> <https://github.com/snapcore/snapd/pull/4082>06:07
mupPR snapd#4083 opened:  snap-{confine,seccomp}: make @unrestricted fully unrestricted (2.29) <Created by mvo5> <https://github.com/snapcore/snapd/pull/4083>06:08
mupPR snapd#4084 opened: interfaces: clean system apparmor cache on core device (2.29) <Created by mvo5> <https://github.com/snapcore/snapd/pull/4084>06:11
Guest63697Hello currently working on ubuntu core 16 need to build qt application which works on postgres database do06:12
Guest63697on need to create a separate snaps for it06:12
Guest63697and is any document for qt and postgres06:12
zyga-solusGuest63697: hello06:15
zyga-solusGuest63697: I don't know about postgres but there's something for a kiosk qt app06:15
zyga-solusGuest63697: my suggestion would be to get postgress up and running06:15
zyga-solusGuest63697: and then move on to qt06:16
zyga-solusGuest63697: also, not sure why you want separate snaps for that but that's ok, you will just need to use content interface to share data/sockets so that they can talk to each other06:16
mupPR snapd#4085 opened:  debian: do not build static snap-exec on powerpc (2.29) <Created by mvo5> <https://github.com/snapcore/snapd/pull/4085>06:16
Guest63697zyga-solus: Hi for more details i am currently working on dell edge gateway 5000 with ubntu core16 installd06:16
zyga-solusGuest63697: right, you can prototype this on a typical ubuntu system (16.04 is ideal) and then just install the resulting snap on the device06:18
zyga-ubuntumvo: o, looking06:18
Guest63697 zyga-solus: I am new to the core os i just tried running hello world application so needed jus help to move my existing application to core :)06:19
zyga-ubuntumvo: aha, I see that service management test failed06:19
zyga-solusGuest63697: I suggest you start by learning about snapcraft, using snaps on your 16.04 desktop/laptop (classic system) and playing with your core system with a few snaps06:20
zyga-solusGuest63697: build a hello-world.c from source, see how that looks like06:20
zyga-solusGuest63697: then look at what it would take to run postgres06:20
=== JanC is now known as Guest53324
=== JanC_ is now known as JanC
zyga-solusGuest63697: or separately at kiosk-style Qt (this is documented on the forum)06:20
zyga-solusGuest63697: in the end all the pieces will come together and you should get it to work fine06:21
zyga-solusGuest63697: stick around, join the forum, experiment. read, and ask :)06:21
zyga-solusoh, and welcome :-)06:21
zyga-ubuntumvo: I'll ignore that master failure for now unless pawel comes around and asks for help06:21
zyga-ubuntumvo: I need to finish apparmor changes for overlayfs06:21
zyga-ubuntumvo: and expand the spread tests for that06:22
Guest63697 zyga-solus: I have been searching on the web a multiple links can you please suggest any useful and just for curiosity should i put all the application and its dependecy under one snp06:22
zyga-solusGuest63697: try forum.snapcraft.io06:22
zyga-solusGuest63697: we also have a snapcraft tutorial on ...06:22
zyga-solushttps://docs.snapcraft.io/build-snaps/your-first-snap06:22
mvozyga-ubuntu: yeah, just a heads up about the failure not a request-for-action :)06:22
zyga-solusnote that you can use a classic "regular" ubuntu system for all of this06:23
zyga-solusthat's the beauty of snaps :)06:23
Guest63697 zyga-solus: sure thanks06:23
zyga-solusin the end you just deploy it on core06:23
zyga-ubuntumvo: ack, thank you :)06:23
mupPR snapd#4081 closed: systemd: run all mount units before snapd.service to avoid race <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4081>06:23
zyga-ubuntumvo: I was asking my son if he would like to wake up at 3AM tomorrow to look at sunirse in the nearby fields, we could take some photos of the birds nesting there06:23
zyga-ubuntumvo: I was talking about this the whole week06:23
zyga-ubuntumvo: and while earlier he was "yeah dad, that would be fun"06:24
zyga-ubuntumvo: today he said "but if we stay at home, can we sleep longer"06:24
zyga-ubuntumvo: I think I lost that one :)06:24
zyga-ubuntumvo: if you want I can work on mount unit refresh later today06:24
zyga-ubuntumvo: I'd like to think how to approach that: as a fixup type thing or as a change in how we maintain them06:25
mupPR snapd#4086 opened: snap-confine: increase sanity_timeout to 6s <Created by mvo5> <https://github.com/snapcore/snapd/pull/4086>06:28
mvozyga-ubuntu: it seems conceptually cleaner to do the later06:28
zyga-ubuntumvo: I agree but then my conclusion was, if this is something that will run in ensure (that is, all the time)?06:29
zyga-ubuntumvo: and if so, what should we do after we notice that the files were chaned06:30
zyga-ubuntumvo: I was thinking that this is where it gets hairy06:30
zyga-ubuntumvo: we could log "discrepancy in unit %q"06:30
zyga-ubuntumvo: and do nothing at all (for this specific case that's fine)06:30
zyga-ubuntumvo: but it feels like a stretch of the concept06:30
zyga-ubuntumvo: we also don't have similar ensure for interfaces06:30
zyga-ubuntumvo: but06:30
zyga-ubuntumvo: if we actually do this then the system is self-healing in a nice way06:31
mvozyga-ubuntu: well, if its a one-off thing we should handle it like this and not complicate things, just a "fixupMountUnits()" somewhere06:31
zyga-ubuntumvo: ^ commented on the PR, I think you need to change a few tests too06:31
mvozyga-ubuntu: 2.29 is super close this healing thing may not even make it06:31
zyga-ubuntumvo: yes, I agree we absolutely have to have something for 2.29, so a fixup is good06:32
mvozyga-ubuntu: aha, thanks. we have two autopkgtest failures where the alarm goes of06:32
zyga-ubuntumvo: maybe 2.31 target for generic healing06:32
mvozyga-ubuntu: 2.29 is super close, candiate targeted monday so it may not even make it06:32
mvozyga-ubuntu: but if it does even better06:32
mvozyga-ubuntu: I plan ~rc2 today06:32
mvozyga-ubuntu: and hopefully that is the last one06:32
zyga-ubuntumvo: for the tests we need "make check" to pass06:32
zyga-ubuntumvo: what about 4008?06:33
mvozyga-ubuntu: its still hanging there, I wanted to see where things are at lunchtime, if everything else is in and ready +106:34
mvozyga-ubuntu: thanks, I adjusted the test now. I did a force push to make it easier to cherry-pick (either way)06:35
zyga-ubuntumvo: no worries, I approve of --force ;D06:36
mupPR snapd#4087 opened: cmd: downgrade log message in InternalToolPath to Debugf() <Created by mvo5> <https://github.com/snapcore/snapd/pull/4087>06:47
mvopstolowski: hey, good morning. you have two 2.29 targeted PRs, could you please create a branch based on upstream/release/2.29 and cherry-pick your commits to it so that we merge to 2.29?07:32
mvopstolowski: also master is failing right now07:32
pstolowskimvo, sure07:34
pstolowskimvo, what is failing?07:35
kalikianao/07:43
Guest63697 zyga-ubuntu: I am trying run the qt4 text editor example on from snapcraft github it is giveing error as application cannot connect to x server07:58
zyga-solusGuest63697: on core or on classic?08:00
Guest63697 zyga-ubuntu: on core08:00
zyga-soluson core there's no display stack08:01
zyga-solusyou need to look at qt + kiosk mir demos for that08:01
mvopstolowski: sorry for the delay, I was distracted: master is broken currently :/ https://travis-ci.org/snapcore/snapd/builds/293175118#L581008:15
mvopstolowski: maybe racy?08:15
mvopstolowski: line 5810 (takes forever to load for me :/08:15
mvopstolowski: maybe https://travis-ci.org/snapcore/snapd/builds/293175118#L5758 works better?08:16
mvopstolowski: the gist is http://paste.ubuntu.com/25828740/08:17
pstolowskimvo, thank you08:17
pstolowskimvo, oh damn.. this indeed might be racy. i wonder what to do about that test :(08:17
mvopstolowski: sleep 10 - what we always do (kidding of course)08:18
pstolowskii guess we need a function that tries a couple of times until a timeout passed, then it gives up08:18
mvopstolowski: yeah, I think that is sensible08:19
pstolowskimvo, ok, i'll work on this, sorry about the problem08:20
mvopstolowski: no worries, thank you08:21
pstolowskimvo, when cherry-picking for 2.29, is it ok to squash?08:23
mvopstolowski: if it is merge in master already then please cherry-pick individually otherwise the merge of 2.29 into master will be infected with conflicts08:25
mvopstolowski: if it is not merged yet the easiest is to squash merge when merging into master to get any easy cherry-pick08:26
pstolowskimvo, ack08:27
pedronismvo: hi,  I'm trying to finish something not to lose state, let's talk about ignore-validation after lunch08:40
mvopedronis: +108:42
mupPR snapd#4082 closed: cmd/snap: tell translators about arg names and descs req's (2.29) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4082>08:54
ackkis there a way for a snap to know the underlying os version? (not the core snap one)09:01
zyga-solusackk: mmm, no I don't think there is09:04
=== JanC_ is now known as JanC
=== JoshStrobl|AFK is now known as JoshStrobl
* zyga-ubuntu -> coffee09:17
mvopstolowski: while you fix the test I can help with the 2.29 cherry-picks for 4070 - we need this for 2.29, right? its a bugfix aiui?09:17
mupPR snapd#4088 opened: snapctl: cherry pick service commands changes <Created by stolowski> <https://github.com/snapcore/snapd/pull/4088>09:19
pstolowskimvo, ^09:20
pstolowskimvo, yes, it's kind of a bugfix09:21
pstolowskimvo, nb, i think 4080 is not very important for 2.2909:23
mvopstolowski: thank you09:27
mvopstolowski: what branches does 4088 cover? i.e. which of the previous PRs that were tagged 2.29?09:28
pstolowskimvo, 4070 and 4065 (the latter for prerequisite for the former anyway)09:29
zyga-solusoooh09:31
zyga-solusman09:31
zyga-solusafter using vim for what, 20 years09:31
zyga-solusI learned what "x" is for when in directory listing mode09:31
mvopstolowski: do we need to cherry-pick b693557 in 4088 as well? its the last commit in 4070?09:33
pstolowskimvo, oh yes, that a test only, but yes. done09:34
mvota09:34
ackkzyga-solus, do you think that adding an interface for allowing that would be accettable?09:35
zyga-solusackk: not sure how such an interface would look like09:35
zyga-solusackk: why do you need this information?09:35
zyga-solusackk: and how would you expect to read it?09:35
ackkzyga-solus, for an app to expose the information. perhaps reading /etc/os-release from the host (possibly linked somewhere else)09:36
zyga-solusackk: most apps I know of don't read or expose /etc/os-release, I'm sure there must be some special cases though that's why I'd like to understand the need better09:38
zyga-solusackk: /etc/os-release says you are on ubuntu core09:38
ackkyeah09:41
pstolowskimvo, ok, i've a tentative fix for test race, let's see how travis likes it, i've never experieced it locally09:52
mvopstolowski: great09:53
pstolowskiand i hope it's a race, nothing else09:53
mvopstolowski: looking forward to it, my top priority for today is to get the 2.29 branches in and release 2.29~rc2 to beta so that it can go to candidate monday. having master in good shape is vital .)09:53
mvopstolowski: yeah09:53
zyga-solusman, it's cold today10:10
mupPR snapd#4088 closed: snapctl: cherry pick service commands changes <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4088>10:10
mupPR snapd#4089 opened: tests: wait for service status change & file update in the test to avoid races <Created by stolowski> <https://github.com/snapcore/snapd/pull/4089>10:11
pstolowskimvo, ^10:12
mvopstolowski: thanks a bunch, lets see if travis is happy with this10:16
zyga-solusok10:27
zyga-solusfingers crossed10:27
zyga-solusmvo: so just to confirm, 4008 should be squash merged today10:29
mvozyga-solus: if we want it in, yes10:34
zyga-solusmvo: ok, please tell me when10:37
=== JoshStrobl is now known as JoshStrobl|zzz
kalikianazyga-solus: ackk /etc/os-release is already exposed in apparmor afair10:55
zyga-soluskalikiana: yes but it doesn't show you the real /etc/os-release file10:57
zyga-soluskalikiana: it shows the one from the core snap10:57
kalikianazyga-solus: Hmm classic snaps can see the real file... but I guess in that case apparmor doesn't apply anyway10:59
zyga-soluskalikiana: can you show me how you determined that?11:01
zyga-soluskalikiana: I just saw the file from core snap on a 16.04 test vm11:02
kalikianazyga-solus: snapcraft can read the file. From checking interfaces/apparmor/template.go in snapd sources it's not obvious, though, if that applies or not11:03
kalikianaTo me at least11:03
zyga-soluskalikiana: I didn't say that it is not unreadable, it *is* readable11:03
zyga-soluskalikiana: I said that it should almost always contain the /etc/os-release file from the core snap or other base snap that is used by a given app snap11:04
zyga-soluskalikiana: thus when read on fedora it will not say "fedora"11:04
zyga-soluskalikiana: it will consistently say "ubuntu core" or whatever the base snap says11:04
kalikianazyga-solus: Right. I didn't mean to contest that... maybe bad wording on my part11:05
zyga-soluskalikiana: no worries, I just wanted to explain what I meant earlier :)11:05
kalikianazyga-solus: I think it technically makes sense so long as you have no access to the underlying system. Tho it would make something like a user agent that's used for statistical purposes impossible11:08
mupPR snapd#4089 closed: tests: wait for service status change & file update in the test to avoid races <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4089>11:11
zyga-soluskalikiana: yes, I agree11:11
zyga-solustechnically we have the real file in /var/lib/snapd/hostfs/{etc,lib}/os-release but it is not readable in strictly confined apps11:11
=== chihchun_afk is now known as chihchun
mupPR snapd#4087 closed: cmd: downgrade log message in InternalToolPath to Debugf() <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4087>11:29
zyga-solushrm11:57
zyga-solussome good and some bad news11:57
zyga-soluslet's make a PR11:57
jdstrandzyga-solus, kalikiana: /var/lib/snapd/hostfs/{etc,lib}/os-release is actually allowed via system-observed12:04
jdstrandsystem-observe*12:04
mupPR snapd#4090 opened: interfaces/mount: exspose mount.{Escape,Unescape} <Created by zyga> <https://github.com/snapcore/snapd/pull/4090>12:05
zyga-solusjdstrand: oh!12:07
zyga-solusjdstrand: that's neat, I didn't know12:07
zyga-solus(and didn't check apparently :)12:07
zyga-solusmvo: I'm merging 4008 (squash)12:08
zyga-solusmvo: speak now to stop me please12:08
zyga-solusmvo: 3...12:09
mupPR snapd#4086 closed: snap-confine: increase sanity_timeout to 6s <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4086>12:10
zyga-solusmvo: 2...12:10
zyga-solusmvo: 1...12:11
zyga-solusmerging12:12
mupPR snapd#4008 closed: cmd/snap-update-ns: create missing mount points automatically <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4008>12:13
mupPR snapd#4060 closed: interfaces: clean system apparmor cache on core device <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4060>12:16
mupPR snapd#4091 opened: cmd/snap-update-ns: allow fault injection to provide dynamic result <Created by zyga> <https://github.com/snapcore/snapd/pull/4091>12:16
mvozyga-solus: ok, no worries12:16
zyga-solusmvo: you can cherry pick for 2.2912:17
kalikianajdstrand: Does system-observed change which one /etc/os-release points to? Is it still the one from the core snap?12:22
zyga-ubuntukalikiana: no, it doesn't12:23
mupPR snapd#4069 closed: debian: do not build static snap-exec on powerpc <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4069>12:23
mupPR snapd#4092 opened: cmd/snap-update-ns: allow Change.Perform to return changes <Created by zyga> <https://github.com/snapcore/snapd/pull/4092>12:23
mupPR snapd#4080 closed: snapctl: added long help to stop/start/restart command <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4080>12:24
mupPR snapd#4085 closed:  debian: do not build static snap-exec on powerpc (2.29) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4085>12:25
mupPR snapd#4083 closed:  snap-{confine,seccomp}: make @unrestricted fully unrestricted (2.29) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4083>12:30
mupPR snapd#4084 closed: interfaces: clean system apparmor cache on core device (2.29) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4084>12:30
mvozyga-ubuntu: just to double check - freezeSnapProcess() is now called everytime snap-update-ns is run, right? with 4008?12:33
zyga-solusyes12:34
cachiokenvandine, hey12:43
zyga-solusmvo: I have one more for 2.29.212:49
mvozyga-solus: which one?12:51
zyga-ubuntumvo: https://github.com/snapcore/snapd/pull/409312:51
mupPR #4093: cmd/snap-update-ns: initialize logger <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4093>12:51
zyga-ubuntujust one liner12:51
zyga-ubuntubut it will help us in case 4008 explodes in the field12:52
kenvandinecachio, hey12:52
mvozyga-ubuntu: ok12:52
mupPR snapd#4093 opened: cmd/snap-update-ns: initialize logger <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4093>12:52
cachiokenvandine, I copied the approach you use for the calculator12:53
cachiokenvandine, but still it can't access to the gsettings schema12:53
cachioI it copying the schema to the correct place12:53
kenvandinecachio, can i get a checkout of your yaml?  I'll try it myself12:54
cachiokenvandine, https://github.com/sergiocazzolato/snapd/tree/tests-interface-gsettings/tests/lib/snaps/test-snapd-gsettings12:54
kenvandinecachio, i have a bunch of snaps all using gsettings12:54
cachiokenvandine, I know12:54
jdstrandkalikiana: system-observe doesn't change the system. you can either look at /etc or /usr/share/... for what the os-release is for the snap's runtime (you have access to this by default), or you can plugs system-observe and look in hostfs to see what the host system is12:55
jdstrandzyga-solus: re new> yes, it is a recent update12:55
kenvandinecachio, oh... you aren't using the desktop helpers12:55
kenvandinei bet that has something to do with it12:55
cachiokenvandine, how should I add it?12:55
kenvandinethe desktop helpers probably tweak the schema env12:56
kenvandineafter: [desktop-gtk3]12:56
kenvandinefor example12:56
kenvandineand command: desktop-launch check-schema12:56
kenvandineor you can look at the launcher script and reproduce that in your own script12:56
cachiokenvandine, ok, I'll try that12:57
kenvandinethat helpers sets lots of env needed for desktop stuff12:57
cachiokenvandine, thanks12:57
kenvandinenp12:57
kalikianajdstrand: Alright, that makes sense, thanks for clarifying! I guess even in that case it's best to have both available and not just change behavior.13:00
mupPR snapcraft#1625 closed: tests: use the snapcraft snap for integration tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1625>13:29
zyga-ubuntujdstrand: hey13:34
zyga-solusjdstrand: do you have 15 minutes to consider and answer a question?13:35
zyga-solusjdstrand: it would require you to have spread (local or remote) and checkout my branch, run it, get a denial and see what you think about it13:35
zyga-solusjdstrand: I suspect you know the answer without running it13:36
zyga-solusjdstrand: but I wanted to check13:36
cachiokenvandine, works with the desktop-lunch13:39
cachiolaunch13:39
om26erpopey: hey! was looking at this yaml a few days ago but couldn't find it today. Do you have a copy ? https://github.com/snapcrafters/pycharm-community/blob/master/snap/snapcraft.yaml13:39
cachiothanks13:39
om26er(need that yaml file to snap a related project)13:39
kenvandinecachio, cool13:39
popeyhi om26er13:39
popeyi deleted the repos from snapcrafters because it's owned upstream now. I have a backup though, can pastebin if you need it?13:40
om26erpopey: yes, that would do.13:40
popeyhttp://paste.ubuntu.com/25830418/13:41
mupPR snapd#4094 opened: tests: cherry pick the fix for services test into 2.29 <Created by stolowski> <https://github.com/snapcore/snapd/pull/4094>13:41
pstolowskimvo, ^13:43
mvopstolowski: ta!13:44
pstolowskimvo, the changes to help docs seem to already be there in 2.29, guess you merged them13:45
mvopstolowski: yeah, I cherry picked13:45
pstolowskicool, thanks13:45
om26erpopey: I would need the .desktop file as well :)13:48
popeyhttp://paste.ubuntu.com/25830453/13:49
popeysorry13:49
* zyga-solus lunches13:57
mupPR snapd#4093 closed: cmd/snap-update-ns: initialize logger <Critical> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4093>14:02
zyga-solusthank you :)14:02
pedronismvo: is Chi-paca supposed to be back Monday?14:03
mvopedronis: AFAIK he is14:04
mvozyga-solus: thank *you* and cherry-picked into 2.2914:04
mupPR snapd#4095 opened: debian: make packaging/ubuntu-14.04/copyright a real file again <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4095>14:07
mattywhey folks, is it possible to have private snaps using the public store?14:11
om26erwhen will build.snapcraft respect `architectures` config ?14:11
jdstrandkenvandine: hey, fyi I noticed an issue with the gedit snap14:16
ogra_om26er, https://forum.snapcraft.io/t/snapcraft-build-on-hint-for-builders/93914:16
kenvandinejdstrand, oh?14:16
noise][mattyw: yes, but just keep in mind a private snap is just for the publisher and collaborators, e.g. for QA prior to release. Collaborators have full read-write access to the snap.14:16
jdstrandkenvandine: if you go to open a file and get the gtk3 file chooser, in the upper left the 'Documents', etc don't work as expected because they are expecting those folders to be under SNAP_USER_DATA (ie, what HOME is set to)14:17
mattywnoise][, is it possible to define who the collaborators are - like if I have a snap that I just want people in my team to have access to?14:17
jdstrandkenvandine: the Documents, etc in the lower left all work fine14:17
kenvandinejdstrand, yeah, i haven't figured out what to do with that14:17
kenvandineportals will help14:17
noise][mattyw: yes - on your snap details page on dashboard.snapcraft.io, there's a "Collaboration" link in the side nav14:18
jdstrandkenvandine: it should. another idea is to symlink from SNAP_USER_DATA/Documents to /home/user/Documents14:18
kenvandinejdstrand, oh... we could do that in the helpers14:18
kalikianakyrofa: when you're up, perhaps we can chat about snapcraft#1641 briefly?14:18
mupPR snapcraft#1641: lxd: catch CalledProcessError in _container_run <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1641>14:18
jdstrandright14:18
jdstrandzyga-solus: can you just show me the denial, the spread test and the branch of the code?14:19
kyrofakalikiana, let me take a look here...14:21
kenvandinejdstrand, i'll take a swing at that14:22
kyrofakalikiana, alright, want to HO real quick?14:22
zyga-solusjdstrand: ha, no denial, this is overlayfs14:22
kalikianakyrofa: Yeah, gimme 1 minute to fetch my headset14:22
kyrofaSure thing14:22
zyga-solusjdstrand: I can show you the branch if you want to try14:23
zyga-solusone sec14:23
kenvandinejdstrand, actually the helpers run from within the snap and don't have access to $HOME14:24
zyga-ubuntujdstrand: fetch my remote please, go to feature/transparent-overlayfs and pop one patch off, that is go to bc687e812a693afe532f51803645cc41d027de00 - then run SPREAD_DEBUG_EACH=0 spread -debug -v -reuse qemu:ubuntu-16.04-64:tests/main/interfaces-content-mkdir-writable:snap14:25
kyrofakalikiana, haha you're ringing my phone, hold on, I need to learn how to use hangouts14:25
kalikianakyrofa: https://hangouts.google.com/hangouts/_/ygq3wu36wzebfjotr7gdj7ofhye14:25
kenvandinewe'd have to do some mangling of the paths like in $SNAP_USER_DATA14:25
kalikianakyrofa: Oh, heh. Wasn't my intention. Just created a hangout ( I think...)14:25
kyrofaAh excellent14:25
zyga-ubuntujdstrand: I'm running it here14:26
jdstrandkenvandine: gedit plugs the home interface14:27
kenvandineyes14:28
kenvandinebut we don't have proper $HOME i meant14:28
kenvandineso we would need to strip out part of the path14:28
kenvandinedoable though14:28
jdstranduse getent. there is already stuff in there14:28
kenvandineoh cool14:28
* zyga-ubuntu is a bit preoccupied and worried about Spain vs Catalonia just now; Catalonia has just declared independence 14:29
jdstrandkenvandine: getent passwd $UID | cut -d ':' -f 614:29
kenvandinejdstrand, yeah, thanks!14:29
* kenvandine always forgets about getent :)14:29
jdstrandzyga-ubuntu: you asked me to look at something with overlayfs. what is it you want me to look at?14:29
zyga-ubuntujdstrand: yes14:29
zyga-ubuntujdstrand: that's exactly that branch and that is exactly what I'm running as well14:30
jdstrandnote, this is not going to take only 15 minutes if you are asking me to verify that it is going to dtrt with apparmor14:30
zyga-ubuntujdstrand: to ensure we're seeing the same thing14:30
zyga-ubuntu2017/10/27 14:31:17.262504 main.go:154: cannot apply mount change mount (/snap/test-snapd-content-advanced-slot/x1/source /snap/test-snapd-content-advanced-plug/x1/target none bind 0 0): cannot open path segment "x1" (got up to "/snap/test-snapd-content-advanced-plug"): permission denied14:31
zyga-ubuntujdstrand: this is the error I'm seeing14:31
zyga-ubuntujdstrand: and there are no denials14:31
jdstrandistr something with overlayfs and private mounts14:32
zyga-ubuntujdstrand: now in that same branch there's one more patch that lets this test pass14:33
zyga-ubuntujdstrand: it makes snap-update-ns unconfined14:33
zyga-ubuntujdstrand: note: when s-u-n is unconfined it can complete the work and then let regularly confined apps work14:34
zyga-ubuntujdstrand: I'm trying to understand if the failure I'm seeing is a result of missing apparmor support for overlayfs14:34
jdstrandzyga-ubuntu: I'll try the spread test, but note, I'm not keen on spending a lot of time on overlayfs until niemeyer or mvo say that the change in direction is what we want in the PR. I laid out many questions about this and didn't get a response that pertains to them. morphis then followed up but no response14:34
zyga-ubuntujdstrand: I suspect the answer is "yes"14:34
zyga-ubuntujdstrand: gustavo strongly wants me to pursue this, I'll review your questions and ensure they are all answered14:35
jdstrands/in the PR/in the forum/14:35
zyga-ubuntujdstrand: ack14:35
jdstrandzyga-ubuntu: that is a complete 180 in terms of direction wrt overlayfs. it has always been "no, because it can't be backported"14:36
jdstrandtyhicks: fyi ^14:36
jdstrandratliff: ^14:36
jdstrandzyga-ubuntu: you mentioned something about a fallback to !overlayfs. if that is supposed to work as well as (from the pov of the user) overlayfs, why not just focus on that instead? you can answer that in the forum (it was one of my questions)14:37
kalikianafg14:41
kalikianaOops14:41
morphiszyga-ubuntu: this means we will always have two different implementations inside snapd for the layouts feature?14:42
kenvandineseb128, the user-dirs.defaults directories, are the actual directory names translated?  Or just the presentation of them?14:43
kenvandines/are the/are they14:43
seb128kenvandine, the actual dirs14:43
kenvandinebummer14:43
kenvandineok14:43
kenvandineis there an easy way to get those names?  Or do i need to parse them out of user-dirs.defaults?14:43
zyga-ubuntumorphis: I don't know yet14:44
* kenvandine thought there was an easy way14:44
seb128kenvandine, g_get_user_special_dir ()14:44
kenvandineyeah, but nothing available in a shell script14:44
seb128you can use the binding from python14:45
kenvandinei guess i can look at the g_get_user_special_dir implementation14:45
kenvandineah14:45
kenvandineseb128, although i doubt starting a python interpretor in the desktop helpers would be a good idea speed wise14:46
morphiszyga-ubuntu: please let me know once you guys are closer to a decision on this as this will have quite some impact on system enablement etc.14:46
seb128kenvandine, $ python -c "from gi.repository import GLib; print(GLib.get_user_special_dir(GLib.USER_DIRECTORY_DOCUMENTS))"14:46
zyga-ubuntumorphis: right, I think this will happen one gustavo is back14:47
tyhickszyga-ubuntu: I'm sure you are aware of this but there will be a considerable lead time before apparmor and overlayfs can be fully working together and the one or two people that can work on that are committed to other work14:47
seb128kenvandine, it wouldn't be the slowest thing in there...14:47
zyga-ubuntumorphis: in the meantime I'll work on options14:47
seb128kenvandine, but yeah, probably easier to just shell parse the .config14:47
zyga-ubuntutyhicks: noted,14:47
kenvandineseb128, thx!14:48
seb128kenvandine, yw14:48
morphiszyga-ubuntu: aye14:48
zyga-ubuntutyhicks: ultimately it is not my decision, I'll just collect facts and help make the descision clear14:48
tyhickszyga-ubuntu: that makes sense - just be sure to point that out if you're in a conversation where the decision is being made14:49
om26erpopey: for you: https://forum.snapcraft.io/t/please-allow-my-android-studio-snap/2634 :-)14:49
zyga-ubuntutyhicks: you will be in the call I'm sure14:49
tyhickssometimes it works out like that, sometimes not :)14:50
tyhicks(in all projects - not just snappy)14:50
=== cachio is now known as cachio_lunch
* zyga-ubuntu breaks for some follow-the-news time15:11
jdstrandkenvandine, seb128: in the past we have said that we won't support translatable directories in the filesystem (how they are presented to the user is entirely different of course). that hasn't changed, has it?15:18
kyrofaHuh. elopio what might be causing this? https://travis-ci.org/snapcore/snapcraft/jobs/29234157715:24
kyrofaAny chance it's from the "use the snap for integration tests" PR?15:24
mupBug #1728076 opened: Initialize Device transaction incorrect "Done" status <Snappy:New> <https://launchpad.net/bugs/1728076>15:32
kenvandinejdstrand, i remember some discussions on that, but i don't recall the details15:33
kenvandinejdstrand, i've found an easy way to get those from xdg-user-dirs15:33
kenvandinein practice what it gives me might not be translated though15:34
kenvandinejdstrand, seb128: http://paste.ubuntu.com/25830955/15:37
kenvandinethat seems to work15:37
kenvandinebut i need to try that with a different LANG now15:37
jdstrandkenvandine: this came up a long time ago wrt click. basically, upstream and Ubuntu felt that translating those at the filesystem level was a mistake. ie, it should always be /home/foo/Documents, not /home/foo/SomeTranslatedThing15:38
jdstrandkenvandine: so we don't support translated dirs officially. as it happens, with the home interface and because all of $SNAP_USER_DATA is usable by the snap, this hasn't been an issue on snappy15:39
jdstrandkenvandine: that said, I don't think user-dirs.dirs is readable today15:40
jdstrandkenvandine: no it isn't. I'm getting lose to writing a PR that will make it readable15:41
jdstrandclose*15:41
=== chihchun is now known as chihchun_afk
seb128jdstrand, who is "we"? translated directories are a xdg reality for 10 years...15:45
ogra_s/reality/annoyance/ :P15:46
kyrofakalikiana, commented on snapcraft#164115:46
mupPR snapcraft#1641: lxd: catch CalledProcessError in _container_run <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1641>15:46
seb128ogra_, says a german speaker...15:46
ogra_who has to type "Arbeitsfläche" instead of Desktop on one machine ... i hate that15:47
jdstrandseb128: you were in the conversation. I remember discussing it in person with you and Allison. we all agreed it was a mistake even if they've been there for 10 years. and we agreed click wouldn't support them. I can pull up bugs to remind you if needed :P15:47
kalikianakyrofa: Thanks!15:47
seb128jdstrand, you might be right, I vaguely remember discussing it but not in the snap context, maybe it was clicks15:47
seb128jdstrand, issue is that for snaps you have to deal with existing apps15:47
jdstrandseb128: no, it wasn't the snap context. only clicks15:47
ogra_(i dont mind Bilder vs Pictures and the like ... but translating the Desktop dir always puts me off)15:47
jdstrandseb128: I was saying with snaps we inherited non-support initially, but now with home and SNAP_USER_DATA, it mostly doesn't matter15:48
jdstrandonly if we decide to carve up the home interface would it be an issue15:49
kenvandineseb128, i guess this is the first time i've run a snap using a different lang... so snaps aren't showing as translated?15:49
ogra_on the phone we could do the translation on the UI level because we had the content-hub and friends15:49
* jdstrand notes that the gtk3 file chooser or nautilus or whatever could present anything they want (that was what we concluded unity8 might end up doing)15:50
seb128kenvandine, they do if built properly15:50
ogra_that is why it wasnt a problem there ... there was a way bigger separation15:50
kenvandineseb128, so i guess mine aren't :)15:50
kenvandineseb128, what's the magic?15:50
seb128kenvandine, do you use the --prefix build hack?15:50
kyrofakalikiana, did you approve snapcraft#1644 ?15:50
mupPR snapcraft#1644: lxd: fix the push in container builds <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1644>15:50
kenvandineseb128, yes15:50
kyrofaRather, I know you didn't, but DO you approve15:51
seb128kenvandine, then translations should work...15:51
jdstrandogra_: right15:51
jdstrandbut again, it isn't actually a problem here15:51
ogra_yeah15:51
jdstrandcause we don't separate ~/Videos from ~/Documents15:51
kenvandinejdstrand, ${XDG_CONFIG_HOME:-~/.config}/user-dirs.dirs is readable because it's under $SNAP_USER_DATA15:52
kenvandineand we run xdg-user-dirs-update after setting that15:52
kenvandineso it should do the right thing15:52
jdstrandif we did, and if translated xdg dirs are still a thing (and it sounds like they are; I guess upstream didn't pursue something better), then there would be work to do make them work in the policy (which is possible)15:53
jdstrandkenvandine: yeah, but, where are you getting that?15:53
jdstrandkenvandine: https://forum.snapcraft.io/t/xdg-user-dirs-and-dconf-apparmor-denials/2390/315:54
jdstrandkenvandine: in addition to that, I also need to add ~/.config/user-dirs.conf15:54
kenvandinethe desktop helper runs xdg-user-dirs-update after setting $XDG_CONFIG_HOME properly15:54
jdstrandkenvandine: in addition to that, I also need to add ~/.config/user-dirs.dirs?15:54
kenvandinejdstrand, that would be good15:55
jdstrandok15:55
jdstrandI was talkingn about .conf15:55
jdstrandbut we should also allow /etc/xdg/user-dirs.defaults15:55
kenvandineyeah15:55
elopiokyrofa: ugh, you broke it :( it worked less than a day.15:56
kyrofaelopio, hahahahaha15:56
elopioLet me check the logs to see if I can understand something there. But more likely I'll have to debug.15:56
jdstrandzyga-ubuntu: I gave spread the wrong args and it is running all the tests. I can't seem to kill it15:56
zyga-solusjdstrand: qemu or linode?15:57
jdstrandzyga-ubuntu: I bg'd it and tried -discard, but it held the lock15:57
zyga-solusjdstrand: if qemu just kill qemu process15:57
jdstrandzyga-ubuntu: linode15:57
zyga-solusjdstrand: ah15:57
jdstrand(hence the wrong argument15:57
zyga-solusjdstrand: kill spread and -discard then15:57
kenvandineseb128, confirmed gedit is using the prefix hack but not showing up as translated for me15:57
zyga-solus(run the same thing bug pass -discard)15:57
kenvandineseb128, can you please confirm?15:57
jdstrandok, wasn't sure that would work15:57
zyga-solusyes, all you need is in that local .spread.* file15:58
zyga-solusit just kills the node from the lindoe API15:58
sergiusenskyrofa can you look at my comment on snapcraft#1641, the objective is to not print an error, not to capture and print the same error again16:01
mupPR snapcraft#1641: lxd: catch CalledProcessError in _container_run <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1641>16:01
jdstrandzyga-solus: did you disable rate limiting? I think we are doing that by default now in spread, but worth asking16:01
seb128kenvandine, indeed, (gedit:8296): Gtk-WARNING **: Locale not supported by C library.16:01
seb128Using the fallback 'C' locale.16:01
kyrofasergiusens, right, capturing it would cause it to _not_ be printed16:01
zyga-solusjdstrand: no, I didn't! that's a good think to check16:01
kyrofasergiusens, and give us the ability to print it16:01
kyrofasergiusens, rather than traceback, we can simply use the stderr16:02
kalikianakyrofa: Yes. I was reluctant to give my v here since I changed the unit tests. But the fix is good to my mind16:02
seb128kenvandine, I had my ghex snap working with that wrapper http://bazaar.launchpad.net/~ubuntu-desktop/+junk/ghexudt/view/head:/ghex.wrapper16:03
jdstrandzyga-solus: note that if it is a capability denial, apparmor itself might be rate limiting it (it actually rate limits quite a few things. see: https://bugs.launchpad.net/apparmor/+bug/1707743). capability is the only one that really seems to be a problem16:03
mupBug #1707743: denied capability logged only after profile load <aa-kernel> <AppArmor:New> <https://launchpad.net/bugs/1707743>16:03
jdstrandzyga-solus: perhaps you could add a base capability rule and see if it passes? 'capability,'16:04
jdstrands/base/bare/16:04
seb128kenvandine, the desktop launcher has https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/common/desktop-exports#L127 ... did you try to stage locales-all?16:05
zyga-solusjdstrand: trying16:05
=== cachio_lunch is now known as cachio
seb128kenvandine, that might take space though, the hack in ghex was only needing libc-bin/locales iirc which is smaller16:06
sergiusenskyrofa kalikiana why is it not possible to NOT traceback and NOT print?16:08
sergiusenskyrofa on a cli, you will run something, it will be seen as a double error being printed16:08
kyrofasergiusens, we're saying the same thing, perhaps we should jump on a HO?16:09
ogra_to say the same thing aloud ?16:10
kyrofaogra_, in harmony16:11
ogra_yeah, thats what i imagined16:11
jdstrandzyga-solus: I see the same thing. no denial16:12
kenvandineseb128, i'll play around with it16:12
kenvandineseb128, thx16:12
zyga-soluscapability didn't change it16:13
kenvandineseb128, i can probably add locales-all to the platform16:15
jdstrandzyga-solus: try removing this: deny capability fsetid,16:15
zyga-solusk16:15
jdstrandzyga-solus: or turn it into an allow by removing 'deny'16:15
zyga-solusjdstrand: running, though it is on the parent profile so probably not a factor16:16
jdstrandremoving the rule would still have it deny of course16:16
zyga-solussure16:16
sergiusenskyrofa I think you want to handle the printing the exception handler which requires all of what you mentioned is needed. I am just saying, from whatever calls lxc exec, raise a specific exception that will be caught and handled differently16:16
jdstrandzyga-solus: that should be unrelated anyway, but, like I said, there are some weird bugs16:17
jdstrand(with overlayfs and apparmor)16:17
kyrofasergiusens, handled differently i.e. just exit non-zero and don't say anything extra?16:17
kyrofaI think we can do that just by raising a SnapcraftError(), but I'll check16:19
kyrofaWe'll need a SnapcraftError with a __str__ that is empty16:20
sergiusenskyrofa yes, exactly; given that the run was owned by the instance of snapcraft run inside the container; if we go a different path this will be exceedingly complex to handle; that said, in a future PR we could just use the piping mechanism to create a .log of the build when using containers (should be straightforward)16:21
kyrofasergiusens, yeah that seems to be the direction we're heading overall anyway16:22
kyrofasergiusens, when it comes to the nested snapcraft I totally agree16:22
kyrofasergiusens, but doing the same for the setup stuff isn't quite as clear. How do you feel about hiding that behind a progress bar?16:22
zyga-solusjdstrand: no change16:23
kyrofaIt'll take two PRs to do that, this one using essentially a dumb exception, and another one splitting the setup tasks out16:24
jdstrandzyga-solus: I've dropped to the shell in spread. I should just be able to edit the profile and run stuff, right? I tried to run test-snapd-content-advanced-slot.sh' but things went terribly wrong16:25
jdstrand/bin/sh: 0: Bad substitution16:25
jdstrandrepeated forever. I couldn't recover and had to kill the vm16:25
zyga-solusyes16:28
zyga-solusyes, that breaks, paste the same line you saw in the test and it will work16:29
zyga-solusso16:29
zyga-ubuntutest-snapd-content-advanced-plug.sh -c 'test -d $SNAP/target'16:29
zyga-ubuntuthis will re-try16:29
zyga-ubuntu /usr/lib/snapd/snap-discard-ns test-snapd-content-advanced-plug; test-snapd-content-advanced-plug.sh -c 'test -d $SNAP/target'; echo $?16:29
zyga-ubuntuthis is even better16:29
sergiusenskyrofa what setup stuff?16:30
jdstrandzyga-solus: unfortunately I was winging it cause I did 'reset' :)16:30
kyrofasergiusens, installing squashfuse, injecting snaps, the stuff that failed for popey that spawned that PR16:30
sergiusenskyrofa oh, that should be handled the way we usually handle exceptions in our code base16:31
kyrofasergiusens, right, which is what kalikiana did. Problem is, the codepath is the same16:31
kyrofasergiusens, so my suggestion is: if we're splitting them out, might as well put that stuff behind a progress bar16:32
mupPR snapd#4094 closed: tests: cherry pick the fix for services test into 2.29 <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4094>16:33
sergiusenskyrofa code path the same being, the sequence of steps comes one after the other?16:33
sergiusensthey just need to be handled differently then, a progressbar could do, but I would hold off on that until we have a better separation of cli/logic16:34
kyrofasergiusens, no, they all go through `_container_run`, which is where the exception-handling logic has been added. They just need to be, yeah, treated differently16:35
kyrofasergiusens, okay, I'll summarize on the PR16:35
sergiusensthanks16:36
kalikianakyrofa: treat differently how? I'm a bit lost now16:36
kyrofakalikiana, don't worry, I will try to make all things clear in my summary16:36
kalikianaOkay thanks16:36
=== JoshStrobl|zzz is now known as JoshStrobl
mupPR snapd#4096 opened: spread: welcome bionic beaver <Created by mvo5> <https://github.com/snapcore/snapd/pull/4096>16:37
kalikianabtw wrapping up for today now - I'll be off most of next week (you can see it in the team view) but will be checking in here and there for comments etc16:38
mvocachio: finally! 2.29~rc2 for i386,amd64 - arm is still pending, no idea what is going on with the arm autobuilders currently, super slow16:45
ogra_i guess you are fighting with doko ;)16:48
ogra_initial import of bionic etc16:48
=== chihchun_afk is now known as chihchun
jdstrandzyga-solus: I've spent way more than 15 minutes on this. unfortunately, my desktop crashed and I lost all state (/me shakes fist at wayland/mutter not being able to restart)16:57
jdstrandzyga-solus: I don't think there is enough information to definitively say it is apparmor. however, you could try different bare rules to see what is the issue16:58
zyga-solusjdstrand: thank you for the effort16:58
zyga-solusjdstrand: I think this is enough for now16:58
jdstrandzyga-solus: eg, add 'file,'16:58
jdstrandthen mount,16:58
jdstrandthen ptrace,16:58
jdstrandetc16:58
zyga-solusI'll try16:58
jdstrandmaybe one of them will work and that will provide a clue16:59
jdstrandcould be a logging bug16:59
jdstrandcould be a poor interaction between attach_disconnected and overlayfs16:59
jdstrandit would not surprise me at all if attach_disconnected is mapping something to the wrong place17:00
jdstrandzyga-solus: ^17:00
zyga-solusaha17:00
zyga-solusI'll try all and we'll know more next time17:01
zyga-solusthank you for investigating this17:01
jdstrandremember, attach_disconnected is a hack. overlayfs would ideally be giving us the proper locations. attach_disconnected just says connect anything that is disconnected to '/'17:01
jdstrandzyga-solus: ^17:01
jdstrandok, yw17:01
zyga-solusI see, I didn't know it's a hack17:02
cachiomvo, could you please upload the snap https://github.com/sergiocazzolato/snapd/tree/tests-interface-gsettings/tests/lib/snaps/test-snapd-gsettings17:03
kyrofasergiusens, snapcraft#1636 is ready, but you put 2.36 on there. Does that mean you don't want it in just yet?17:03
mupPR snapcraft#1636: internal: more gracefully determine host OS <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1636>17:03
kyrofaIt's not approved yet either, to be clear17:04
kyrofaI'm also good with snapcraft#1593 if you want to take a look17:05
mupPR snapcraft#1593: catkin tools plugin: add catkin tools support <Created by cratliff> <https://github.com/snapcore/snapcraft/pull/1593>17:05
cachiomvo, I am running beta validation now17:05
kyrofaelopio, also, what do you think about the plainbox tests? Do you agree that we should remove the years?17:08
om26erwhy do classic snaps need manual approval ?17:23
ogra_because they have full system access17:24
om26erwhen does ogra_ actually go offline ?17:24
ogra_heh17:25
om26eranyways, I have a android-studio snap waiting manual review because its a classic snap. Hopefully that'll get figured out soon.17:25
elopiokyrofa: yes, I'll update my branch. Sorry the day.got complicated and I'm in a bus.17:30
kyrofaelopio, quite alright, I'm happy to update it if you like, I just wanted to make sure you agreed17:30
elopiokyrofa and your PR has the snap stage after.that integration test. That way it will never work. I'm not sure what's going on, I'll keep digging.17:31
kyrofaelopio, huh...17:31
elopiokyrofa yes please, go for it17:31
sergiusenskyrofa if you provide a list of all the systems you've checked then maybe yes; but I put 2.36 on most so the focus would stay on things for 2.35 and potentially the pip/python stuff (which is the only thing we could think about backing into 2.35)17:33
kyrofasergiusens, alright I figured, just wanted to make sure we were on the same page17:33
sergiusensthe "just one more thing" is what is causing all these release delays ;-)17:33
kyrofaHaha, amen17:34
kyrofaIf you want to just lock down the release now that's fine too. Focus on autopkgtests17:35
kyrofasergiusens, remember we can always make a release branch for stabilizing if we don't want to hold up landings17:35
kenvandinejdstrand, are you actively working on adding access to user-dirs related paths?17:36
sergiusenskyrofa I don't mind as we all have things to work on for 2.35; this is not a big team :-)17:36
jdstrandkenvandine: yes. I'm preparing a branch with various updates that includes that as we speak17:36
sergiusensI really want our small team to focus on 2.3517:36
kenvandinejdstrand, excellent17:36
kyrofasergiusens, alright will do. I'll focus on autopkgtests17:37
mvocachio: thanks! core build still tells me in 1h/2h for armhf/arm64 :(17:42
mvocachio: I keep an eye one it17:42
cachiook, np17:43
cachiomvo, ce you updaload the snap I'll create the PR17:44
=== cachio is now known as cachio_afk
sergiusenskyrofa feel free to make the ocd change in snapcraft#164417:54
mupPR snapcraft#1644: lxd: fix the push in container builds <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1644>17:54
kyrofasergiusens, haha, okay17:54
=== ahasenack is now known as andreas
elopioalright, back on my machine18:21
stokachunoise][: can you give cory johns @canonical.com access to charmtools snap?18:24
elopiokyrofa: I will start the hangout in a few minutes. Let me know if you want to join to test. Also sergiusens where in the world are you? You are welcome to join us, of course.18:25
mupPR snapd#4097 opened: interfaces/many: miscellaneous updates based on feedback from the field <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4097>18:26
kyrofaelopio, awesome18:26
sergiusenselopio I am finally home, since yesterday!18:26
stokachunoise][: sorry the snap is "charm"18:26
stokachunoise][: or maybe give ownership to the same group you did with conjure-up18:26
zyga-ubuntumvo: hey, still there?18:26
jdstrandmvo: hey, I know its late, but there is the PR I was talking about. no need to review now, but I add the 2.29 milestone-- is that what you wanted me to do?18:27
zyga-ubuntumvo: sorry for going AWOL, tracking unfolding events in spain now18:27
stokachunessita: or if you're available to give access to charm for the canonical group (same group set for conjure-up)18:27
stokachusergiusens: seen https://pastebin.ubuntu.com/25830958/ before?18:28
nessitastokachu, hey there. I can't add collaborators, you need mvo for that, sorry18:28
stokachunessita: ok ty!18:28
stokachumvo: if you got a minute from the spain madness :)18:29
zyga-ubuntustokachu: mvo or me?18:30
stokachuzyga-ubuntu: can you give store access to people?18:30
zyga-ubuntustokachu: I don't think I can18:30
stokachuok18:31
sergiusensstokachu seems like request's raise_for_code did not get triggered and status was not returned in the json results. Mind logging a bug? Is this a one time thing?18:33
sergiusensFacu any idea about that scenario ^ in stokachu's pastebin?18:33
stokachusergiusens: cory_fu is the one that hit this issue18:34
jdstrandkenvandine: fyi, https://github.com/snapcore/snapd/pull/409718:34
mupPR #4097: interfaces/many: miscellaneous updates based on feedback from the field <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4097>18:34
kyrofaelopio, give me the link when you have it18:34
elopioone second18:34
cory_fusergiusens: Pretty sure it's because I don't have access to the snap yet (there's an invite pending, but I never got the email nor can I find it via the Dashboard)18:35
Facusergiusens, nop18:35
Facucory_fu, but you can repeat it, right?18:36
sergiusenscory_fu ah, no snap access, that should return some sort of 5xx I believe, but let me try and release a snap I don't have listed here and see what happens; if you don't mind a bug might help this from falling into the cracks18:36
cory_fusergiusens: Yep, filing one to LP now18:36
cory_fuFacu: Yes, I can reproduce it18:37
cory_fuhttps://bugs.launchpad.net/snapcraft/+bug/172812118:38
mupBug #1728121: Traceback from snapcraft release <Snapcraft:New> <https://launchpad.net/bugs/1728121>18:38
elopiokyrofa, sergiusens and anybody else who would like to join the ubuntu hour: https://hangouts.google.com/hangouts/_/jdpkqoaaz5fw7f6b2jlmhy5auie18:41
mupPR snapd#4098 opened: snap-confine: allow reading uevents from any where in /sys <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4098>18:41
jdstrandmvo: same question for ^18:41
Facucory_fu, sergiusens, will track this server side, thanks18:42
=== JoshStrobl is now known as JoshStrobl|Store
kenvandinejdstrand, cool, i'll watch that18:44
kenvandinejdstrand, also i have a WIP branch for the helpers https://github.com/kenvandine/snapcraft-desktop-helpers/commit/9be256f76362a4f109890e033d9fc5467144f71518:44
sergiusensFacu stokachu cory_fu I can totally reproduce this https://pastebin.ubuntu.com/25831852/18:45
jdstrandkenvandine: come to think of it, `id -u` will be more robust than $UID. istr not always having $UID18:46
Facusergiusens, also trying to release something you don't have permissions?18:46
jdstrandkenvandine: and cool! :)18:46
sergiusensI will look at the responses a bit closer (we could add one more call before release to get the account info and verify you can release to that snap if it comes to it).18:46
sergiusensFacu yes, I have no access to conjure-up :-)18:46
Facusergiusens, I would have thought that the server is not 200ing in this case, will check18:47
sergiusensFacu ah, it is the exception that is at fault18:48
sergiusenswe have if not response.ok and pass the response to our own exception implementation18:48
sergiusensFacu I'll take it from here :-)18:49
Facusergiusens, so, server is returning that you can not access it, right?18:50
sergiusensFacu at least returning something saying it is not ok19:05
mvojdstrand: what was the question?19:21
mvojdstrand: I think thats reasonable19:21
jdstrandmvo: you said to 'tag' the PR with 2.29. I don't see 'tag's in the github interface, so I milestoned it19:22
jdstrandmvo: I just wanted to make sure I was doing what you asked :)19:22
mvojdstrand: yeah, sorry, milestoned is the right thing19:22
jdstrandok, cool19:22
mvojdstrand: thanks! this is fine for 2.2919:22
jdstrandthank you :)19:22
jdstrandmvo: note it is 4097 and 4098 (both only add access so not risky)19:23
=== JoshStrobl|Store is now known as JoshStrobl
mvojdstrand: aha, thank you19:26
=== cachio_afk is now known as cachio
mvocachio: armhf/arm64 is now ready as well19:29
cachiomvo, great19:30
cachioI'll run that now19:30
mvocachio: thanks a lot!19:30
mvocachio: keep me updated please :)19:30
cachiomvo, so far everything passed19:31
cachiomvo, l run the devices now19:33
mupPR snapd#4054 closed: snap-{confine,seccomp}: make @unrestricted fully unrestricted <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4054>19:56
=== JoshStrobl is now known as JoshStrobl|Food
mupPR snapd#4099 opened: merge 2.29~rc2 release back into master <Created by mvo5> <https://github.com/snapcore/snapd/pull/4099>20:00
om26erdoes the dump plugin support dynamic `source` parameter ?20:19
om26ermaybe a script that resolves to a url ?20:19
=== JanC_ is now known as JanC
kyrofaom26er, no, can you explain your use-case?20:27
om26erkyrofa: There is no direct link for the source zip that I want to download from. The url is resolved after a script is executed.20:28
kyrofaom26er, can you execute it locally and then copy/paste that URL?20:29
om26erI am setting version using version-script but was looking for a way to set the `source` as well.20:29
kyrofaom26er, you always do it in a local plugin20:29
kyrofaom26er, inherit from the dump plugin but make the source dynamic20:29
kyrofayou CAN always, rather20:30
om26erkyrofa: that could work but I was thinking to full automate it. i.e. whenever I know there is a new release available, just do a dummy commit to my snap package and push so that auto build kick in20:30
kyrofaom26er, yeah this doesn't preclude that20:31
kyrofaI do the same thing for daily builds, although in my case the URL is just a symlink20:31
kyrofaI just change the version and push20:31
om26erkyrofa: can you share examples of a local plugin ?20:32
kyrofaom26er, sure thing, one sec20:33
kyrofaom26er, here's an example: https://github.com/nextcloud/nextcloud-snap/blob/master/snap/plugins/x-php.py20:33
kyrofaYou just need to put them in snap/plugins and snapcraft will find them20:34
kyrofa(like they are there)20:35
om26erkyrofa: so when I refer them in my yaml I prepend `x-` ?20:35
kyrofaom26er, no actually-- refer to the YAML in that same project20:35
om26erkyrofa: you got an example to override dump plugin somewhere ?20:36
kyrofaThe naming pattern is confusing, so just trust me: name your plugin x-<plugin name>.py and then refer to it in the YAML as <plugin name>20:37
kyrofaom26er, I don't, but simply import snapcraft.plugins.dump and inherit from snapcraft.plugins.dump.DumpPlugin20:37
kyrofaom26er, then overwrite the `pull` method, but not the `build`20:38
om26erlooking into this.20:41
mupPR snapcraft#1546 closed: cli: update parts cache in the container <Created by kalikiana> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1546>20:48
=== JoshStrobl|Food is now known as JoshStrobl
=== JoshStrobl is now known as JoshStrobl|Away
sergiusenselopio what is that close/open attempt all about on snapcraft#1607 ?21:29
mupPR snapcraft#1607: python plugin: use extracted pip <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1607>21:29
elopiosergiusens: kyle broke the order of the stages. I turned it on and off again to fix it.21:31
kyrofaelopio, wait... what?21:34
kyrofaHow did that fix things? :P21:34
elopio(shrug)21:35
mupPR snapd#4100 opened: add ssh-keys, ssh-public-keys, gpg-keys and gpg-public keys interfaces <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4100>21:37
elopiokyrofa I saw only yours was failing that way, and restarting didn't help21:38
elopioI was just touching buttons. It might be necessary to do this for the ones that have been open before the change.21:39
elopioI'm going to propose the transfer nicety now.21:43
kyrofaelopio, quick plug for the `transfer` snap22:08
sergiusenskyrofa why transfer when you can wormhole it ;-)22:12
kyrofasergiusens, one to many versus one to one22:12
kyrofasergiusens, elopio is talking about making the snapcraft snap available for each PR by uploading it to transfer.sh22:12
sergiusenskyrofa ah, it would be much nicer to have a webhook sent to some infra we control that would end up pushing and releasing to a branch :-)22:17
sergiusensbut one step at a time22:17
elopioQuick cheat until build.snapcraft.io makes it nicer for us22:17
sergiusenskyrofa is transfer.sh the one from mozilla?22:17
elopiosergiusens: the bot can't release to a branch yet22:18
sergiusensah, no, it was send (the one from mozilla)22:18
sergiusenselopio btw, how is the bot protected?22:18
elopiosergiusens ssh-only on Google cloud.22:19
elopioACLs for the commands, but the commands can't expose the password.22:20

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