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

=== robert_ancell_ is now known as robert_ancell
=== JoshStrobl is now known as JoshStrobl|AFK
PhoenixMageHi all05:40
PhoenixMagezyga-solus: Has your layout remapping stuff been released yet?05:40
zyga-solusPhoenixMage: no, but it's slowly taking shape05:46
zyga-solusPhoenixMage: I hope to land the first user visible thing today05:46
zyga-solusPhoenixMage: and then the most useful user visible thing (overlayfs)05:46
PhoenixMagezyga-solus: Nice, let me know if you need a guinea pig05:47
PhoenixMageNow I am back from vacation05:47
PhoenixMageNeed to get some Olimex Lime2 boards I think05:47
zyga-solusPhoenixMage: I could use code review right away :)06:43
zyga-solusPhoenixMage: if you are interested in that I can show you the way06:44
zyga-solusok, 50% sent to school, time for some work06:47
PhoenixMagezyga-solus: Code is not my strong suit :/06:51
zyga-solusPhoenixMage: I see, thank you for the offer still06:55
zyga-soluspstolowski: hello07:31
zyga-soluspstolowski: I was wondering how much work is needed to land https://github.com/snapcore/snapd/pull/3972 and let you iterate07:32
mupPR #3972: repo: sanitize plugs and slots early in ReadInfo <Created by stolowski> <https://github.com/snapcore/snapd/pull/3972>07:32
pstolowskizyga-solus, hey!07:34
pstolowskizyga-solus, 3972 itself is ready and captures item 1 of the plan I hope (https://forum.snapcraft.io/t/preparing-the-interfaces-logic-for-connection-hooks/2184)07:36
pstolowskizyga-solus, items 2 and 3 are ready and I'm about to push a PR for that07:36
pstolowskizyga-solus, item 4 ready too (will be part of same PR)07:37
zyga-soluspstolowski: I wonder if we can get a 2nd review for 3972 today07:37
zyga-soluspstolowski: maybe chipaca can help?07:37
pstolowskizyga-solus, I need the second review from Gustavo07:37
pstolowskizyga-solus, the sprint this week isn't going to help :/07:38
PhoenixMagezyga-solus: Configuration and troubleshooting is more my area08:03
zyga-solusikey: hey, around?08:27
seb128https://errors.ubuntu.com/problem/65c0ce797c1e385496c43cb7d869f3e2c0bc55ab looks like it could be a snappy issue?08:42
seb128those reports have that error message08:42
seb128 hook configure in snap "core" failed: cannot change profile for the next exec call: No such file or directory08:42
zyga-solusseb128: looking08:51
zyga-solusseb128: typically that means ubuntu package reused on !ubuntu kernel08:51
seb128zyga-solus, thanks, I guess those reports don't have enough details to be useful then08:52
zyga-solus 4.11.1-041101-generic08:52
zyga-soluslook at the kernel08:52
zyga-solusthat looks like the mainline kernel08:53
zyga-solusI've been working on some patches that will let us work on mainline kernels soon, I may be able to put that into 2.2908:53
mupPR snapd#4011 opened: cmd: correctly name the "Ubuntu" and "Arch" NVIDIA methods <Created by zyga> <https://github.com/snapcore/snapd/pull/4011>09:15
mupPR snapd#4012 opened: cmd: add autoget case for solus <Created by zyga> <https://github.com/snapcore/snapd/pull/4012>09:22
mupPR snapd#4013 opened: repo, daemon: use PlugInfo, SlotInfo <Created by stolowski> <https://github.com/snapcore/snapd/pull/4013>09:41
* __chip__ hugs mwhudson 10:26
__chip__mwhudson: just realised the two oldest PRs are yours10:27
=== JoshStrobl|AFK is now known as JoshStrobl
* zyga-solus -> food11:21
c-lobranoelopio: Hi, I'm on bug 1604815, but there might be a problem with the tests. The test_release_snap_to_invalid_channel triggers the same BAD RESPONSE reply of the bug, but the response payload doesn't seem the one expected (https://dashboard.snapcraft.io/docs/api/snap.html#id3) since the "errors" key is paired with a str and not with a list of dicts. Can you confirm, or am I missing something? Thanks!11:40
mupBug #1604815: The error when trying to release a revision that's not a integer is ugly <bitesize> <Snapcraft:In Progress by c-lobrano> <https://launchpad.net/bugs/1604815>11:40
zyga-solus re11:50
zyga-solusnow back to work11:50
mupPR snapd#4012 closed: cmd: add autogen case for solus <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4012>12:10
niemeyerpstolowski: Let's see if I can look quickly before the plenary starts here12:12
zyga-solusniemeyer: hey12:12
zyga-solusniemeyer: how's the sprint?12:12
pstolowskiniemeyer, o/, thanks12:19
niemeyerpstolowski: Sent a first review12:31
niemeyerpstolowski, zyga-solus: Let's please try to have sane code..12:31
niemeyerzyga-solus: Sprint starting just now12:31
zyga-solusniemeyer: ack12:35
zyga-soluspstolowski: I left a comment on the PR12:38
zyga-solusman, I should have read more kernel docs12:38
zyga-solusI found a good way to solve another problem12:39
__chip__zyga-solus: ...? :-)12:39
zyga-solus__chip__: notify_on_release is such a natural12:40
__chip__zyga-solus: sysctl -w kernel.global-warming=0 ?12:40
zyga-solushaha12:40
zyga-solusthat'd be nice12:40
__chip__who's standup-able today?12:41
zyga-solusI am12:41
__chip__me too12:41
zyga-solususing notify_on_release I can solve an existing problem naturally12:41
__chip__zyga-solus: isn't the release-agent snapside?12:43
wdouglasswhen i snap runs, is it chrooted to the /snap/packagename/xx/ directory? i'm trying to figure out how paths work in a snap12:43
wdouglasslike if i do 'snap run --shell packagename' it's not chrooted, but the environment is set up12:43
__chip__wdouglass: it's not chrooteed, no; what exactly are you trying to figure out?12:43
wdouglass__chip__: i'm trying to run a tkinter program, and it can't find 'init.tcl'12:43
wdouglassi'm trying to set the paths properly, and in a way that's portable.12:44
__chip__wdouglass: "snap run --shell" is the exact same environ12:44
wdouglasshmm ok12:44
__chip__oooh, that should be fun12:44
__chip__wdouglass: we haven't snapped a tcl thing before? strange12:44
zyga-solus__chip__: snapside? I mean it snapd could then do the cleanup properly12:44
wdouglasswell I haven't12:44
wdouglassi'm very new at this12:44
zyga-soluswdouglass: it's not as simple as that12:45
zyga-soluswdouglass: when snap runs it gets a mount namespace with the designated base snap as the rootfs12:45
zyga-soluswdouglass: and a few things changed all around the place to make the world workable12:45
zyga-soluswdouglass: the shell advice is very useful, explore and look around12:45
__chip__wdouglass: https://stackoverflow.com/questions/39177158/tcl-cant-find-init-tcl-in-a-snap-package12:45
zyga-soluswdouglass: you may also look at how mounts are laid out12:45
wdouglassi saw that stackoverflow -- i'm trying to have as little impact on my upstream package as possible.12:46
__chip__ah12:46
__chip__wdouglass: but the answer there doesn't seem (at a quick read) to impact the upstream code at all?12:46
pstolowskiniemeyer, thanks for the review12:46
__chip__zyga-solus: “the kernel runs the command specified by the contents12:47
__chip__of the "release_agent" file in that hierarchy's root directory”12:47
wdouglasshmmm...guess i didn't really understand the "glue" section. i'll look into that12:47
__chip__wdouglass: the "wrappers" are little scripts that set up the environ before calling the binaries12:48
wdouglassok, so i can just put those wrappers next to my snapcraft.yaml, and then use the 'copy' plugin to put them in the right place?12:48
__chip__yes12:49
wdouglassawesome. Thanks for the clarification12:49
zyga-solus__chip__: right, that's what I need12:49
__chip__zyga-solus: but my point was that "that hierarchy" is snapside12:49
zyga-solushmm, I don't follow12:50
zyga-solussnap-side as in ?12:50
zyga-soluswhere?12:50
zyga-solus__chip__: my intent is to have that run snap-discard-ns (indirectly012:51
zyga-solus__chip__: this would allow us to simplify snap-confine12:52
__chip__zyga-solus: i mean it runs inside the namespace, doesn't it?12:52
zyga-solus__chip__: I don't think so12:52
zyga-solusbut even if that's the case it's not a problem12:53
__chip__ok, fair enough12:53
zyga-solus__chip__: we can setns outside and unmount what we have to12:54
zyga-solus__chip__: setns, unmount, unlink, done12:54
zyga-solusthat and the locking12:54
wdouglasshmmm....ok, the tcl wrapper thing worked. thanks for that. Now there's a new problem! i'm getting some fontconfig errors. "Unable to update the static FcBlanks"13:07
wdouglassis there a trick to getting fontconfig working?13:07
=== JoshStrobl is now known as JoshStrobl|Work
zyga-solusand now I notice that chipaca is *not* on irc13:14
zyga-solus__chip__: so does that give 4011 two +1s?13:20
zyga-solusI +1d the orinal13:20
zyga-solusoriginal*13:20
zyga-solusnote that I need to also update the packaging trees but nvidia is not tested much13:20
zyga-solusI shall better to that13:21
zyga-solus__chip__: are you using python ;)13:22
__chip__zyga-solus: in what sense?13:35
__chip__zyga-solus: this nick comes from my python days, yes13:35
__chip__for when i was feeling "special"13:35
__chip__or i wanted to pull __lucio__'s leg13:35
zyga-solushaha13:38
zyga-solusI was wondering the dunder semantics of chip(object)13:38
* ikey blinks at the zyga-solus 13:40
zyga-soluso/13:42
zyga-solusikey: I picked up one of your branches13:42
zyga-solusikey: I pushed a new one up with conflict fixes, I'll do one more tweak to it and let's land it13:42
ikeyoh thanks bud13:42
ikeyive been hammered with this gnome work the last few days -_-13:42
ikey(3.26 stack update + systemd + llvm + ....)13:43
zyga-solusikey: thank you for putting it up, I'll try to land the other branches soon too13:43
ikeyyou are too good. ^_^13:43
zyga-solusdoes anyone know when v2 cgroups will be around?13:46
zyga-solusjdstrand, tyhicks ^ you maybe?13:46
cachioniemeyer, I saw this error: 2017-10-09 13:08:29 Discarding linode:ubuntu-14.04-64 (Spread-78), cannot connect: cannot connect to linode:ubuntu-14.04-64 (Spread-78): ssh: handshake failed: ssh: unable to authenticate, attempted methods [none password], no supported methods remain13:51
cachioniemeyer, https://travis-ci.org/snapcore/spread-cron/builds/28535522313:51
cachioI'll check if there are more like this13:52
cachioSon_Goku, hey, I saw some test errors setting up fedora13:54
cachio++ dnf -q -y --refresh install expect13:54
cachioError: Failed to synchronize cache for repo 'updates'13:54
Son_Gokulinode *grumbles*13:54
cachioSon_Goku, any idea what could be causing that?13:54
Son_GokuI think Linode has a registered mirror for their IP block with Fedora MirrorManager13:55
Son_Gokuso all requests to the metalink and mirrorlist return Linode's mirror13:55
Son_Gokubut when it's mid metadata sync, the repomd.xml file doesn't exist, so that happens13:55
zyga-solus ahh13:56
cachioSon_Goku, ah, ok, any workaroud at least to manage that error?13:56
zyga-solusSon_Goku: nice work13:56
Son_Gokucachio: force a different mirror or try again later?13:57
Son_Gokureally, someone needs to talk to Linode about how they rsync from tier 1 mirrors13:57
Son_Gokuthey probably are using the wrong rsync options to keep things sane during update13:58
zyga-solusSon_Goku: can you jump into #linode and ask them, all the linode staff seems to be lurking there13:58
zyga-solusSon_Goku: and I think you are the best qualified to explain how to do that properly13:59
Son_GokuI guess13:59
cachioSon_Goku, agree13:59
cachiowith zyga13:59
__chip__cachio: are you ok with https://github.com/snapcore/snapd/pull/3951/commits/a803b5a0af7f86e461f2a5d21c0b9d4aa0935511 ?14:15
mupPR #3951:  snap: add new `snap pack` and use in tests  <Created by mvo5> <https://github.com/snapcore/snapd/pull/3951>14:15
cachio__chip__, checking14:15
cachio__chip__, yes, lgtm14:16
__chip__ok, i'll merge when green then14:17
mupPR snapd#4011 closed: cmd: correctly name the "Ubuntu" and "Arch" NVIDIA methods <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4011>14:17
mupPR snapd#3978 closed: cmd: Correctly name the "Ubuntu" and "Arch" NVIDIA methods <Created by ikeydoherty> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3978>14:18
mupPR snapd#4014 opened: packaging: update nvidia configure options <Created by zyga> <https://github.com/snapcore/snapd/pull/4014>14:20
wdouglasshmmm..ok so it looks like the fcblanks thing is a red herring. i'm getting a segfault somewhere in TCL14:43
zyga-soluswdouglass: you probably are missing fonts, core has no fonts14:47
wdouglassthat make sense, thanks14:47
zyga-soluswdouglass: it's a work in progress from our end, for now you can use one of the workarounds people use that inject fonts and some fontconfig env variables14:47
ogra_use the desktop launcher and the snapcraft desktop part14:47
ogra_alternatively here is an example with a wrapper script https://github.com/ogra1/jtiledownloader (make sure to have something in your stage-packages that pulls in fontconfig and some fonts ... i.e. a theme package)14:49
wdouglassso i just stage-package a theme and it should work. Cool! trying this now.14:50
ogra_well, you need the env variables the wrapper sets as well14:50
zyga-soluswdouglass: i don't know - I suspect you need a bit more but I really don't know14:50
wdouglassogra_: alright cool, i'm already using a wrapper for tcl (meantioned above) so i'll just add more variables there14:50
ogra_right, even though jtiledownloader is java, the font stuff should work for tcl too14:51
wdouglassok, so that got rid of my fcblanks problem, but i'm still getting a segfault as soon as I create my first Tk widget14:55
wdouglassoh wait, i may have missed a variable...14:55
zyga-solus__chip__: let's land this one please https://github.com/snapcore/snapd/pull/401414:57
mupPR #4014: packaging: update nvidia configure options <Created by zyga> <https://github.com/snapcore/snapd/pull/4014>14:57
__chip__zyga-solus: this is the other half of the previous one?14:57
wdouglassit works! thanks so much guys!14:58
__chip__wdouglass: huzzah!14:58
zyga-solusyep14:59
elopiogood morning15:03
__chip__hah, i approved twice15:06
__chip__not that it's a day i'm easily distracted or anything15:06
elopioclobrano: hello! The unit tests use a fake server with hardcoded replies.15:07
c-lobranoelopio: hi! Yes, I saw it. I'd like to have a double check, before changing this test15:07
elopioc-lobrano: https://github.com/snapcore/snapcraft/blob/master/snapcraft/tests/fake_servers/api.py#L382 That line is wrong. We should put the message in a list.15:12
elopiothat's why we are not very happy with the fake servers.15:12
c-lobrano:)15:12
c-lobranoelopio: is that just a list or a list of dictionaries?15:12
c-lobranoelopio: the format seems to be {"name": ["reason"]}15:13
c-lobranoI meant, errors :[ {"name": ["reason"]}] (quite complicated)15:14
elopioyeah, a list of dictionaries, with the field as the key, and a list of strings as the value.15:14
elopiolet me try to release to an invalid channel, to get the exact reply from the store.15:15
c-lobranoook, so I could expect more that one "reason" per key?15:15
c-lobranoalright, thanks a lot15:15
elopioc-lobrano: ahh, this one is different: {'success': False, 'errors': 'Track does not exist: invalid', 'error_list': [{'code': 'invalid-field', 'message': 'Track does not exist: invalid'}]}15:17
elopiolet me now try to release to not a number and see if it's the same.15:18
elopioc-lobrano: {'success': False, 'error_list': [{'code': 'invalid-field', 'message': "The 'revision' field must be an integer"}], 'errors': {'revision': ['This field must be an integer.']}}15:19
c-lobranoelopio: uhm, ok. The problem is that StoreReleaseError is at the edge of "too complex" :D15:28
c-lobranoelopio: I need to find a simple solution15:28
c-lobranoerror_list is actually quite nice15:29
jdstrandzyga-solus: note we are both sprinting (cc tyhicks), but my understanding is that practically speaking, v2 cgroups won't be around by default until the issues surrounding them not being able to be used at the same time are resolved15:40
jdstrand(same time as v1)15:40
ikeyso then does snapd mandate legacy cgroup hierarchy in systemd?15:41
jdstrandiirc, there were a lot of discussions about how to make that happen, but no concrete plan that people are working on. stgraber would also be able to orrect me15:41
jdstrandikey: I think that what we would want to support is that when systems are using only v2 cgroups, snappy shuld be able to detect that nand use them15:42
ikeyyea15:42
ikeygood job my systemd is set to legacy then i guess xD15:42
jdstrandmy point was that I don't really know when a system can reasonably be v215:42
* ikey encountered that issue in the past with docker already15:42
jdstrandthere are a lot of technical challenges with mixing the two that need to be reasonably resolved15:43
zyga-solusjdstrand: thank you for the note15:45
zyga-solusjdstrand: I'm making progress, I think we are in a good position15:45
mupPR snapd#3951 closed:  snap: add new `snap pack` and use in tests  <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3951>15:46
__chip__zyga-solus: what's missing for snapd#3958?15:47
mupPR #3958: many: add support for /home on NFS <Created by zyga> <https://github.com/snapcore/snapd/pull/3958>15:47
zyga-solus__chip__: niemeyer asked for a wait for review15:47
zyga-solusI'm happy as is15:47
elopioc-lobrano: you can split the big function in subfunctions. There can be one like _get_text_for_store_release_errors_401_and_403.15:54
c-lobranoelopio: right, that would be a good idea15:55
c-lobranoelopio: but with error_list I should be able to format a nice message passing only the dictionary15:55
c-lobranoand runtest.sh isn't complaining so far :)15:55
mupPR snapd#4014 closed: packaging: update nvidia configure options <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4014>17:37
__chip__zyga-solus: i suspect master is broken (but it might be just this PR)17:37
__chip__let me push this out and check master before frightening you, better17:37
__chip__zyga-solus: phew. looks like just this PR. sorry for the scare.17:38
__chip__in my defense it's not _my_ pr :-)17:39
zyga-solus__chip__: ouch, is that my doing?17:51
zyga-solus__chip__: let me see how I can help17:51
__chip__zyga-solus: no, it's mvo's doing, in mvo's branch17:51
zyga-solus__chip__: which branch is that?17:51
__chip__zyga-solus: master is fine17:51
zyga-solusah, uff17:51
zyga-solusgood17:51
zyga-solusI'm deep in systemd and cgroups17:51
__chip__zyga-solus: https://github.com/snapcore/snapd/pull/3995/commits/d1dab9d03903efa3d10e39d3d0ce44683ebf23fa17:51
mupPR #3995: snap: support "command: foo $ENV_STRING" <Created by mvo5> <https://github.com/snapcore/snapd/pull/3995>17:51
zyga-solusgoing from "aha, eureka" to "darn s***"17:51
zyga-solusand back17:51
zyga-solushmm17:52
zyga-solusdidn't I like push to that branch?17:52
__chip__zyga-solus: systemd <4-dimensional emoji that turns mazlow's pyramid on end and breaks several international conventions on human rights> cgroups ?17:52
__chip__zyga-solus: github says no17:53
zyga-solus__chip__: I just feel it's a bit complex and not working17:53
zyga-solus__chip__: odd17:53
zyga-solusah that was https://github.com/snapcore/snapd/pull/400617:54
mupPR #4006:  snap-exec: update tests to follow main_test pattern  <Created by mvo5> <https://github.com/snapcore/snapd/pull/4006>17:54
zyga-solusI just found this odd because I also made a chmod +x patch17:54
__chip__heh17:55
__chip__zyga-solus: i didn't --force, promise17:55
zyga-solus"""17:55
zyga-soluscgroup empty notification is seriously broken unfortunately in the17:55
zyga-soluskernel the way it is currently implemented. And we'll miss the17:55
zyga-soluscallouts in a number of cases (for example, if somebody has any dir in17:55
zyga-solusa cgroup still we get no events for it. It's also not available at all17:55
zyga-solusinside of containers, since the callouts take place on the main pid17:55
zyga-solusnamespace, and nowhere else)."""17:55
zyga-solus^- I should get a drnk17:55
zyga-solus*drink17:55
__chip__drnk snds rght17:55
ogra_jdstrand, zyga-solus ... http://paste.ubuntu.com/25708869/ note that i uninstalled the ubports-instller snap before i plugged in the SD card reader in that log18:05
ogra_this mess goes on and on ...18:05
ogra_looks like uninstalling the snap left some udev stuff around18:06
zyga-solusogra_: looking18:08
zyga-solusogra_: is pid 29417 still alive?18:09
ogra_ogra@styx:~/Devel/model-creator$ ps ax|grep 2941718:09
ogra_ 9179 pts/5    S+     0:00 grep --color=auto 2941718:09
ogra_nope18:09
zyga-solusthe comm name is interesting18:09
zyga-solusogra_: are you still seeing those messages18:10
ogra_yes, every time i plug or remove the SD card reader18:10
zyga-solusogra_: interesting18:11
zyga-solusjdstrand: I'm lost, it looks like a bug18:12
ogra_it definitely does18:14
ogra_note the snap uses devmode by default https://github.com/ubports/ubports-installer/blob/master/snapcraft/snapcraft.yaml18:15
ogra_(though that should be obviousl from the "ALLOWED" messages)18:16
zyga-solusright, I'm trying to see what's going on here18:16
* zyga-solus puts this laptop back on the charger and gets to do something on the othe rone18:20
mupPR snapcraft#1596 closed: tests: move ruby demo test to snapd integration suite <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1596>18:41
mupPR snapcraft#1348 closed: repo: setup a foreign arch and sources <Created by kalikiana> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1348>18:50
mupPR snapcraft#1382 closed: rust plugin: make libc configurable <Created by kalikiana> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1382>18:50
mupPR snapcraft#1387 closed: [WIP] tests: reenable the cleanbuild integration test <Created by elopio> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1387>18:50
=== lamont` is now known as lamont
=== JanC_ is now known as JanC
mwhudson__chip__: two oldest?? hah20:05
mwhudsoni guess i'm glad random contributors from outside the company have a better time20:06
=== JoshStrobl|Work is now known as JoshStrobl
mupPR snapd#3995 closed: snap: support "command: foo $ENV_STRING" <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3995>20:51
=== ahasenack is now known as andreas
__chip__facubatista: o/23:47

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